Implement Spec Execution Policy Grill Status

Phase State

• Topic: implement-spec execution throughput and assurance policy.
• Scope boundary: requirements only; no shared-skill implementation.
• Shared-understanding confirmation: confirmed.

Branch Dashboard

Technical Grounding

Current Round

• Round: 2026-09-05 review-topology follow-up (umbrella R6)
• Prior round: R1 (closed)
• Current frontier: empty
• Shared-understanding confirmation: confirmed

Parked Branches

• Isolated worker worktrees and merger agents are rejected for the current model. Reconsider only if shared-branch isolation proves inadequate with disjoint write scopes.
• External GitHub or Codex PR reviewer integration remains outside this grill.

Glossary

Terms

• Execution Frontier: Tasks whose dependencies have passed, whose required write scopes are available, and whose declared read, write, and shared-runtime conflicts permit release now.
• Task Gate: The smallest validation and parent check that makes one completed task safe for its dependents to consume.
• Architecture Checkpoint: A declared cumulative barrier for ownership, dependency, public-seam, responsibility, and migration conformance.
• Active Write Scope: Paths exclusively owned by one currently running worker in the shared branch.
• Context Pointer: A stable reference to authoritative spec, plan, code, test, or skill content that avoids copying that content into the task brief.
• Full Code Review Pass: One complete review-phase run over a frozen change with all mandatory Code Review lenses. It does not run the product or perform Verification. Avoid: full review.
• Focused Repair Validation: Checks tied to accepted findings and the surfaces changed by their repairs.
• Verification: Exercise observable product behavior through a real user path and retain evidence of the action, result, and applicable side effects.
• Project Verifier: Project-owned app-specific executable knowledge consumed through the single verify-behavior entrypoint.

Relationships

• The Execution Frontier is recomputed after each Task Gate result.
• A task enters the Execution Frontier only when all dependencies pass their Task Gates, its Active Write Scope is available, and its declared read, write, and shared-runtime conflicts permit release.
• An Architecture Checkpoint or declared relevant-input conflict may block otherwise eligible tasks.
• implement-spec performs Verification through verify-behavior and the Project Verifier, completes implementation, and returns control to delivery-phase.
• The subsequent delivery-phase review step invokes review-phase for a Full Code Review Pass over the frozen implemented change.
• review-phase may inspect retained Verification evidence, but it does not run or refresh Verification.
• Focused Repair Validation may replace another Full Code Review Pass only under an accepted review policy.

Axioms

• Unrelated slow work does not delay an otherwise safe dependent task.
• Concurrent workers write in one current branch and never share active write scope.
• Architecture, runtime, UI, provider, and acceptance proof remain when applicable.
• Shared artifacts remain authoritative even when their update is moved off the dependency-release critical path.
• An eager draft PR must preserve accepted branch/base and stack intent.
• Verification and Code Review remain separate gates with separate evidence.

Flagged Ambiguities

• None. Ordinary scheduling uses Execution Frontier with declared conflict checks; cumulative architecture barriers use Architecture Checkpoint.
• A passed Task Gate can release dependents. Shared-artifact reconciliation and final acceptance remain later completion states.
• Full Code Review Pass means only one review-phase run after implement-spec; it never means Verification.

Accepted Review Policy

implement-spec first completes implementation, task checks, and Verification through verify-behavior and the Project Verifier. It then returns control to delivery-phase. The subsequent review step invokes review-phase against the frozen implemented change.

Accepted policy:

1. Run one Full Code Review Pass in the subsequent delivery-phase review step.
2. Repair accepted findings.
3. Run Focused Repair Validation for those findings and rerun only Verification scenarios invalidated by the repair.
4. Do not automatically run a second Full Code Review Pass.
5. Run one second Full Code Review Pass only when the repair changes architecture, security or authorization, a public contract, deployment or runtime topology, or accepted scope.
6. Never run more than two Full Code Review Passes in one delivery goal without explicit human direction.

Recommended Next Direction

Compile a focused agent-ready specification for the accepted execution-policy change. Backlog projection and implementation planning remain downstream actions.

Accepted Follow-Up: Review Topology Alignment (2026-09-05)

• A Full Code Review Pass uses one comprehensive primary reviewer with explicit coverage of all five mandatory axes; it does not require five separate review workers.
• autoreview is the primary reviewer and no extra advisory scan is required. One independent risk-focused challenger is mandatory for a bounded independent risk area; additional challengers may be used when larger changes require separate independent risk areas.
• Primary and challenger reviewers consume the same frozen factual packet. Challengers complete their independent checks before consuming primary conclusions.
• The parent adjudicates findings and owns the report. Per-axis gaps or incomplete challenger work are incomplete and cannot be clean.
• Detailed topology is authoritative in the Delivery Phase Flow Optimization specification.
• Existing one-pass default, focused repairs, affected Verification reruns, risk-triggered second pass, and two-pass ceiling remain unchanged. No experiment or admission-policy change is added.

Follow-up Accepted Decisions (2026-09-05)

Final Handoff

• Shared understanding confirmed on 2026-09-04.
• Every active branch is closed at 100%; no technical decision remains open.
• External PR reviewer integration remains parked outside this capability.
• Requirements are ready for create-spec.
• Follow-up decisions Q12-Q15 were accepted on 2026-09-05. Experiments remain unchanged and were not added to the specification.