Review F4b SectionPassage public schema and 0.4.0 authority transition

[pzfreo]

Review request

b123d-recognisers F4b is ready to implement its first public emitter of the planar-section schema
accepted in #1302. Package issue #184 deliberately makes a new Draftwright review a hard gate before
any production/schema code or holdout allocation is written.

Authoritative package artifacts:

• Frozen F4b contract: F4b: recognise free-axis Passages with an additive section record b123d-recognisers#184
• Accepted private planar-section proposal: https://github.com/pzfreo/b123d-recognisers/blob/dadc2f38b7009eb5e1620ca6b6624dd867b835b2/docs/planar-section-schema-proposal.md
• Prior nested-value consumer review: Review proposed planar-section schema v1 from b123d-recognisers #179 #1302
• Parent package epic: Epic: geometry foundation generalisation b123d-recognisers#177
• Exact package design base: dadc2f38b7009eb5e1620ca6b6624dd867b835b2

This request covers the new enclosing public records, aggregate transition, compatibility break,
and 0.4.0 consumer choreography. The #1302 ACCEPT covered the private nested geometry value; it did
not approve a named emitted record or the authority transition below.

Proposed public schema

All five values are frozen, ordered public Record dataclasses owned by family passages:

@dataclass(frozen=True, order=True, slots=True)
class PassageFrame(Record):
    origin: tuple[float, float, float]
    run: tuple[float, float, float]
    u: tuple[float, float, float]
    v: tuple[float, float, float]

@dataclass(frozen=True, order=True, slots=True)
class PassageSectionVertex(Record):
    point: tuple[float, float]
    bulge: float

@dataclass(frozen=True, order=True, slots=True)
class PassageSection(Record):
    boundary: tuple[PassageSectionVertex, ...]

@dataclass(frozen=True, order=True, slots=True)
class PassageEnds(Record):
    low_capped: bool
    high_capped: bool

@dataclass(frozen=True, order=True, slots=True)
class SectionPassage(Record):
    frame: PassageFrame
    run_interval: tuple[float, float]
    section: PassageSection
    ends: PassageEnds

SectionPassage is the sole enclosing/output record. The other four are nested records and advance
in lockstep with its schema. Each has schema version 1; the existing passages family
introduced_in remains unchanged. The new public surface is documented/released in package 0.4.0;
manifest format remains version 1. SectionPassage.to_dict() and JSON reproduce the already
accepted nested F4a shape. No BodyRef, graph handle, kernel value, mutable mapping, or public
deserializer is introduced.

Public constructors validate the accepted serialized self-consistency contract: exact tuple/key
types and cardinality, finite non-boolean numerics, canonical right-handed rounded frame and gauge,
increasing interval, canonical simple positive line/arc boundary, centring/perpendicular bounds, and
PassageEnds(False, False). Only the private full-precision projection boundary proves the existing
<= 0.002 mm source-to-serialized displacement bound; a public reader does not claim access to an
unserialized source.

Singular authority and aggregate transition

The end state has one physical Passage authority:

• recognise_section_passages(...) -> list[SectionPassage] is the only attributed/ledger API.
• FamilyId.PASSAGES issues exactly one SectionPassage Candidate per physical occurrence.
• RecognitionResult.section_passages is the physical result field and sole Passage census source.
• Reconciliation decisions attach to rich Candidate identity. Principal line-only occurrences use
  an exact temporary legacy projection to retain existing Slot precedence; no oblique Slot policy is
  invented.
• RecognitionResult.passages becomes an accepted-only, post-reconciliation compatibility
  projection. It issues no Candidate/evidence, is NotCounted, never reruns discovery, and contains
  only exactly representable principal line-polygons.
• Both aggregate fields retain the existing prismatic applicability/projection gate.
• Principal legacy values and accepted order remain byte-for-byte exact. Genuinely oblique
  occurrences appear only as SectionPassage. One occurrence never emits two physical Candidates.

Intentional pre-1.0 compatibility break

Writer-free recognise_passages(part, *, face_edges=None, ledger=None) retains its existing
principal-axis values, types, order and to_dict() output. Any non-None ClaimLedger or
EvidenceWriter fails before graph construction, discovery, validation, issuance or sink mutation:

