I finished my slack status sync api.

Currently I have made a basic HTML site with google built into the tab which you can use for searches. It features the same styling as my OS and can also be launched from my OS. Additionally it has a motivational quote API that changes the quote every hour. In the future I may add new quotes by a button.

I pinpointed the issue with the spotify login not working, turns out i need premium, and need a backend, so ill probably work on that later.

Development Log — 02‑07‑2026

Overview

Today’s development session focused on refining the project foundation and establishing a stronger systems engineering baseline for the ASTRA Autonomous Flight System (AAFS).

---

Completed

• Completed the Project Administration documentation (EN‑0001 through EN‑0013).
• Refined the overall project scope and engineering objectives.
• Removed autonomous powered landing from the baseline project architecture.
• Updated EN‑0001 – Project Initialization to reflect the revised project vision.
• Updated EN‑0002 – Development Roadmap to align with the new project scope.
• Established a formal document revision workflow using Semantic Versioning.
• Finalized engineering notebook standards, document templates, and repository organization.

---

Engineering Decisions

Scope Revision

The autonomous powered landing objective has been removed from the baseline ASTRA roadmap.

The project will instead focus on:

• Autonomous Guidance
• Navigation
• Flight Stabilization
• Telemetry
• Ground Control Systems
• State Estimation
• Recovery System Deployment
• Mission Analysis

This decision reduces overall project complexity while allowing greater emphasis on developing a robust and modular flight computer platform.

---

Current Status

Project Phase: Program Foundation
Overall Progress: Administrative Foundation Complete

The engineering framework is now established, allowing development to transition into formal Systems Engineering activities.

---

Next Steps

• Begin SYS‑001 – Mission Requirements
• Define mission objectives and operational concept
• Develop stakeholder requirements
• Establish functional requirements
• Build the initial system architecture

---

Notes

The project now has a complete administrative framework, including documentation standards, repository standards, requirements traceability, configuration management, verification and validation strategy, and systems engineering management planning.

Future development will focus on transforming mission objectives into traceable engineering requirements.

---

Ad Astra Per Artem

EN‑0004 – Documentation Standards

Document Number: EN‑0004
Title: Documentation Standards
Author: Pathan
Created: 30‑06‑2026
Last Modified: 30‑06‑2026
Revision: 0.1.0
Status: Draft
Subsystem: Project Administration
Related Documents:

• EN‑0001
• EN‑0003

---

1. Purpose

This document defines the documentation standards used throughout the ASTRA Autonomous Flight System (AAFS).
The objective is to ensure all engineering records are clear, consistent, traceable, and maintainable throughout the project’s lifetime.

---

2. Documentation Philosophy

Documentation is a primary engineering deliverable.
Every major engineering decision, requirement, calculation, trade study, simulation, implementation, and test shall be documented.
Engineering documentation shall accurately reflect the current state of the project.

---

3. Standard Document Format

Unless otherwise required, engineering notebook documents should follow the standard ASTRA document template.

Each document shall include:

• Document Number
• Title
• Author
• Created
• Last Modified
• Revision
• Status
• Subsystem
• Related Documents

---

4. Writing Standards

Documentation shall:

• Be technically accurate.
• Be concise and objective.
• Use consistent terminology.
• Define acronyms on first use.
• Avoid ambiguous language.
• Use proper grammar and spelling.

Opinions shall be supported by engineering reasoning whenever possible.

---

5. Engineering Content

Engineering documents should record:

• Design intent
• Requirements
• Assumptions
• Constraints
• Design decisions
• Interfaces
• Mathematical analysis
• Test procedures
• Results
• Conclusions

The level of detail shall be appropriate for the document type.

---

6. Figures, Tables, and Diagrams

Figures and diagrams should:

• Have descriptive titles.
• Be referenced within the document.
• Support the engineering discussion.

Block diagrams, system architectures, flowcharts, and mathematical models should be included whenever they improve understanding.

---

7. Revision Control

Every revision shall:

• Update the revision number.
• Update the Last Modified field.
• Describe the changes in the Revision History section.

Major engineering changes should be documented through new notebook entries when appropriate.

---

8. Traceability

