Skip to content

L-7b-ii Phase 2c: wrapper mono routing + activate ('eq','tr') BPSD coupling #208

@k-yoshimi

Description

@k-yoshimi

Context

Phase 2a (PR #206) and Phase 2b (PR #207) shipped the L-7b-ii monolithic image foundation:

  • libtotapi_mono.so is dlopen-loadable and 1e-10 equivalent to default libtotapi.so on existing fixtures.
  • tot_is_mono() C ABI distinguishes the two builds at runtime.
  • TotPipeline._detect_mono + _active_rules + _MONO_ONLY_RULES overlay infrastructure is in place.
  • Layer-C smoke test proves the broker IS shared in the mono image when called via direct ctypes (eq_run(1) → eq_bpsd_put → tr_check_bpsd_pull = 1).

What is still missing for production-ready monolithic BPSD coupling:

  1. Eqlib / Trlib / Fplib / Tilib / Wrxlib each load their OWN per-module lib<mod>api.so via EQLIB_PATH / TRLIB_PATH / etc.
  2. A TotPipeline user setting TOTLIB_PATH=...mono.so gets tot_is_mono() == 1, but the wrapper instances inside the pipeline (Eqlib, Trlib, ...) still each load THEIR per-module .so.
  3. Consequence: even though the _MONO_ONLY_RULES overlay is in place, populating ("eq","tr") would cause run_pipeline to fire the verify rule against a Trlib instance reading from libtrapi.so's PRIVATE bpsd, not from the mono image's shared bpsd. Verify would deterministically fail.

_MONO_ONLY_RULES is intentionally empty in Phase 2b (Codex pre-push review HOLD on PR #207 caught this). Phase 2c closes the gap.

Scope: short chain of 2 PRs (per Codex retrospective 2026-05-18)

PR-A — Wrapper mono routing contract

Single authoritative routing rule, NOT ad-hoc per-wrapper env handling.

  • Design + implement a shared mechanism (e.g. MONO_LIB_PATH env var honored by all 5+ wrappers' _ffi.py, OR a python/_runtime_mode.py module that each wrapper consults).
  • Update python/eqlib/_ffi.py, python/trlib/_ffi.py, python/fplib/_ffi.py, python/tilib/_ffi.py, python/wrxlib/_ffi.py to honor the shared mechanism.
  • Do NOT activate ("eq","tr") in this PR — keep _MONO_ONLY_RULES empty so the wrapper plumbing can ship without behavioral side-effect.
  • CI: extend mono-build job to verify that setting the shared env var routes all 5 wrappers to the mono image (sanity test, not a behavioral test).

PR-B — Behavioral activation

  • Populate _MONO_ONLY_RULES with the ("eq","tr") verify rule.
  • Add a TotPipeline integration test: pipeline.run_pipeline([("eq", ...), ("tr", ...)]) with MONO_LIB_PATH set; verify rule fires and check_bpsd_pull returns True on mono, False on default.
  • Stale BPSD state isolation: --forked enforced (Codex retrospective 2026-05-15 item 5).
  • CI: full TotPipeline + mono behavioral test.

Acceptance criteria (combined)

  1. Eqlib(...) / Trlib(...) / etc. constructed inside a TotPipeline whose tot_is_mono() returns 1 ALSO load the mono image (not their per-module .so).
  2. TotPipeline().run_pipeline([("eq",...),("tr",...)]) with mono routing populated runs ("eq","tr") verify rule and PASSES (broker round-trip succeeds).
  3. Same call with default libtotapi.so selected: rule NOT activated (or activated but fails cleanly with a clear "mono image required" error).
  4. CLAUDE.md: 1e-10 equivalence preserved.
  5. Default per-module path: untouched.

Out of scope

  • Restructuring any Fortran source (feedback_fortran_refactor_needs_lead_signoff.md).
  • Cross-module coupling rules other than ("eq","tr").
  • Changing the existing per-module _ffi.py path-resolution priority for non-mono users.

References

Codex's specific guidance for this PR chain

"Make Phase 2c a short chain, not one wide PR. First PR adds a shared mono-path loading contract and updates the 5+ module _ffi.py loaders without activating eq -> tr; second PR flips _MONO_ONLY_RULES and adds a true TotPipeline.run_pipeline([eq, tr]) integration test."

"The other cross-cutting risk is loader semantics — current _ffi.py loaders resolve environment/default paths independently, so Phase 2c needs a single authoritative mono routing rule, not ad hoc env handling in each wrapper."

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions