Review Phase Graph Rework Grill Log

Branch: Invocation And Ownership

Q1

Prerequisites:

• none

Question: Should review-phase retain explicit-only invocation, and how may an explicitly invoked delivery workflow traverse its review gate?

Accepted answer:

• review-phase keeps disable-model-invocation: true; no automatic model invocation is allowed.
• An explicitly invoked delivery workflow may traverse a delivery-owned review gate without relying on spontaneous skill selection.

Q2

Prerequisites:

• Q1

Question: What does review-phase own within the delivery graph?

Accepted answer:

• review-phase consumes durable inputs, performs readonly review, writes a report, and returns routing.
• It does not plan work, assign implementation skills, implement fixes, or own implementation-stage evidence creation.
• This supersedes any suggestion that review-phase should split assignments into planning, implementation, and review.

Branch: Skill Guidance And Evidence

Q3

Prerequisites:

• Q2

Question: What skill guidance must implementation workers receive?

Accepted answer:

• Implementation workers must receive usable guidance for every applicable assigned skill.
• The exact transport and shape remain open.

Q4

Prerequisites:

• Q3

Question: What implementation-note evidence should exist for assigned skill application?

Accepted answer:

• Recording that a named skill was loaded and applied is valid evidence.
• IMPLEMENTATION-NOTES.md should gain skill-application evidence.
• Whether attestation alone is sufficient for a clean review remains open.

Branch: Durable Report

Q5

Prerequisites:

• Q2

Question: What durable artifact must every review run produce?

Accepted answer:

• Every review run writes one immutable private project-wiki review report, analogous to research, grilling, and implementation artifacts.
• The exact schema and freshness contract remain open.

Branch: Skill Guidance And Evidence, R1 Closure

Q7

Prerequisites:

• Q2
• Q3

Question: 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?

Accepted answer:

• create-plan adds per-task implementation_skill_guidance.
• implement-spec forwards that guidance unchanged.
• Existing assigned_skills remains planning provenance.
• review-phase does not classify stages.

Q8

Prerequisites:

• Q4

Question: What is the minimum per-skill IMPLEMENTATION-NOTES.md evidence: name and status only, or name and status plus a short how/where pointer?

Accepted answer:

• Record the skill name.
• Record status as loaded, applied, or not_applicable.
• Include a short how/where pointer.

Q9

Prerequisites:

• Q4

Question: Is implementation-note attestation sufficient by itself, or must review independently check every applicable claim against the changed code and artifacts?

Accepted answer:

• Skill-application attestation is valid evidence.
• Review independently checks every applicable implementation-note skill statement against the changed code and artifacts.

Branch: Review Lenses And Routing

Q10

Prerequisites:

• Q2

Question: Which lenses always run: Standards, Spec, and skill adherence only with simplify and architecture conditional, or all current lenses always?

Accepted answer:

• All current lenses remain mandatory.
• The tentative priority is Standards and skill adherence, architecture, simplify, then Spec.
• Whether that priority controls execution order or only report and triage order remains open as Q15 because current $review runs Standards and Spec as parallel, separate axes.

Q11

Prerequisites:

• Q2

Question: What autonomous review or repair budget applies after the first report?

Accepted answer:

• Preserve current routing behavior.
• No blockers route to docs ingest or closeout.
• An in-scope non-runtime blocker routes to implement.
• Runtime evidence routes to debug.
• Broad architecture debt routes to follow-up debt.
• Fixes can make review stale and route the work back through review.
• The rerun cycle limit remains open as Q16.

Branch: Targets, Durability, And External Findings

Q12

Prerequisites:

• Q2

Question: Should delivery review support only Git/diff snapshots, while plan, spec, and docs reviews remain standalone target adapters?

Accepted answer:

• Delivery-owned review uses Git/diff snapshots.
• Plan, spec, and docs reviews use standalone target adapters.

Q13

Prerequisites:

• Q5

Question: 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?

Accepted answer:

• The immutable review report is the review-phase handoff.
• Freshness uses a bounded snapshot hash that excludes only the report, navigation, and wiki-log envelope.