Documents should reference related notebook entries, requirements, software modules, simulations, and test reports whenever applicable.
Engineering decisions should remain traceable throughout the project lifecycle.

---

9. Revision History

Revision Date Description 0.1.0 30‑06‑2026 Initial document.

---

Ad Astra Per Artem

EN‑0003 – Repository Standards

Document Number: EN‑0003
Title: Repository Standards
Author: Aamir Khan Pathan
Created: 30‑06‑2026
Last Modified: 30‑06‑2026
Revision: 0.1.0
Status: Draft
Subsystem: Project Administration
Related Documents:

• EN‑0001
• EN‑0002
• EN‑0004

---

1. Purpose

This document establishes the standards governing the structure, organization, and maintenance of the ASTRA Autonomous Flight System (AAFS) repository. These standards ensure consistency, traceability, maintainability, and scalability throughout the project’s lifecycle.

---

2. Repository Organization

The ASTRA repository shall be organized by engineering discipline.

Top‑level Directories include:

• Engineering Notebook
• firmware
• ground
• simulation
• hardware
• analysis
• missions
• data
• assets
• docs
• tools
• tests
• .github

Each directory shall contain only files relevant to its designated purpose.

---

3. Directory Standards

• Each directory shall contain a README.md file describing its purpose when practical.
• Directory names shall remain consistent throughout the project.
• New top‑level directories shall only be created when a clear engineering need exists.
• Duplicate directory structures should be avoided.

---

4. File Naming Standards

Engineering notebook documents shall follow the format:
EN‑0001_Project_initialization.md

Subsystem documents shall follow the format:
SYS‑001_Mission_Requirements.md
SW‑001_Software_Architecture.md
MECH‑001_Airframe.md
ELEC‑001_Power_System.md

For full breakdown of prefixes refer to [Astra/Document Templates And Breakdowns/Prefix_Definitions.md](url)

File names shall:

• Use descriptive names.
• Preserve document identifiers.
• Use underscores instead of spaces.
• Use the .md extension unless another format is required.

---

5. Branch Strategy

Development shall use the following branches:

