Skip to content

Boundary B4: the realizer composes R ∘ G through ONE generic body, and the descriptor algebra gains its product #367

Description

@deOliveira-R

Goal (outcome). The realizer reads a law's two factor objects and composes R ∘ G through one generic body, so adding a boundary law stops meaning "add an arm"; and the descriptor algebra can spell the same composition, so R ∘ G is expressible at BOTH layers.

Campaign phase B4 of the boundary-machinery track (.claude/plans/boundary_machinery_review.md:1211). Reconciled against the tree [M] 2026-08-14 at 0f5ca91c — B0–B3.5 are all landed and merged, so this is the next substantive phase.

The premise still holds — measured

  • The isinstance ladder is still there: 8 arms at orpheus/sn/boundary/realizer.py:791, 831, 836, 911, 936, 955, 1049, 1117. The tree says so itself at :968: "the shape B4 generalizes: that phase turns this branch's isinstance chain into the realizer's ONE dispatch, over all laws."
  • The descriptor algebra still has no : orpheus/geometry/boundary/_composition.py defines only LawScaled (:80) and LawSum (:137). No LawProduct, no __matmul__.
  • as_operator is still deliberately absent, with the standing ruling stated in place — orpheus/geometry/boundary/_factors.py:242 is the Protocol signature and :252-258 the note: "No as_operator yet — deliberately. … The realization method arrives in campaign phase B4, together with its first consumer … Minting a method with no caller and no test is precisely the dead-capability pattern this campaign exists to remove."
  • A third realizer arm in disguise, already reading the two factors B4 will read: orpheus/sn/operators/boundary.py:167-173.

⛔ One sub-claim of the plan is now FALSE

The plan's [G] row says "OperatorProduct currently used by no boundary operator". It is used: orpheus/sn/boundary/realizer.py:755 is return emission @ contraction (white's IsotropicEmissionOperator @ PartialCurrentOperator, landed at G6.3 step 3 b4290873), and 84d7861f made the face action itself composed. ⟹ the gap at the OPERATOR layer is partly closed by a sibling campaign. B4's remaining operator-layer job is the generic dispatch, not the first use of @. The descriptor-layer gap is untouched and is the larger half.

Two live defects B4 owns

Both are recorded in the tree with B4 named as the closer:

  1. The specular corner swap is UNSCALED. orpheus/sn/operators/boundary.py:1029-1037 carries a .. warning:: ending "It closes when B4 composes :math:R \circ G here."_reflect_corner applies the geometry without the response factor.
  2. compute_keff's leakage predicate is the wrong question. orpheus/sn/solver.py:1603 tests op.law.response_kernel.is_zero where the honest predicate is R ≠ 1. Becomes reachable the moment SN: wire WhiteBoundary / PeriodicBoundary / AlbedoBoundary into SNMesh BOUNDARY_OPERATOR_REGISTRY #189 admits partial reflectors.

⚠ The stated gate is the KNOWN-BLIND shape — do not ship it alone

B4's acceptance is written as "realized operators bit-identical to today, per law per method". That is exactly the pattern the campaign already measured blind: crosswalk §15.12 (b3_domain_narrowing_crosswalk.md:1192) records [M] that under a to_local → arange mutation the route-equivalence suite read 60 passed / 0 failed while the operator was wrong on 3 of 5 quadratures — because a shared body makes an gate compare a value with itself.

⟹ the catchers are the independent hand-built expression anchors, and the memo's own instruction is that "those must not be deleted later as redundant." A B4 that unifies the body and then leans on route-equivalence has no gate at all.

Related, and where the boundary sits

Delegation posture

Surgical-carve family (.claude/rules/delegation.md): main agent writes directly with the user steering; method-implementer is NOT dispatched. test-architect is warranted before the carve — this crosses the realizer, the descriptor algebra and the factor tier.

Metadata

Metadata

Assignees

No one assigned

    Labels

    level:L0Term verificationmodule:geometrygeometry/ mesh infrastructuremodule:sn02.Discrete.Ordinatestype:improvementEnhancement to existing functionality

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions