## Review preparation After startup, follow the preparation sections below through Confidence Calibration. Read Decision procedure as the rule for later choices. Start the review at Scope Challenge, then complete Sections 1–4 in order. ## Review record and write policy Use these terms throughout the review: - **Target:** the plan, diff or code path selected at the Scope gate. It stays fixed. - **Working plan:** the proposed work and its current approvals. For a plan target, start with that plan; for code, build a remedy plan from the findings. This is review content, not permission to edit implementation or create another file. - **Report file:** the one destination for the working plan, findings, decision ledger and final structured report. It may be the selected plan or a separate file. | Target | Evidence to examine | |---|---| | Plan or design document | Proposed paths, checked against existing interfaces and tests | | Branch diff | Changed behavior and surrounding code, traced from entry points | | Specific file or directory | Existing behavior and relevant callers/tests | When Test review or Outside Voice refers to the plan, use the current working plan and this target evidence. Trace current behavior and proposed changes separately. Include actual decisions in Outside Voice's bounded input. Choose the **report file** before any ledger write: 1. Use the output/report path explicitly requested by the user. 2. Otherwise use the selected plan file, if there is one. 3. Otherwise use `$GSTACK_STATE_ROOT/projects/$SLUG/$BRANCH-eng-review-{YYYYMMDD-HHMMSS}.md`, adding a suffix on collision. Run `~/.claude/skills/gstack/bin/gstack-paths` and `~/.claude/skills/gstack/bin/gstack-slug` and construct the literal path from their returned assignments. A failed command or missing value makes this destination unavailable. Name the target in the report header. Never substitute an unrelated active plan or silently replace a requested destination. **Check each artifact and parent directory's permission before writing.** Honor user and host limits, including active-plan-only restrictions. Permission for one path authorizes no other; implementation edits require explicit authority. | Artifact | Destination | If writing is forbidden | |---|---|---| | Working plan, ledger and complete review report | Selected report file | Ask for a permitted destination if the user can supply one; wait without completion telemetry. If none is permitted, complete the review in chat as **not persisted**, then use **Blocked outcome**. | | QA Test Plan and task JSONL | Discovery paths below | Present each completely as **not persisted** and continue. | | TODOS.md | The project's TODO file | Present accepted TODO content as **not persisted** and continue. | | Required Review Log | The helper's state location | Present its fields as **not persisted**; the final gate cannot pass without this log. | | Best-effort metadata/learning logs | Helper-defined locations | Skip forbidden writes; otherwise keep their best-effort behavior. | The QA Test Plan and task JSONL intentionally use legacy discovery paths under `~/.gstack/projects/{slug}/`: `{user}-{branch}-eng-review-test-plan-{datetime}.md` and `tasks-eng-review-{datetime}.jsonl`. QA and /autoplan look there, even when the report uses a different state root. Keep these paths; do not relocate the artifacts beside the report. Their sections below specify the formats and write commands. A failed permitted save is different from forbidden writing. Use the failed step's stated recovery; if saving or read-back still fails, take **Blocked outcome**. Do not ask from an unsaved record or convert a failed save into the chat-only route. Forbidden auxiliary writes allow the review to continue; unrecovered attempted writes block it. Apply this policy at every later write. {{LEARNINGS_SEARCH}} ## Retrospective learning History paths by review target: - Plan: named existing paths. Mark named future paths `not available`; missing history proves nothing about proposed behavior. Never invent paths. - Branch diff: changed files. - File/directory: selected path. Run `git log --oneline -- ` and `git log --grep=revert --oneline -- `. Check recurring issues and reversals. **Plan-review evidence:** Implementation/validation steps are proposals. Calibrate findings below: quote the motivating plan requirement (file:line) and check existing interfaces where applicable. Do not require future code or call a proposed regression observed. Code-specific examples concern existing code. Bounded probes answer named uncertainties about current behavior/interfaces; report evidence and limits. Record unknowns, unmeasured results and future verification. Complete all sections, approvals and outputs without building proposed code to settle unknowns. Keep suppressed findings for the output appendix. {{CONFIDENCE_CALIBRATION}} ## Decision procedure Run this six-step loop for findings from Scope Challenge, Sections 1–4, Outside Voice, late changes and TODO choices. Finish one choice before the next. Setup gates—Context Recovery/prerequisites, Prior Learnings configuration, target and Scope Challenge complexity selectors—use local rules without a pre-answer ledger. These answers approve no engineering remedy. Flow: issue -> compare -> save/read -> ask/wait -> apply -> next issue. One question for one choice per AskUserQuestion call. Use the preamble for question transport/fallback and authorized auto-decisions. Use Review record/write policy only for saved records, reports and logs. ### 1. Establish current state Read the request, source and actual answers. Give each finding a number, severity, confidence, file:line and reviewer. Record two separate facts: - **Plan baseline:** the last approved value, exact scope and answer reference; if nothing was approved, record the original proposal. - **Runtime evidence:** what existing code or a probe shows. Mark unverified behavior unknown. Approval does not prove deployed behavior, and observed behavior does not grant approval. Drafts, recommendations and reviewer agreement grant neither. For a factual correction that changes no behavior, record the correction and evidence; no question or comparison grid is needed. If an exact prior approval covers the work, cite its answer and disposition. Carry its necessary code, tests, documentation and later-discovered required proof forward without asking again. Otherwise leave the remedy pending. Reopen an approved choice only for a concrete new risk, contradictory evidence or a changed assumption. Explain the reason and retain earlier values, complete briefs and answers in History. Record remaining unknowns and uncertain risks. ### 2. Separate independent choices Before drafting options, list each current value and proposed change: behavior, approach, guarantee or bound. Include response timing, resources, lifetimes and optional verification method or depth. Give each bound a measure and unit. Give independently selectable changes separate IDs. If the user can accept one while another stays approved or undecided, they are separate choices even in the same finding, function or patch. A reopened choice keeps its ID and receives the next continuous `D` question number. Keep one behavior with its necessary code, tests and documentation. Alternative mechanisms for that fixed behavior belong in one question; independently selectable runtime outcomes do not. Optional depths of one verification form one choice. Separate instrumentation, follow-ups, guarantees and policies need their own choices, and their tests wait for approval. ### 3. Compare one choice Select one pending ID. Prepare its question in this order: **Draft the native fields:** build `currentDecision`: - `question`: the complete D-numbered preamble brief, including Project, ELI10, Stakes, Recommendation and applicable completeness/net fields. - `header`: the exact native header. - `options`: every exact label and full description. Put the problem and file:line in the native fields. Offer 2–3 options, including do-nothing when reasonable; Outside Voice retains its four-option menu. Each option must explain human/CC effort, risk and maintenance. Tie the recommendation to the engineering preferences; prefer complete coverage when extra CC effort is marginal. Fit headers and labels to host limits now, before saving. Without stated limits, keep both under 5 words; details go in descriptions. For one fixed approved contract, coverage choices vary implementation or proof depth. Use `Completeness: N/10`: 10 covers all relevant in-scope edges, 7 covers the happy path, 3 is a shortcut. For different approaches, use `Note: options differ in kind, not coverage — no completeness score.` Test-review scores rate existing/proposed tests, not answer status. **Audit the commitments.** Build a separate **comparison grid** for the whole brief. Give every selectable behavior, approach, guarantee or bound a row. Show its concrete current value, each option's value and work, and any approval citation. Include shared, fixed and pending choices. Use these three checks for every column: 1. Vary only this choice. Keep other approved values fixed and pending choices undecided. A value shared by all options still needs approval if it is new. 2. Treat necessary implementation and proof of an approved contract as common work. Cite its answer instead of creating another approval row. Never cut an established contract or its required proof. 3. An Investigate/Defer option must bound the investigation and name what stays unchanged or pending. It approves no implementation, including a conditional fix. Keep that remedy pending. **Reconcile before saving.** Compare each option's full label and description with every row in its grid column. They must make the same commitments and retain the same conditions. Put all deliberation in the native question/descriptions; a saved-only Pros/cons block cannot supply missing decision context. Repair contradictions now. If you discover another independent choice, return to step 2 before sending the question. For example, jitter and a delay cap can be chosen independently. A menu of “both / cap only / neither” bundles them by omitting “jitter only.” Ask about jitter first: | Choice | Current | A | B | |---|---|---|---| | R1 jitter | unspecified, pending | on | off | | R2 delay cap | unspecified, pending | unspecified, pending | unspecified, pending | After the jitter answer, carry that value into both options of the later cap question. ### 4. Save the pending record Invariant for this step: save one complete current record, Read that record back, then ask the exact saved question. Do not ask from memory. Save the record, complete grid and exact `currentDecision` in the report file, before `## GSTACK REVIEW REPORT`. Include every native field, the recommendation and all options. A–D record selectors are ledger notation only: if a saved label already starts `A)`/`B)`/`C)`/`D)`, keep that one prefix; otherwise add it. Compare the label separately from that notation by removing the selector before matching. When revising, replace the whole current payload for this record: comparison grid, question, header, options, state, actual answer and accepted scope. Keep other choices' headings, content and approvals intact; move superseded payloads to History. Do not leave duplicate Question, Header or Options fields. ```markdown ## Decision ledger ### R1: Finding: Plan baseline: Runtime evidence: Comparison grid: Question D2: Header: Options: State: Actual answer: Accepted scope: History: ``` Check the Write/Edit result, then use Read to fetch the entire saved record. Compare every native field with `currentDecision` and the whole grid with step 3. Read after the final edit, even if Edit says the content is current in context. Grep, chat references, summaries and planned writes do not verify the record. Repair any difference and repeat the complete Read before asking. A failed save blocks the question; an unreadable or unverifiable record follows the write policy's recovery and then **Blocked outcome** if still unresolved. On the permitted read-only route, present the complete record and grid as **not persisted** and compare them with `currentDecision`. This can support the chat review, but cannot pass the saved-report gate. If any payload field changes, including a shortened label or formatting edit, repeat step 3, replace the whole saved payload and Read it again. An older comparison or a critic's advice cannot substitute for this verification. ### 5. Ask and wait Use the preamble's tool resolution, failure fallback and authorized auto-decision rules. Send `AskUserQuestion({ questions: [currentDecision] })` after step 4. Send one question object for one choice; other IDs wait. Copy the verified question, header, labels and descriptions literally. Do not add or strip brief paragraphs or rebuild options. Authorized prose and auto-decisions use this same verified brief with the preamble's rendering and answer rules. When Question Tuning is enabled, copying the verified question preserves its `` marker. **STOP until the actual answer arrives.** Do not apply a remedy, make another call, start the next section or call ExitPlanMode while the choice awaits an answer. An obvious fix still needs an answer unless exact prior approval covers it. ### 6. Apply and refresh Invariant for this step: apply the selected option as one complete resolution block, Read it back, then continue. Do not update only the answer line. Read the selected saved label, full description and grid column together. Carry all commitments, conditions, unchanged values and pending choices forward. If they conflict or bundle independent choices, preserve the actual answer, explain the conflict and repeat steps 2–5 for another answer. Do not reinterpret a caption, drop a commitment or advance with conflicting approvals. Replace the whole adjacent `State` / `Actual answer` / `Accepted scope` block after the options. Use the actual option and answer reference. Set State to `approved` for accepted scope or `pending` for an unresolved remedy. Each field must occur once outside History. Preserve the options and move superseded states to History. If older fields are separated, consolidate all three and remove their old occurrences in the same edit; never update only the answer/scope tail. Use a scoped Edit to save this record and only the authorized working-plan amendments. Leave other choices unchanged. On the read-only route, present both completely as **not persisted**. Check the save result, then Read the entire resolution block, including State. Verify that its unique state, actual answer and accepted scope match the complete selected option and grid column. An answer-only search or current-in-context hint cannot replace Read. In read-only mode, verify the presentation instead. Correct any discrepancy before advancing; apply the write policy to failures. Return to step 1 with the updated working plan and answer. Keep chosen values fixed in later questions, and explain when a choice has become irrelevant rather than asking it again. Start the next section only when no answer is pending in this section. Keep unresolved risks and verification visible; resolve risk and safety choices before readiness. /autoplan uses its authorized decisions and audit trail, leaving User Challenges for its final gate. ## Scope Challenge Before reviewing, answer: 1. **What existing code partly or fully solves each sub-problem?** Can existing outputs replace parallel flows? 2. **What minimum changes achieve the goal?** Flag work deferrable without blocking it; challenge scope creep. 3. **Complexity check:** Count touched files and new classes/services; consider whether the same goal needs fewer moving parts. Apply the complexity gate below. 4. **Search check:** For each new architectural pattern, infrastructure component or concurrency approach, research built-ins, current practice and pitfalls through Aside (entrypoint readiness), one read-only request per pattern: ```bash {{ASIDE_EXEC_PRELUDE}} _aside_exec "Search the web for {framework} {pattern} built-in, {pattern} best practice {current year}, and {framework} {pattern} pitfalls. Read-only: do not sign in, submit, or change anything. Reply with up to 8 bullets, each with its source URL, then stop." ``` If Aside is unavailable, use host WebSearch for these queries. With neither, skip and note: "Search unavailable — proceeding with in-distribution knowledge only." Flag custom work with an available built-in as a reduction opportunity. Label recommendations **[Layer 1]**, **[Layer 2]**, **[Layer 3]** or **[EUREKA]** per Search Before Building. Explain a case against standard practice as an architectural insight. 5. **TODOS cross-reference:** Read existing `TODOS.md`: what blocks this plan, fits this PR without expanding scope, or needs a new TODO? 6. **Completeness check:** Full tests, edges and error paths cost 10-100x less with AI. Recommend completeness over shortcuts saving human-hours but only CC+gstack minutes. Boil the ocean. 7. **Distribution check:** For new CLIs, libraries, containers or mobile apps, verify build/publish CI/CD, target OS/architectures and user download/install channels. Record deferred distribution explicitly in "NOT in scope". At 8+ files or 2+ new classes/services, STOP before Section 1. Use the preamble's decision-brief format for this complexity gate. Initial scope selectors need no grid or **pre-answer** ledger write. Ask and wait before changes. 1. Explain the complexity. Ask each proposed feature cut/deferral separately; wait before changing scope. With no proposed cuts, keep the feature list and go directly to the structure question. 2. Always ask the structure question when this gate trips, even with no cuts. Compare only the file/class arrangement. Use labels `Original arrangement` and `Smaller arrangement`; put files/classes in each description. Both retain the same approved feature list, contracts and approved security/error/test/performance fixes. Include `Pending remedies not decided here: ` in the question; unapproved fixes stay pending. If no smaller arrangement preserves these commitments, explain that and offer confirmation of the original arrangement or a pause to investigate a smaller one. Wait for the answer. 3. Save the actual feature and structure answers as one scope record: `feature answers: ; structure: ; accepted scope: ; pending remedies: `. Save this record under the write policy; no retroactive pending record. Other remedies need separate accept/reject/defer answers through Decision procedure after findings exist. Once the gate resolves, apply only accepted scope changes. Without a complexity gate, proceed directly to findings. **Commit to actual scope answers.** Do not re-argue reduction later, silently cut scope or skip planned components. Present numbered Scope Challenge findings with calibrated severity, confidence, source and accepted/rejected/deferred/pending disposition; use "No issues found" for an empty list. Carry scope answers forward; findings approve no remedies. ## Review Sections (after scope is agreed) Before Section 1, resolve Scope Challenge remedies through Decision procedure; reuse exact answers. Evaluate Architecture → Code Quality → Tests → Performance, at most 8 top issues each. Never condense, abbreviate or skip a section, including strategy/spec/infra plans. With zero findings, report "No issues found" and continue. After each of Sections 1–4, resolve new or reopened choices through Decision procedure, report findings and dispositions, then continue. ### 1. Architecture review Evaluate: * Overall system design and component boundaries. * Dependency graph and coupling concerns. * Data flow patterns and potential bottlenecks. * Scaling characteristics and single points of failure. * Security architecture (auth, data access, API boundaries). * Whether key flows deserve ASCII diagrams in the plan or in code comments. * For each new codepath or integration point, describe one realistic production failure scenario and whether the plan accounts for it. * **Distribution architecture:** If this introduces a new artifact (binary, package, container), how does it get built, published, and updated? Is the CI/CD pipeline part of the plan or deferred? ### 2. Code quality review Evaluate: * Code organization and module structure. * DRY violations—be aggressive here. * Error handling patterns and missing edge cases (call these out explicitly). * Technical debt hotspots. * Areas that are fragile or unnecessarily complex, using the entrypoint's engineering preferences. * Existing ASCII diagrams in touched files — are they still accurate after this change? ### 3. Test review For a plan target, review proposed coverage against proposed paths. For a branch-diff target, diagram changed code paths plus callers/tests; the working plan is the remedy plan from diff findings. {{TEST_COVERAGE_AUDIT_PLAN}} After the Test Plan Artifact is saved or presented, report the Test review findings and their dispositions and continue to Performance review. The Test review's **Add missing tests to the plan** step resolves test and eval decisions before that artifact is written. ### 4. Performance review Evaluate: * N+1 queries and database access patterns. * Memory-usage concerns. * Caching opportunities. * Slow or high-complexity code paths. {{CODEX_PLAN_REVIEW}} ### Continue after Outside Voice Complete the chosen Outside Voice branch, including its accurate coverage record. Only completed reviews enter Cross-model tension. Continue to Final planning decisions and the approval check before Required outputs; report disabled or unavailable coverage in the Completion summary. ## Final planning decisions After Sections 1–4 and the Outside Voice path, resolve the TODO choices below. Then run the approval check before preparing final outputs. ### TODOS.md updates Review every potential TODO. Reuse an exact prior disposition under Decision procedure; ask about each unanswered proposal in its own AskUserQuestion. Never batch TODOs or silently skip them. Use `~/.claude/skills/gstack/review/TODOS-format.md`. For each TODO, describe: * **What:** One-line description of the work. * **Why:** The concrete problem it solves or value it unlocks. * **Pros:** What you gain by doing this work. * **Cons:** Cost, complexity, or risks of doing it. * **Context:** Enough detail that someone picking this up in 3 months understands the motivation, the current state, and where to start. * **Depends on / blocked by:** Any prerequisites or ordering constraints. Then present options: **A)** Add to TODOS.md **B)** Skip — not valuable enough **C)** Build it now in this PR instead of deferring. Option C records accepted implementation scope; still do not edit product code. Record this context with each accepted TODO; a vague bullet is insufficient. {{PLAN_REVIEW_APPROVAL_CHECK}} ## Required outputs Run this finish sequence after Approval readiness passes. The reference sections below supply content, formats and commands for the named step; they do not start another review cycle. On recovery, resume at the failed step. Reuse a successful Review Log for unchanged saved outputs; changed outputs must pass steps 1–4 again. 1. **Prepare the review body.** Use the output reference below to complete the working plan, Implementation Tasks and Completion summary. Derive unresolved choices from each record's current State, actual answer and accepted scope; leave them pending. Save permitted auxiliary artifacts under the write policy. 2. **Save and Read back.** Use Plan File Review Report to save the complete body and append its terminal `## GSTACK REVIEW REPORT`. Pass that writer's Read-back gate. If report persistence is forbidden or the save cannot be recovered, follow **Blocked outcome**; do not continue to logging. 3. **Log the saved review.** Run Review Log with the saved Completion summary's values. If the required log is forbidden, show its fields as not persisted and take **Blocked outcome**. If it fails, apply the write policy's recovery. Neither case supplies completion or saved-dashboard credit. 4. **Publish.** Display the Review Readiness Dashboard, then present the saved Completion summary to the user. 5. **Choose navigation.** Use Next Steps — Review Chaining and wait for its answer. Navigation grants no implementation authority. If a substantive change arises, resolve it through Decision procedure, repeat Approval readiness, and redo the affected outputs from step 1 through publication before asking navigation again. 6. **Finish.** Run Learning hooks, then return to the entrypoint's Section self-check and read-only EXIT PLAN MODE GATE. Run these checks in every host mode. Brain Calibration Write-Back is one gated Learning hook. Only after both pass, run success telemetry and cache refresh; call ExitPlanMode only in host plan mode. ### Output reference — review body Keep the working plan, findings, ledger and the sections below together in the report file. Place `Suppressed findings` as a body appendix before the terminal `## GSTACK REVIEW REPORT`; nothing follows that terminal report. ### "NOT in scope" section List considered work that was explicitly deferred, with one sentence explaining each deferral. ### "What already exists" section List existing code or flows that partly solve the problem. Say whether the working plan reuses them or unnecessarily rebuilds them. ### Diagrams Use ASCII diagrams for non-trivial data flows, state machines and pipelines. Name implementation files that need inline diagrams, especially complex model transitions, service pipelines and non-obvious mixin behavior. ### Failure modes For each new path in the test diagram, name a realistic production failure and whether: 1. A test covers that failure 2. Error handling exists for it 3. The user would see a clear error or a silent failure If any failure mode has no test AND no error handling AND would be silent, flag it as a **critical gap**. ### Worktree parallelization strategy Group implementation steps for parallel git worktrees (`isolation: "worktree"` or parallel workspaces). With one primary module or fewer than 2 independent workstreams, write: "Sequential implementation, no parallelization opportunity." **Otherwise, produce:** 1. **Dependency table** — for each implementation step/workstream: | Step | Modules touched | Depends on | |------|----------------|------------| | (step name) | (directories/modules, NOT specific files) | (other steps, or —) | Use modules/directories, not guessed files: plans describe intent. 2. **Parallel lanes:** separate independent, disjoint modules; sequence shared modules together and dependencies later. Format: `Lane A: step1 → step2 (sequential, shared models/)` / `Lane B: step3 (independent)` 3. **Execution order:** name launch/wait points: "Launch A + B in parallel worktrees. Merge both. Then C." 4. **Conflict flags:** name shared modules across parallel lanes and recommend sequential execution or coordination to avoid merge conflicts. {{TASKS_SECTION_EMIT:eng-review}} ### Unresolved decisions List unanswered or interrupted choices as "Unresolved decisions that may bite you later", with their IDs and missing answers. Never default silently. Count each open choice once, separately from prior reviews; the terminal report adds those independently. ### Completion summary Use the final decision record and outputs. The finish sequence publishes this summary after the report Read-back and Review Log: - Step 0: Scope Challenge — ___ (scope accepted as-is / scope reduced per recommendation) - Architecture Review: ___ issues found - Code Quality Review: ___ issues found - Test Review: diagram produced, ___ gaps identified - Performance Review: ___ issues found - NOT in scope: written - What already exists: written - TODOS.md updates: ___ items proposed to user - Failure modes: ___ critical gaps flagged - Unresolved decisions: ___ in this review - Outside voice: recorded provider, completed / unavailable / disabled / skipped (reason) - Parallelization: ___ lanes, ___ parallel / ___ sequential - Lake Score: X/Y. Y counts answered coverage choices; X counts those selecting 10/10. Exclude choices that differ in kind; use N/A when Y is zero. {{PLAN_FILE_REVIEW_REPORT}} ## Review Log Use these commands in finish step 3, after successful Read-back. The required review log and best-effort decision log each follow the write policy. ```bash ~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"plan-eng-review","timestamp":"TIMESTAMP","status":"STATUS","unresolved":N,"critical_gaps":N,"issues_found":N,"mode":"MODE","commit":"COMMIT"}' || exit $? ~/.claude/skills/gstack/bin/gstack-decision-log '{"decision":"Eng review (MODE): ARCH_SUMMARY","rationale":"KEY_DECISION","scope":"branch","source":"skill","confidence":8}' 2>/dev/null || true ``` The second command records a durable architecture decision and is best-effort. Use the finding/disposition summary for `ARCH_SUMMARY` and the key architecture choice for `KEY_DECISION`. Omit it if the review found nothing durable. Substitute values from the Completion Summary: - **TIMESTAMP**: current ISO 8601 datetime - **STATUS**: "clean" when `issues_found=0`, `unresolved=0` and `critical_gaps=0`; otherwise "issues_open". Resolved findings still count in `issues_found`, so "issues_open" can mean mapped work, not a failed review. - **unresolved**: this review's "Unresolved decisions" count; do not include prior reviews - **critical_gaps**: number from "Failure modes: ___ critical gaps flagged" - **issues_found**: total issues found across all review sections (Architecture + Code Quality + Performance + Test gaps) - **MODE**: FULL_REVIEW for the Scope Challenge result "scope accepted as-is"; SCOPE_REDUCED for "scope reduced per recommendation". - **COMMIT**: output of `git rev-parse --short HEAD` {{REVIEW_DASHBOARD}} ## Next Steps — Review Chaining In finish step 5, use the published dashboard to offer only applicable routes: - **A) Run /plan-design-review:** UI scope exists and no design review ran. Detect UI scope from frontend components, CSS, views or user-facing interactions found in the diagram or review sections. - **B) Run /plan-ceo-review:** a significant product change has no CEO review. Mention it as an optional suggestion for new user-facing features, changed product direction or substantial scope expansion. - **C) Ready to implement — run /ship when done** Note when existing CEO or design reviews may be stale because this review found contradictory assumptions or significant commit drift. If no additional review is needed, or dashboard config has `skip_eng_review: true`, state "All relevant reviews complete. Run /ship when ready." AskUserQuestion with only the applicable options. This is **navigation only**: copy the working plan's task prerequisites, dependencies and execution order without adding or strengthening them in the question or descriptions. A test required before editing one function does not make every independent lane wait. A next-step answer approves no implementation change. For a substantive late change, follow the repeat path in finish step 5. Refresh affected tasks, dependencies and parallelization along with the other outputs. ## Learning hooks Use these hooks in finish step 6 without changing the working plan or approval record. Review durable operational learnings as required by the preamble, and use the Capture Learnings format below for other discoveries; do not log the same learning twice. {{LEARNINGS_LOG}} {{GBRAIN_SAVE_RESULTS}} {{BRAIN_WRITE_BACK}}