• main
• develop
• feature/*
• release/*
• hotfix/*

The main branch shall always represent the latest stable revision.

---

6. Commit Standards

Commits shall represent a single logical change.

Commit messages should follow the format:

docs(EN‑0003): update repository standards  
feat(nav): implement sensor fusion  
fix(control): resolve PID oscillation  
hardware(pcb): revise flight computer layout

Just finished my calendar app and added Google as well, finished some style bugs as well.

Finished The Scripting Added Some Apps and i also finished styling. Just debugging and im gonna add an interactable calendar I also have to move the icons from teh taskbar to the main screen.

Just got the HTML done on this gonna work on the CSS next.

EN‑0002 — Development Roadmap

Document Number: EN‑0002
Title: Development Roadmap
Author: Aamir Khan Pathan
Created: 2026‑06‑29
Revision: 0.1
Status: Draft
Subsystem: Project Administration
Related Documents: EN‑0001, ROADMAP.md

---

1. Purpose

The purpose of this document is to establish the planned development strategy for the ASTRA Autonomous Flight System.

This roadmap defines the engineering phases, major milestones, dependencies, expected deliverables, and success criteria that will guide development throughout the project lifecycle.

This document serves as the baseline planning document for the ASTRA program and may evolve as new requirements, technical discoveries, and project priorities emerge.

---

2. Development Philosophy

ASTRA follows an iterative systems engineering approach.

Each subsystem progresses through the following lifecycle:

Concept
Requirements
Research
Trade Study
Architecture
Design
Implementation
Simulation
Testing
Verification
Validation
Integration
RevisionCode

3. Program Phases

Phase 0 — Program Foundation

Status: Complete

Objectives

• Repository
• Documentation
• Engineering Notebook
• Version Control

Deliverables

• GitHub Repository
• README
• Documentation Standards
• Engineering Notebook

---

Phase I — Systems Engineering

Objectives

• Mission Requirements
• Functional Requirements
• Architecture
• Interfaces
• Risk Assessment

Success Criteria

• Complete engineering baseline documentation.

---

Phase II — Simulation

Objectives

• Digital Twin
• Flight Dynamics
• Wind Models
• Sensor Simulation
• Guidance Testing

Deliverable

• Simulation capable of validating flight software.

---

Phase III — Flight Software

Objectives

• Navigation
• Guidance
• Control
• Recovery
• Telemetry
• Logging

---

Phase IV — Ground Control

Objectives

• Mission Planner
• Dashboard
• Telemetry
• Flight Replay
• Configuration
• Diagnostics

---

Phase V — Hardware

Objectives

• Flight Computer
• Power
• Sensors
• PCB
• Mechanical Integration
• Bench Testing

---

Phase VI — Integration

Objectives

• Hardware Integration
• Software Integration
• Communication
• Subsystem Validation

---

Phase VII — Flight Testing

Objectives

• Ground Tests
• Static Tests
• Flight Tests
• Mission Reports
• Lessons Learned

---

4. Engineering Workflow

Every feature follows the workflow:

Research
Notebook Entry
Requirements
Design
Trade Study
Simulation
Implementation
Testing
Documentation Update
MergeCode

5. Milestones

1. Repository Established
2. Engineering Notebook Complete
3. Systems Engineering Baseline
4. Simulation Operational
5. Ground Station Operational
6. Flight Software Prototype
7. Hardware Prototype
8. Integrated System
9. First Successful Flight
10. Controlled Recovery

---

6. Exit Criteria

Each phase should have a clear definition of “done.”

Example — Phase II Exit Criteria

• Flight dynamics validated
• Sensor models complete
• Simulation produces repeatable results
• Documentation approved

---

7. Risks

Major risks (high‑level only):

• Software complexity
• Sensor reliability
• Hardware failures
• Power limitations
• Communication failures
• Schedule growth

---

8. Revision History

Revision Description 0.1 Initial document

EN-0001 - Project Initialization

Document Number: EN-0001
Title: Project Initialization
Author: Aamir Khan Pathan
Date Created: 29-06-2026
Revision: 0.1.0
Status: Draft
Subsystem: Project Administration

---

Purpose

This document formally establishes the ASTRA Autonomous Flight System (AAFS) project and defines its initial engineering vision, objectives, scope, and development philosophy.

This entry serves as the foundation of the engineering notebook and provides the baseline from which all future technical decisions, requirements, and design work will evolve.

---

Project Name

ASTRA Autonomous Flight System
AAFS

---

Vision

ASTRA is intended to become a modular autonomous flight platform capable of collecting telemetry, estimating vehicle state, executing autonomous guidance algorithms and corrections, and supporting progressively advanced recovery capabilities.

The project is designed as a long-term engineering initiative focused on learning and applying principles from:

• Aerospace Engineering
• Systems Engineering
• Embedded Systems
• Flight Software
• Electronics
• Control Theory
• Navigation
• Software Engineering

The emphasis is placed on designing every subsystem as an independent module while maintaining full system integration through well-defined interfaces.

---

Primary Objectives

The initial goals of ASTRA are:

• Develop a complete systems engineering workflow.
• Design a modular avionics architecture.
• Build a scalable flight software framework.
• Develop a desktop Ground Control Station.
• Create a complete engineering notebook documenting every design decision.
• Validate all major subsystems through simulation before hardware implementation.
• Support future autonomous navigation and controlled recovery.

---

Engineering Philosophy

ASTRA follows several core principles:

1. Safety before capability.
2. Documentation before implementation.
3. Simulation before hardware.
4. Modularity over complexity.
5. Verification before validation.
6. Continuous improvement.

Every engineering decision should and shall be justified through analysis, testing, or documented trade studies.

---

Long-Term Development Phases

Phase I

• Project Planning
• Repository
• Documentation
• Architecture
• Simulation

Phase II

• Avionics
• Flight Computer
• Telemetry
• Ground Station

Phase III

• Navigation
• Sensor Fusion
• Guidance
• Flight Control
• Recovery

Phase IV

• Integrated Testing
• Hardware
• Simulation
• Flight Testing
• Mission Operations

---

Success Criteria

The ASTRA project will be considered successful if it achieves:

• Comprehensive engineering documentation.
• Modular subsystem architecture.
• Repeatable verification procedures.
• Reliable software architecture.
• Successful integrated subsystem operation.
• Continuous engineering improvement through iterative development.

---

Notes

This engineering notebook shall record every major engineering decision, design revision, analysis, simulation, trade study, and test result produced throughout the ASTRA project lifecycle.

Each notebook entry should provide sufficient technical detail to allow another engineer to understand the reasoning behind the decisions made.

---

Ad Astra Per Artem

I rewrote the README, and some styling to make it more of my style, and align it with the styles of one of my other non open source apps.

Finally figured out how to add my image instead of that floating orange box.

I just finished my personal portfolio just some image placeholders to replace right now.

Changelog - AeroStrike

All notable changes to this project will be documented in this file.

[1.2.0] - 2026-06-15

Added

• Scoring System: Implemented a comprehensive scoring system.
  • +500 points for destroying enemy jets.
  • +2000 points for sinking the enemy cruiser.
  • +100 bonus points for every flare burst conserved at the end of a mission.
• HUD Updates: Added a real-time score display to the top-left HUD.
• End Screens: Victory and Game Over screens now display the final score.
• Disorientation Mechanics:
  • Player: Rapid high-G turns (7 direction changes) now cause a 5-second stall and fire lockout with a “DISORIENTED” HUD warning.
  • Missiles: Incoming missiles can now be disoriented by 4 sharp evasion turns when in close proximity, causing them to lose their lock.

Changed

• Enemy Missile Visuals: Enemy missiles (from both jets and the cruiser) now match the geometry of friendly missiles but are colored red (0xff3333) for clear identification.
• Combat Balance:
  • Enemy jets and the cruiser now have a 10-second cooldown between homing missile launches.
  • Friendly carrier defense missiles now deal 0 damage but continue to track and explode on targets for visual atmosphere.
• Camera System: Refined the follow-camera to be closer and more dynamic, improving visibility and the sense of speed.
• Enemy AI: Fixed a bug where enemy aircraft were stationary; they now correctly patrol and engage in dogfights.

Fixed

• Enemy Jet Orientation: Corrected the nose orientation of enemy jets so they face forward during flight.
• Spawn Logic: Adjusted enemy spawn distances and visibility for better engagement flow.
• Carrier Defense: Restored the carrier’s missile launch logic after it was temporarily removed.

---

[1.1.0] - 2026-06-15

Added

• Flare System: Added a flare limit of 10 bursts per sortie.
• HUD Counter: Added a “FLARES” counter to the status panel.
• Refill Logic: Landing on the carrier now fully replenishes flares along with health and missiles.

Fixed

• Enemy Missile Geometry: Updated enemy projectiles to use proper 3D missile models instead of simple spheres.

Devlog – Major Update to AeroStrike
Hey everyone!
I just pushed a big update to AeroStrike, and I wanted to share what’s new, what I fixed, and what I learned while improving the project.

✨ What’s New
• New Enemy Jets + AI
I added simple enemy fighters that chase the player, turn toward you, and fire homing missiles.
This helped me learn more about vector math, direction interpolation, and basic pursuit behavior.

• Homing Missiles
Enemy missiles now track the player smoothly instead of flying straight.
They steer using direction lerping and have a warning indicator when they get close.

• Flares (Countermeasures)
You can now deploy flares to distract incoming missiles.
Missiles will retarget flares if they get close enough.

• Carrier HP + Bomb Damage
The enemy cruiser now has a proper health system.
Bombs deal damage, and the cruiser sinks when its HP reaches zero.

• Radar System
I added a 2D radar that shows:

Enemy jets

The enemy cruiser

This taught me how to convert world coordinates into UI positions.

• Landing + Rearming
You can land on the carrier to repair and restock bombs.
This added a fun gameplay loop and made the mission feel more complete.

🎮 Controls Fixes
The Up/Down pitch controls were broken before — they now work properly.
Pitching feels smoother and more responsive.

🎨 CSS Overhaul
I completely reworked the UI styling:

Cleaner HUD

Minimal, modern look

Consistent color theme

Better spacing and readability

Subtle glow effects for a “fighter jet” feel

This makes the game look more polished and easier to read during gameplay.