T-38B lens_ownership: subject roster + run_test_claim wiring + family CI receipt

[briansrls]

Summary

Adds the T-38B lens_ownership family receipt: a subject roster for the resource-dependency ownership claim, a workflow evaluator that maps that roster through run_test_claim, and CI model wiring for the family command/frontier.

This keeps the ownership family visible as a structured TestClaimRun surface instead of a loose source-shape check.

Test plan

• python3 scripts/check_t38b_lens_ownership.py — passed
• python3 scripts/test_check_t38b_lens_ownership.py — passed
• python3 scripts/check_t19_testgen_activation.py — passed
• ctrl-build -- cargo test -p v3-compiler --test integration v4_workflow_ci_runner -- --quiet — passed, 39 tests
• ctrl-build -- cargo test -p v2-compiler-tests v4_workflow_ci_runner -- --quiet — built successfully but matched 0 tests; reran the correct v3-compiler --test integration command above

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 9aaddc79 · Trigger: schedule
• Thinking: 266s wall

---

BLOCKING (1)

Root Cause

• src/v4/test/claim/lens_ownership/subject_roster.dag LensOwnershipSubject stores the real structural_witness beside eval_subject, but the runner consumes only lens_ownership_node_subject_rows → make the ownership witness the evaluated TestClaim fact or have the family runner fold LensOwnershipSubject rows and gate the witness with the run verdict.

⚠️ The family CI receipt can currently go green while the lens_ownership resource-dependency witness is false.

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: c0ea91b8 · Trigger: manual
• Comparison: main @ c7d9f99d ... session/royal-otter-710 @ c0ea91b8
• Conversation: View conversation

---

1. Story of the diff

This PR takes the existing lens_ownership/resource_dependency claim and turns it into a family-level TestClaim surface: subject_roster.dag wraps the ownership witness into claim_lens_ownership_resource_dependency, creates a TestClaimEvalSubject<Node>, and exposes a LensOwnershipSubject roster plus a projected node-subject row list. chatgpt-review-d7efe13c-98b2-46…

The new family evaluator then maps those roster rows through run_test_claim, folds the resulting verdicts into a tally, requires all structural witnesses to hold, fail-closes an empty roster, and emits witness_lens_ownership_family_gate_closed. chatgpt-review-d7efe13c-98b2-46…

Finally, ci.dag models a new LensOwnershipFamilyEvalCommand, a verdict-surface authority, a job/gate pair, command/surface projection nodes, upsert inputs, and component-mask coverage so the family receipt becomes part of the modeled CI graph rather than a host-only status string. chatgpt-review-d7efe13c-98b2-46…

2. Invariant categories

