Spec: Review Phase Graph Rework

Context

The current review workflow has conflicting invocation guidance, no required durable report, a diff-only child contract that does not explain artifact review, and incomplete evidence that distributed skill bytes match their canonical source. Delivery can route findings, but review ownership, freshness, lens aggregation, skill-adherence proof, and bounded rereview behavior are not one coherent contract.

Repository contributors need one explicit, readonly review capability that evaluates a frozen target, records durable evidence, and returns routing without repairing its own findings. Delivery needs that result to remain resumable and bounded while preserving focused validation and a durable clean-state handoff after the final allowed fix.

Non-Goals

• Let review-phase invoke itself through model selection.
• Make review-phase plan work, classify implementation stages, assign implementation skills, create implementation-stage evidence, or fix findings.
• Merge artifact-only review into the delivery Git/diff target protocol.
• Add exploratory validation after the third review-triggered fix.
• Run a fourth review after the third completed review permits a third fix.
• Include external GitHub or Codex PR review integration in this capability.
• Treat live or packaged skill mirrors as independent source authority.

User Stories

US-001: Invoke review deliberately

As a delivery operator, I want review to run only through an explicit invocation so that the workflow cannot start through spontaneous skill selection.

US-002: Receive one complete readonly review record

As a repository contributor, I want every completed review to inspect one frozen snapshot through every mandatory lens and preserve one immutable report so that its findings and freshness are auditable.

US-003: Verify implementation-skill adherence

As a reviewer, I want implementation guidance and skill-application evidence to remain traceable from planning through implementation notes so that adherence claims can be checked against changed artifacts.

US-004: Review supported target kinds coherently

As a reviewer, I want delivery changes and standalone artifacts to use target-appropriate adapters while producing the same readonly review contract.

US-005: Bound review-triggered repair

As a delivery operator, I want a fixed review budget and durable counter semantics so that repairs cannot create an unbounded review loop.

US-006: Preserve a clean final-fix handoff

As a delivery operator, I want the third permitted fix to receive focused validation and a durable clean-state handoff without a fourth review.

Acceptance Criteria

• AC-001: review-phase retains disable-model-invocation: true, and no model-selection path automatically invokes it.
  • Covers: US-001
• AC-002: An explicitly invoked delivery or standalone caller enters review_due with accepted bounds and a supported target before mode-specific budget evaluation.
  • Covers: US-001, US-004
• AC-003: Review remains readonly with respect to the reviewed target; only the report, navigation, and wiki-log retention envelope may be written.
  • Covers: US-001, US-002
• AC-004: After verified report retention and routing output, review-phase terminates without entering a repair state.
  • Covers: US-001, US-002
• AC-005: review-phase does not plan work, classify implementation stages, assign implementation skills, create implementation-stage evidence, or implement repairs.
  • Covers: US-001, US-003
• AC-006: Target normalization uses the smallest certain inclusive scope and does not expand to the full repository unless the caller explicitly requests it.
  • Covers: US-004
• AC-007: A delivery Git/diff target satisfies the complete normative Git/diff adapter schema.
  • Covers: US-004
• AC-008: A standalone plan, spec, or documentation target satisfies the complete deterministic ordered-bundle adapter schema without embedding raw bytes or inventing a Git fixed point.
  • Covers: US-004
• AC-009: Unsupported target normalization, invalid accepted bounds, or a non-retryable contract or infrastructure failure before retention enters terminal review_failed with exact failure evidence, no retained report, and no counter change.
  • Covers: US-001, US-004, US-005
• AC-010: Both normalized target kinds enter the same review graph and use the same composition, report, routing, and freshness contracts.
  • Covers: US-002, US-004
• AC-011: The identity contract validates stable lineage, deterministic mode-specific run identity, lineage-derived filename slug, and mode-specific delivery fields.
  • Covers: US-002, US-004, US-005
• AC-012: Delivery counter recovery keys on lineage and the highest valid retained ordinal, reconciles the handoff projection when needed, and evaluates target and source freshness independently.
  • Covers: US-002, US-005
• AC-013: Standalone mode never reads, increments, resets, or persists delivery counters.
  • Covers: US-002, US-004
• AC-014: One completed invocation evaluates exactly one frozen bounded snapshot.
  • Covers: US-002
• AC-015: $autoreview runs exactly once as advisory candidate generation for that frozen snapshot.
  • Covers: US-002
