@codename_inc/spectre 5.2.1 → 5.2.2

package/package.json

@@ -1,9 +1,9 @@
 {
   "name": "@codename_inc/spectre",
-  "version": "5.2.1",
+  "version": "5.2.2",
   "type": "module",
   "bin": {
-    "spectre": "./bin/spectre.js"
+    "spectre": "bin/spectre.js"
   },
   "files": [
     "bin",

package/plugins/spectre/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "spectre",
-  "version": "5.2.1",
+  "version": "5.2.2",
   "description": "Agentic coding workflow with session memory. spectre guides you through Scope, Plan, Execute, Clean, Test, Rebase, and Extract phases."
 }

package/plugins/spectre/skills/create_plan/SKILL.md

@@ -27,6 +27,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 - **Action** — CheckExistingResearch: Check if technical research already completed.
   - Read `TASK_DIR/task_context.md`; look for "## Technical Research" section.
   - **If** found with comprehensive analysis → use existing research; skip to Step 3.
+  - **If** ARGUMENTS contains `--depth light` and `TASK_DIR/task_context.md` already contains substantive router research (file locations, code understanding, codebase patterns, and impact summary) → use existing research; skip to Step 3.
   - **Else** → proceed with new research below.
 - **Action** — AutomatedResearch: Spawn parallel research agents for comprehensive analysis.
   - Use `@finder` to find all files related to feature area.
@@ -61,6 +62,8 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 Dynamically generate up to 10 technical questions based on research findings. **IMPORTANT**: Only ask questions genuinely not answered in the PRD or discoverable through code investigation. Goal: eliminate scope and design ambiguity. If a question involves choosing between approaches, present options with Pros/Cons/Trade-offs.
 
+- **Action** — LightModeClarifications: If ARGUMENTS contains `--depth light`, do NOT stop for user clarifications. Use conservative, codebase-consistent defaults and record them in the plan's **Filled Assumptions** section, then skip to Step 3. If an unresolved question would affect canonical scope, security/privacy, data correctness, or public API behavior, return control to `plan` with a tier reassessment recommendation instead of guessing.
+
 - **Action** — DetectClarificationMethod: Check if `AskUserQuestion` tool is available.
   - **If available** → use inline clarification flow (Path A).
   - **If not available** → use file-based clarification flow (Path B).
@@ -94,16 +97,17 @@ Dynamically generate up to 10 technical questions based on research findings. **
 - **Action** — DetermineDepth: Read `--depth` from ARGUMENTS
 
   - Default: `standard` if not specified
-  - Options: `standard`, `comprehensive`
+  - Options: `light`, `standard`, `comprehensive`
+- **Action** — DetectOrchestratedMode: If ARGUMENTS contains `--no-review`, this workflow is being invoked by `plan` as part of the meta-flow. Generate and save the plan, then return control to `plan` without asking for standalone user review.
 
 - **Action** — DesignTechnicalApproach: Create the implementation plan.
 
-  Every plan, regardless of depth, MUST include these seven sections. They are the verification spine — without them, downstream agents cannot self-check their work.
+  Every plan, regardless of depth, MUST include the verification spine. LIGHT is concise, not shallow: keep it brief and decisive, but still explain the solution shape, codebase pattern to follow, risks/assumptions, and how the work will be verified.
 
-  **Required for both STANDARD and COMPREHENSIVE:**
+  **Required for LIGHT, STANDARD, and COMPREHENSIVE:**
   1. **Overview** — 1–2 paragraphs: what problem, what shape the solution takes, why this approach.
   2. **Technical Approach** — How the change actually lands: components touched, data flow, key decisions with rationale. Reference existing patterns from `@patterns` research by file:line (e.g., "follow the shape of `src/widgets/HotDogWidget.ts:42` for the registration step").
-  3. **Critical Files for Implementation** — 3–7 specific files from research. Format: `path/to/file.ts` — *reason* (Core logic to modify / Pattern to follow / Interface to implement / Test to extend). No guesses — only files surfaced during Step 1 research.
+  3. **Critical Files for Implementation** — 1–7 specific files from research. Format: `path/to/file.ts` — *reason* (Core logic to modify / Pattern to follow / Interface to implement / Test to extend). No guesses — only files surfaced during Step 1 research.
   4. **External Dependencies — Verify Before Implementation** — Every third-party package required, with exact version and a one-line existence check. Format: `package@1.2.3 — verify: npm view package@1.2.3` (or pip equivalent). Required even if "no new packages" (write that explicitly). This is the slopsquatting fence: ~20% of AI-suggested packages don't exist; we catch that here, not in production.
   5. **Verification — How We Know This Works** — For each major change in Technical Approach, 1–3 falsifiable signals: a test name, an observable behavior, or a state/file condition. Prose like "the feature works" is not acceptable — it must be checkable. Format: `<change> → verifies by: <test name | observable behavior | state condition>`. These become acceptance criteria in `create_tasks` downstream.
   6. **Out-of-Bounds — DO NOT add** — 4–8 concrete things the implementation must NOT add, even if "best practice." Examples: rate limiting, retry/backoff, caching layer, optimistic UI, soft-delete, telemetry events, feature flags, admin UI. This is the YAGNI fence against familiar-shape bias (agents reproduce mature-system patterns unprompted). Be specific to this feature, not generic.
@@ -111,6 +115,12 @@ Dynamically generate up to 10 technical questions based on research findings. **
      - *Risks*: what could go wrong (e.g., concurrent write race, migration ordering, third-party rate limit). Each with a one-line mitigation or "accept and monitor."
      - *Filled Assumptions*: things the plan defaulted because the spec didn't say (e.g., "Assumed Postgres; spec didn't specify DB." "Assumed retry count = 0; spec didn't mention failure modes."). Reviewer-visible by design — these are the silent decisions that bite at execution.
 
+  **LIGHT constraints:**
+  - Keep the seven required sections compact: usually 1 short paragraph or 3–5 bullets per section.
+  - Prefer one clear implementation path that follows existing codebase patterns; do not enumerate broad alternatives.
+  - Do not add standalone clarification gates, review gates, plan_review, or expanded architecture sections.
+  - If the plan needs more than 3 critical files, a new abstraction, data migration, public API change, or unresolved scope/security/data correctness decision, stop and return a tier reassessment recommendation to `plan`.
+
   **COMPREHENSIVE additionally requires:**
   8. **Current State** — How the affected code path works today, with file:line refs. Anchored to research findings.
   9. **Implementation Phases** — Ordered phases, each with its own Verification subsection (Phase N succeeds when …). Phases must be sequenced by dependency, not by file. Migration phases come before consumer phases.
@@ -125,14 +135,28 @@ Dynamically generate up to 10 technical questions based on research findings. **
 
 - **Action** — RequestReview:
 
-  > "Implementation plan saved to `{path}`. Review and reply with feedback or 'Approved' to proceed."
+  - **If `--no-review` is present**:
+
+    > "Draft implementation plan saved to `{path}`. Returning to `plan` for the next routed step."
+
+    Do NOT wait for user approval. Return control to the invoking `plan` workflow.
+
+  - **Else**:
 
-- **Wait** — User provides feedback or approval
+    > "Implementation plan saved to `{path}`. Review and reply with feedback or 'Approved' to proceed."
+
+- **Wait** — User provides feedback or approval, unless `--no-review` is present.
 
 ## Step (4/4) - Finalize and Present Next Steps
 
 - **Action** — ConfirmCompletion:
 
+  - **If `--no-review` is present**:
+
+    > "Draft implementation plan saved to `{plan_path}`. Returning to `plan`."
+
+    Stop here. Do not render the standalone Next Steps footer.
+
   > "🎯 Implementation Planning Complete. Documents: {plan_path}, task_context.md"
 
-- **Action** — RenderFooter: Use `@skill-spectre:spectre-guide` skill for Next Steps footer
+- **Action** — RenderFooter: Use `@skill-spectre:spectre-guide` skill for Next Steps footer

package/plugins/spectre/skills/plan/SKILL.md

@@ -15,7 +15,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 ## Description
 
 - **What** — Research codebase, assess complexity, route to appropriate workflow (direct tasks or plan-first)
-- **Outcome** — Detailed task breakdown ready for execution
+- **Outcome** — A right-sized `plan.md` + `tasks.md`; STANDARD/COMPREHENSIVE include review and a final execution gate, while LIGHT stays non-blocking.
 
 ## ARGUMENTS Input
 
@@ -23,7 +23,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 ## MANDATORY COMPLIANCE RULES
 
-> **⚠️ NON-NEGOTIABLE**: This workflow MUST invoke nested workflows via the Skill tool. Failure to invoke `Skill(create_plan)` and `Skill(create_tasks)` (Claude slash route: `/spectre:create_plan` and `/spectre:create_tasks`) is a critical error. Do NOT summarize, describe, or skip these workflows. INVOKE THEM.
+> **⚠️ NON-NEGOTIABLE**: After tier routing, this workflow MUST invoke nested workflows via the Skill tool. LIGHT must invoke `Skill(create_plan)` and `Skill(create_tasks)`; STANDARD/COMPREHENSIVE must invoke `Skill(create_plan)`, `Skill(create_tasks)`, and `Skill(plan_review)` (Claude slash route: `/spectre:create_plan`, `/spectre:create_tasks`, and `/spectre:plan_review`). Failure to invoke the required skills is a critical error. Do NOT summarize, describe, or skip these workflows. INVOKE THEM.
 
 **After ANY user conversation or questions:**
 
@@ -33,14 +33,16 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 **You MUST call these skills (not describe them):**
 
-- Use the **Skill** tool with `skill: "spectre-create_plan"` and `args: "{path} --depth {tier}"` — generates plan.md
+- Use the **Skill** tool with `skill: "spectre-create_plan"` and `args: "{path} --depth {tier}"` — generates plan.md, including LIGHT
 - Use the **Skill** tool with `skill: "spectre-create_tasks"` and `args: "{path}"` — generates tasks.md
+- Use the **Skill** tool with `skill: "spectre-plan_review"` and `args: "{OUT_DIR} --auto-apply scope-safe"` — reviews and integrates scope-safe feedback for STANDARD/COMPREHENSIVE
 
 ## Instructions
 
 - Research before routing; present architectural options for user buy-in
 - Route based on hard-stops and clarity, not point-scoring
 - Never overwrite existing `tasks.md` or `plan.md` — use scoped names
+- Treat `concepts/scope.md` (then `specs/prd.md` / `specs/ux.md` when present) as canonical. Plan generation, task generation, review, and feedback integration may change implementation approach, sequencing, verification, references, and YAGNI fences, but MUST NOT cut, narrow, expand, or reinterpret the agreed scope without an explicit user scope-change gate.
 
 ## Step 1 - Research Codebase
 
@@ -124,7 +126,7 @@ Use research findings from Step 1 to determine appropriate planning depth.
 
 ## Step 3 - High-Level Design
 
-**SKIP IF LIGHT** — proceed directly to Step 4.
+**SKIP IF LIGHT** — proceed directly to Step 4. LIGHT still generates a real plan in Step 4; it only skips this human alignment gate.
 
 Goal: align on the *shape* of the solution before generating a full plan. This catches misalignments early and gives the user a chance to redirect before reading a long plan doc.
 
@@ -171,7 +173,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - **Action** — PersistDesign: Append a "Selected Design" section to `{OUT_DIR}/task_context.md` capturing the agreed approach, key decisions, and resolved questions. This is what `create_plan` consumes.
 
-> **CHECKPOINT**: After alignment, proceed IMMEDIATELY to Step 4. The ONLY valid next action is invoking a Skill.
+> **CHECKPOINT**: After alignment, proceed IMMEDIATELY to Step 4. This is the early gate. The next valid actions are Skill invocations that generate the draft plan, generate tasks, run plan_review, integrate scope-safe feedback, and then present the final plan/tasks for the user's final gate.
 
 ## Step 4 - Route to Workflow
 
@@ -187,6 +189,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 │                                                                        │
 │  ✅ CORRECT: Skill tool with skill: "spectre-create_plan", args: "..." │
 │  ✅ CORRECT: Skill tool with skill: "spectre-create_tasks", args: "..."│
+│  ✅ CORRECT: Skill tool with skill: "spectre-plan_review", args: "..." │
 └────────────────────────────────────────────────────────────────────────┘
 ```
 
@@ -202,6 +205,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - Use the Skill tool: `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth {tier}"`
 - Use the Skill tool: `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
+- For STANDARD/COMPREHENSIVE, use the Skill tool: `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
 
 ---
 
@@ -209,27 +213,34 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - **If LIGHT**:
 
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth light --no-review"`
+  - **Wait** — Returns concise plan with solution shape, patterns, risks, and verification approach
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md --depth light"`
-  - **Wait** — Returns task breakdown with brief implementation approach
+  - **Wait** — Returns task breakdown grounded in the light plan
+  - **Action** — PresentLightArtifacts: Summarize `{OUT_DIR}/specs/plan.md` and `{OUT_DIR}/specs/tasks.md`. State that LIGHT skipped `plan_review` and the human execution gate by design.
   - Skip to footer
 
 - **ElseIf STANDARD**:
 
-  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth standard"`
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth standard --no-review"`
   - **Wait** — Returns focused plan (Overview, Approach, Out of Scope)
-  - **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
-  - **Wait** — User approval
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
   - **Wait** — Returns task breakdown
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
+  - **Wait** — Returns findings, applied edits, skipped scope-changing recommendations, and updated artifacts
+  - **Action** — IntegratePlanReviewFeedback: Read the plan_review report path returned by `plan_review`. Confirm every scope-safe Blocker/High finding is reflected in `plan.md` and/or `tasks.md`. If `plan_review` produced a scope-safe suggested edit but did not apply it because it needed minor adaptation, apply the smallest artifact edit now and record it in the final summary. Do not apply Scope Change Required findings.
+  - Continue to Final Gate
 
 - **ElseIf COMPREHENSIVE**:
 
-  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth comprehensive"`
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth comprehensive --no-review"`
   - **Wait** — Returns full plan (all sections: Architecture, Phases, API Design, Testing Strategy, etc.)
-  - **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
-  - **Wait** — User approval
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
   - **Wait** — Returns task breakdown
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
+  - **Wait** — Returns findings, applied edits, skipped scope-changing recommendations, and updated artifacts
+  - **Action** — IntegratePlanReviewFeedback: Read the plan_review report path returned by `plan_review`. Confirm every scope-safe Blocker/High finding is reflected in `plan.md` and/or `tasks.md`. If `plan_review` produced a scope-safe suggested edit but did not apply it because it needed minor adaptation, apply the smallest artifact edit now and record it in the final summary. Do not apply Scope Change Required findings.
+  - Continue to Final Gate
 
 ---
 
@@ -253,4 +264,19 @@ Only proceed past this checkpoint when the user confirms.
 
 ---
 
+### Final Gate
+
+- **Action** — PresentFinalArtifacts:
+  - Summarize final artifact paths: `{OUT_DIR}/specs/plan.md`, `{OUT_DIR}/specs/tasks.md`, and the saved plan_review report under `{OUT_DIR}/reviews/`.
+  - Summarize review integration: findings applied by `plan_review`, any additional plan-orchestrator edits applied to integrate feedback, skipped edits, and any recommendations that were blocked because they would change canonical scope.
+  - If plan_review surfaced a scope-changing recommendation, state: "This requires a scope change; I did not apply it." Ask the user whether to reopen scope or approve the current canonical-scope-preserving plan/tasks.
+  - Otherwise prompt: "Final reviewed plan/tasks are ready. Reply `Approved` to proceed to execution, or provide final feedback."
+
+- **Wait** — User final approval or feedback.
+
+- **If feedback preserves canonical scope** — apply the smallest edits to `plan.md`/`tasks.md`, re-run `plan_review {OUT_DIR} --auto-apply scope-safe` if the feedback changes implementation approach, verification, dependencies, task sequencing, or references, then present the Final Gate again.
+- **If feedback changes canonical scope** — stop and route back to `/spectre:scope` (or explicitly update the canonical scope artifact if the user directs it). Do not silently update plan/tasks against stale scope.
+
+---
+
 - **Action** — RenderFooter: Use `@skill-spectre:spectre-guide` skill for Next Steps

package/plugins/spectre/skills/plan_review/SKILL.md

@@ -16,8 +16,15 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 - **What** — Independent review of any available planning artifacts (`plan.md`, `tasks.md`, and optional `task_context.md`) from four specialized lenses, dispatched in parallel
 - **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update the available artifacts
+- **Artifact** — Always save a Markdown review report before any write-back so pre-integration findings are auditable
 - **Role** — Senior staff engineer + reviewer panel; bias toward pragmatic problem-solving, YAGNI enforcement, and verifiability
 
+## Canonical Scope Invariant
+
+`concepts/scope.md` is canonical when present. If absent, use `specs/prd.md`, `specs/ux.md`, and explicit requirements in `task_context.md` as the scope source, in that order.
+
+Reviewers may recommend deleting unrequested implementation details, unnecessary abstractions, weak verification, hallucinated references, bad dependencies, or task sequencing problems. They MUST NOT cut, narrow, expand, or reinterpret agreed scope. If a reviewer believes the agreed scope itself is too large, internally inconsistent, or missing a requirement, phrase that as a **Scope Change Required** recommendation for the user. Do not apply it to `plan.md` or `tasks.md` during write-back.
+
 ## ARGUMENTS Input
 
 <ARGUMENTS>
@@ -46,12 +53,15 @@ A single reviewer biases toward the issues it notices first. Published practice
   - `PLAN=${TASK_DIR}/specs/plan.md` (or scoped name)
   - `TASKS=${TASK_DIR}/specs/tasks.md` (or scoped name)
   - `CONTEXT=${TASK_DIR}/task_context.md`
+  - `SCOPE=${TASK_DIR}/concepts/scope.md` when present; otherwise use `specs/prd.md` / `specs/ux.md` as available
+  - `REVIEWS_DIR=${TASK_DIR}/reviews`
+  - `REVIEW_REPORT=${REVIEWS_DIR}/plan_review.md`; if that exists, use `plan_review_{YYYY-MM-DD_HHMMSS}.md` to avoid overwriting prior review evidence.
   - `plan.md` and `tasks.md` are independently reviewable. It is valid to review only `plan.md`, only `tasks.md`, or both.
   - `task_context.md` is helpful context but is not required. If it is missing, continue and note that requirements traceability is limited.
   - If both `plan.md` and `tasks.md` are missing, stop and suggest the user run `/spectre:plan` or `/spectre:create_tasks` first.
   - If exactly one of `plan.md` or `tasks.md` is missing, list it as absent context and continue. Do not decline, stop, or ask the user to create the missing artifact.
 
-- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker.
+- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker. The manifest must label the canonical scope source and state that review findings may not remove or narrow scope.
 
 ## Step 2 — Dispatch Four Parallel Reviewers
 
@@ -64,13 +74,15 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
 > Review the available plan and/or task list for unrequested complexity. Agents have a documented "familiar-shape bias": shown a feature, they reproduce the mature-system shape from their training data (auth → adds rate-limiting; CRUD → adds soft-delete; form → adds optimistic UI; service → adds telemetry; module → adds feature flags). Your job is to find that bias here.
 >
 > Find:
-> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`task_context.md` / scope / PRD). If context is absent, use the plan's own requirements and boundaries.
+> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`scope.md` / `task_context.md` / PRD / UX). If context is absent, use the plan's own requirements and boundaries.
 > 2. When `tasks.md` is present: tasks that implement something the available requirements don't ask for. If requirements context is absent, use the task list's stated goals and boundaries.
 > 3. Abstractions, interfaces, or layers introduced for a single concrete caller.
 > 4. Generality (config files, plugin points, factories) where the actual need is one specific behavior.
 > 5. Overlap with the `Out-of-Bounds — DO NOT add` list (if anything violates that list, it's a hard fail).
 >
-> Required output: nominate the SINGLE highest-leverage thing to delete and justify it. You must pick one. Then list other simplifications ranked by impact. For each finding, cite the exact file:line or section header it lives in.
+> Scope guard: you may nominate implementation detail to delete only when it is not required by canonical scope. Do not nominate an agreed requirement, user-approved behavior, or required task as the thing to delete. If the best "cut" would change canonical scope, label it **Scope Change Required** and do not include it as an auto-applicable deletion.
+>
+> Required output: nominate the SINGLE highest-leverage implementation detail to delete and justify it. You must pick one unless every possible deletion would change canonical scope; in that case, say "No scope-safe deletion found" and provide the nearest Scope Change Required recommendation separately. Then list other simplifications ranked by impact. For each finding, cite the exact file:line or section header it lives in.
 
 ### Lens 2 — Verifiability (`@analyst`)
 
@@ -118,6 +130,7 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - **High** — meaningfully reduces output quality (missing RED test, weak canonical reference, prose criterion)
   - **Medium** — overengineering or reuse miss without functional blast radius
   - **Low** — stylistic or nice-to-have
+  - **Scope Change Required** — may be valid feedback, but would cut, expand, or reinterpret canonical scope and therefore needs explicit user approval before any artifact edit
 
 - **Action** — RenderFindingsTable: Output a single structured table. Schema is fixed.
 
@@ -143,11 +156,24 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - Low: {N}
   ```
 
+- **Action** — SaveReviewArtifact: Before applying any edits to `plan.md` or `tasks.md`, save the pre-integration review findings as a Markdown report.
+  - Create `${REVIEWS_DIR}` if missing.
+  - Write `${REVIEW_REPORT}` using the RenderFindingsTable content plus:
+    - Reviewed artifacts: exact plan/tasks/context/scope paths present and absent.
+    - Canonical scope source used.
+    - Auto-apply mode: enabled/disabled.
+    - Timestamp.
+    - Explicit note: "This report captures plan_review findings before any write-back to plan.md or tasks.md."
+  - Do not overwrite an existing report. Use the timestamped filename if the default already exists.
+  - Include the saved report path in all subsequent summaries and in `ReportApplied`.
+
 ## Step 4 — Surface Findings & Apply Edits
 
-- **Action** — PresentFindings: Render the findings table inline.
+- **Action** — PresentFindings: Render the findings table inline and include `Review report saved: {REVIEW_REPORT}`.
+
+- **Action** — DetectAutoApplyMode: If ARGUMENTS contains `--auto-apply scope-safe`, skip the user selection prompt and apply all scope-safe Blocker and High findings, plus Medium/Low findings only when the Suggested Edit is unambiguous and cannot change canonical scope. Do not apply findings marked Scope Change Required. Continue to ApplyEdits and SelfCheck, then return the applied/skipped summary to the invoking workflow.
 
-- **Action** — OfferWriteBack: After the table, prompt:
+- **Action** — OfferWriteBack: Unless `--auto-apply scope-safe` is present, after the table prompt:
 
   > Reply with which findings to apply:
   > - `all` — apply every suggested edit
@@ -163,17 +189,21 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - Open the named artifact (`plan.md` or `tasks.md`)
   - Apply the Suggested Edit verbatim where possible; if the edit needs adaptation, make the minimum change consistent with the finding's intent
   - Track which findings were applied
+  - Before writing, confirm the edit preserves every requirement and boundary in the canonical scope source. If it would remove, narrow, expand, or reinterpret scope, skip it and record it as "skipped: requires scope change."
 
 - **Action** — SelfCheck: After edits, run a fast pass over the modified sections:
   - Re-verify any file:line refs touched
   - Re-verify acceptance criteria are still executable
   - Confirm no edit introduced a new Out-of-Bounds violation
+  - Confirm canonical scope is still fully represented by the resulting plan/tasks
   - If any check fails, surface it and ask the user before continuing
 
 - **Action** — ReportApplied:
 
   > Applied: {list of finding numbers}. Skipped: {list}.
+  > Review report: {REVIEW_REPORT}.
   > {Path to updated artifact(s)}.
+  > Scope-change recommendations not applied: {list or "none"}.
 
 ## Step 5 — Next Steps
 

package/plugins/spectre-codex/skills/create_plan/SKILL.md

@@ -27,6 +27,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 - **Action** — CheckExistingResearch: Check if technical research already completed.
   - Read `TASK_DIR/task_context.md`; look for "## Technical Research" section.
   - **If** found with comprehensive analysis → use existing research; skip to Step 3.
+  - **If** ARGUMENTS contains `--depth light` and `TASK_DIR/task_context.md` already contains substantive router research (file locations, code understanding, codebase patterns, and impact summary) → use existing research; skip to Step 3.
   - **Else** → proceed with new research below.
 - **Action** — AutomatedResearch: Spawn parallel research agents for comprehensive analysis.
   - Use `@finder` to find all files related to feature area.
@@ -61,6 +62,8 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 Dynamically generate up to 10 technical questions based on research findings. **IMPORTANT**: Only ask questions genuinely not answered in the PRD or discoverable through code investigation. Goal: eliminate scope and design ambiguity. If a question involves choosing between approaches, present options with Pros/Cons/Trade-offs.
 
+- **Action** — LightModeClarifications: If ARGUMENTS contains `--depth light`, do NOT stop for user clarifications. Use conservative, codebase-consistent defaults and record them in the plan's **Filled Assumptions** section, then skip to Step 3. If an unresolved question would affect canonical scope, security/privacy, data correctness, or public API behavior, return control to `plan` with a tier reassessment recommendation instead of guessing.
+
 - **Action** — DetectClarificationMethod: Check if `AskUserQuestion` tool is available.
   - **If available** → use inline clarification flow (Path A).
   - **If not available** → use file-based clarification flow (Path B).
@@ -94,16 +97,17 @@ Dynamically generate up to 10 technical questions based on research findings. **
 - **Action** — DetermineDepth: Read `--depth` from ARGUMENTS
 
   - Default: `standard` if not specified
-  - Options: `standard`, `comprehensive`
+  - Options: `light`, `standard`, `comprehensive`
+- **Action** — DetectOrchestratedMode: If ARGUMENTS contains `--no-review`, this workflow is being invoked by `plan` as part of the meta-flow. Generate and save the plan, then return control to `plan` without asking for standalone user review.
 
 - **Action** — DesignTechnicalApproach: Create the implementation plan.
 
-  Every plan, regardless of depth, MUST include these seven sections. They are the verification spine — without them, downstream agents cannot self-check their work.
+  Every plan, regardless of depth, MUST include the verification spine. LIGHT is concise, not shallow: keep it brief and decisive, but still explain the solution shape, codebase pattern to follow, risks/assumptions, and how the work will be verified.
 
-  **Required for both STANDARD and COMPREHENSIVE:**
+  **Required for LIGHT, STANDARD, and COMPREHENSIVE:**
   1. **Overview** — 1–2 paragraphs: what problem, what shape the solution takes, why this approach.
   2. **Technical Approach** — How the change actually lands: components touched, data flow, key decisions with rationale. Reference existing patterns from `@patterns` research by file:line (e.g., "follow the shape of `src/widgets/HotDogWidget.ts:42` for the registration step").
-  3. **Critical Files for Implementation** — 3–7 specific files from research. Format: `path/to/file.ts` — *reason* (Core logic to modify / Pattern to follow / Interface to implement / Test to extend). No guesses — only files surfaced during Step 1 research.
+  3. **Critical Files for Implementation** — 1–7 specific files from research. Format: `path/to/file.ts` — *reason* (Core logic to modify / Pattern to follow / Interface to implement / Test to extend). No guesses — only files surfaced during Step 1 research.
   4. **External Dependencies — Verify Before Implementation** — Every third-party package required, with exact version and a one-line existence check. Format: `package@1.2.3 — verify: npm view package@1.2.3` (or pip equivalent). Required even if "no new packages" (write that explicitly). This is the slopsquatting fence: ~20% of AI-suggested packages don't exist; we catch that here, not in production.
   5. **Verification — How We Know This Works** — For each major change in Technical Approach, 1–3 falsifiable signals: a test name, an observable behavior, or a state/file condition. Prose like "the feature works" is not acceptable — it must be checkable. Format: `<change> → verifies by: <test name | observable behavior | state condition>`. These become acceptance criteria in `create_tasks` downstream.
   6. **Out-of-Bounds — DO NOT add** — 4–8 concrete things the implementation must NOT add, even if "best practice." Examples: rate limiting, retry/backoff, caching layer, optimistic UI, soft-delete, telemetry events, feature flags, admin UI. This is the YAGNI fence against familiar-shape bias (agents reproduce mature-system patterns unprompted). Be specific to this feature, not generic.
@@ -111,6 +115,12 @@ Dynamically generate up to 10 technical questions based on research findings. **
      - *Risks*: what could go wrong (e.g., concurrent write race, migration ordering, third-party rate limit). Each with a one-line mitigation or "accept and monitor."
      - *Filled Assumptions*: things the plan defaulted because the spec didn't say (e.g., "Assumed Postgres; spec didn't specify DB." "Assumed retry count = 0; spec didn't mention failure modes."). Reviewer-visible by design — these are the silent decisions that bite at execution.
 
+  **LIGHT constraints:**
+  - Keep the seven required sections compact: usually 1 short paragraph or 3–5 bullets per section.
+  - Prefer one clear implementation path that follows existing codebase patterns; do not enumerate broad alternatives.
+  - Do not add standalone clarification gates, review gates, plan_review, or expanded architecture sections.
+  - If the plan needs more than 3 critical files, a new abstraction, data migration, public API change, or unresolved scope/security/data correctness decision, stop and return a tier reassessment recommendation to `plan`.
+
   **COMPREHENSIVE additionally requires:**
   8. **Current State** — How the affected code path works today, with file:line refs. Anchored to research findings.
   9. **Implementation Phases** — Ordered phases, each with its own Verification subsection (Phase N succeeds when …). Phases must be sequenced by dependency, not by file. Migration phases come before consumer phases.
@@ -125,14 +135,28 @@ Dynamically generate up to 10 technical questions based on research findings. **
 
 - **Action** — RequestReview:
 
-  > "Implementation plan saved to `{path}`. Review and reply with feedback or 'Approved' to proceed."
+  - **If `--no-review` is present**:
+
+    > "Draft implementation plan saved to `{path}`. Returning to `plan` for the next routed step."
+
+    Do NOT wait for user approval. Return control to the invoking `plan` workflow.
+
+  - **Else**:
 
-- **Wait** — User provides feedback or approval
+    > "Implementation plan saved to `{path}`. Review and reply with feedback or 'Approved' to proceed."
+
+- **Wait** — User provides feedback or approval, unless `--no-review` is present.
 
 ## Step (4/4) - Finalize and Present Next Steps
 
 - **Action** — ConfirmCompletion:
 
+  - **If `--no-review` is present**:
+
+    > "Draft implementation plan saved to `{plan_path}`. Returning to `plan`."
+
+    Stop here. Do not render the standalone Next Steps footer.
+
   > "🎯 Implementation Planning Complete. Documents: {plan_path}, task_context.md"
 
-- **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps footer
+- **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps footer

package/plugins/spectre-codex/skills/plan/SKILL.md

@@ -15,7 +15,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 ## Description
 
 - **What** — Research codebase, assess complexity, route to appropriate workflow (direct tasks or plan-first)
-- **Outcome** — Detailed task breakdown ready for execution
+- **Outcome** — A right-sized `plan.md` + `tasks.md`; STANDARD/COMPREHENSIVE include review and a final execution gate, while LIGHT stays non-blocking.
 
 ## ARGUMENTS Input
 
@@ -23,7 +23,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 ## MANDATORY COMPLIANCE RULES
 
-> **⚠️ NON-NEGOTIABLE**: This workflow MUST invoke nested workflows via the Skill tool. Failure to invoke `Skill(create_plan)` and `Skill(create_tasks)` (Claude slash route: `create_plan` and `create_tasks`) is a critical error. Do NOT summarize, describe, or skip these workflows. INVOKE THEM.
+> **⚠️ NON-NEGOTIABLE**: After tier routing, this workflow MUST invoke nested workflows via the Skill tool. LIGHT must invoke `Skill(create_plan)` and `Skill(create_tasks)`; STANDARD/COMPREHENSIVE must invoke `Skill(create_plan)`, `Skill(create_tasks)`, and `Skill(plan_review)` (Claude slash route: `create_plan`, `create_tasks`, and `plan_review`). Failure to invoke the required skills is a critical error. Do NOT summarize, describe, or skip these workflows. INVOKE THEM.
 
 **After ANY user conversation or questions:**
 
@@ -33,14 +33,16 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 **You MUST call these skills (not describe them):**
 
-- Use the **Skill** tool with `skill: "spectre-create_plan"` and `args: "{path} --depth {tier}"` — generates plan.md
+- Use the **Skill** tool with `skill: "spectre-create_plan"` and `args: "{path} --depth {tier}"` — generates plan.md, including LIGHT
 - Use the **Skill** tool with `skill: "spectre-create_tasks"` and `args: "{path}"` — generates tasks.md
+- Use the **Skill** tool with `skill: "spectre-plan_review"` and `args: "{OUT_DIR} --auto-apply scope-safe"` — reviews and integrates scope-safe feedback for STANDARD/COMPREHENSIVE
 
 ## Instructions
 
 - Research before routing; present architectural options for user buy-in
 - Route based on hard-stops and clarity, not point-scoring
 - Never overwrite existing `tasks.md` or `plan.md` — use scoped names
+- Treat `concepts/scope.md` (then `specs/prd.md` / `specs/ux.md` when present) as canonical. Plan generation, task generation, review, and feedback integration may change implementation approach, sequencing, verification, references, and YAGNI fences, but MUST NOT cut, narrow, expand, or reinterpret the agreed scope without an explicit user scope-change gate.
 
 ## Step 1 - Research Codebase
 
@@ -124,7 +126,7 @@ Use research findings from Step 1 to determine appropriate planning depth.
 
 ## Step 3 - High-Level Design
 
-**SKIP IF LIGHT** — proceed directly to Step 4.
+**SKIP IF LIGHT** — proceed directly to Step 4. LIGHT still generates a real plan in Step 4; it only skips this human alignment gate.
 
 Goal: align on the *shape* of the solution before generating a full plan. This catches misalignments early and gives the user a chance to redirect before reading a long plan doc.
 
@@ -171,7 +173,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - **Action** — PersistDesign: Append a "Selected Design" section to `{OUT_DIR}/task_context.md` capturing the agreed approach, key decisions, and resolved questions. This is what `create_plan` consumes.
 
-> **CHECKPOINT**: After alignment, proceed IMMEDIATELY to Step 4. The ONLY valid next action is invoking a Skill.
+> **CHECKPOINT**: After alignment, proceed IMMEDIATELY to Step 4. This is the early gate. The next valid actions are Skill invocations that generate the draft plan, generate tasks, run plan_review, integrate scope-safe feedback, and then present the final plan/tasks for the user's final gate.
 
 ## Step 4 - Route to Workflow
 
@@ -187,6 +189,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 │                                                                        │
 │  ✅ CORRECT: Skill tool with skill: "spectre-create_plan", args: "..." │
 │  ✅ CORRECT: Skill tool with skill: "spectre-create_tasks", args: "..."│
+│  ✅ CORRECT: Skill tool with skill: "spectre-plan_review", args: "..." │
 └────────────────────────────────────────────────────────────────────────┘
 ```
 
@@ -202,6 +205,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - Use the Skill tool: `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth {tier}"`
 - Use the Skill tool: `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
+- For STANDARD/COMPREHENSIVE, use the Skill tool: `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
 
 ---
 
@@ -209,27 +213,34 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - **If LIGHT**:
 
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth light --no-review"`
+  - **Wait** — Returns concise plan with solution shape, patterns, risks, and verification approach
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md --depth light"`
-  - **Wait** — Returns task breakdown with brief implementation approach
+  - **Wait** — Returns task breakdown grounded in the light plan
+  - **Action** — PresentLightArtifacts: Summarize `{OUT_DIR}/specs/plan.md` and `{OUT_DIR}/specs/tasks.md`. State that LIGHT skipped `plan_review` and the human execution gate by design.
   - Skip to footer
 
 - **ElseIf STANDARD**:
 
-  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth standard"`
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth standard --no-review"`
   - **Wait** — Returns focused plan (Overview, Approach, Out of Scope)
-  - **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
-  - **Wait** — User approval
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
   - **Wait** — Returns task breakdown
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
+  - **Wait** — Returns findings, applied edits, skipped scope-changing recommendations, and updated artifacts
+  - **Action** — IntegratePlanReviewFeedback: Read the plan_review report path returned by `plan_review`. Confirm every scope-safe Blocker/High finding is reflected in `plan.md` and/or `tasks.md`. If `plan_review` produced a scope-safe suggested edit but did not apply it because it needed minor adaptation, apply the smallest artifact edit now and record it in the final summary. Do not apply Scope Change Required findings.
+  - Continue to Final Gate
 
 - **ElseIf COMPREHENSIVE**:
 
-  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth comprehensive"`
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth comprehensive --no-review"`
   - **Wait** — Returns full plan (all sections: Architecture, Phases, API Design, Testing Strategy, etc.)
-  - **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
-  - **Wait** — User approval
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
   - **Wait** — Returns task breakdown
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
+  - **Wait** — Returns findings, applied edits, skipped scope-changing recommendations, and updated artifacts
+  - **Action** — IntegratePlanReviewFeedback: Read the plan_review report path returned by `plan_review`. Confirm every scope-safe Blocker/High finding is reflected in `plan.md` and/or `tasks.md`. If `plan_review` produced a scope-safe suggested edit but did not apply it because it needed minor adaptation, apply the smallest artifact edit now and record it in the final summary. Do not apply Scope Change Required findings.
+  - Continue to Final Gate
 
 ---
 
@@ -253,4 +264,19 @@ Only proceed past this checkpoint when the user confirms.
 
 ---
 
+### Final Gate
+
+- **Action** — PresentFinalArtifacts:
+  - Summarize final artifact paths: `{OUT_DIR}/specs/plan.md`, `{OUT_DIR}/specs/tasks.md`, and the saved plan_review report under `{OUT_DIR}/reviews/`.
+  - Summarize review integration: findings applied by `plan_review`, any additional plan-orchestrator edits applied to integrate feedback, skipped edits, and any recommendations that were blocked because they would change canonical scope.
+  - If plan_review surfaced a scope-changing recommendation, state: "This requires a scope change; I did not apply it." Ask the user whether to reopen scope or approve the current canonical-scope-preserving plan/tasks.
+  - Otherwise prompt: "Final reviewed plan/tasks are ready. Reply `Approved` to proceed to execution, or provide final feedback."
+
+- **Wait** — User final approval or feedback.
+
+- **If feedback preserves canonical scope** — apply the smallest edits to `plan.md`/`tasks.md`, re-run `plan_review {OUT_DIR} --auto-apply scope-safe` if the feedback changes implementation approach, verification, dependencies, task sequencing, or references, then present the Final Gate again.
+- **If feedback changes canonical scope** — stop and route back to `scope` (or explicitly update the canonical scope artifact if the user directs it). Do not silently update plan/tasks against stale scope.
+
+---
+
 - **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps

package/plugins/spectre-codex/skills/plan_review/SKILL.md

@@ -16,8 +16,15 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 - **What** — Independent review of any available planning artifacts (`plan.md`, `tasks.md`, and optional `task_context.md`) from four specialized lenses, dispatched in parallel
 - **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update the available artifacts
+- **Artifact** — Always save a Markdown review report before any write-back so pre-integration findings are auditable
 - **Role** — Senior staff engineer + reviewer panel; bias toward pragmatic problem-solving, YAGNI enforcement, and verifiability
 
+## Canonical Scope Invariant
+
+`concepts/scope.md` is canonical when present. If absent, use `specs/prd.md`, `specs/ux.md`, and explicit requirements in `task_context.md` as the scope source, in that order.
+
+Reviewers may recommend deleting unrequested implementation details, unnecessary abstractions, weak verification, hallucinated references, bad dependencies, or task sequencing problems. They MUST NOT cut, narrow, expand, or reinterpret agreed scope. If a reviewer believes the agreed scope itself is too large, internally inconsistent, or missing a requirement, phrase that as a **Scope Change Required** recommendation for the user. Do not apply it to `plan.md` or `tasks.md` during write-back.
+
 ## ARGUMENTS Input
 
 <ARGUMENTS>
@@ -46,12 +53,15 @@ A single reviewer biases toward the issues it notices first. Published practice
   - `PLAN=${TASK_DIR}/specs/plan.md` (or scoped name)
   - `TASKS=${TASK_DIR}/specs/tasks.md` (or scoped name)
   - `CONTEXT=${TASK_DIR}/task_context.md`
+  - `SCOPE=${TASK_DIR}/concepts/scope.md` when present; otherwise use `specs/prd.md` / `specs/ux.md` as available
+  - `REVIEWS_DIR=${TASK_DIR}/reviews`
+  - `REVIEW_REPORT=${REVIEWS_DIR}/plan_review.md`; if that exists, use `plan_review_{YYYY-MM-DD_HHMMSS}.md` to avoid overwriting prior review evidence.
   - `plan.md` and `tasks.md` are independently reviewable. It is valid to review only `plan.md`, only `tasks.md`, or both.
   - `task_context.md` is helpful context but is not required. If it is missing, continue and note that requirements traceability is limited.
   - If both `plan.md` and `tasks.md` are missing, stop and suggest the user run `plan` or `create_tasks` first.
   - If exactly one of `plan.md` or `tasks.md` is missing, list it as absent context and continue. Do not decline, stop, or ask the user to create the missing artifact.
 
-- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker.
+- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker. The manifest must label the canonical scope source and state that review findings may not remove or narrow scope.
 
 ## Step 2 — Dispatch Four Parallel Reviewers
 
@@ -64,13 +74,15 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
 > Review the available plan and/or task list for unrequested complexity. Agents have a documented "familiar-shape bias": shown a feature, they reproduce the mature-system shape from their training data (auth → adds rate-limiting; CRUD → adds soft-delete; form → adds optimistic UI; service → adds telemetry; module → adds feature flags). Your job is to find that bias here.
 >
 > Find:
-> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`task_context.md` / scope / PRD). If context is absent, use the plan's own requirements and boundaries.
+> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`scope.md` / `task_context.md` / PRD / UX). If context is absent, use the plan's own requirements and boundaries.
 > 2. When `tasks.md` is present: tasks that implement something the available requirements don't ask for. If requirements context is absent, use the task list's stated goals and boundaries.
 > 3. Abstractions, interfaces, or layers introduced for a single concrete caller.
 > 4. Generality (config files, plugin points, factories) where the actual need is one specific behavior.
 > 5. Overlap with the `Out-of-Bounds — DO NOT add` list (if anything violates that list, it's a hard fail).
 >
-> Required output: nominate the SINGLE highest-leverage thing to delete and justify it. You must pick one. Then list other simplifications ranked by impact. For each finding, cite the exact file:line or section header it lives in.
+> Scope guard: you may nominate implementation detail to delete only when it is not required by canonical scope. Do not nominate an agreed requirement, user-approved behavior, or required task as the thing to delete. If the best "cut" would change canonical scope, label it **Scope Change Required** and do not include it as an auto-applicable deletion.
+>
+> Required output: nominate the SINGLE highest-leverage implementation detail to delete and justify it. You must pick one unless every possible deletion would change canonical scope; in that case, say "No scope-safe deletion found" and provide the nearest Scope Change Required recommendation separately. Then list other simplifications ranked by impact. For each finding, cite the exact file:line or section header it lives in.
 
 ### Lens 2 — Verifiability (`@analyst`)
 
@@ -118,6 +130,7 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - **High** — meaningfully reduces output quality (missing RED test, weak canonical reference, prose criterion)
   - **Medium** — overengineering or reuse miss without functional blast radius
   - **Low** — stylistic or nice-to-have
+  - **Scope Change Required** — may be valid feedback, but would cut, expand, or reinterpret canonical scope and therefore needs explicit user approval before any artifact edit
 
 - **Action** — RenderFindingsTable: Output a single structured table. Schema is fixed.
 
@@ -143,11 +156,24 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - Low: {N}
   ```
 
+- **Action** — SaveReviewArtifact: Before applying any edits to `plan.md` or `tasks.md`, save the pre-integration review findings as a Markdown report.
+  - Create `${REVIEWS_DIR}` if missing.
+  - Write `${REVIEW_REPORT}` using the RenderFindingsTable content plus:
+    - Reviewed artifacts: exact plan/tasks/context/scope paths present and absent.
+    - Canonical scope source used.
+    - Auto-apply mode: enabled/disabled.
+    - Timestamp.
+    - Explicit note: "This report captures plan_review findings before any write-back to plan.md or tasks.md."
+  - Do not overwrite an existing report. Use the timestamped filename if the default already exists.
+  - Include the saved report path in all subsequent summaries and in `ReportApplied`.
+
 ## Step 4 — Surface Findings & Apply Edits
 
-- **Action** — PresentFindings: Render the findings table inline.
+- **Action** — PresentFindings: Render the findings table inline and include `Review report saved: {REVIEW_REPORT}`.
+
+- **Action** — DetectAutoApplyMode: If ARGUMENTS contains `--auto-apply scope-safe`, skip the user selection prompt and apply all scope-safe Blocker and High findings, plus Medium/Low findings only when the Suggested Edit is unambiguous and cannot change canonical scope. Do not apply findings marked Scope Change Required. Continue to ApplyEdits and SelfCheck, then return the applied/skipped summary to the invoking workflow.
 
-- **Action** — OfferWriteBack: After the table, prompt:
+- **Action** — OfferWriteBack: Unless `--auto-apply scope-safe` is present, after the table prompt:
 
   > Reply with which findings to apply:
   > - `all` — apply every suggested edit
@@ -163,17 +189,21 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - Open the named artifact (`plan.md` or `tasks.md`)
   - Apply the Suggested Edit verbatim where possible; if the edit needs adaptation, make the minimum change consistent with the finding's intent
   - Track which findings were applied
+  - Before writing, confirm the edit preserves every requirement and boundary in the canonical scope source. If it would remove, narrow, expand, or reinterpret scope, skip it and record it as "skipped: requires scope change."
 
 - **Action** — SelfCheck: After edits, run a fast pass over the modified sections:
   - Re-verify any file:line refs touched
   - Re-verify acceptance criteria are still executable
   - Confirm no edit introduced a new Out-of-Bounds violation
+  - Confirm canonical scope is still fully represented by the resulting plan/tasks
   - If any check fails, surface it and ask the user before continuing
 
 - **Action** — ReportApplied:
 
   > Applied: {list of finding numbers}. Skipped: {list}.
+  > Review report: {REVIEW_REPORT}.
   > {Path to updated artifact(s)}.
+  > Scope-change recommendations not applied: {list or "none"}.
 
 ## Step 5 — Next Steps