1. LAYER MODEL — Finding. This is not implementation-only: the PR extends modeled workflow substrate in src/v4/workflow/ci.dag with LensOwnershipFamilyEvalCommand at src/v4/workflow/ci.dag:158 and LensOwnershipFamilyVerdictSurfaceAuthority at src/v4/workflow/ci.dag:185. The new CI frontier then declares data ci_lens_ownership_family_eval_claim_ids: List<Symbol> at src/v4/workflow/ci.dag:1062 and explicitly says it “mirrors the family roster” at src/v4/workflow/ci.dag:1060-1061, while the actual family roster is independently authored at src/v4/test/claim/lens_ownership/subject_roster.dag:85-90. That makes the CI claim frontier a second source of the same family membership fact; a future roster addition can update lens_ownership_subject_roster and be run by run_lens_ownership_family_eval at src/v4/test/claim/workflow/lens_ownership_family_eval.dag:41 while being absent from the CI claim-ref inputs folded from ci_lens_ownership_family_eval_claim_ids at src/v4/workflow/ci.dag:1072-1075. Boundary/model facts should flow from one authority, not from a manually mirrored list. The invariants name this as P2 Boundary Discipline: every fact lives in exactly one authoritative place, and parallel authorities drift. chatgpt-review-1834db06-9ea6-44…
2. INVARIANTS.md + modeling-discipline.md — Finding. Same blocking issue under P2 Boundary Discipline / single authority and P5 Progress Is Dissolution: src/v4/workflow/ci.dag:1060-1063 introduces a mirrored claim-id roster instead of deriving CI claim inputs from the lens_ownership_subject_roster surface or marking the mirror as a bounded bridge with its own local dissolution trigger. The new subject type also shows why this should be single-sourced: LensOwnershipSubject carries claim: TestClaim and eval_subject: TestClaimEvalSubject<Node> at src/v4/test/claim/lens_ownership/subject_roster.dag:61-64, while subject_lens_ownership_resource_dependency is already constructed with the claim at src/v4/test/claim/lens_ownership/subject_roster.dag:77-81 and the runner consumes only subject.eval_subject at src/v4/test/claim/workflow/lens_ownership_family_eval.dag:35. The CI list is therefore not a shared read of a resolved fact; it is another independently editable representation of family membership. Fix by deriving the CI claim-ref inputs from the family roster/canonical subject rows, or by landing an explicitly tracked bridge on the mirrored list itself with bound + owner/lane + named dissolution trigger.
3. CODING.md — Compliant. The new Python checker keeps I/O at the script edge (_read fails closed on missing files at scripts/check_t38b_lens_ownership.py:16-19) and the .dag code is mostly data plus small free functions: run_lens_ownership_subjects, lens_ownership_family_report_tally, lens_ownership_structural_witnesses_hold, and lens_ownership_family_gate each expose a narrow input→output shape. chatgpt-review-d7efe13c-98b2-46…

The comments are mostly load-bearing scope/status headers rather than prose compensating for unclear control flow, which fits the CODING.md comment discipline. chatgpt-review-7da3090a-f3a2-4d…

1. TESTING.md — Compliant with one caveat covered by the finding above. The PR adds .dag TestClaim data for the actual behavior and routes it through run_test_claim, which is the right direction for the project’s “tests are data” intent. chatgpt-review-d7efe13c-98b2-46…

The Python receipt is a host-side shape checker, but it is framed as a receipt for wiring rather than the behavioral authority; the behavioral surface remains the modeled TestClaim and family evaluator. The caveat is that the checker currently blesses the mirrored CI claim list instead of forcing derivation from the roster; that is the single-authority finding, not a separate test-style finding.

1. LOCKED DESIGN DECISIONS — N/A. I do not see this diff altering a locked thesis/design decision. The PM-level direction it touches—CI as modeled .dag workflow and tests as TestClaim data—is preserved rather than redefined. chatgpt-review-f226291a-948e-48…
2. TRACKED vs UNTRACKED DEBT — Finding. The new workflow header says explicit family rosters can exist “until generated item-registry reflection replaces explicit family rosters” at src/v4/test/claim/workflow/lens_ownership_family_eval.dag:3, which is a reasonable dissolution trigger for the family-roster scaffold. But the separate CI mirror at src/v4/workflow/ci.dag:1060-1063 does not carry the same tracked-bridge contract locally: it documents that it mirrors the roster, but it does not name the bound/dissolution trigger that makes this second representation safe. Since P5 requires scaffolds and parallel representations to have explicit dissolution paths, the CI mirror should either derive from the roster or be marked as a bounded bridge with a checkable trigger in the same place it is introduced. chatgpt-review-1834db06-9ea6-44…

2.5. Top-down PM intent review

Finding. The high-level intent is that correctness and test surfaces are structurally derived from modeled data rather than hand-maintained behavioral or roster assertions; the thesis says correctness dimensions are structural facts and Tier 3 test surfaces are TestClaim data, not hand-authored behavior assertions. chatgpt-review-f226291a-948e-48…

The PR mostly follows that intent by adding TestClaim and run_test_claim wiring, but src/v4/workflow/ci.dag:1060-1063 semantically dilutes it by making CI claim membership a manually mirrored list next to the subject roster. A worker following this faithfully could add the next LensOwnershipSubject row and believe the family evaluator is complete while forgetting the separate CI frontier list, which is exactly the kind of cross-layer drift the PM intent is trying to eliminate.

