Grilling
Review Phase Graph Rework Grill Status
Review Phase Graph Rework Grill Status
Phase State
- Topic: Review Phase Graph Rework.
- Scope boundary: requirements only; no skill implementation.
- Shared understanding: confirmed; requirements are ready for spec compilation.
Branch Dashboard
| Branch | Completion | Locked direction | Still-open items |
|---|---|---|---|
| Invocation and ownership | 100% | Explicit-only review-phase performs readonly review, writes its report, returns routing, and ends. Delivery owns repair routing and may start a later review epoch. | None. |
| Skill guidance and evidence | 100% | Planning adds per-task guidance, delivery forwards it unchanged, notes record name/status/how-where evidence, and review independently checks applicable statements. | None. |
| Review cost control | 100% | At most three completed review runs are allowed. After review 3 permits fix 3, focused validation passes before delivery marks clean without review 4. | None. |
| Durable report | 100% | Each review report remains immutable for its snapshot; the delivery handoff links review 3, fix-3 changes, focused validation, and final clean status. | None. |
| Target integration | 100% | Delivery review uses Git/diff snapshots; plan, spec, and docs use standalone adapters. | None. |
| External PR review integration | parked | GitHub and Codex PR review remains outside this review-phase rework. | Outside current scope. |
Current Round
- Round: R7
- Current frontier: empty
- Shared-understanding confirmation: confirmed
| Question id | Prerequisites | Question | State |
|---|---|---|---|
| Q6 | none | Should review-phase end after a readonly report and route, with no internal repair loop? | answered |
| Q7 | Q2, Q3 | Should create-plan add per-task implementation_skill_guidance that implement-spec forwards verbatim while assigned_skills remains planning provenance, or should implement-spec forward the current flat assigned_skills plus guidance? | answered |
| Q8 | Q4 | What is the minimum per-skill IMPLEMENTATION-NOTES.md evidence: name and status only, or name and status plus a short how/where pointer? | answered |
| Q9 | Q4 | Is implementation-note attestation sufficient by itself, or must review independently check every applicable claim against the changed code and artifacts? | answered |
| Q10 | Q2 | Which lenses always run: Standards, Spec, and skill adherence only with simplify and architecture conditional, or all current lenses always? | answered |
| Q11 | Q2 | What autonomous review or repair budget applies after the first report? | answered |
| Q12 | Q2 | Should delivery review support only Git/diff snapshots, while plan, spec, and docs reviews remain standalone target adapters? | answered |
| Q13 | Q5 | Should the immutable report be the review-phase handoff and remain fresh through a bounded snapshot hash that excludes only its own report and navigation envelope? | answered |
| Q14 | Q2, Q5 | Should external PR reviewer findings join the same finding ledger and cycle budget, or remain an independent loop? | answered |
| Q15 | Q10 | Does the tentative lens priority control execution order, or only report and triage order, given that current $review runs Standards and Spec as parallel, separate axes? | answered |
| Q16 | Q11 | Should one delivery goal allow at most three total review passes, where pass 1 is the initial full review and passes 2-3 are post-repair reviews? | answered |
| Q17 | Q16 | When the fourth completed review pass still has a blocking finding, should delivery stop at a human checkpoint or blocked handoff, or may it convert the finding to debt or continue? | answered |
| Q18 | Q16 | What resets the three-repair counter: only an explicitly new delivery goal with materially changed bounds, or any resumed run, new commit, or scope change? | answered |
| Q19 | Q13, Q16 | What counts as one review pass: only a completed all-lens report for a new frozen snapshot, with same-snapshot infrastructure retries and no-op duplicates excluded? | answered |
| Q20 | Q14, Q16 | If the internal review run and an external PR reviewer inspect the same frozen commit, do they together consume one review pass or two? | parked |
| Q21 | Q17, Q19 | After review 3 triggers fix 3 and there is no review 4, what terminal state must delivery record for the unreviewed final fix? | answered |
| Q22 | Q13, Q21 | The immutable review-3 report describes the pre-fix-3 snapshot. Which durable artifact records the final clean state after fix 3: the delivery handoff linking the review report and final-fix evidence, or some other authority? | answered |
| Q23 | Q19, Q21 | Before delivery marks clean after fix 3, must fix 3 still pass the focused validation required by its finding or plan, without running review 4? | answered |
Parked Branches
- External PR review integration: GitHub and Codex PR review is a separate concern outside the current
review-phaserework. Q20 supersedes Q14 for this scope.
Glossary
Terms
- Review epoch: One frozen snapshot plus its readonly review and report.
- Skill-application attestation: An implementation-note claim that a named skill was loaded and applied.
- Adversarial adherence check: A readonly check of claimed skill application against implementation evidence.
- Review report: The immutable private project-wiki record for one review epoch.
- Review-triggered repair: A delivery-owned fix permitted by a completed review run; the third repair is not followed by a fourth review.
- Review pass: One completed invocation against one frozen snapshot that inspects every mandatory existing lens and records all lens results in one immutable report.
- Budget-exhaustion exception: The third-review, third-fix edge where delivery marks the goal clean and continues without a fourth review.
- Delivery handoff: The durable final-state authority linking review evidence, final-fix changes, focused validation, and clean status.
Relationships
- A Review epoch produces exactly one Review report.
- An Adversarial adherence check evaluates a Skill-application attestation against implementation evidence.
- A Review report is the handoff for its Review epoch and is fresh only for its bounded snapshot hash.
- The Delivery handoff preserves the immutable pre-fix Review report while recording the final post-fix clean state.
Axioms
review-phaseis explicitly invoked and cannot rely on spontaneous model selection.- Delivery owns traversal of its review gate.
review-phaseconsumes durable inputs, performs readonly review, writes a report, and returns routing.review-phaseends after its readonly report and route and never fixes findings.delivery-phaseowns implement, debug, and follow-up routing and may start a later review epoch.- Planning, implementation-skill assignment, fixes, and implementation-stage evidence creation are outside
review-phaseownership. - Implementation workers receive usable guidance for every applicable assigned skill.
create-planrecords per-taskimplementation_skill_guidance;implement-specforwards it unchanged, whileassigned_skillsremains planning provenance.- Per-skill implementation evidence includes the skill name,
loaded,applied, ornot_applicablestatus, and a short how/where pointer. - Review independently checks every applicable skill statement against changed code and artifacts.
- All review lenses remain mandatory.
- Independent lenses run in parallel on the same frozen snapshot.
- Lens priority controls report and triage order only: Standards and skill adherence, architecture, simplify, then Spec.
- Standards and Spec retain separate-axis reporting where applicable.
- Current routing sends clean results to docs ingest or closeout, in-scope non-runtime blockers to implement, runtime evidence to debug, and broad architecture debt to follow-up debt.
- Delivery-owned review uses Git/diff snapshots; plan, spec, and docs reviews use standalone target adapters.
- Every review run produces one immutable private project-wiki review report.
- The review report is the
review-phasehandoff and its freshness hash excludes only its report, navigation, and wiki-log envelope. - External GitHub and Codex PR review integration is outside this
review-phaserework; Q20 supersedes Q14 for this scope. - Q17 supersedes Q16's four-completed-pass interpretation.
- One delivery goal permits at most three completed review runs and one review-triggered repair after each run.
- Review 1 may trigger fix 1, review 2 may trigger fix 2, and review 3 may trigger fix 3; fix 3 is not followed by review 4.
- Only an explicitly new delivery goal with materially changed accepted bounds resets the budget; resume, rebase, new commit, process retry, and handoff do not.
- A review pass inspects every mandatory existing lens against one frozen snapshot and records all results in one immutable report.
- Infrastructure failures, partial runs, and same-snapshot retries without a completed report do not consume a review pass.
- After review 3 permits fix 3,
delivery-phasemarks the goal clean and continues without review 4. - The budget-exhaustion exception applies only to the third-review, third-fix edge; ordinary fixes continue to stale the prior review.
- After fix 3, the
delivery-phasehandoff links the immutable review-3 report, fix-3 changes, fix-3 validation, and final clean status. - The review-3 report remains the immutable record of its own pre-fix snapshot.
- Fix 3 must pass only the focused tests or validation required by its finding or plan; exploratory testing and review 4 do not run.
Flagged Ambiguities
- None remain in the current scope.
Final Handoff
- Requirements are ready for spec compilation.
- External GitHub and Codex PR review integration remains parked outside this scope.