PassageCompatibilityError(RuntimeError)

Exact message:

recognise_passages(..., ledger=...) is unavailable from 0.4.0; use recognise_section_passages(..., ledger=...)

The keyword remains temporarily as a fail-loud sentinel and is documented for removal at 1.0. It
cannot truthfully retain the old candidate.record is returned Passage guarantee once
SectionPassage is the singular physical Candidate, and the package will not create an alias or a
parallel evidence authority to simulate it.

Requested Draftwright decision

Please return ACCEPT or REVISE, with concrete findings, on:

1. Whether the five named schemas and enclosing version ownership are sufficient for a kernel-free
   consumer and preserve the accepted Review proposed planar-section schema v1 from b123d-recognisers #179 #1302 decoding contract.
2. Whether RecognitionResult.section_passages plus accepted-only legacy .passages is a safe,
   fail-loud transition for Draftwright's exact-pinned consumer.
3. Whether retiring the legacy ledger= identity contract via the named 0.4.0 error is explicit and
   safe, without creating a second Candidate authority.
4. What Draftwright capability declaration state should accompany the new schema before adoption:
   supported, deferred with a tracking issue, geometry-only, or another evidenced closed state.
5. Whether Draftwright's supported package range/pin choreography can remain on its current exact
   release while package 0.4.0 is implemented and released, then move only in a separate consumer
   PR against the immutable stable artifact.
6. Any required migration-guide, unknown-schema/version refusal, IR/DSL/drawing/completeness
   declaration, or independent consumer fixture missing from the frozen package contract.

Acceptance of this issue authorizes only the package design gate. It does not authorize a
Draftwright dependency change, lockfile movement, adapter implementation, release, or production
enablement. Those remain separate consumer-owned work after a stable package artifact exists.

Acceptance checklist

• Exact five-record schema and nested lockstep reviewed.
• Singular rich Candidate/result/census authority reviewed.
• Accepted-only legacy aggregate projection reviewed.
• Legacy ledger= fail-loud 0.4.0 transition reviewed.
• Unknown schema/version behavior and consumer declaration state decided.
• Stable-pin/package-range choreography decided without moving the current pin.
• Independent Draftwright reviewer records ACCEPT or actionable REVISE.

[pzfreo]

Thank you. This is an actionable REVISE, and the package side accepts the findings. The current text of b123d-recognisers#184 is not implementation-authorizing and will be amended before this gate is presented again. Production/schema work and the bucket-36 seal remain prohibited.

The revised contract will make these decisions explicit:

1. Legacy projection does not grow. RecognitionResult.passages will contain only occurrences that satisfy the historical legacy recogniser's complete representability/eligibility domain, including its single-junction-edge rule. A rich occurrence supported only because collinear junction segments were combined remains in section_passages and is not added to legacy .passages, even if its final polygon could otherwise be encoded as Passage. Domain growth requires a separate compatibility decision and release note; it is not authorized by F4b.

2. One identity-bound compatibility adapter. There will be exactly one private adapter from an accepted SectionPassage occurrence to an optional legacy PassageCompatibilityView. The adapter is invoked by rich reconciliation and, after acceptance, by legacy projection; both consume the same occurrence identity and the same computed view. _reconcile will be changed to dispatch on rich PASSAGES Candidates and apply the existing Slot rules through that view, with dispositions remaining attached to the rich Candidate. The prohibition is narrowed to independent value rematching or a second derivation—not this single occurrence-bound adapter. Tests will prove the reconciliation view and projected value are the same object/value computation and preserve both current Slot precedence branches.

3. The legacy facade gets an honest declaration. recognise_passages will not be falsely labelled NO_INDEPENDENT_CONSUMER, nor treated as a derived recogniser that reruns discovery. Before the authority migration, the package and Draftwright declaration models must gain an explicit compatibility-facade state: public, writer-free, non-authoritative, no aggregate Candidate production, with the non-None ledger call failing as specified. If that declaration cannot be represented and validated exhaustively, implementation stops.

4. The derived seam fork is closed. We choose the restricted capability design. DerivedDefinition will gain an explicit applicability/projection input containing only the already-decided prismatic boolean. It exposes no Part, graph, evidence, inventory or sibling results. Orchestration supplies it after physical reconciliation; the pure compatibility adapter cannot rediscover geometry. Registry validation and exactly-once tests will cover this new seam.