3. Verdict

REQUEST_CHANGES. The core family-eval shape is good, but the new CI claim frontier is a second authority for the same family membership represented by lens_ownership_subject_roster. Please derive CI claim inputs from the canonical roster, or make the mirror an explicitly bounded tracked bridge with a local dissolution trigger so future roster changes cannot silently drift.

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: c0ea91b8 · Trigger: schedule
• Thinking: 347s wall

---

BLOCKING (1)

Root Cause

• src/v4/test/claim/lens_ownership/subject_roster.dag The subject roster is modeled as a manually assembled bundle of parallel claim facts → derive claim_id, structural_witness, and eval_subject from one claim authority via a constructor/accessor surface, or remove the parallel field that is not consumed.

⚠️ One substrate-level authority drift remains in the new roster shape.

[briansrls]

Review feedback addressed (commit 5d9f450)

Codex — structural_witness must gate the family receipt

Valid, fixed. Removed the LensOwnershipSubject wrapper that stored structural_witness beside eval_subject. The family evaluator now:

• runs lens_ownership_subject_rows directly through run_test_claim
• gates witness_lens_ownership_family_gate_closed on lens_ownership_structural_witnesses_hold(), which reads the single authority ownership_resource_dependency_claim_passes from resource_dependency.dag (not a roster-local bool that could drift)

Codex — parallel claim_id / structural_witness / eval_subject authorities

Valid, fixed. Roster is now List<TestClaimEvalSubject<Node>> with one co-located claim + subject + lens_ownership_family_claim_ids frontier in subject_roster.dag (same pattern as lens_idempotency/subject_roster.dag).

openai-pro — CI ci_lens_ownership_family_eval_claim_ids mirrored roster membership

Valid, fixed. CI imports lens_ownership_family_claim_ids from the roster module (ci_lens_ownership_family_eval_claim_ids: List<Symbol> = lens_ownership_family_claim_ids) instead of a hand-maintained parallel list.

Inline — reflexive TestClaim (lhs/rhs both ownership_root)

Not applicable to current code. The executable claim is an EqualsClaim with lhs: ownership_claim_input(ok: ownership_resource_dependency_claim_passes) and rhs: ownership_claim_pass_node() — the resource-dependency bool is in the claim surface, matching the lens_idempotency write-effect receipt pattern. ownership_root is only the infer tree root, not either claim operand.

Verification

• python3 scripts/check_t38b_lens_ownership.py — pass
• cargo test -p v3-compiler --test integration v4_workflow_ci_runner — 37 passed

— sent from sharp-wren-177

[briansrls]

Dashboard reviews (561785d)

composer-2.5 — APPROVE

No code change required. Confirmed: T-38B wiring only, claim authority on resource_dependency.dag / ownership_resource_dependency_claim_passes, checker blocks LensOwnershipSubject, modeled ci.dag is the CI surface.

claude-opus-4-7 — APPROVE (advisory: dead lens_ownership_node_subject_rows Symbol in ci.dag)

Valid, fixed in 561785d. Removed the unused data lens_ownership_node_subject_rows: Symbol from ci.dag; verdict-surface projection already binds lens_ownership_subject_rows via ci_lens_ownership_subject_roster_decl_name. The roster-module alias lens_ownership_node_subject_rows = lens_ownership_subject_rows remains for the host receipt only.

— sent from sharp-wren-177

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 11c3029d · Trigger: schedule
• Thinking: 274s wall

---

BLOCKING (1)

Root Cause

• src/v4/workflow/ci.dag CiCommand shape changed without atomically updating all construction sites → add a canonical ci_testclaim_corpus_eval_command() carrying ci_testclaim_corpus_verdict_surface_authority() and use it in job/upsert construction.

⚠️ One command-shape update is incomplete and needs to be fixed before merge.

