Doel: maak in de bestaande Cockpit Manager/Session Launcher één vluchtvoorbereidingsoverzicht voor BeyondATC + DA62 + X-Plane 12, later bruikbaar voor DA62/MSFS en Phenom. Sluit aan op WingRally, zonder SimBrief als verplichte bron voor alle vluchten te maken. Functionele eisen: - Haal op expliciete gebruikersactie of bij openen van de preflight het meest recent gegenereerde SimBrief OFP op via een gedocumenteerde, op dat moment ondersteunde gebruikers-API/JSON-feed; geen onnodig periodiek pollen. Pilot ID/accountinstellingen lokaal/configureerbaar; geen persoons- of accountnummers of tokens in publieke Buildory-kennis, logs of broncode. - Toon met bron en gegenereerd-tijdstip: vertrek/bestemming, vliegtuig/type, callsign, IFR/VFR waar beschikbaar, route, SID/STAR indien aanwezig, cruisehoogte en route-/AIRAC-informatie indien beschikbaar. Maak stale/verkeerd type/verkeerde simulator/onbereikbare bron expliciet; nooit suggereren dat SimBrief een echte 'actieve vlucht' aanduidt. Het laatste OFP is slechts een kandidaat. - Laat de gebruiker dit OFP expliciet als sessievluchtplan bevestigen, vernieuwen of afwijzen. Bij ontbrekend OFP moet de launcher werkbaar blijven met handmatige bestemming of WingRally-route, conform bestaande contracten. - Modelleer per sessie vluchtplanbron, gegenereerd-tijdstip, sessiebevestiging en route-identiteit, zodanig dat BATC Fly!-bediening pas na bevestiging mag proberen en niet ongemerkt een later SimBrief-plan adopteert. Controleer de daadwerkelijke import of synchronisatie in BATC apart; 'OFP getoond' is niet hetzelfde als 'door BATC geladen'. - Stem af met WingRally: geïmporteerde SimBrief-route vs native WingRally-route zijn apart, behoud .fms-provenance voor bestaande XP-brug waar relevant, en ga niet uit van automatische G1000-lading. Rapporteer ontvangst/routeoverdracht, activatie in avionics en cockpit-ready als afzonderlijke stappen; verschil met geladen DA62-route waar meetbaar zichtbaar maken. - Eerst tests voor X-Plane 12/Aerobask DA62/BATC; daarna MSFS 2024/DA62; andere aircraft later. Test verouderd plan, dubbel klikken, later nieuw OFP, SimBrief offline, mislukte BATC-import en actief vliegende sessie. Geen automatische reset van actieve vlucht. Afhankelijkheden: Cockpit Platform #205 (flight load/cold dark), #217 (orchestration), #209 (WingRally lifecycle), #220 (Navigraph/SimBrief v1/v2), kennisitems #118/#119. Geen bestaande werkende SimBrief API-client of BATC-integratie als feit aannemen voordat code/run gevalideerd is.
.png)
02 - Cockpit Manager / Session Launcher
Evolve the existing launcher into the central session controller with mobile/tablet access, simulator profiles, embedded Sim Agent and FreeTrack coordination.
Doel: breid de bestaande Cockpit Manager/Session Launcher uit zodat de gebruiker bij sessiestart ATC=None, BeyondATC of SayIntentions kiest; focus eerst op BeyondATC + Aerobask DA62 + X-Plane 12, daarna DA62 + MSFS 2024. Codex werkt reeds aan de ATC-keuze en processtart; inspecteer bestaande wijzigingen voordat nieuwe code wordt gebouwd en voorkom duplicatie. Functionele eisen: - Bij keuze None: niets starten of ongevraagd afsluiten. Bij keuze BATC/SI: bestaand passend proces detecteren en hergebruiken; anders gekozen programma starten. Bij conflicterend actief ATC-programma waarschuwen en geen tweede ATC automatisch starten. Geen processen van de gebruiker onverwacht stoppen. - Toon onderscheiden toestanden not_running, running, main_menu, connecting, connected/flight_active en unknown, alleen als daarvoor aantoonbare signalen bestaan. Proces-running is geen bewijs van simulatorverbinding of een actieve vlucht. - Onderzoek of de Fly!-actie in BeyondATC (getoond in v1.11.0 Experimental) via ondersteunde integratie of betrouwbare Windows UI Automation kan worden geactiveerd. Geen officiële BATC-API of automatiseerbare knop veronderstellen. Voor ontbrekende betrouwbare detectie handmatige bediening tonen, nooit blind schermcoördinaten klikken. - Fly! uitsluitend activeren na expliciete gebruikerskeuze/bevestiging van het actuele sessievluchtplan en wanneer de geselecteerde simulator/DA62 aantoonbaar gereed is. Herhaalde startacties mogen geen dubbele sessie of herhaald Fly! veroorzaken; bewaak lopende verbinding/flight. - Scheid ATC-procesbeheer, ATC-simulatorverbinding, Flight Preflight en cockpit_ready; onbekende status blijft unknown/degraded. Integreer in bestaande .NET-launcher zonder herontwerp en behoud huidige FreeTrack, broker/Sim Agent en node-opstartafspraken. - Voorkom dat BATC en SayIntentions gelijktijdig verkeersinjectie of ATC afhandelen. Test op simulator-PC Windows met eerst XP12/DA62, daarna MSFS2024/DA62. Geen live resultaat aannemen tot geobserveerd. Afhankelijkheden/verwijzingen: Cockpit Platform taak #217 (session orchestration), #203 (bestaande preflight-basis, afgerond), nieuwe SimBrief Flight Preflight-taak; convertible cockpit-project besluit #232 heeft BeyondATC als primaire ATC gekozen. Status uitvoering niet bevestigd.
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.
Build Log
1 entryImplemented read-only session profiles and preflight
Implemented task 203 in Broker/Launcher commit 3b70d2a and updated the shared contract in cockpit orchestration commit 5c16568. Launcher 0.0.1.18 now loads msfs_da62 and xp12_phenom300 profiles, renders separate readiness evidence, rejects incompatible XP broker placement/simulator attachment, keeps XP12/Phenom blocked while unqualified, and preserves the existing MSFS startup path. Optional component start commands remain metadata only. Confirmed FreeTrack is active and vJoy is diagnostic fallback. Debug build passed with 0 warnings/errors and preflight contract tests passed. Nothing was published or activated on the simulator PC.
Knowledge
6 itemsRequest from dedicated ATC-display session,3November2026, following user request to investigate implementing BATC taxi routing. Adds concrete TAXI source needs to279 (readback) and320 coordination. This is a producer request/proposal, NOT owner acceptance, a new endpoint, a completed interface or permission to alter launcher/broker from the display chat. NEW VERIFIED FACTS: existing GET8097/v1/launcher/airport-map?airport=EHAM returns ready schema1 Global Airports geometry. Source endpoint is typed Func<...,Task<XPlaneMap>> and uses XPlaneMapCatalog. Real payload619nodes/597edges includes119oneway edges,381active-zone1204rows and48runway edges. This is X-Plane geometry even while broker family=msfs; it does not qualify as current MSFS scenery. Current display AirportMap retains only(start,end,name), dropping direction/type/active-zone semantics; sufficient for diagram drawing, insufficient for route reconstruction. Current native SimulatorSession.Msfs/MsfsLocalSession.cs already resolves SimConnect_AddToFacilityDefinition and SimConnect_RequestFacilityData, validates instance/cancellation/bounded/completed packets and has real ObserveAsync latitude/longitude/ground readback. Current MsfsAirport.cs definition requests AIRPORT, TAXI_PARKING and START only, not TAXI_POINT/TAXI_PATH/TAXI_NAME. MsfsAirportCache likewise contains parking/runway starts, not the taxi graph. Reuse these owned native mechanisms instead of adding another Windows SimConnect service in the display chat. Official retail MSFS2024 SDK documents TAXI_POINT (including HOLD_SHORT type/orientation/local bias), TAXI_PATH (start/end/name index/type/runway association) and TAXI_NAME. This establishes an implementation mechanism; native graph lookup was NOT executed or qualified this turn. FRESH READ-ONLY STATE: MSFSconnectedtrue, flight_loaded/controls_ready/radios/position null through existing broker status. BATC is in menu, no ATC/taxi messages. No flight requested/restarted, no ATC/control/PTT/tuning action. Display/Pi remains0.24.0; no product/broker/launcher code change. PRODUCER REQUEST, PENDING OWNER AGREEMENT: publish a complete bounded graph for the actual selected simulator scenery/airport, explicit simulator family+instance+airport+revision/provenance+real timestamp/completion; nodes and geographic/documented-origin coordinates, normal/hold-short/ILS types/orientation; edges with validated references, names, kind/closed/vehicle/runway classification and available direction/runway constraints; runway/holding associations and qualified apron/parking connectors or explicit missing/ambiguous data. Keep exact current simulator own-position with actual timestamp, instance and stable flight/session binding, lat/lon/known true heading/on-ground or null. Do not invent readiness. Choose transport within existing owned read-only source infrastructure; no URL/implemented schema presumed here. POSITION CONTRACT ISSUE: current Pi BrokerRadio.parse gates position on flight_loaded=true AND radio.source/session_key. A position-only source extension must be agreed independently of missing radio actuals, with real simulator/session provenance; do not fabricate COM1 to unlock a moving map. The display owner will implement the corresponding normalization only after the source contract is agreed. DISPLAY RESPONSIBILITY: full own-callsign/current-session BATC taxi text -> bounded interpretation preserving exact taxiway order, hold/crossing restrictions -> unique path on matching graph/current own-position. Label as text-derived reading aid, not exported authoritative BATC geometry. If branch, endpoint, runway, wording, scenery or freshness is uncertain, show text/reason and withhold the polyline. No guessed shortest-route clearance. Real Schiphol/MSFS DA62 facility+position+taxi-instruction capture precedes live acceptance; retain SI and XP12 behavior. Evidence reports/atc-taxi-feasibility-20261103/summary.json, EHAM-map.json, batc-frames.json, audit.json and platform-handoff-proposal.json; report reports/atc-taxi-feasibility-20261103.md. ATC task323 stays OPEN. No implementation/deployment claimed; owner handoff remains unaccepted.
Afstemming vanuit dedicated ATC-displaychat,2november2026; aanvulling op taak320/kennis236/244. Geen broker-/launcherwijziging of toestemming tot automatische implementatie in deze notitie. GEOBSERVEERD1NOV: echte MSFS DA62/BATC-clearance PHVCC EHAM->EBCI. BATC InfoBoxes bevat Squawk1000 en Ground Frequency121.805; Facility Schiphol Ground|121.805. Pi0.23.2 toont assigned squawk1000 correct, maar SIMUNKNOWN en SIM—WAIT. Broker session/status geeft connected=true, flight_loaded=null, controls_ready=null, radios=null, position=null. Geïnspecteerde FormMain-statusconstructie vult controls_ready/flight_loaded/radios/position alleen voor XPlaneSimulatorAdapter.2november opnieuw read-only bevestigd op productie0.0.1.401: MSFS connected=true en dezelfde nullvelden. Geen bewijs dat simulatorverbinding ontbreekt of squawk1000 fout staat; actuele radio/transponder ontbreken in de interface. DISPLAYCORRECTIE0.23.3: SIM LINK amber bij verse connected=true met onbekende readiness, nooit groen cockpit-ready. Bestaande BATC Ground Frequency-chip tonen als unconfirmed fase-referentie GROUND FREQ/VERIFY, niet blind als assignment. Ontbrekende echte squawk toont NO READBACK. Geen SimConnect-client/Windowsdienst/providerproceslogica of tweede broker op Pi; geen verzonnen actuals vanuit BATC-assignment of Facility. CONSUMERBEHOEFTE TER AFSTEMMING: uitbreiden bestaande read-only /v1/session/status met werkelijk onderbouwde MSFS flight_loaded/controls_ready (bool of null; unknown niet true maken om UI groen te krijgen) en simulator.radios conform bestaande normalisatie: source=simulator, stabiele session_key, com1_active_hz als int Hz of null en squawk als exact octale4cijfer-string of null. Geldige simulatorinstantie/flight binding, bron/freshness, disconnect/stale/reset en onbeschikbaarheid moeten zichtbaar blijven. Pi-parser vereist momenteel connected=true plus flight_loaded=true en passende radio-source/session_key voordat actuals worden gebruikt; een anders gewenste radio-readinessgate eerst expliciet afstemmen. controls_ready is niet uit alleen radio-readback af te leiden. Position is apart voor TAXI; geen MSFS-scenery/routeclaim uit de gevraagde radioreadback. Bestaande addon/MSFS/native readbron hergebruiken bij implementatie door broker-eigenaar; geen tuning/PTT/transponderwrites of flightstart als onderdeel van readback. Controle met echte MSFS DA62 COM/squawk en behoud XP12-regressies vereist. Tot die tijd actuals onbekend laten, geen MATCH/MISMATCH op target alleen. Lokaal bewijs: reports/atc-msfs-diagnosis-20261101/ en reports/atc-msfs0233-20261102/broker-preflight.json; source/UI rapport volgt bij taak324.300lokale displaytests PASS; geen brokerimplementatie/live write-test uitgevoerd. Deze notitie legt behoefte en eigenaarschap vast; geen eigenaaracceptatie, gepland endpoint of serverwijziging geclaimd.
Afstemming vanuit dedicated ATC-displaychat,26oktober2026; aanvullend op kennis236 en taak320. Geen opdracht of toestemming om launcher/broker nu te wijzigen, geen geaccepteerde nieuwe interface. Feiten: screenshot25oktPHVCC LEBL-LERS bevat alleen ATC, terwijl BATC Player-prev.log24eigen PHVCC Speech Transcription / AI Processed-regels bevat. Ook Flight Rules: IFR en de squawk4446-clearance staan in dit log. Bestaande Pi-toolbaradapter ontvangt ATC:/Player:-tekst; Player->PILOT werkt in fixtures. Exacte oorzaak van ontbrekende pilotexport in de vlucht is zonder opgeslagen WebSocketframes onbekend. Huidige read-only menuproef heeft geen pilotframes; geen liveacceptatie. Pi0.23.x verwijdert foutieve LoadState.vfr->flight_rules-mapping, verwerkt expliciet gelabelde infochips en markeert letterlijk herkende handoffs als historische referentie. Geen Windows-logdienst/SSH-credentials/proces-/Fly!-logica op Pi toegevoegd. MENU-status maakt ontbrekende pilottekst zichtbaar. Vervolg voor gezamenlijke interfaceafstemming: eerst gecontroleerde eigen spraak vergelijken met de werkelijke toolbar Player-stream. Indien de geïnstalleerde experimentele BATC-versie die tekst niet exporteert, moet een aanvullende uitsluitend-lezen Windows-bron door de Windows-eigenaar worden gekozen. Gebruik zo mogelijk bestaande infrastructuur; geen tweede provider-/launcherlevenscyclus. Voor aansluiting zijn expliciete provider/epoch/session- en flightidentitybinding, stabiele berichtidentiteit/volgorde, bron/provenance, freshness, bounded payload, rotatie/reset en deduplicatie tegen echte Player-frames vereist. AI Processed-logtekst is herkende pilotspraak, geen bewezen uitgezonden readback of ATC-assignment. Er is geen endpoint/veldnaam voor een dergelijke tekstfeed afgesproken of geconsumeerd. Voorstel236 voor statusfeed blijft apart ongewijzigd en onbevestigd. Displayresultaten/diagnose: ATC-project39 buildlog5911 en reports/atc-screenshot-review-20261026.md. Laat implementatie en endpoint pas volgen na eigenaarafstemming; geen code gewijzigd in Platform.
Afstemming vanuit ATC-displaytaak39/#324,24oktober2026. Taak320 en bestaande launcher66-bron read-only geïnspecteerd. AtcProvider is voorkeur, AtcSummary mensgerichte tekst; geen betrouwbaar machinecontract voor proces/menu/Fly/windowstatus. Pi zal die tekst niet parsen en geen Windows-proces-/Fly-/vensterlogica dupliceren. Launcher/brokerbron of runtime wordt niet gewijzigd door displaywerk. Huidige implementatierichting: Pi normaliseert uitsluitend bestaande directe BATC-toolbar/SI-, broker- en historieobservaties met bron, epoch/session en lokale monotone ontvangsttijd. Transport≠flight≠history; ontbrekend bewijs UNKNOWN. Menu alleen expliciete LoadState.stage=menu, geen afleiding uit Facility/lege historie. Geen Fly!-acties. VOORSTEL TER ACCEPTATIE DOOR EIGENAAR320, nog geen geïmplementeerde feed: additief atcStatus-object in bestaande read-only launcherstatus, schema=1, observedAtUtc, ttlMs (max5000), selectedProvider (voorkeur), activeProvider (waargenomen), ambiguous (bool), providers[] met provider plus process/link/flight/window-observaties. Elke observatie bevat state, observedAtUtc, source, errorCode; flight optioneel sessionId. Process off/running/starting/unknown; link connecting/connected/error/unknown; flight idle/loading/active/unknown; window visible/minimized/unknown. Niet-geobserveerde waarden unknown, geen afleiding uit voorkeur. Fouten codes, geen vendorpayloads/credentials. Pi moet eigen ontvangst-age én bron-age begrenzen, unknown schema/ambiguïteit/stale/conflict niet groen tonen. Windows blijft eigenaar van processen, Fly en vensters; directe Pi-observaties blijven eigen bron en worden niet stilzwijgend overschreven. Deze notitie is een contractvoorstel/handoff, geen bevestiging van eigenaaracceptatie en geen opdracht om automatisch Windows-code te wijzigen. Display levert voorlopig status zonder deze toekomstige feed.
Implemented in Broker/Launcher commit 3b70d2a; shared contract update is cockpit orchestration commit 5c16568. Launcher 0.0.1.18 loads configuration-driven msfs_da62 and xp12_phenom300 profiles. Each profile records its explicit simulator target and aircraft plus required/optional components, configured host, start-command metadata, readiness method, dependencies and route-source qualification. Behavior: - Profile selection and preflight are read-only. They do not launch, stop, relocate or dispatch to optional processes. - The existing MSFS/DA62 Start session workflow remains the only executable workflow. - Evidence is reported separately for support qualification, running, reachability, simulator connection and functional readiness. Unknown never becomes ready. - Broker runtime ready remains catalogue readiness only. Equal nodes.connected/nodes.total does not prove expected inventory or synchronization; preflight waits for explicit expected/synchronized evidence. - XP12 requires the active broker endpoint on the configured simulator-PC host and rejects attachment to a conflicting simulator. It never moves or duplicates the broker. - XP12/Phenom remains blocked until its catalogue and mappings are proven. - RadioBridge, Ollama, AI-ATC, WingRally and Instructor start commands remain metadata; missing manager-consumable readiness/version contracts remain visible as unknown. - WingRally native XP routes remain unsupported. Imported SimBrief .fms remains unqualified until Bridge 0.4, the XP plugin and X-Plane 12.1+ are observed. - Active MSFS camera flow is semantic view.yaw/view.pitch through the embedded Agent's FreeTrack/TrackIR shared-memory endpoint. Separate msfs.vjoy keys are diagnostic legacy fallback only; vJoy is not a normal runtime dependency. Validation: - Windows-targeted Launcher Debug build: 0 warnings, 0 errors. - Dependency-free preflight contract tests pass: both profiles load; catalogue-ready and 8/8 current node counters do not yield cockpit-ready; XP remote-broker and wrong-simulator cases block; bridge readiness remains unknown; XP route qualifications remain conservative. No publish, simulator-PC activation or live simulator acceptance was performed.
Reported current implementation The MSFS-oriented launcher finds an existing broker on the simulator PC or an alternate broker host, starting one locally if neither is running. It embeds Sim Agent on port 8097, powers on tablets, launches MSFS 2024, waits for SimConnect, loads a saved flight, handles Ready-to-Fly/cockpit entry and temporary cockpit power, coordinates POPM and four pop-outs, synchronizes nodes and provides FreeTrack output for the viewing joystick. It must start before MSFS for the current FreeTrack/TrackIR viewing integration. Do not separately start standalone Sim Agent: its port conflicts with the embedded instance. Target user flow 1. On tablet/phone, select DA62/MSFS or Phenom/X-Plane. 2. Start the session and the tools selected by that profile. 3. Wait for a WingRally flight or select an airport and available runway/ramp. 4. Load the aircraft, departure location and supported route data; wait for actual flight/aircraft readiness. 5. Apply the aircraft-specific cold-and-dark state after loading. 6. Finish and verify cockpit screens, camera and physical-node synchronization; show Ready only when required checks pass. Implementation proposal Run the manager on the simulator PC and expose a local-network responsive web interface. Session execution survives closing the browser. No framework choice has been made. Distinguish process running, simulator connected, flight loaded and cockpit ready. Show waiting and failure reasons. An explicit simulator profile controls a cold start; auto-detection can help attach to an existing simulator. Open details Default user request is cold and dark, including completion after route load. A separate ready-for-departure runway option was suggested but is not a confirmed requirement. Determine loading and cockpit-power order per simulator/aircraft, including interaction with physical switch states. Do not claim universal cold-and-dark support before verification. Operational proposals Track which processes were started by the manager. Do not stop an externally started simulator/broker without an explicit user action. Avoid duplicate instances, bound recovery attempts, and require an intentional new-session action before a new route resets an active flight. Static audit clarification (knowledge item 117) Launcher .NET 8 version 0.0.1.17 is a suitable base; no broad rewrite is needed. It currently has only the MSFS workflow. Embedded Sim Agent exposes /v1/health on port 8097; standalone version 0.0.1.14 must not run alongside it. Tablet Agent is Android 0.2.11 build 14 with discovery/commands on 8095. First implement read-only configuration-driven preflight for msfs_da62 and xp12_phenom300: required/optional components, host, start command, readiness method and dependencies. Report running, reachable, simulator connection, functional readiness, unsupported and unknown separately. Start commands are metadata only in this phase. XP12 local-broker enforcement initially means reporting/rejecting an incompatible location, not stopping or moving processes. Block the integrated XP12/Phenom profile while catalogue/mappings are unverified. Do not add automatic RadioBridge, WingRally or Instructor startup before useful readiness contracts are available. The earlier FreeTrack-only/no-vJoy-required statement and the audit's vJoy/head-tracking description must be reconciled by inspecting active configuration/code; do not infer that vJoy must be installed or started. The audit did not run or rebuild the simulator stack.