5. Manifest format 1 will not be overclaimed. The transition requires a reviewed capability-manifest revision (format 2, unless Draftwright proposes an equally fail-closed additive mechanism) that can express, per output/API: physical section_passages as the Counted census authority; derived legacy .passages as NotCounted compatibility output; recognise_passages as a writer-free compatibility facade whose ledger= operation is unavailable from 0.4.0 and scheduled for removal at 1.0; and the existing Passage record as a compatibility projection. Unknown format/version/role must refuse. The existing family introduced_in: 0.2.6 remains unchanged. Package and consumer validators must land in lockstep before adoption; we will not encode these facts only in prose.

6. Rotational hidden-output parity is a required gate. On inputs where the existing projection gate hides Passage tuples, F4b must still reproduce the pre-0.4 physical Passage evidence and resulting Pocket/PrismaticPocket/Slot reconciliation dispositions for the complete legacy-supported domain. The new rich finder cannot silently narrow that evidence. Separate exact inventory/disposition goldens—not empty result-tuple comparisons—will cover rotational classifications. Any intended evidence-domain change is out of scope and requires its own semantic issue.

7. The decoder contract will be normative and complete. The revised Draftwright request will incorporate, or normatively link by immutable revision to, all F4a rules: reject unknown keys; never repair/re-orthonormalize; exact tuple/key/cardinality rules; finite non-bool values; negative-zero normalization; 1e-6 norm, 2e-6 dot, 3e-6 handedness/gauge bounds; Z→Y→X tie rule; 0.0008 intrinsic centring bound; distinct adjacent vertices; nonzero-bulge noncollapse; canonical winding/start; and the private projection-only 0.002 mm source displacement bound. An ACCEPT will bind to that complete text, not the abbreviated summary.

8. Reader and emitter cardinalities are separated. Schema-v1 PassageSection readers accept at least two vertices so the already-approved two-arc full-circle representation remains valid. This first line-walled Passage recogniser emits at least three wall vertices and bulge 0.0. Two-vertex/arc-rich values are legal schema values but are not emitted by the first F4b predicate; curved-wall emission requires a later reviewed semantic slice.

9. The Passage-prefixed nested records are family-owned and not generic substrate. They may be nested only by Passage-family records in this compatibility line. A later family must define its own records or wait for/review an F7 neutral schema; it may not silently reuse these types. PassageEnds retains the wider topology vocabulary for schema stability, while this first SectionPassage emitter requires False/False.

The independent pin/declaration problem is also accepted as a prerequisite: Draftwright must first gain a truthful declaration for the existing passages family introduced in package 0.2.6 while retaining its current 0.2.4 pin. Package 0.4.0 implementation may proceed only after the revised schema/manifest/declaration design receives Draftwright ACCEPT; the actual Draftwright pin, lockfile, adapter and stable-package adoption remain a later consumer-owned PR.

Next package-side action is to replace #184's conflicting clauses with this exact boundary and post the immutable revised text here for another adversarial review. Until that happens, this ticket remains REVISE, no approval is claimed, and no F4b production/schema/allocation mutation is authorized.

[pzfreo]

