Rewrite plan: Zibo/LevelUp logic → MSFS 2024 WASM + HTML display units

Status date: 2026-10-31. Replaces the "original plugins in LU737 Host over a WebSocket" architecture of CONVERSION_ASSESSMENT.md §2.3–2.4 for everything except the models. Keeps the stable cockpit interface (SCI, COCKPIT_IO_REDESIGN.md, SCI_IMPLEMENTATION.md) as the seam between the model and the logic.

1. Owner's decisions (2026-10-31)#

2. Architecture#

MSFS 2024 package
├─ lu737_systems.wasm   (wasm/, C++20, gauge LU737_Systems in panel.cfg VCockpit01)
│    electrics, APU, pneumatics, engines + CFM56 tables, fuel, hydraulics,
│    flight controls, AFDS/AT, TCAS, GPWS, annunciators, failures
│    implements the SCI contract (data/sci/contract): SCI states as
│    L:LU737_<STATE> for the model, SCI events from the clicks;
│    reads A:vars, drives MSFS through K: events
├─ display units        (avionics/, TSX + SVG, one VCockpit per display material)
│    PFD, ND, upper/lower EICAS, CDU, ISFD; FMS (MSFS facilities, flight plan)
└─ models               (unchanged: original objects as glTF, behaviours from
                         tools/msfs/generate_behaviors.py)

• src/core never includes MSFS headers; it talks to the sim through SimIO. The same code builds natively for unit tests and for the differential tests.
• WASM ↔ JS (FMS ↔ AFDS, CDU keys, display data that is not a single number): MSFS_CommBus (in the SDK headers) or L:vars.
• The model's interface is the SCI contract. The behaviours read 959 SCI states as L:LU737_<STATE> and every click sends an SCI event H:LU737_<CONTROL>_<ACTION> (2,123 events; data/cockpit_io.json). The contract (data/sci/contract) defines states (kind, enum, default) and controls (type, guard, momentary positions); it names no Zibo dataref, so the model does not change when the logic is rewritten. The Zibo profile (data/sci/profiles/zibo_2S1_50) records how each SCI state and control maps to Zibo's datarefs and commands, measured on the original plugins: it is the specification of what each control does in Zibo.
• Clicks reach WASM through JS. H events are delivered to JS instruments only (MSFS_Events.h: "HVar are events distributed to js vcockpits"), so a display unit (or a small IO instrument) receives them and forwards them to the module over CommBus. Decided in M3.
• Duties of the removed gauge that the rewrite takes over: SCI event relay and state output, display power gates, L:LU737_SYS_LINK, screen brightness gain L:LU737_DU_GAIN, exterior fan rotation L:LU737_fan_angle_1/2 (integrated from N1), and the MSFS coupling (sim inputs, control and engine outputs, AP/AT authority).

3. Sources for the rewrite#

4. Proving parity: the oracle#

xphost/ is now a test tool. It runs the original Linux plugins headless with the SCI layer: --sci-test script.json runs SCI scripts (events, expectations on SCI states; xphost/test/sci, e.g. cold & dark power-up), and lu737host --replay in.bin --out out.bin runs recorded frame inputs (sim datarefs, SCI events, commands, dt) and writes every frame's outputs. Because both the oracle and the rewrite speak SCI, the comparison is made on SCI state names. A differential test drives the original plugins and the rewritten subsystem (native build of wasm/src/core) with the same input sequence and compares the outputs frame by frame within a stated tolerance (float32 vs double, fixed dt). Each subsystem lands with:

1. its specification (from the decompiled function and the Lua);
2. unit tests;
3. differential scenarios against the oracle (e.g. cold & dark → battery → APU start → APU gen on), run in CI.

What cannot be identical, stated per milestone in the test reports:

• flight physics is MSFS's, not X-Plane's: the AFDS control laws and gains are Zibo's, but the aircraft responds differently and may need retuning;
• navigation data comes from MSFS (another AIRAC/provider than X-Plane);
• the displays are redrawn as vectors in Zibo's layout, colours and symbols, not pixel copies of the bitmaps;
• no sound in phase 1.

5. Milestones (phase 1)#

6. Repository map#