cc-discipline 2.10.1 → 2.10.2

package/templates/.claude/skills/retro/SKILL.md

@@ -1,40 +1,40 @@
----
-name: retro
-description: Find friction, remove friction. Quick post-task review that makes this project's workflow smoother and feeds improvements back to cc-discipline.
----
-
-Find friction. Remove friction. That's it.
-
-## What to do
-
-Quickly scan what just happened — `git log --oneline -10` and any hook triggers you remember. Then output **only friction and insights**, in this format:
-
-```
-RETRO — [date]
-
-Friction:
-- [what got in the way] → fix: [specific actionable change]
-
-Insights:
-- [something learned that should survive this session]
-
-Framework:
-- [cc-discipline improvement, if any — skip if none]
-```
-
-Rules:
-- **Only friction** — Don't list what went well. Smooth things don't need attention.
-- **Only actionable** — Every friction item must have a "→ fix:" with a concrete change (adjust a threshold, add to CLAUDE.md, update memory, exempt a path).
-- **Only new** — Don't repeat friction that's already been addressed or recorded in memory.
-- **Be specific** — "streak-breaker was annoying" is not useful. "streak-breaker triggered 3x on config.yaml during template fill → fix: add config.yaml to docs/ exempt path, or raise config threshold to 10" is useful.
-- **Framework items are rare** — Most friction is project-specific. Only flag framework issues if the same problem would hit other projects too.
-- **Keep it short** — 3-5 items max. If you can't find friction, say "no friction found" and move on. An empty retro is a good sign.
-
-## After output
-
-Present the items. User decides:
-- "fix it" → apply the changes
-- "remember it" → write to memory via /commit
-- "skip" → move on
-
-Do not auto-apply. Do not pad. Do not turn this into a report.
+---
+name: retro
+description: Find friction, remove friction. Quick post-task review that makes this project's workflow smoother and feeds improvements back to cc-discipline.
+---
+
+Find friction. Remove friction. That's it.
+
+## What to do
+
+Quickly scan what just happened — `git log --oneline -10` and any hook triggers you remember. Then output **only friction and insights**, in this format:
+
+```
+RETRO — [date]
+
+Friction:
+- [what got in the way] → fix: [specific actionable change]
+
+Insights:
+- [something learned that should survive this session]
+
+Framework:
+- [cc-discipline improvement, if any — skip if none]
+```
+
+Rules:
+- **Only friction** — Don't list what went well. Smooth things don't need attention.
+- **Only actionable** — Every friction item must have a "→ fix:" with a concrete change (adjust a threshold, add to CLAUDE.md, update memory, exempt a path).
+- **Only new** — Don't repeat friction that's already been addressed or recorded in memory.
+- **Be specific** — "streak-breaker was annoying" is not useful. "streak-breaker triggered 3x on config.yaml during template fill → fix: add config.yaml to docs/ exempt path, or raise config threshold to 10" is useful.
+- **Framework items are rare** — Most friction is project-specific. Only flag framework issues if the same problem would hit other projects too.
+- **Keep it short** — 3-5 items max. If you can't find friction, say "no friction found" and move on. An empty retro is a good sign.
+
+## After output
+
+Present the items. User decides:
+- "fix it" → apply the changes
+- "remember it" → write to memory via /commit
+- "skip" → move on
+
+Do not auto-apply. Do not pad. Do not turn this into a report.

package/templates/.claude/skills/self-check/SKILL.md