• AC-016: Parent verification against the frozen target and adjacent evidence decides which advisory candidates become findings.
  • Covers: US-002
• AC-017: A ClawPatch helper, when present, remains inside advisory candidate generation and consumes no additional review pass.
  • Covers: US-002
• AC-018: The report records explicit outcomes for Standards, skill adherence and scoped skills, architecture, simplify, and Spec.
  • Covers: US-002, US-003
• AC-019: All independent normative lenses inspect the same bounded snapshot in parallel.
  • Covers: US-002
• AC-020: Standards and skill adherence, architecture, simplify, then Spec affects report and triage order only.
  • Covers: US-002
• AC-021: Standards and Spec remain distinct report sections without cross-axis merging or reranking.
  • Covers: US-002
• AC-022: Review runs only the smallest safe readonly validation needed to verify candidates or governing acceptance evidence.
  • Covers: US-002, US-004
• AC-023: Broader checks run only when the accepted spec or plan explicitly requires them.
  • Covers: US-002, US-004
• AC-024: Missing required RED/GREEN evidence becomes a reported and routed finding; review does not create it.
  • Covers: US-002, US-003, US-005
• AC-025: create-plan writes implementation_skill_guidance for every implementation entry with applicable scoped or named skill obligations, and each guidance item identifies the skill and its concise applicable behavior.
  • Covers: US-003
• AC-026: assigned_skills remains planning provenance, every implementation-applicable item maps to exactly one guidance entry, and implement-spec forwards every guidance item unchanged.
  • Covers: US-003
• AC-027: IMPLEMENTATION-NOTES.md satisfies the normative one-record-per-guidance-entry skill evidence schema, including not_applicable evidence.
  • Covers: US-003
• AC-028: Review verifies evidence cardinality and every skill record against frozen changed artifacts.
  • Covers: US-003
• AC-029: Missing, extra, or contradicted skill evidence produces a skill-adherence finding.
  • Covers: US-003
• AC-030: A complete local report enters report_retention_pending without changing any counter.
  • Covers: US-002, US-005
• AC-031: The report satisfies the complete normative durable report schema and unique lineage-derived path contract.
  • Covers: US-002, US-003, US-004, US-005
• AC-032: The report remains immutable after creation.
  • Covers: US-002
• AC-033: The designated writer retains only the report, navigation, and wiki-log envelope without mutating the reviewed target.
  • Covers: US-002, US-004
• AC-034: Successful retention uses a mode-appropriate approved ref and verifies that the retained ref contains the report commit.
  • Covers: US-002, US-004, US-005
• AC-035: The retained output envelope validates report path, report SHA-256, report commit SHA, and verified retained ref outside the immutable report.
  • Covers: US-002, US-004, US-006
• AC-036: Retryable retention failure remains report_retention_pending, while non-retryable contract or infrastructure retention failure enters review_failed; both return exact evidence, establish no authoritative pass, and change no counter.
  • Covers: US-002, US-005
• AC-037: Retention retries reuse the local report without rerunning lenses while target and source hashes remain fresh.
  • Covers: US-002, US-004
• AC-038: A target or source hash change before retention returns to review_due without consuming a pass.
  • Covers: US-002, US-005
• AC-039: A verified retained delivery report is the authoritative completed ordinal from which review_count is projected exactly once; standalone retention changes no delivery counter.
  • Covers: US-002, US-004, US-005
• AC-040: Delivery resume validates lineage and handoff counters, recomputes target and source freshness, and selects the highest fresh completed retained ordinal.
  • Covers: US-002, US-005
• AC-041: Standalone resume validates lineage, bounds, target, and scope; recomputes freshness; and selects the most recent fresh retained report without changing delivery counters.
  • Covers: US-002, US-004
• AC-042: Every normative state-transition row produces its specified next state, counter effect, owner, and required evidence when its event and guard match.
  • Covers: US-001, US-002, US-004, US-005, US-006
• AC-043: Mixed findings route primarily to debugging when runtime evidence exists.
  • Covers: US-005
• AC-044: Without runtime evidence, mixed findings route primarily to implementation when an in-scope non-runtime blocker exists.
  • Covers: US-005
• AC-045: Without either higher-precedence blocker, broad architecture debt routes primarily to debt follow-up.
  • Covers: US-005