Q14

Prerequisites:

• Q2
• Q5

Question: Should external PR reviewer findings join the same finding ledger and cycle budget, or remain an independent loop?

Accepted answer:

• External PR reviewer findings enter the same finding ledger and cycle budget.

Branch: Invocation And Ownership, R2 Closure

Q6

Prerequisites:

• none

Question: Should review-phase end after a readonly report and route, with no internal repair loop?

Accepted answer:

• Yes. review-phase ends after its readonly report and route.
• review-phase never fixes findings.
• delivery-phase owns implement, debug, and follow-up routing and may start a later review epoch.

Branch: Review Lens Priority, R2 Closure

Q15

Prerequisites:

• Q10

Question: 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?

Accepted answer:

• Lens priority controls report and triage order only.
• Independent lenses still run in parallel on the same frozen snapshot.
• Priority is Standards and skill adherence, architecture, simplify, then Spec.
• Preserve separate-axis Standards and Spec reporting where applicable.

Branch: Review Cycle Budget, R3 Closure

Q16

Prerequisites:

• Q11

Question: 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?

Accepted answer:

• The question's three-total-pass wording is superseded.
• One delivery goal has one initial full review plus at most three repair cycles.
• Each repair cycle is followed by a post-repair review.
• The hard maximum is therefore four completed review passes total, not three.
• The earlier assistant interpretation allowed only two repairs; the user corrected the budget to three repairs.

Branch: Review Budget Semantics, R4 Closure

Q17

Prerequisites:

• Q16

Question: 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?

Accepted answer:

• The question's fourth-review premise does not apply.
• There are at most three completed review runs total.
• Review 1 may trigger fix 1, review 2 may trigger fix 2, and review 3 may trigger fix 3.
• There is no review 4 after fix 3.
• This decision explicitly supersedes Q16's four-completed-pass interpretation.

Q18

Prerequisites:

• Q16

Question: 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?

Accepted answer:

• Only an explicitly new delivery goal with materially changed accepted bounds resets the budget.
• Resume, rebase, new commit, process retry, and handoff do not reset it.

Q19

Prerequisites:

• Q13
• Q16

Question: 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?

Accepted answer:

• One review pass is one completed invocation against one frozen snapshot.
• The run inspects every mandatory existing lens and reports all lenses in one immutable report.
• Infrastructure failures, partial runs, and same-snapshot retries that do not complete a report do not consume a pass.

Branch: Scope And Budget Exhaustion, R5 Closure

Q20

Prerequisites:

• Q14
• Q16

Question: If the internal review run and an external PR reviewer inspect the same frozen commit, do they together consume one review pass or two?

Accepted answer:

• External GitHub and Codex PR review is a separate concern outside this review-phase rework.
• Park external PR review integration.
• This scope decision explicitly supersedes Q14's earlier decision that external findings enter this skill's finding ledger and cycle budget.

Q21

Prerequisites:

• Q17
• Q19

Question: After review 3 triggers fix 3 and there is no review 4, what terminal state must delivery record for the unreviewed final fix?

Accepted answer:

• delivery-phase marks the goal clean and continues.
• It does not use incomplete, review_required, blocked, or a human-checkpoint status.
• This is an explicit budget-exhaustion exception to the normal stale-review route.
• Only the third-review, third-fix edge receives this exception.

Branch: Final Fix Authority And Validation, R6 Closure

Q22

Prerequisites:

• Q13
• Q21

Question: 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?

Accepted answer:

• The delivery-phase handoff is the durable authority for final clean state after fix 3.
• It links the immutable review-3 report, fix-3 changes, fix-3 validation, and final clean status.
• The review report remains the immutable record of its own pre-fix snapshot.

Q23

Prerequisites:

• Q19
• Q21

Question: 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?

Accepted answer:

• Yes. Run only the focused tests or validation required by the finding or plan before marking clean.
• Do not expand into exploratory testing.
• Do not run review 4.

Shared Understanding Confirmation

• The user explicitly confirmed the shared understanding after the design frontier reached empty.
• Requirements are ready for spec compilation.