Problem
@simlin/engine (the TypeScript WASM surface) never binds simlin_analyze_get_loops_runtime, so TS consumers can never observe runtime-reclassified loop polarity (MostlyReinforcing/MostlyBalancing, "Rux"/"Bux") or a real polarity_confidence -- even though the enum variants and the Loop.polarityConfidence field already exist in src/engine/src/types.ts (the #495 type plumbing).
Concretely, src/engine/src/direct-backend.ts (~line 424) binds only the structural entry point:
The runtime entry point that does the honest post-simulation reclassification exists in libsimlin:
pysimlin binds it (Sim.get_loops_runtime, and Run.loops consumes the same reclassification), so Python sees honest post-sim labels. TS does not, so the diagram/web UI cannot render them.
Why it matters
Capability/parity gap (severity low-medium): Python consumers get honest Rux/Bux labels with real confidence values; TS/web consumers are stuck with pre-simulation structural labels and a degenerate 1.0/0.0 confidence. This is the same #495-follow-on plumbing class as #701 (runtime/discovery signals that exist in the engine and FFI but never reach TS).
It is also a prerequisite for #731 (diagram: render Rux/Bux with confidence-gray treatment): #731's body states "the data is now available to the diagram via the @simlin/engine Loop type", but that is only true of the types -- no binding actually delivers Rux/Bux or a non-trivial polarityConfidence to TS at runtime. #731 cannot render honest post-simulation polarity until this lands.
Components affected
src/engine/src/direct-backend.ts (bind the runtime entry point; expose e.g. Sim.getLoops() / a runtime-loops method on the sim handle)src/engine/src/types.ts (types already present; surface API addition)- the worker backend /
EngineBackend interface (worker-server.ts / worker-backend.ts) so the binding works on both Direct and Worker paths
Possible approach
Mirror pysimlin's split: keep the structural Model-level loops accessor and add a Sim-level (post-run) loops accessor that calls simlin_analyze_get_loops_runtime on the completed sim handle. The existing readLoops/LOOP_SIZE readers should be reusable since both entry points return the same SimlinLoop array shape.
Context
Identified during GH #679 work on branch ltm-core-batch (commit fca4cfec). The gap exists on main today: src/libsimlin/src/analysis.rs exports both entry points, pysimlin binds both, src/engine/src references only the structural one.
Related
Problem
@simlin/engine(the TypeScript WASM surface) never bindssimlin_analyze_get_loops_runtime, so TS consumers can never observe runtime-reclassified loop polarity (MostlyReinforcing/MostlyBalancing, "Rux"/"Bux") or a realpolarity_confidence-- even though the enum variants and theLoop.polarityConfidencefield already exist insrc/engine/src/types.ts(the #495 type plumbing).Concretely,
src/engine/src/direct-backend.ts(~line 424) binds only the structural entry point:simlin_analyze_get_loops(src/libsimlin/src/analysis.rs~474) -- model-only, pre-simulation labels;polarity_confidenceis hardcoded1.0(all links signed) or0.0(any link unknown), and Rux/Bux are structurally unreachable (ltm: exhaustive-mode loops never get runtime polarity reclassification (Rux/Bux unreachable) #679).The runtime entry point that does the honest post-simulation reclassification exists in libsimlin:
simlin_analyze_get_loops_runtime(src/libsimlin/src/analysis.rs~557) takes a runSimlinSimand reclassifies viaLoopPolarity::from_runtime_scoresover the simulated loop-score series (the ltm: exhaustive-mode loops never get runtime polarity reclassification (Rux/Bux unreachable) #679 surface).pysimlin binds it (
Sim.get_loops_runtime, andRun.loopsconsumes the same reclassification), so Python sees honest post-sim labels. TS does not, so the diagram/web UI cannot render them.Why it matters
Capability/parity gap (severity low-medium): Python consumers get honest Rux/Bux labels with real confidence values; TS/web consumers are stuck with pre-simulation structural labels and a degenerate 1.0/0.0 confidence. This is the same #495-follow-on plumbing class as #701 (runtime/discovery signals that exist in the engine and FFI but never reach TS).
It is also a prerequisite for #731 (diagram: render Rux/Bux with confidence-gray treatment): #731's body states "the data is now available to the diagram via the
@simlin/engineLooptype", but that is only true of the types -- no binding actually delivers Rux/Bux or a non-trivialpolarityConfidenceto TS at runtime. #731 cannot render honest post-simulation polarity until this lands.Components affected
src/engine/src/direct-backend.ts(bind the runtime entry point; expose e.g.Sim.getLoops()/ a runtime-loops method on the sim handle)src/engine/src/types.ts(types already present; surface API addition)EngineBackendinterface (worker-server.ts/worker-backend.ts) so the binding works on both Direct and Worker pathsPossible approach
Mirror pysimlin's split: keep the structural
Model-level loops accessor and add aSim-level (post-run) loops accessor that callssimlin_analyze_get_loops_runtimeon the completed sim handle. The existingreadLoops/LOOP_SIZEreaders should be reusable since both entry points return the sameSimlinLooparray shape.Context
Identified during GH #679 work on branch
ltm-core-batch(commitfca4cfec). The gap exists onmaintoday:src/libsimlin/src/analysis.rsexports both entry points, pysimlin binds both,src/engine/srcreferences only the structural one.Related
polarityConfidencethrough the FFI/TS types; this issue is the missing runtime binding