[briansrls]

Verified the blocking TestClaimCorpusEvalCommand command-shape finding against current head f4354c6c: it is already addressed. ci_testclaim_corpus_eval_command() constructs TestClaimCorpusEvalCommand { selection_fn: ci_testclaim_corpus_selection_fn, verdict_surface: ci_testclaim_corpus_verdict_surface_authority() }, and the current ci_command_authority_ok, projection, and component-mask match sites all destructure both selection_fn and verdict_surface. The relayed review targeted stale commit 11c3029d; no current-head code change is needed for that item. — sent from royal-otter-710

[briansrls]

Outstanding blocking items verified on dad4a15772

composer-2.5 — APPROVE (2026-06-02T05:09:50Z)

No code change. Confirmed on HEAD: roster → family eval → structural witness + run_test_claim tally → gate; CI declaration-qualified authorities; ownership_resource_dependency_claim_passes gates the family receipt.

codex — missing Bool import (subject_roster.dag)

Valid, fixed in 9fed0b1663 (on branch). Added import v4.std.logic { Bool } for ownership_claim_input(ok: Bool).

codex — incomplete TestClaimCorpusEvalCommand construction (ci.dag, sha 11c3029d)

Not applicable to this PR’s delta / already satisfied on HEAD. fn ci_testclaim_corpus_eval_command() exists at ci.dag:1220 and supplies both selection_fn and verdict_surface: ci_testclaim_corpus_verdict_surface_authority(). All construction sites use it (ci_job_testclaim_corpus_eval_execution_mk command: and upsert verify/payload_type). Remaining TestClaimCorpusEvalCommand { ... } occurrences are authority-check and projection matches, not orphan constructors. This PR adds LensOwnershipFamilyEvalCommand with the parallel ci_lens_ownership_family_eval_command() pattern; it does not regress the corpus command wiring landed on main.

Inline — LensOwnershipSubject parallel authority

Stale. Type removed in 5d9f450; roster is List<TestClaimEvalSubject<Node>>; checker forbids reintroducing LensOwnershipSubject.

Inline — TestClaimCorpusEvalCommand API / verdict_surface at ci.dag:157

Stale. Line 157 is LeafModelGoVerifyCommand; corpus variant at :159 already carries verdict_surface, and constructors bind via ci_testclaim_corpus_eval_command() as above.

— sent from sharp-wren-177

[briansrls]

Dashboard reviews on dad4a15772

composer-2.5 — APPROVE (2026-06-02T05:13:49Z)

No code change. Confirmed: T-38B roster + family eval + CI upsert/verdict-surface wiring; no rubric violations on changed lines.

claude-opus-4-7 — APPROVE (advisory: lens_ownership_node_subject_rows alias)

Valid observation, intentionally kept (non-blocking). 561785d removed only the unused CI Symbol (data lens_ownership_node_subject_rows: Symbol in ci.dag); the roster-module alias lens_ownership_node_subject_rows = lens_ownership_subject_rows remains as a shared-read name aligned with manual_corpus_node_subject_rows for the host receipt script. It is not a second authority (same list value). Happy to drop alias + checker pin in a follow-up if we standardize on lens_ownership_subject_rows only.

— sent from sharp-wren-177

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: dad4a157 · Trigger: schedule
• Thinking: 344s wall

---

BLOCKING (1)

Root Cause

• src/v4/test/claim/workflow/lens_ownership_family_eval.dag LensOwnershipFamilyEvalReport reimplements the existing CorpusEvalReport/tally surface and then drifts from its report.entries non-empty contract → return/use the canonical CorpusEvalReport path and gate over the report contents.

⚠️ The family gate needs to certify the report it receives before this can merge.

[briansrls]

BLOCKING: lens_ownership_family_gate checks the global subject roster instead of the report it is certifying, so an empty or mismatched LensOwnershipFamilyEvalReport can still close when the structural witness is true, violating P2 boundary discipline/API-level enforcement.