• AC-046: With no blocker or broad architecture debt, delivery routes to documentation ingest or closeout according to documentation completeness.
  • Covers: US-005
• AC-047: Broad architecture debt may remain a secondary follow-up beside a primary debugging or implementation route.
  • Covers: US-005
• AC-048: Each completed delivery review may open at most its one correspondingly numbered implementation or debugging repair epoch only after a durable idempotent handoff transition records repair_count.
  • Covers: US-005
• AC-049: Q17 supersedes Q16: one delivery goal permits at most three completed reviews mapped to at most three corresponding fixes, and fix 3 never opens review 4.
  • Covers: US-005, US-006
• AC-050: Only an explicitly new delivery goal with materially changed accepted bounds resets delivery counters; resume, rebase, commit, retry, and handoff do not.
  • Covers: US-005
• AC-051: Ordinary repairs stale the preceding report and re-enter review_due only while review_count < 3.
  • Covers: US-002, US-005
• AC-052: Focused-validation failure after fix 3 stays within repair epoch 3 and returns to its delivery-owned implementation or debugging route without changing counters.
  • Covers: US-005, US-006
• AC-053: After the required focused fix-3 validation passes, delivery records the normative clean handoff and continues without review 4 or a rejected post-fix status.
  • Covers: US-002, US-006
• AC-054: Canonical source, active mirror, packaged mirror, managed fixture and manifest, durable docs, and wiki guidance satisfy the normative parity contract.
  • Covers: US-001, US-002, US-004, US-005, US-006
• AC-055: External GitHub and Codex PR review integration remains outside this capability.
  • Covers: US-001, US-004
• AC-056: Delivery enters review_running only while recovered review_count < 3; standalone review has no delivery-budget guard.
  • Covers: US-004, US-005
• AC-057: A delivery invocation with recovered review_count >= 3 returns terminal no-op review_budget_exhausted with exact current-route evidence, creates no report, changes no counter or status, and cannot block clean continuation.
  • Covers: US-001, US-005, US-006
• AC-058: Delivery report retention rejects a review ordinal greater than 3 without creating an authoritative pass or changing counters.
  • Covers: US-002, US-005
• AC-059: Delivery lineage derives only from stable delivery-goal identity; same-goal bounds revisions preserve lineage and counters, while only an explicitly new goal with materially changed accepted bounds creates a new lineage and reset.
  • Covers: US-002, US-005
• AC-060: A delivery run preallocates ordinal recovered review_count + 1 and its review_run_id, and its verified retained commit becomes the authoritative pass record before the handoff projection is updated.
  • Covers: US-002, US-005
• AC-061: Repair opening is one atomic durable handoff transition that writes active state, route, repair_count, and idempotency review_run_id; resume of a recorded run enters that active state without another increment or fallthrough to an unrecorded guard.
  • Covers: US-005, US-006
• AC-062: Before retention, retryable infrastructure or partial failure returns to review_due with exact evidence and no counter change; non-retryable failure enters review_failed under AC-009.
  • Covers: US-001, US-002, US-005

Constraints

