Integration-level follow-up for knowledge item 118, not a copy of the WingRally product backlog. Coordinate detailed work with the WingRally Codex. Reported implemented: Navigraph account linking, subscription checks and AIRAC selection; external client registration is no longer a blocker. Staging review remains open. Review and record its actual results using repository documentation docs/NAVIGRAPH_INTEGRATION.md. Reported working: SimBrief v1 import. Planned: v2 migration. Record these as distinct states; do not claim v2 is complete. Confirm retained original .fms payload for the current XP import path and relevant metadata for route eligibility. Acceptance: staging outcome and remaining defects are explicit; v1 working evidence and v2 migration status are independently documented; account/subscription requirements apply only to dependent features, not ordinary simulator startup or native WingRally routes. No credentials, secrets or private machine configuration in public records.
.png)
06 - WingRally Integration
WingRally and optional SimBrief route sources, Bridge 0.4 simulator detection and XP plugin, Navigraph/SimBrief dependencies, explicit simulator selection and flight handoff. Distinguish source capability, last inspected deployment and live aircraft qualification. Native WingRally-to-XP route export remains to be implemented.
Coordinate with the WingRally Codex and checkpoint/release tasks 215 and 211. Source 0.4 includes automatic sim detection and the X-Plane plugin; the last inspected NAS runtime was 0.3/MSFS2024-only. Windows-plugin and practical simulator validation remain open. Inspect current publication first, record exact source/build/runtime versions and reconcile the gap without reimplementing existing XP code. Validate the Windows plugin and XP12 12.1+ requirements. Acceptance: reproducible build/publication evidence, plugin presence/compatibility checks and live tests on the intended simulator. Test explicit simulator selection, two running sims, missing plugin, restart, duplicates and route arrival during an active flight. Imported-SimBrief/.fms and native-WingRally paths must reflect what is actually built. Native path depends on its exporter task. Record Phenom 300 route load/activation evidence separately; if untested or unsupported, say so. No publication or code review alone qualifies the aircraft or complete cockpit state. Preserve standalone WingRally use.
User-approved goal: SimBrief must be optional for both MSFS and XP12. Read knowledge items 113 and 119 and coordinate with the WingRally Codex. Current XP bridge accepts imported SimBrief briefings with original .fms data and rejects ordinary WingRally routes. Implement the missing native WingRally route export for simple supported routes using departure, intermediate points and destination. Simulator-specific .fms-format data may be generated internally; do not require manual file export or a SimBrief account/briefing for this path. This does not promise arbitrary file-format imports. Preserve the original imported SimBrief plan for detailed IFR routes when available, including supported procedure information. Track available route/AIRAC provenance and validate unresolved points or incompatible procedures; do not invent missing legs or navdata. Acceptance: a plain WingRally route can reach a qualified XP target without SimBrief; native and imported routes remain distinguishable; errors are explicit; duplicate/restart/active-flight behavior follows task 209. A successful transfer is not automatic avionics activation or cockpit readiness. Phenom compatibility requires separate live evidence. Update capability advertisement and manager eligibility once the implementation is actually available.
Read knowledge items 113 (current bridge/source behavior), 118 (Navigraph/SimBrief dependencies) and 119 (handoff contract), plus static audit 117. Coordinate implementation with the WingRally Codex. Source/deployment/test distinction Bridge source 0.4 already includes automatic simulator detection and XP12 12.1+ plugin support. The last inspected NAS runtime was 0.3/MSFS2024-only. Windows-plugin validation and practical simulator tests remain incomplete; Phenom 300 is not qualified. Recheck publication rather than assuming source equals deployment. Route sources MSFS currently uses an imported SimBrief plan if available, otherwise the WingRally route. The current XP path requires an imported SimBrief briefing retaining original .fms data; plain WingRally routes are currently rejected. SimBrief is OPTIONAL in the target design for both sims. Coordinate the native WingRally XP export follow-up; do not require users to supply .fms permanently. Contract Define route eligibility from installed capabilities and data, explicit simulator selection, request correlation, acceptance, transfer, avionics activation evidence, cockpit preparation, failure, timeout/restart and idempotency. Keep bridge acknowledgement, route active in avionics and cockpit prepared separate. Unknown observations cannot become successful completion. Preserve standalone WingRally use. Manager's selected simulator profile must govern its handoff despite different component autodetection rules. Two running sims must not cause silent dispatch to the wrong target. Readiness and validation Existing signal is server heartbeat, not a local health API. Agree adequate readiness before new automatic manager startup; preflight remains read-only initially. Verify MSFS Route Provider and local XP plugin compatibility. Test missing plugins, two simulators, restart/reconnect, duplicates and arrival during active flight. No automatic active-flight reset. Handle missing departure information explicitly. A route-transfer result does not establish parking position or cold-and-dark state. Acceptance: repository-owned contract, source/published/tested version matrix and concrete test evidence, with unsupported capabilities and remaining gaps explicit. No staging or Phenom success claim without evidence.
Build Log
1 entryWingRally completeness review and optional-SimBrief requirement recorded
The user supplied a WingRally Codex comparison of current project files with Cockpit Platform and a clarification of route-source behavior. The report says Bridge 0.4 simulator autodetection and XP plugin are built, but the last inspected NAS runtime was 0.3; Windows-plugin and live tests, especially Phenom, remain open. It reports Navigraph linking/subscription/AIRAC implementation and a working SimBrief v1 flow; staging review and v2 migration remain open. The user explicitly requested native WingRally routes as well as optional SimBrief imports for XP12. The current XP original-SimBrief-.fms restriction is recorded as an implementation limitation, not a simulator requirement. Native WingRally export is still unbuilt. Knowledge item 113 and section 06 were corrected; items 118 and 119 capture dependencies and the staged handoff contract. Existing manager/integration tasks were refined and focused follow-ups created. The official XPLMLoadFMSFlightPlan reference was read and linked. Repository-relative documents bridge/README.md and docs/NAVIGRAPH_INTEGRATION.md are cited from the user report but were not directly read here; no public repository URL was supplied. This records reported code-review findings and documentation changes only. No local code edits, builds, staging checks, publishing or live simulator tests were executed in this chat.
Knowledge
3 itemsStatus Required integration behavior agreed from the user-supplied WingRally review and subsequent clarification. Exact API/schema and implementation remain to be designed and tested with the WingRally and cockpit Codex owners. Inputs and capability checks Treat a route as a domain object whose source may be WingRally or an imported SimBrief briefing. Do not require the caller to supply .fms universally. Simulator-specific export is an adapter responsibility. Associate each handoff with a chosen simulator profile, flight/request identity and relevant route-source/format capability. Define exact field names in repository-owned specifications; no schema is asserted to exist yet. Evaluate eligibility against installed bridge/plugin versions, target simulator/aircraft support and available route data. Current XP eligibility requires original .fms from imported SimBrief; future native WingRally export removes that condition for supported simple routes. Cockpit Manager's explicit simulator profile governs its sessions. Multiple independent autodetection rules must not silently redirect a request. Preserve independent WingRally use with an explicit standalone selection policy. Completion stages 1. Transfer acknowledgement: the bridge reports what was accepted/transferred or failed. This is transport/load-step evidence only. 2. Avionics route state: establish separately whether the target avionics actually loaded and activated the route; if unobservable, expose unknown or a required manual verification, never fabricate success. 3. Cockpit prepared: verify chosen departure/parking or runway, appropriate aircraft state (including requested cold and dark), and required cockpit/component readiness. These stages may progress or fail independently. A successful transfer must not become Cockpit ready by implication. Lifecycle behavior to specify Validation/rejection reasons, capability mismatch, correlation/idempotency, timeout, restart/reconnect and stale-request handling. No automatic active-flight reset or duplicate loading. An intentional new-session action is needed before destructive flight replacement. Missing plugin, two simulators running, restart, duplicate requests and route arrival during an active flight are mandatory cases in live verification. Preserve route source/procedure data and AIRAC provenance. Check unresolved points and procedure support rather than inventing them. Keep the initial manager preflight read-only. Later orchestration must use an adequate bridge readiness contract instead of assuming a server heartbeat proves simulator/avionics readiness.
Scope and provenance Integration-level summary only; do not duplicate the full WingRally backlog. Source: WingRally Codex review supplied by the user on 18 September 2026. Local documents were referenced by the user, not directly read by this chat. Repository-relative references: docs/NAVIGRAPH_INTEGRATION.md and bridge/README.md. No public repository/document URL has been supplied; these paths are references, not publicly accessible links. Navigraph Account linking, subscription checks and AIRAC selection are reported implemented. Waiting for external client registration is no longer a current blocker. Staging review remains open. Do not mark staging or production behavior verified based on the implementation report alone. SimBrief The v1 briefing-import flow is reported working. The v2 migration is planned and must remain a separate future item; do not label it implemented or conflate v1 functionality with v2 migration. The current XP bridge path uses an imported briefing's original .fms data. Preserve this payload and route/procedure provenance where applicable. Dependency boundaries Navigraph account/subscription/AIRAC requirements apply to the features that actually use those services. Do not impose them as a universal requirement to start the cockpit or fly an ordinary WingRally route. SimBrief is optional in the target design for both MSFS and XP12. Native WingRally-to-XP export is outstanding. Show the temporary imported-SimBrief/.fms requirement only for the currently limited XP bridge capability. Keep route origin, briefing/import version, selected/available AIRAC and original payload provenance distinguishable where available. Never silently invent procedures or hide unsupported/mismatched data; exact handling belongs in the contract and tests. No credentials, client secrets, token values, personal account data or installation-specific configuration belong in this public project.
Evidence and ownership Sources: cockpit Codex static audit (knowledge item 117) and the WingRally Codex review/clarification supplied by the user on 18 September 2026. Implementation claims below are reported by those developers; this chat did not inspect the local repository or run a simulator. WingRally implementation remains with the WingRally Codex; Cockpit Manager work must coordinate interface changes with it. Repository-relative reference supplied by the user: bridge/README.md. Its contents were not directly read in this chat. Source, publication and runtime are separate Bridge source 0.4 includes automatic simulator detection and an X-Plane plugin, with reported MSFS and XP12 12.1+ support. The last inspected NAS deployment was still runtime 0.3, explicitly MSFS2024-only; current deployment must be rechecked before use. Windows-plugin validation and live simulator tests are not complete. Phenom 300 avionics compatibility remains unproven independently of the broker catalogue/mapping qualification. Do not describe XP12 code as wholly unbuilt or source support as proven deployed behavior. The MSFS Route Provider belongs in the Community folder and is not a separate process. The bridge runs on the simulator PC for SimConnect/CommBus or the local XP plugin. The reported XP plugin uses loopback UDP 19782. Existing readiness is a server heartbeat, not a structured local health API. Current route-source behavior, as reported by WingRally Codex MSFS: use an imported SimBrief plan when available, otherwise WingRally's own route. Current XP bridge path: requires an imported SimBrief briefing retaining its original .fms payload. Plain WingRally routes without that payload are currently rejected; WingRally's own XP flight-plan export is not built yet. This is a restriction of the current bridge implementation, not an inherent requirement for X-Plane to use SimBrief. User-approved target: SimBrief optional on both simulators Support ordinary WingRally routes as well as imported SimBrief briefings. Do not reduce the product contract to only SimBrief or only a user-supplied .fms file. Separate route source (WingRally route or SimBrief briefing) from simulator transport/representation. The XP adapter may generate valid .fms-format data internally from departure, intermediate points and destination for a simple WingRally route. Users should not need to visit SimBrief or manually supply an .fms file for that path. Retain the original imported SimBrief plan for detailed IFR routes where available, including applicable procedure data. Never invent unresolved waypoints, procedure legs or AIRAC compatibility. A change of file representation alone does not prove that the target aircraft accepted or activated a route. Official reference: https://developer.x-plane.com/sdk/XPLMLoadFMSFlightPlan/ describes loading X-Plane 11-and-later plan data from a buffer into FMS/GPS, including procedures; this supports a provider-independent representation, not a claim of tested Phenom compatibility. Manager integration Preserve standalone WingRally use. The manager may prepare a session and wait for a WingRally flight or use manual departure selection. Display route eligibility using the selected simulator profile and the capabilities of the actually installed bridge/plugin. Until native WingRally XP export is implemented and qualified, clearly explain the current imported-SimBrief/.fms requirement for that path. Do not turn that temporary condition into a permanent SimBrief requirement. One selected simulator profile must govern dispatch: independent autodetection must not silently choose different simulators when both are running. Missing or conflicting target information needs an explicit failure or user choice. Keep route-transfer acknowledgement, route-active-in-avionics evidence and cockpit-prepared evidence separate. A bridge acknowledgement alone does not prove correct parking position, avionics activation or cold-and-dark state. Receiving a new or duplicate route during an active flight must not reset it without an intentional new-session action. Define request identity, acknowledgements and restart behavior with component owners before implementation. Read-only preflight remains the first manager milestone; add no automatic bridge startup before an adequate readiness contract exists.