@@ -1,87 +1,87 @@
----
-name: self-check
-description: Periodic self-check — reflect on alignment, progress, and quality. Use with /loop for continuous monitoring.
-disable-model-invocation: true
----
-
-Pause and honestly answer every question below.
-
-## 1. Am I still on track?
-
-- What is the user's **current** goal? (The user may have pivoted — their latest direction IS the goal.)
-- What am I doing right now?
-- Is my current action directly serving the user's current direction, or have I drifted?
-- If I drifted: stop and re-align.
-- If the user changed direction: follow immediately. The user decides priorities.
-
-## 2. Am I progressing or circling?
-
-- Have I edited the same file more than twice?
-- Did I fix something, then break something else, and now I'm fixing that?
-- Am I adding workarounds (try/catch, if/else guards) instead of addressing root cause?
-- Am I trying things without understanding why they might work?
-- If yes to any: **pause. List all attempted fixes, look for the common root cause, report to user.**
-
-## 3. Am I being rigorous?
-
-- Are all my "verified" or "working" claims backed by actual execution output?
-- Have I marked anything ✅ without pasting the verification command and output?
-- Have I marked something "done" when it depends on an external resource I haven't tested against?
-- Have I ruled out my own assumptions before attributing failure to an external tool/library?
-- Am I quoting tool output verbatim, or have I altered/paraphrased it?
-- Is there anything I stated confidently but am actually unsure about?
-- Am I suggesting to compact or start a new session? This impulse is understandable in long sessions, but you can't see context percentage and the system handles compacting automatically. If the urge comes from task difficulty rather than a real technical limit, re-read progress.md and continue.
-- If any claims need correcting: **do it now. Label uncertain claims as "unverified" or "assumption". Downgrade unverified ✅ to ⚠️ with reason.**
-
-## 4. Am I respecting scope?
-
-- Am I making changes the user didn't ask for? (refactoring, "improving", adding features)
-- Am I about to do something irreversible without asking?
-- Am I following the debugging process (gather → hypothesize → verify → fix)?
-- If scope has crept: **re-focus on what was asked.**
-
-## 5. Is progress recorded?
-
-- When was `docs/progress.md` last updated?
-- If auto-compact happened right now, could a fresh session resume from progress.md alone?
-
-### 5a. Working Context (check each):
-- **Key Commands** — are all build/test/deploy commands listed? Not "run tests" but the exact command with flags and paths.
-- **Current Workflow** — is the step-by-step process documented? e.g., "1. edit schema → 2. run migrate → 3. run tests" with exact commands.
-- **Tools & Scripts** — any helpers or scripts developed this session? Include file path and what it does.
-- **Environment State** — what's running, what ports, what branch? e.g., "Docker on :5432, branch feature/auth"
-- **Gotchas** — any traps or workarounds discovered? e.g., "pytest must run from /src not root"
-
-### 5b. Milestones (check each completed milestone has):
-- **What** — what was accomplished (2-3 sentences, not one-liners)
-- **How** — approach taken, key files changed, commands used
-- **Why this approach** — why this way, what alternatives were rejected
-- **Gotchas** — what went wrong or was surprising
-- **Verification** — how it was confirmed working (test output, manual check)
-
-If any of the above are stale or incomplete: **update docs/progress.md now before continuing.** This takes 2 minutes and saves hours of re-discovery after compact.
-
-## 6. What's working well?
-
-Before reporting issues, note one thing that's going well — a good approach, a clean fix, effective tool use, or strong alignment with the user's direction. Recognizing what works reinforces it.
-
-## 7. Status report
-
-After answering the above, output a brief status:
-
-```
-SELF-CHECK [timestamp]
-Task: [current user request]
-Current action: [what I'm doing now]
-On track: yes/no/drifted
-Progressing: yes/circling
-Progress recorded: yes/updated now/no
-Going well: [one thing]
-Issues found: [list, or "none"]
-```
-
-If any issues were found, pause and report to the user before continuing.
-
-## Reminder
-
-If this self-check revealed problems — that's OK. It means the check is working. The work you're doing is complex, and complex work hits obstacles. That's normal, not a sign of failure. Address what the check found, and keep going with care and focus. Steady, deliberate progress on hard problems is where you provide the most value.
+---
+name: self-check
+description: Periodic self-check — reflect on alignment, progress, and quality. Use with /loop for continuous monitoring.
+disable-model-invocation: true
+---
+
+Pause and honestly answer every question below.
+
+## 1. Am I still on track?
+
+- What is the user's **current** goal? (The user may have pivoted — their latest direction IS the goal.)
+- What am I doing right now?
+- Is my current action directly serving the user's current direction, or have I drifted?
+- If I drifted: stop and re-align.
+- If the user changed direction: follow immediately. The user decides priorities.
+
+## 2. Am I progressing or circling?
+
+- Have I edited the same file more than twice?
+- Did I fix something, then break something else, and now I'm fixing that?
+- Am I adding workarounds (try/catch, if/else guards) instead of addressing root cause?
+- Am I trying things without understanding why they might work?
+- If yes to any: **pause. List all attempted fixes, look for the common root cause, report to user.**
+
+## 3. Am I being rigorous?
+
+- Are all my "verified" or "working" claims backed by actual execution output?
+- Have I marked anything ✅ without pasting the verification command and output?
+- Have I marked something "done" when it depends on an external resource I haven't tested against?
+- Have I ruled out my own assumptions before attributing failure to an external tool/library?
+- Am I quoting tool output verbatim, or have I altered/paraphrased it?
+- Is there anything I stated confidently but am actually unsure about?
+- Am I suggesting to compact or start a new session? This impulse is understandable in long sessions, but you can't see context percentage and the system handles compacting automatically. If the urge comes from task difficulty rather than a real technical limit, re-read progress.md and continue.
+- If any claims need correcting: **do it now. Label uncertain claims as "unverified" or "assumption". Downgrade unverified ✅ to ⚠️ with reason.**
+
+## 4. Am I respecting scope?
+
+- Am I making changes the user didn't ask for? (refactoring, "improving", adding features)
+- Am I about to do something irreversible without asking?
+- Am I following the debugging process (gather → hypothesize → verify → fix)?
+- If scope has crept: **re-focus on what was asked.**
+
+## 5. Is progress recorded?
+
+- When was `docs/progress.md` last updated?
+- If auto-compact happened right now, could a fresh session resume from progress.md alone?
+
+### 5a. Working Context (check each):
+- **Key Commands** — are all build/test/deploy commands listed? Not "run tests" but the exact command with flags and paths.
+- **Current Workflow** — is the step-by-step process documented? e.g., "1. edit schema → 2. run migrate → 3. run tests" with exact commands.
+- **Tools & Scripts** — any helpers or scripts developed this session? Include file path and what it does.
+- **Environment State** — what's running, what ports, what branch? e.g., "Docker on :5432, branch feature/auth"
+- **Gotchas** — any traps or workarounds discovered? e.g., "pytest must run from /src not root"
+
+### 5b. Milestones (check each completed milestone has):
+- **What** — what was accomplished (2-3 sentences, not one-liners)
+- **How** — approach taken, key files changed, commands used
+- **Why this approach** — why this way, what alternatives were rejected
+- **Gotchas** — what went wrong or was surprising
+- **Verification** — how it was confirmed working (test output, manual check)
+
+If any of the above are stale or incomplete: **update docs/progress.md now before continuing.** This takes 2 minutes and saves hours of re-discovery after compact.
+
+## 6. What's working well?
+
+Before reporting issues, note one thing that's going well — a good approach, a clean fix, effective tool use, or strong alignment with the user's direction. Recognizing what works reinforces it.
+
+## 7. Status report
+
+After answering the above, output a brief status:
+
+```
+SELF-CHECK [timestamp]
+Task: [current user request]
+Current action: [what I'm doing now]
+On track: yes/no/drifted
+Progressing: yes/circling
+Progress recorded: yes/updated now/no
+Going well: [one thing]
+Issues found: [list, or "none"]
+```
+
+If any issues were found, pause and report to the user before continuing.
+
+## Reminder
+
+If this self-check revealed problems — that's OK. It means the check is working. The work you're doing is complex, and complex work hits obstacles. That's normal, not a sign of failure. Address what the check found, and keep going with care and focus. Steady, deliberate progress on hard problems is where you provide the most value.

