02 - Cockpit Manager / Session Launcher

Later phase, following task 203's read-only preflight, corrected broker readiness (206), appropriate aircraft catalogue/mapping qualification and usable readiness contracts for the selected components. Use msfs_da62 and xp12_phenom300 profile metadata to start or reuse selected components in dependency order, observe real readiness and stop only processes owned by the session. Preserve current pre-MSFS FreeTrack requirements and embedded Sim Agent; prevent duplicate brokers and Sim Agent instances. Do not enable new automatic RadioBridge, WingRally or Instructor starts while their required readiness evidence is missing. Coordinate their contracts with component owners; keep all radio/audio/device logic in RadioBridge. Acceptance: supported profiles progress through explicit waiting/ready/failure states; required failures block false-ready; optional failures identify degraded functions; unqualified XP12/Phenom remains blocked. Combine with mobile control task 204 and flight preparation task 205 without treating a read-only preflight as completed orchestration. Live acceptance remains task 212. WingRally target selection and eligibility Knowledge items 113, 118 and 119 define the source/deployment limits and handoff boundary. Keep one chosen simulator profile authoritative across components, especially with two running sims. Dispatch only when the selected target and route source are supported by installed versions. SimBrief remains optional in the target design; current XP original-.fms gating must be removed for qualified native routes once that exporter exists. Do not collapse transfer acknowledgement, avionics activation and cockpit-ready into one success flag.

Depends on session profiles and the flight-loading contract. Provide manual airport plus runway/ramp selection and the supported WingRally waiting/loading path. Inspect available departure data and simulator APIs; do not invent support for airport/parking lists. Load the aircraft/location/route, wait for readiness, then apply and verify an aircraft-specific cold-and-dark procedure. Acceptance: implement and exercise DA62/MSFS and Phenom/XP12 separately; reconcile temporary cockpit power, pop-outs and physical switch states so they do not silently undo preparation; report incomplete preparation honestly. The user requested cold and dark. An optional ready-for-departure runway mode remains a proposal. New incoming routes must not reset active flights without an intentional new-session action. WingRally completion contract Use knowledge item 119. Track transfer acknowledgement, actual avionics route activation and complete cockpit preparation separately. A bridge acknowledgement cannot establish a valid active route, correct parking/runway position or cold-and-dark state. Expose unknown/manual-verification requirements where the selected avionics cannot be observed. Accept WingRally-native routes and optional SimBrief imports according to implemented capabilities; never impose SimBrief on all target XP12 sessions. The current imported-.fms restriction is temporary for the present XP bridge path. Scope simulator target explicitly and preserve active-flight protection.

Build a responsive local-network interface backed by the manager on the simulator PC, using the existing code architecture where appropriate. Support profile selection, selected optional tools, start/stop, preparation progress, component status and useful logs. Allow the user to switch to WingRally on the same phone while preparation continues. Acceptance: usable on the Samsung tablet and phone; closing/reopening the browser preserves session state; repeated clicks do not start duplicate sessions; process-running and cockpit-ready states are distinct. Assume the PC is already on. Framework choice follows code investigation.

First implementation step after checkpointing the relevant working trees. Use the existing .NET 8 Session Launcher; no broad rewrite. Read static audit knowledge item 117. Implement configuration-driven profiles msfs_da62 and xp12_phenom300. Per component include required/optional, configured host, start command, readiness method and dependencies. In this phase start commands are metadata only: the new preflight layer must not launch, stop or relocate processes. Expose separate evidence for supported/unsupported/unqualified, running, reachable, simulator connected, functionally ready and unknown. A running process or reachable endpoint does not prove readiness. Read existing Launcher/Sim Agent health and broker session status with their documented limitations; missing bridge contracts remain unknown. For XP12, report/reject a broker not on the simulator PC. Block the integrated XP12/Phenom profile with a clear explanation until the Phenom catalogue/mappings are proven. Do not silently move a broker or launch a duplicate. Acceptance: both profile definitions load; preflight gives actionable reasons; broker catalogue-ready cannot become cockpit-ready; identical connected/total counters cannot prove all expected nodes are present. Missing health contracts and unqualified adapters remain visible. Preserve the current working startup workflow. Add no new automatic RadioBridge, WingRally or Instructor starts. Clarify the active FreeTrack/vJoy path from code/configuration, including whether vJoy is legacy, optional or actively required; record evidence rather than assuming a dependency. Automatic lifecycle orchestration follows in a separate task after readiness contracts and profile qualification. WingRally capability refinement (knowledge items 113, 118, 119) Expose route-source eligibility for the installed bridge/plugin and selected simulator. Current XP handoff requires an imported SimBrief briefing's original .fms; native WingRally export is planned so SimBrief must not become a permanent requirement. WingRally source 0.4 capability is not proof of the last inspected deployed 0.3 runtime. Enforce one explicit simulator target without silently following conflicting autodetection, including when two sims are running. This phase still only observes and rejects, not dispatches or starts processes.