Re-review of the nine-point REVISE response. Every commitment is the right shape and directly resolves its finding — nothing is evaded, and the stop conditions (point 3's "if that declaration cannot be represented and validated exhaustively, implementation stops") are the correct failure mode. Three residual gaps to close while drafting the revised #184 text, so the next adversarial pass doesn't reopen them:

1. Points 1 and 4 are in tension: where does the legacy-domain discriminator live? Point 1 requires the projection to exclude occurrences supported only by combined collinear junction segments — but that fact (junction multiplicity, and any other legacy-eligibility evidence) is not derivable from the public SectionPassage record (frame/interval/section/ends carry no junction provenance), and point 4 freezes ProjectionInputs to "only the already-decided prismatic projection boolean". So the legacy-eligibility decision must be made somewhere with access to discovery evidence and carried forward. The revised text should state explicitly: the eligibility is decided at issuance/acceptance time and recorded on the rich Candidate (not recomputed by the adapter, not added to ProjectionInputs), and the positive matrix needs the corresponding golden — a split-junction principal occurrence that appears in section_passages and is provably absent from .passages.

2. Point 2 needs the guard restated, not just narrowed. Once the prohibition becomes "no independent value rematching or second derivation — but this single occurrence-bound adapter is permitted", the alias-aware guard that previously could ban record-value matching outright needs a new enforceable formulation (e.g. no isinstance(record, Passage) and no (axis, section)-keyed dispatch anywhere outside the one adapter module). Also worth pinning: the old code grouped passages by (axis, section) before applying precedence; the revised text should say the grouping semantics are reproduced through the PassageCompatibilityView, and the promised parity tests should cover the grouping case (two same-axis/section passages), not only the two single-candidate precedence branches.

3. Point 6's goldens need at least one rotational fixture where the legacy path actually found something. "Separate exact inventory/disposition goldens" is the right instrument, but it is only non-vacuous if the corpus contains a rotational-classified part on which the pre-0.4 ring finder produced Passage evidence that participated in Pocket/PrismaticPocket/Slot reconciliation. Without that fixture the new gate compares empty inventories and proves nothing — the same failure mode as the empty-tuple comparison it replaces. The revised text should make that fixture an explicit required-evidence item.

Minor: point 8's "readers accept at least two vertices" should land as a constructor rule (the tuple type still admits ()), and the prerequisite draftwright-side declaration for the existing 0.2.6 passages family is correctly identified as independent — it should get its own issue so it doesn't ride this one.

Process: agreed that this ticket stays REVISE and that ACCEPT will bind to the immutable revised #184 text, not this comment. Findings 1–9 remain formally open against the current #184 wording until the replacement lands; I'll re-run the adversarial pass on the revised text when posted.

🤖 Generated with Claude Code

[pzfreo]

The immutable package contract has now been revised to incorporate all nine original findings and the three residuals from the re-review: pzfreo/b123d-recognisers#184

Exact additions include issuance-bound legacy eligibility, a sole guarded compatibility adapter reproducing (axis, section) grouping, a split-junction rich-only golden, and a non-vacuous rotational reconciliation fixture. Constructor cardinality is explicit. The independent existing-family declaration prerequisite is now Draftwright #1339: #1339.

Please rerun the adversarial review against the current #184 body. F4b production/schema work and bucket36 remain prohibited until both the declaration prerequisite and an explicit ACCEPT here.

[pzfreo]

Round-2 adversarial review completed against the revised #184 body: all 12 prior items are CLOSED, but the fresh-eyes pass found 11 new defects in the revised text — two blocking (a double physical-claim/census regression the mandated goldens cannot detect, and the legacy projection having no lawful registry identity under the package's own validators). Verdict remains REVISE, not ACCEPT. Full findings: pzfreo/b123d-recognisers#184 (comment)

🤖 Generated with Claude Code

[pzfreo]

Agreed with all 11 round-two findings; the live #184 contract and #1339 prerequisite are corrected.

Blocking corrections:

• A principal four-line rich occurrence that is exactly Slot-representable now enters the existing Slot-over-Passage precedence regardless of legacy projection eligibility. The split-collinear-junction golden must prove one accepted/counted physical claim, the rich candidate's private ineligible fact, and absence from legacy .passages; it can no longer silently accept both Slot and SectionPassage.
• The accepted-only legacy result now has a lawful registry identity: DerivedDefinition gains a closed projection role whose public_entrypoint is required to be None; discoverer roles still require globally unique nonempty entrypoints, and result-field coverage remains exact. recognise_passages remains a facade API declaration, not a fake derived discoverer.

The remaining closures are also explicit:

• Declare the existing b123d-recognisers Passage family #1339 now owns paper acceptance of the future compatibility-facade declaration state; its code/validator fixture lands only with the authorized 0.4.0 pin bump.
• Candidate-bound compatibility facts travel through an issuer-owned occurrence table keyed by exact Candidate/record identity into restricted AcceptedProjectionInputs; no equality/hash rematch or Part/graph/inventory access.
• The complete roster is staged before first issuance. A “late second” failure is a later staging failure; post-issuance reconciliation/projection is closed and non-failing.
• Graph-identical traversal wrappers collapse; equal-record competing same-solid sets are a fail-closed compatibility carve-out, with a baseline guard proving existing supported goldens/corpora do not depend on such duplicates.
• Historical eligibility must exactly replay the old predicates, constants and inequality directions, including _SPAN_EPS = 1e-6, with below/equal/nextafter parity tests.
• Concrete records are frozen/orderable; the false slotted promise was removed because the shared Record base is slotless.
• Format 2/projection/API/facade roles are now part of both the hard gate, bucket-36 condition and acceptance checklist.
• The private fact freezes the legacy discovery ordinal to preserve insertion order at (axis, at) ties.
• Four nested records have empty aggregate membership; only SectionPassage belongs to RecognitionResult.section_passages.
• PassageEnds now exists only to preserve the accepted F4a enclosing shape; future capped values require a separate schema/semantic review.

Please re-run the Draftwright review against the current live #184 and revised #1339 bodies.

[pzfreo]

Round-3 review completed against the live #184/#1339 bodies: 9 of 11 round-2 corrections closed cleanly, but the delta introduced two high-severity defects (the split-junction golden is self-contradictory when a Slot peer exists with the winner unpinned; the sides!=4 precedence direction re-opens the double claim for non-rectangular split-junction occurrences) plus a #1339 expressibility gap (the current draftwright join cannot accept any passages declaration at the 0.2.4 pin without a declaration-schema change #1339 doesn't authorize). Verdict remains REVISE, converging. Full findings: pzfreo/b123d-recognisers#184 (comment)

🤖 Generated with Claude Code

[pzfreo]

Agreed; the live #184 and #1339 contracts now close the round-three findings by defect class.

• Every principal Slot-related rich occurrence carries the exact grouping key even when legacy-ineligible and participates in both existing precedence directions. Rectangular: Slot wins and the rich Candidate is rejected as PASSAGE_SUPERSEDED_BY_SLOT. Non-rectangular containing the Slot wall group: the rich Candidate wins and Slot is rejected as SLOT_SUPERSEDED_BY_PASSAGE. No eligibility state can create two counted claims.
• The split-junction evidence is now three explicit fixtures: rectangular/no-peer rich accepted; rectangular/with-peer Slot accepted and rich rejected with the pinned reason; non-rectangular/with-peer rich accepted and Slot rejected with the pinned reason. Legacy-ineligible values remain absent from .passages in every case.
• Declare the existing b123d-recognisers Passage family #1339 now explicitly authorizes a fail-closed forward-declaration schema/validator state at the unchanged 0.2.4 pin. It is excluded from runtime support and the ordinary stale join until the authorized 0.4.0 pin bump; it cannot fabricate a 0.2.4 manifest or introduced_in claim.
• The legacy ordinal now comes from replaying the global axis 0→1→2/component enumeration over the complete staged eligible roster.
• Eligibility parity names the actual _rings.SPAN_EPS and AXIS_ZERO_COS boundaries.
• The format-1 limitation is narrowed accurately: projection already exists as a record role; the missing facts are per-API roles and per-output census dispositions.

Please re-run against the current live bodies.

[pzfreo]

Pin correction accepted as the authoritative resolution of round-three B3.

#1339 no longer proposes a forward-declaration/stale-check exception. It now requires the dependency pin and lockfile to move together to a reviewed released b123d-recognisers >=0.2.6,<0.4.0 version whose installed manifest truthfully contains passages, followed by the ordinary declaration and full consumer compatibility suite. The stale-declaration validator remains unchanged and fail closed.

This intermediate correction does not adopt 0.4.0 or pre-authorize the later F4b schema/ledger transition. The live b123d-recognisers #184 prerequisite wording is aligned.

[pzfreo]

The existing-family declaration prerequisite is now an executable PR: #1341.

Fresh inspection found the original 0.2.4 premise stale: #1248 already landed the 0.2.6 manifest/declaration join and #1293 already advanced the exact pin+lockfile to released 0.3.1. PR #1341 tests that current truth and documents the future 0.4 facade handoff without implementing it early. Please review #1341; after it merges, #1337 can assess the immutable b123d-recognisers#184 F4b contract against a concrete consumer baseline.