Skip to content

Bridge contract OD-1/2/3: pin the tolerant door — direct check_facts() diverges from load() (unknown kind fallback, line coercion) #294

Description

@PhysShell

From the #258 bridge-contract inventory (spec/Bridge.md §9, OD-1..OD-3). Python-first: settle before #259 relies on it.

The bridge has two entry doors: strict load() (fail-loud, BR-D1) and the direct check_facts(facts) path tests/embedders use (tolerant, BR-D2). Three divergences look accidental rather than designed:

  1. OD-1 — scope. Should Rust own-bridge expose the tolerant door at all, or is strict-only + a Python-side test shim the porting contract? Today the tolerant behaviors (skip-malformed effects/protocol entries, _as_int degradation, DI string coercion, duplicate-protocol first-wins) are load()-bypass conveniences, not documented API.
  2. OD-2 — unknown kind fallback. to_module/to_own route a present-but-unknown resource kind as subscription via _RESOURCES.get(rkind, default) when load() is bypassed — the tolerant door contradicts IR4 (fail-loud routing). Options: raise in the lowerer too (IR4 everywhere), or spec the fallback as the tolerant-door contract.
  3. OD-3 — line coercion inconsistency. Finding construction uses strict int(sub.get("line", 0)) on the token/capture anchor paths but _as_int elsewhere — a non-int line on the tolerant door crashes one path and silently degrades the other.

Per #258's ambiguity rule: either document current behavior as the migration contract, or change it Python-first before the port. Recommendation: IR4-everywhere for (2), _as_int-everywhere for (3), and decide (1) explicitly in #259's design.

Refs #258, #259.

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