• The external shared-skills repository is the canonical source. Shared-skill changes synchronize source-first into Harness mirrors; .agents/skills/* and apps/cli/skills/* are not independent authoring authorities.
• review-phase remains readonly and ends after its report and routing response.
• Every completed review pass uses one frozen snapshot for every mandatory existing lens.
• Lens priority affects presentation and triage, never parallel execution or the separate Standards and Spec axes.
• Every completed run produces one immutable private project-wiki review report.
• Standalone reviews use target-derived identity and never participate in delivery review or repair counters.
• The delivery handoff, not a mutation of the review-3 report, is final clean-state authority after fix 3.
• The third-review, third-fix clean transition is the only exception to normal stale-review routing.
• Q17 supersedes Q16: three completed reviews may open three fixes, and there is no fourth review.
• Review validation remains readonly and no broader than governing accepted evidence requires.
• External GitHub and Codex PR review integration remains outside this specification.

Dependency Readiness

No Stack Required.

Branch/Base Intent

Not applicable.

Accepted Technical Decisions

Review State Graph

review-phase is explicitly invoked and owns only normalization, frozen-snapshot inspection, report persistence, routing output, and termination. Delivery or a standalone caller enters review_due; review-phase then freezes the normalized target and executes exactly one all-lens fan-out. Delivery owns every repair, debugging, debt, documentation, closeout, and clean-handoff state.

review_lineage_id persists across snapshots and same-goal bounds revisions. Delivery derives it deterministically only from stable delivery-goal identity. Accepted-bounds identity and hash remain report and freshness evidence, not delivery lineage input. Standalone mode derives lineage deterministically from target locator plus accepted-bounds hash. Delivery preallocates ordinal recovered review_count + 1 and derives review_run_id from lineage plus that ordinal before review begins; standalone mode derives the run identity from lineage plus snapshot12. The filename slug derives from lineage.

One designated review report writer commits only the report, navigation, and wiki-log envelope. It pushes or uses an explicit repository-approved retained ref, then verifies that ref contains the report commit. Delivery mode retains through the current delivery branch or another approved ref. Standalone mode uses deterministic review/<review-scope-slug>-<snapshot12> or another approved ref. Retention remains readonly with respect to the reviewed target.

A complete local report changes no completed-pass counter. The verified retained commit for a delivery report is the authoritative pass record. Its ordinal becomes the recovered review_count; the handoff counter is a projection reconciled from the highest valid retained ordinal for the lineage if an update was interrupted. State transitions with counter effects complete only after durable authority exists. Repair opening is one atomic durable handoff write of active state, primary route, new repair_count, and idempotency review_run_id; the transition completes only after that write. On resume, an already recorded run ID enters its recorded active state without another increment and cannot fall through to an unrecorded guard. Standalone mode never participates in the delivery review or repair budget.

Ordinary repair makes the prior report stale and re-enters review_due only while review_count < 3. Q17 explicitly supersedes Q16: review 3 may open fix 3, but fix 3 never opens review 4. A focused-validation failure remains inside repair epoch 3 until that same focused validation passes.

Same-goal bounds revisions preserve delivery lineage and counters. Only an explicitly new delivery goal with materially changed accepted bounds creates a new lineage and reset. Resume, rebase, new commit, process retry, and handoff preserve them. Counter recovery keys on lineage and the highest valid retained ordinal, reconciling the durable handoff projection when needed; target, accepted-bounds, and governing source hashes determine report freshness separately.

review_budget_exhausted is a terminal no-op for that invocation. It returns exact current-route evidence, creates no report, changes no counter or delivery status, and cannot block clean continuation. review_failed is reserved for non-retryable invocation-level contract or infrastructure failure. It is not a post-fix delivery status and consumes no counter. Retryable infrastructure failure or a partial run returns to review_due with exact evidence and no counter change.

Normative Review Composition

• $autoreview runs once per frozen snapshot as advisory candidate generation. Parent verification against the frozen target and adjacent evidence decides reported findings.
• A ClawPatch helper, when present, is internal to advisory candidate generation and never creates a second review pass.
• The normative lenses are Standards, skill adherence and scoped skills, architecture, simplify, and Spec.
• Independent lenses inspect the same bounded snapshot in parallel.
• Standards and skill adherence, architecture, simplify, then Spec controls report and triage order only.
• Standards and Spec retain distinct report sections and are not merged or reranked across their axes.

Readonly Validation Boundary

Review uses the smallest safe readonly validation needed to verify advisory candidates or governing acceptance evidence. Broader checks run only when the accepted spec or plan explicitly requires them. Missing required RED/GREEN evidence becomes a reported and routed finding; review never creates that evidence.

Normalized Target Adapters

Every adapter records the smallest certain inclusive scope. Full-repository expansion requires an explicit caller request.

The delivery Git/diff target records:

• locator;
• actual base ref;
• merge-base or fixed-point SHA;
• head or dirty-worktree identity;
• inclusive scope;
• canonical patch hash.

The standalone plan, spec, or documentation adapter freezes the exact selected file bytes into one deterministic ordered bundle. Its normalized target records:

• locator;
• ordered file identities;
• inclusive scope;
• ordered bundle content hash;
• explicit absence of a Git fixed point.

The normalized target and report do not need to embed the raw selected bytes.

Both target forms enter the same review state graph and use the same normative lenses, report contract, routing semantics, and freshness rules.

Durable Review Report

Every completed run writes one unique immutable report at:

apps/wiki/content/docs/project/reviews/<review-scope-slug>-<UTC>-<snapshot12>-review-report.md

review-scope-slug derives from stable review_lineage_id. Every report contains:

• review_lineage_id;
• review_run_id;
• accepted-bounds identity and hash;
• reviewed_at and mode;
• normalized target;
• snapshot hash and narrow excluded envelope;
• source paths and hashes for Spec, Standards, scoped guidance, and every named skill;
• an explicit outcome for each normative lens;
• stable finding identifiers with severity, location, impact, evidence, and action;
• routing and validation.

Delivery mode also records delivery-goal identity, review ordinal, and preceding repair ordinal when present. Standalone mode records those delivery-only fields as null or not applicable and never reads or changes the delivery budget.

The report path is unique and its content never changes after creation. The snapshot hash excludes only the report itself, navigation metadata, and the wiki log envelope. Navigation ordering does not affect freshness.

In delivery mode, entry to review_running preallocates the next ordinal as recovered review_count + 1 and fixes the corresponding review_run_id. review_running produces the complete local report and then enters report_retention_pending. The designated review report writer rejects any delivery ordinal greater than 3. For a permitted ordinal, it commits only the report, navigation, and wiki-log envelope; pushes or uses an explicit repository-approved retained ref; and verifies that the retained ref contains the report commit. Delivery mode uses its current delivery branch or another approved ref. Standalone mode uses deterministic review/<review-scope-slug>-<snapshot12> or another approved ref.

Retention success produces report path, final report SHA-256, report commit SHA, and verified retained ref outside the immutable report. In delivery mode, that verified retained commit is the authoritative pass record and the durable handoff projects its highest valid ordinal as review_count, alongside repair_count. In standalone mode the readonly return records each field while the immutable retained report remains the handoff.

A retryable retention failure remains report_retention_pending; while target and source hashes remain fresh, retry reuses the complete local report without rerunning lenses. A non-retryable contract or infrastructure retention failure enters review_failed. Both return exact evidence, establish no authoritative pass, and change no counter. If either hash changes before successful retention, the local report is stale and the graph returns to review_due.

Delivery counter recovery keys on review_lineage_id and the highest valid retained ordinal for that lineage. If report retention succeeded but handoff update was interrupted, resume reconciles the handoff projection from the authoritative retained pass record. Delivery report freshness separately recomputes target, accepted-bounds, and governing source hashes, then selects the highest fresh completed retained review ordinal for the lineage. Standalone resume matches lineage, accepted bounds, normalized target, and inclusive scope; recomputes target and source hashes; and selects the most recent fresh completed retained report by reviewed_at. Standalone changes no delivery counter.

The review report is the review-phase handoff for its frozen snapshot. After fix 3, the delivery handoff is final clean-state authority and links the immutable review-3 report, final changes, focused validation, and clean status. Review 3 remains immutable pre-fix evidence.

Implementation-Skill Evidence

• assigned_skills remains planning provenance.
• create-plan writes implementation_skill_guidance for every implementation entry with applicable scoped or named skill obligations.
• Every assigned_skills item applicable during implementation maps to exactly one guidance entry; no applicable item may be omitted.
• Each guidance item contains the skill identity and concise applicable behavior.
• implement-spec forwards every guidance item unchanged.
• IMPLEMENTATION-NOTES.md contains exactly one evidence record per guidance entry.
• Each record contains skill, one status from loaded, applied, or not_applicable, and a how/where pointer.
• A not_applicable record also states why and where the guidance was assessed.
• Review checks record completeness and every record, including not_applicable, against frozen changed artifacts.
• Missing, extra, or contradicted claims become skill-adherence findings.

Source Authority And Synchronization

The external shared-skills repository remains canonical authority. The active skill mirror, packaged skill mirror, managed fixture and manifest evidence, and durable docs/wiki guidance must agree with synchronized canonical bytes and accepted behavior. None is an independent authoring authority.

Accepted Testing Decisions

• Verify explicit invocation and end-after-report behavior independently.
• Verify one $autoreview advisory run, parent candidate verification, one outcome per normative lens, parallel same-snapshot inspection, report priority, and distinct Standards/Spec sections.
• Verify Git/diff normalization fields and canonical patch identity without applying standalone-only fields.
• Verify deterministic standalone bundle ordering, ordered file identities, content identity, absence of a Git fixed point, and omission of raw bytes from the normalized target and report.
• Verify smallest-certain scope and explicit full-repository expansion behavior for both adapters.
• Verify delivery lineage derives only from stable goal identity and survives same-goal bounds revisions; verify standalone lineage, mode-specific run identity, and snapshot stability independently.
• Verify mode-specific report naming and fields, required field completeness, and post-creation immutability.
• Verify the local-report to retention-pending boundary changes no counter.
• Verify report-only envelope commit scope, approved retained-ref selection, push or retention behavior, and retained-ref commit containment.
• Verify delivery and standalone retention outputs independently: report path, report SHA-256, report commit SHA, and verified retained ref.
• Verify retryable retention failure remains pending and reuses a fresh local report, while non-retryable retention failure enters review_failed; prove exact evidence, no authoritative pass, and zero-counter behavior for both.
• Verify delivery ordinal preallocation, authoritative retained-pass recovery, interrupted handoff projection reconciliation, and freshness selection independently.
• Verify standalone resume identity, hash recomputation, freshness, latest retained selection, and zero delivery-counter mutation.
• Verify unsupported targets, invalid bounds, and non-retryable failures independently enter review_failed; verify retryable infrastructure and partial failures return to review_due; require exact evidence, no report, and no counter change in each failure path.
• Verify create-plan guidance production for every applicable implementation entry, exact mapping from every implementation-applicable assigned_skills item, absence of omissions, skill identity and behavior content, unchanged implement-spec forwarding, one-to-one evidence cardinality, allowed statuses, not_applicable evidence, and missing or contradicted claim findings.
• Verify every state transition, guard, owner, counter effect, and evidence requirement in the review graph.
• Verify mixed-finding route precedence and each primary routing outcome independently, including secondary architecture follow-up beside debugging or implementation.
• Verify verified retained delivery ordinals establish completed passes, handoff counters remain recoverable projections, and standalone mode never changes delivery counters.
• Verify the three-review and three-fix ceiling, delivery budget guard, terminal no-op exhaustion, ordinal-greater-than-three retention rejection, atomic repair handoff fields, transition-after-write behavior, recorded-run resume without increment or guard fallthrough, non-resetting continuation events, no-review-4 boundary, repeated focused-validation failure within repair 3, passing validation, and final clean handoff.
• Verify canonical source, active mirror, packaged mirror, managed fixture and manifest, and durable docs/wiki parity as separate surfaces.
• Verify smallest-safe readonly validation, accepted broader-check requirements, and missing RED/GREEN finding routing independently.

Verification Seams

• Invocation seam: review-phase frontmatter and explicit delivery-gate traversal.
• Snapshot seam: the frozen target identity shared by every mandatory lens in one completed run.
• Composition seam: one advisory candidate generation run, parent verification, and explicit per-lens outcomes.
• Identity seam: goal-derived delivery lineage, target-and-bounds-derived standalone lineage, per-run review_run_id, and lineage-derived filename slug.
• Report seam: the immutable private project-wiki report, its all-lens contents, and bounded freshness hash.
• Retention seam: pending local report, retryable versus non-retryable failure, envelope-only report commit, report SHA-256, report commit SHA, verified retained ref, and containment verification.
• Skill-evidence seam: complete assigned_skills-to-guidance mapping, create-plan guidance production, unchanged implement-spec forwarding, planning provenance, and per-skill IMPLEMENTATION-NOTES.md evidence checked against changed artifacts.
• Target seam: normalized delivery Git/diff snapshots and standalone plan, spec, and documentation artifacts.
• Resume seam: authoritative retained-ordinal recovery and handoff projection reconciliation separated from target/source freshness and retained-report selection.
• Budget seam: delivery entry guard, terminal no-op exhaustion, ordinal cap, durable projected review_count, atomic active-state/route/repair_count/run-ID handoff, recorded-run resume, reset conditions, and review-triggered fix transitions.
• Final-state seam: focused fix-3 validation and the delivery handoff linking pre-fix review evidence to final clean status.
• Validation seam: the smallest safe readonly check, explicit broader-check authority, and missing RED/GREEN evidence finding.
• Synchronization seam: canonical source, active mirror, packaged mirror, managed fixture and manifest, and durable docs/wiki guidance.

Parked Decisions

• External GitHub and Codex PR review integration. Owner: separate external-review capability. Resume trigger: an explicitly confirmed requirements scope is opened for that capability.

Decision Log