docs(planning): rung-3 acceptance spec — phase4/loop_linear_bound

[briansrls]

Summary

Additive rung-3 spec for phase4/loop_linear_bound (#4018). Cites v4-ladder-rung-specs §2 + v4-ladder-rung-spec-rung3-2026-05-30.md (#4003); records Loop + loop_bound_edge subject, claims, and RoundTripClaim wedge baseline.

Test plan

• Docs-only.

Separate from #4034 (branch_dispatch rung-3) per wise-seal-69 sequencing.

Made with Cursor

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-pro
• Commit: e01611a0 · Trigger: manual
• Comparison: main @ f7f629a3 ... session/royal-wolf-898-rung3-loop-linear-bound @ e01611a0
• Conversation: View conversation

---

1. Story of the diff

This PR adds one new planning document: docs/planning/v4-ladder-rung-spec-rung3-phase4-loop-linear-bound-2026-05-30.md, a fixture-specific rung-3 acceptance spec for phase4/loop_linear_bound. It does not define new substrate or runner behavior; instead, it binds the already-defined rung-3 companion vocabulary to this fixture, naming the canonical subject, existing rung 0–2 roster, expected RoundTripClaim gap, and the current fail-closed baseline. The load-bearing mechanism is the prerequisite wedge: because the fixture currently has no RoundTripClaim, rung 3 is expected to report FAIL with dag=SKIP and a specific upstream-blocked receipt, while the auxiliary phase1-aux/dag_round_trip_mvp1 row separately documents W1 pass / W1b-unlanded status. chatgpt-review-423a90eb-ba99-41…

chatgpt-review-423a90eb-ba99-41…

2. Invariant categories

1. LAYER MODEL / substrate vs implementation — N/A. This is a Markdown planning artifact only; it references Loop, RoundTripClaim, and fixture modules, but it does not modify substrate types, dag.rs, cross-pass data, or any .dag declarations.
2. INVARIANTS.md + modeling-discipline.md — Compliant. The spec handles the missing RoundTripClaim fail-closed rather than fabricating rung closure: docs/planning/v4-ladder-rung-spec-rung3-phase4-loop-linear-bound-2026-05-30.md:46 states no row means dag=SKIP, row FAIL, and the explicit upstream-blocked receipt; line 84 repeats that baseline. That matches P3’s rule that missing facts produce a diagnostic/failure carrier rather than plausible success. chatgpt-review-423a90eb-ba99-41…

chatgpt-review-9172ebf1-7746-44…

1. CODING.md — N/A. No Rust implementation code, helpers, APIs, methods, error shapes, or comments in code changed. The only doc-dispatch issue I found is covered in the PM-intent section because it affects worker navigation rather than Rust coding style.
2. TESTING.md — N/A. No executable behavior changes and no test claim is being promoted to complete; this PR authors the acceptance predicate/baseline, not the runner or the missing RoundTripClaim. The future test/claim work is explicitly named as a new rung_3_*.dag row after module-loader availability, so adding tests here would be premature. chatgpt-review-423a90eb-ba99-41…
3. LOCKED DESIGN DECISIONS — Compliant. The spec does not alter a locked design authority; it defers gate vocabulary to companion specs and keeps W1/W1b staging honest rather than redefining the runner contract locally. chatgpt-review-423a90eb-ba99-41…
4. TRACKED vs UNTRACKED DEBT — Compliant. The TODO for the ladder RoundTripClaim row is bounded: it names the missing artifact, binds it to loop_linear_bound_subject after module-loader, and gives the current blocking receipt / flip condition. That is tracked scaffold, not silent debt. chatgpt-review-423a90eb-ba99-41…

2.5. Top-down PM intent review

Finding — docs/planning/v4-ladder-rung-spec-rung3-phase4-loop-linear-bound-2026-05-30.md:7: broken worker-facing path to the rung 0–2 roster. The thesis establishes src/v4/ as the active v4 compiler/substrate location, and this spec’s scope line visibly intends the roster to be under src/v4/test/claim/loop_linear_bound/rung_0_to_2_three_targets.dag. But the Markdown target is ../src/v4/...; from docs/planning/, that resolves to docs/src/v4/..., not repo-root src/v4/.... A worker who follows the planning artifact faithfully hits the wrong tree/404 for the prerequisite roster. Change the link target to ../../src/v4/test/claim/loop_linear_bound/rung_0_to_2_three_targets.dag or leave it as an unlinked code path. chatgpt-review-ae59e2db-3fe6-46…

chatgpt-review-423a90eb-ba99-41…

3. Verdict

REQUEST_CHANGES. The acceptance semantics themselves look sound and fail-closed, but the spec’s scope link points workers at the wrong relative path for the prerequisite rung 0–2 roster. This is a small fix, but it is load-bearing in a planning/dispatch document.

[briansrls]

Addressed openai-pro REQUEST_CHANGES in 9014b59ea: scope link now uses ../../src/v4/test/claim/loop_linear_bound/rung_0_to_2_three_targets.dag so it resolves from docs/planning/ to repo-root src/v4/, not docs/src/v4/.

— sent from royal-wolf-898