docs(planning): tighten Phase 4 rung-4 branch/loop fixture specs

[briansrls]

Summary

Addresses review feedback on the DRAFT rung-4 fixture-binding specs for phase4/branch_dispatch and phase4/loop_linear_bound:

• Explicit headline ordering: transport missing → R2 not PASS → runtime rows empty
• Separate modeling_gap vs execution_gap in worker briefs (no implied SG dispatch from these docs)
• loop_bound_edge failures route through existing T-12 / SG-1 Loop-bound lane
• Blocked-aggregate wording for FAIL with all SKIP cells
• Phase 4 scope note (rung 4 only; rungs 7–9 still open)
• Loop doc aligned with branch doc (rung-3 independence, host closure row, baseline table)

Test plan

• Docs-only change; no code or CI targets affected
• Reviewed against May 30 fixture-binding review comments

[briansrls]

Review metadata

• Provider / model: openai-pro / gpt-5-5-thinking
• Commit: 21fcc0f9 · Trigger: manual
• Comparison: main @ 117dc50f ... session/bright-lynx-891 @ 21fcc0f9
• Conversation: View conversation

---

1. Story of the diff

This PR tightens two Phase 4 rung-4 fixture planning specs so future workers do not confuse “rung blocked by missing execution infrastructure” with “fixture evaluation attempted and failed.” For both branch_dispatch and loop_linear_bound, it replaces the older “two states, one headline” wording with an explicit prerequisite order: host transport first, then R2-rust-compile, then runtime-value row roster population. The worker briefs are also split into modeling vs execution gaps, which makes the dispatch instruction sharper: do runner/roster work when transport exists, and do not spawn local SG/modeling work from these rung-4 docs unless the separate modeling worksheet/lane says so. The loop fixture spec additionally quarantines the known loop_bound_edge Symbol-tag debt to its existing SG-1/T-12 lane instead of letting this rung-4 spec become a competing modeling authority.

2. Invariant categories

1. LAYER MODEL (substrate vs implementation).

N/A — the diff is planning-doc-only; it does not touch .dag substrate types, dag.rs, compiler implementation, or runtime carriers. The docs explicitly keep the missing closure/row roster as fixture activation work rather than introducing substrate shape changes at docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:21 and docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:19.

1. INVARIANTS.md + modeling-discipline.md.

Compliant — Boundary Discipline / single-authority is improved: both specs name one headline ordering chain instead of leaving per-cell SKIP receipts and headline status partially conflated. Branch dispatch does this at docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:50-56; loop linear bound mirrors it at docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:40-46. Progress-is-dissolution is also respected because the loop spec routes loop_bound_edge Symbol-tag debt to the existing SG-1/T-12 lane rather than creating a new local modeling authority at docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:22.

1. CODING.md.

Compliant — although this is markdown, the comment/prose discipline analogue is handled well: the worker briefs now use named fields (modeling_gap, execution_gap, predicate) instead of the ambiguous “modeling_gap=none (W3 roster + transport)” shorthand. See docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:81-86 and docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:71-76.

1. TESTING.md.

N/A — no executable behavior or test harness is changed. The docs clarify expected blocked aggregate state and future PASS/FAIL transition semantics rather than adding a new behavior needing a test: docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:70 and docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:60.

1. LOCKED DESIGN DECISIONS.

Compliant — the PR does not alter a locked substrate/design decision; it narrows scope language to avoid overclaiming Phase 4 completion. Both specs explicitly say rung 4 only and preserve the broader Phase 4 remaining-rungs scope at docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:58 and docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:48.

1. TRACKED vs UNTRACKED DEBT.

Compliant — the PR does not introduce new untracked scaffolding. Existing gaps are named with bounds and routing: closure/runtime roster work is fixture activation follow-up (docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:94-95, docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:84-85), host carrier work is pending phase4 host gate/script follow-up (docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:20), and Loop-bound modeling debt is assigned to SG-1 DFS / T-12 (docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:22).

2.5. Top-down PM intent review

Compliant — the highest-level intent here is to make rung-4 planning dispatchable without semantic dilution: prove emit-equals-eval only after execution infrastructure exists, keep blocked aggregate state honest, and avoid turning fixture-local planning docs into modeling authority. The diff preserves that intent by separating execution gaps from modeling gaps (docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:81-86, docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:71-76) and by explicitly saying Phase 4 is not complete just because these rung-4 bindings exist (docs/planning/v4-ladder-rung-spec-rung4-phase4-branch-dispatch-2026-05-30.md:58, docs/planning/v4-ladder-rung-spec-rung4-phase4-loop-linear-bound-2026-05-30.md:48). I do not see a worker-following-this-faithfully path that would execute the wrong work.

3. Verdict

APPROVE. The PR is a docs/planning clarification that improves single-authority dispatch semantics and reduces overclaim risk. I found no blocking invariant, testing, or PM-intent issue in the changed lines.