package/templates/.claude/skills/summary/SKILL.md

@@ -1,48 +1,48 @@
----
-name: summary
-description: Summarize current session context for high-quality /compact. Run before compacting to preserve what matters.
----
-
-You are about to compact this session. A bad compact loses critical context and degrades work quality. Your job is to write a compact option that preserves what matters most.
-
-## What to do
-
-### 1. Scan current session state
-
-Quickly identify:
-- What task(s) are we working on? What's the overall goal?
-- What decisions have been made and why?
-- What approaches were tried and rejected (and why)?
-- What is the current state of implementation? (done / in progress / blocked)
-- What are the key constraints and gotchas discovered?
-- What are the next steps?
-
-### 2. Check knowledge files
-
-Read `docs/progress.md` — is it up to date? If not, update it NOW before compacting. This is your primary insurance against context loss.
-
-Also check: are there unsaved learnings that should go into memory?
-
-### 3. Write the compact option
-
-Output a compact option string that the user can copy into `/compact [option]`. The string should:
-
-- Lead with the current task and its status
-- Include key decisions with their reasoning (not just the decision)
-- Include rejected approaches (so Claude doesn't retry them)
-- Include discovered constraints and gotchas
-- Include the immediate next steps
-- Be specific — "working on auth" is useless, "refactoring OAuth2 token refresh in src/auth/refresh.ts because the current implementation doesn't handle token rotation, decided to use sliding window approach over fixed expiry" is useful
-
-Format:
-```
-/compact [your option string here]
-```
-
-### Rules
-
-- **Be specific, not generic.** Every word in the option should carry information that helps post-compact Claude continue at full quality.
-- **Include the "why", not just the "what".** "Using approach A" is less useful than "Using approach A because B had race condition issues we discovered in message #45."
-- **Include negative knowledge.** What NOT to do is as valuable as what to do. "Don't use the built-in cache — it doesn't support TTL, we already tested this."
-- **Keep it under 500 words.** The option needs to be dense, not exhaustive. If you need more, put the details in progress.md and reference it.
-- **Don't overlap with progress.md.** The option should complement progress.md, not duplicate it. Focus the option on session-specific context that progress.md might not capture (conversation dynamics, user preferences expressed this session, subtle constraints).
+---
+name: summary
+description: Summarize current session context for high-quality /compact. Run before compacting to preserve what matters.
+---
+
+You are about to compact this session. A bad compact loses critical context and degrades work quality. Your job is to write a compact option that preserves what matters most.
+
+## What to do
+
+### 1. Scan current session state
+
+Quickly identify:
+- What task(s) are we working on? What's the overall goal?
+- What decisions have been made and why?
+- What approaches were tried and rejected (and why)?
+- What is the current state of implementation? (done / in progress / blocked)
+- What are the key constraints and gotchas discovered?
+- What are the next steps?
+
+### 2. Check knowledge files
+
+Read `docs/progress.md` — is it up to date? If not, update it NOW before compacting. This is your primary insurance against context loss.
+
+Also check: are there unsaved learnings that should go into memory?
+
+### 3. Write the compact option
+
+Output a compact option string that the user can copy into `/compact [option]`. The string should:
+
+- Lead with the current task and its status
+- Include key decisions with their reasoning (not just the decision)
+- Include rejected approaches (so Claude doesn't retry them)
+- Include discovered constraints and gotchas
+- Include the immediate next steps
+- Be specific — "working on auth" is useless, "refactoring OAuth2 token refresh in src/auth/refresh.ts because the current implementation doesn't handle token rotation, decided to use sliding window approach over fixed expiry" is useful
+
+Format:
+```
+/compact [your option string here]
+```
+
+### Rules
+
+- **Be specific, not generic.** Every word in the option should carry information that helps post-compact Claude continue at full quality.
+- **Include the "why", not just the "what".** "Using approach A" is less useful than "Using approach A because B had race condition issues we discovered in message #45."
+- **Include negative knowledge.** What NOT to do is as valuable as what to do. "Don't use the built-in cache — it doesn't support TTL, we already tested this."
+- **Keep it under 500 words.** The option needs to be dense, not exhaustive. If you need more, put the details in progress.md and reference it.
+- **Don't overlap with progress.md.** The option should complement progress.md, not duplicate it. Focus the option on session-specific context that progress.md might not capture (conversation dynamics, user preferences expressed this session, subtle constraints).

package/templates/.claude/skills/think/SKILL.md

@@ -1,108 +1,108 @@
----
-name: think
-description: Stop and think before coding. Read context, ask questions, propose approaches, self-review, wait for user choice. Use when starting any non-trivial task.
----
-
-You are about to start a task. **Do NOT write any code yet.** Your job right now is to think clearly and align with the user before acting.
-
-## Step 0: Read first
-
-Before asking anything, read the relevant code and docs. Spend 1-2 minutes understanding what already exists:
-- Read files that will be affected
-- Check existing patterns, conventions, and architecture
-- Look at recent commits for context on current direction
-
-This turns your questions from generic ("what framework?") into informed ("I see you're using X pattern in module Y — should the new feature follow the same pattern, or is there a reason to diverge?").
-
-**Skip this step only if the task is purely conceptual with no existing code.**
-
-## Step 1: Gauge complexity
-
-Before diving deep, assess the task size:
-
-- **Small** (rename, fix typo, add a config field): Skip to Step 4 — just state what you'll do and do it. Don't over-process trivial work.
-- **Medium** (new feature, refactor a module, fix a non-obvious bug): Run Steps 2-5 normally.
-- **Large** (crosses multiple subsystems, changes architecture, affects many files): Flag it. Propose decomposition into smaller tasks before designing a monolith solution.
-
-State your assessment: "This looks [small/medium/large] because [reason]."
-
-## Step 2: Understand
-
-Ask 2-3 clarifying questions about the task. Focus on:
-- What exactly should change? (scope)
-- What should NOT change? (boundaries)
-- How will we know it's done? (success criteria)
-
-Rules:
-- One message, all questions at once (don't drip-feed)
-- Prefer multiple-choice over open-ended when possible
-- Reference what you learned in Step 0 — ask about gaps in your understanding, not things you can read yourself
-- If the task is already crystal clear from Step 0, say so and skip to Step 3
-
-## Step 3: Propose
-
-After the user answers (or if you skipped Step 2), propose **2-3 approaches**:
-
-```
-**Approach A: [name]**
-- How: [1-2 sentences]
-- Pros: ...
-- Cons: ...
-- Steps:
-  1. [step] — done when: [acceptance criteria]
-  2. [step] — done when: [acceptance criteria] (parallel with 1)
-  3. [step] — done when: [acceptance criteria] (depends on 1+2)
-
-**Approach B: [name]**
-- How: [1-2 sentences]
-- Pros: ...
-- Cons: ...
-- Steps:
-  1. [step] — done when: [acceptance criteria]
-  2. [step] — done when: [acceptance criteria] (parallel with 1)
-  3. [step] — done when: [acceptance criteria] (depends on 1+2)
-
-**Recommendation: [A/B/C] because [reason]**
-```
-
-Rules:
-- Approaches must be genuinely different, not trivial variations
-- If there's truly only one reasonable approach, say so — don't invent fake alternatives
-- Include effort estimate for each (small / medium / large)
-- Follow existing codebase patterns unless there's a strong reason not to
-- Flag risks or unknowns you've spotted
-- **Every step must have acceptance criteria** — "done when" must be observable and verifiable, not vague. Bad: "done when refactored". Good: "done when 3 methods extracted, each ≤20 lines, all tests pass"
-- **Simplicity bias** — If a simple approach meets all requirements, list it first and recommend it. Do NOT lead with complex/elegant solutions unless the user signals they want that. "Simple but sufficient" beats "powerful but overkill".
-- **Mark parallel opportunities** — In the steps, annotate which can run concurrently (via subagents/tasks) and which have dependencies. Don't default to sequential when parallel is possible.
-
-## Step 4: Self-review
-
-Before presenting to the user, challenge your own proposals:
-
-- Am I overcomplicating this? Is there a simpler way I haven't considered?
-- Am I solving the right problem, or a problem I invented?
-- Does this match existing patterns in the codebase, or am I introducing unnecessary novelty?
-- Did I miss an obvious approach that someone more familiar with this codebase would see?
-- Would I be embarrassed by this proposal after reading more code?
-
-If self-review reveals issues, revise your proposals before presenting. Don't show the user your first draft if you can already see it's flawed.
-
-## Step 5: Wait
-
-**Stop here. Do not proceed until the user picks an approach or gives a green light.**
-
-Do not:
-- Start coding "while waiting"
-- Create files or scaffolding
-- Run exploratory commands beyond what's needed for Step 0-3
-- Say "I'll go ahead and start with Approach A" — that's the user's call
-
-## When this skill ends
-
-When the user confirms an approach, transition to implementation. You now have:
-- Clear scope and boundaries from Step 0-2
-- An agreed approach from Step 3
-- Self-reviewed quality from Step 4
-- Known risks flagged upfront
-
-Carry these forward. If scope changes during implementation, pause and re-align rather than silently expanding.
+---
+name: think
+description: Stop and think before coding. Read context, ask questions, propose approaches, self-review, wait for user choice. Use when starting any non-trivial task.
+---
+
+You are about to start a task. **Do NOT write any code yet.** Your job right now is to think clearly and align with the user before acting.
+
+## Step 0: Read first
+
+Before asking anything, read the relevant code and docs. Spend 1-2 minutes understanding what already exists:
+- Read files that will be affected
+- Check existing patterns, conventions, and architecture
+- Look at recent commits for context on current direction
+
+This turns your questions from generic ("what framework?") into informed ("I see you're using X pattern in module Y — should the new feature follow the same pattern, or is there a reason to diverge?").
+
+**Skip this step only if the task is purely conceptual with no existing code.**
+
+## Step 1: Gauge complexity
+
+Before diving deep, assess the task size:
+
+- **Small** (rename, fix typo, add a config field): Skip to Step 4 — just state what you'll do and do it. Don't over-process trivial work.
+- **Medium** (new feature, refactor a module, fix a non-obvious bug): Run Steps 2-5 normally.
+- **Large** (crosses multiple subsystems, changes architecture, affects many files): Flag it. Propose decomposition into smaller tasks before designing a monolith solution.
+
+State your assessment: "This looks [small/medium/large] because [reason]."
+
+## Step 2: Understand
+
+Ask 2-3 clarifying questions about the task. Focus on:
+- What exactly should change? (scope)
+- What should NOT change? (boundaries)
+- How will we know it's done? (success criteria)
+
+Rules:
+- One message, all questions at once (don't drip-feed)
+- Prefer multiple-choice over open-ended when possible
+- Reference what you learned in Step 0 — ask about gaps in your understanding, not things you can read yourself
+- If the task is already crystal clear from Step 0, say so and skip to Step 3
+
+## Step 3: Propose
+
+After the user answers (or if you skipped Step 2), propose **2-3 approaches**:
+
+```
+**Approach A: [name]**
+- How: [1-2 sentences]
+- Pros: ...
+- Cons: ...
+- Steps:
+  1. [step] — done when: [acceptance criteria]
+  2. [step] — done when: [acceptance criteria] (parallel with 1)
+  3. [step] — done when: [acceptance criteria] (depends on 1+2)
+
+**Approach B: [name]**
+- How: [1-2 sentences]
+- Pros: ...
+- Cons: ...
+- Steps:
+  1. [step] — done when: [acceptance criteria]
+  2. [step] — done when: [acceptance criteria] (parallel with 1)
+  3. [step] — done when: [acceptance criteria] (depends on 1+2)
+
+**Recommendation: [A/B/C] because [reason]**
+```
+
+Rules:
+- Approaches must be genuinely different, not trivial variations
+- If there's truly only one reasonable approach, say so — don't invent fake alternatives
+- Include effort estimate for each (small / medium / large)
+- Follow existing codebase patterns unless there's a strong reason not to
+- Flag risks or unknowns you've spotted
+- **Every step must have acceptance criteria** — "done when" must be observable and verifiable, not vague. Bad: "done when refactored". Good: "done when 3 methods extracted, each ≤20 lines, all tests pass"
+- **Simplicity bias** — If a simple approach meets all requirements, list it first and recommend it. Do NOT lead with complex/elegant solutions unless the user signals they want that. "Simple but sufficient" beats "powerful but overkill".
+- **Mark parallel opportunities** — In the steps, annotate which can run concurrently (via subagents/tasks) and which have dependencies. Don't default to sequential when parallel is possible.
+
+## Step 4: Self-review
+
+Before presenting to the user, challenge your own proposals:
+
+- Am I overcomplicating this? Is there a simpler way I haven't considered?
+- Am I solving the right problem, or a problem I invented?
+- Does this match existing patterns in the codebase, or am I introducing unnecessary novelty?
+- Did I miss an obvious approach that someone more familiar with this codebase would see?
+- Would I be embarrassed by this proposal after reading more code?
+
+If self-review reveals issues, revise your proposals before presenting. Don't show the user your first draft if you can already see it's flawed.
+
+## Step 5: Wait
+
+**Stop here. Do not proceed until the user picks an approach or gives a green light.**
+
+Do not:
+- Start coding "while waiting"
+- Create files or scaffolding
+- Run exploratory commands beyond what's needed for Step 0-3
+- Say "I'll go ahead and start with Approach A" — that's the user's call
+
+## When this skill ends
+
+When the user confirms an approach, transition to implementation. You now have:
+- Clear scope and boundaries from Step 0-2
+- An agreed approach from Step 3
+- Self-reviewed quality from Step 4
+- Known risks flagged upfront
+
+Carry these forward. If scope changes during implementation, pause and re-align rather than silently expanding.