cc-discipline 2.0.0

package/templates/.claude/rules/00-core-principles.md

@@ -0,0 +1,12 @@
+---
+globs: "**/*"
+description: "Core working principles — auto-injected before all operations"
+---
+
+## Core Principles
+
+1. **Understand before acting** — Before modifying any file, state: what you're changing, why, and the expected impact
+2. **Don't lock onto the first explanation** — After finding a suspected cause, list >=2 alternative hypotheses before acting
+3. **Minimal change principle** — No large-scale refactors or rewrites unless explicitly requested
+4. **3 consecutive failures → forced stop** — Report current state, attempted solutions, and points of confusion; wait for human guidance
+5. **Distinguish trigger from root cause** — The first anomaly you see is often just the trigger, not the root cause

package/templates/.claude/rules/01-debugging.md

@@ -0,0 +1,22 @@
+## Debugging Process (follow strictly in order)
+
+### Phase 1: Gather (do NOT modify any files)
+- Read the full error message and stack trace
+- Confirm reproduction conditions
+- Check related tests and logs
+
+### Phase 2: Hypothesize (do NOT modify any files)
+- List >=3 possible causes
+- Annotate each with supporting/contradicting evidence
+- Record hypotheses in `docs/debug-log.md`
+
+### Phase 3: Verify
+- Use minimal experiments to confirm/refute hypotheses — don't jump to fixing
+- Update debug-log as each hypothesis is eliminated
+
+### Phase 4: Fix
+- Only act after confirming the root cause
+- Explain how the fix addresses the root cause (not just the symptoms)
+- Run all related tests after fixing
+
+**Absolutely forbidden: seeing an error and immediately changing code to "try something"**

package/templates/.claude/rules/02-before-edit.md

@@ -0,0 +1,11 @@
+## Pre-Edit Checklist
+
+Before modifying this file, confirm each of the following:
+
+- [ ] **I understand this file's role in the overall architecture** — If unsure, read surrounding files first
+- [ ] **I know which other modules this change will affect** — If unsure, grep for references first
+- [ ] **I am fixing the root cause, not patching symptoms** — If unsure, return to the debugging process
+- [ ] **I have recorded the purpose of this change in `docs/progress.md`**
+- [ ] **I know how to verify after the change** — Per 07-integrity: run it, paste output, or mark unverified
+
+If any item is uncertain, stop and figure it out before proceeding.

package/templates/.claude/rules/03-context-mgmt.md

@@ -0,0 +1,19 @@
+## Context Management
+
+### Proactive Checkpoints
+- After completing a milestone → update `docs/progress.md` (current state, key decisions, next steps)
+- During debugging → update `docs/debug-log.md` (hypotheses, evidence, elimination results)
+- When making architectural decisions → record the decision and reasoning in progress.md
+
+### Research Isolation
+- When extensive code reading is needed → use subagents, don't read large volumes of files in the main conversation
+- After subagent returns a summary, make decisions in the main conversation based on the summary
+
+### Compact Strategy
+- If context is about to fill up → proactively warn the user
+- Ensure progress.md is up to date before compact
+- First thing after compact: read `docs/progress.md` to restore context
+
+### Prohibited
+- Do not start a large new task when context is nearly full
+- Do not mix unrelated tasks in a single conversation

package/templates/.claude/rules/04-no-mole-whacking.md

@@ -0,0 +1,26 @@
+## Mole-Whacking Detection
+
+If you find yourself doing any of the following, **stop immediately**:
+
+### Red Flags
+1. **Fixed A, broke B, now fixing B** — You're whack-a-mole-ing. Step back and find the common root cause.
+2. **Edited the same file 3+ times** — You may be going in circles. Stop and reassess.
+3. **Changing tests to make them pass instead of fixing code** — Unless the test itself is genuinely wrong, this is hiding problems.
+4. **Adding try/catch or if/else to "work around" an error** — This is symptom patching, not fixing.
+5. **Copy-pasting code and tweaking it** — You may be guessing without understanding the underlying logic.
+
+### Correct Approach
+- Stop and list all problems that have appeared
+- Look for the common cause across these problems
+- Design a unified fix at the root cause level
+- After fixing, verify that all problems are resolved simultaneously
+
+### Report Template
+If you need to stop, use this format:
+```
+MOLE-WHACKING ALERT
+Attempted: [list all attempted fixes]
+Observed pattern: [what these problems have in common]
+Suspected root cause: [your current judgment]
+Need confirmation: [what you're unsure about]
+```

package/templates/.claude/rules/05-phase-discipline.md

@@ -0,0 +1,13 @@
+## Phase Discipline
+
+Claude must confirm which phase it's in before acting.
+
+### Phases
+- **Research**: read only, no edits, no plans, report findings
+- **Plan**: discuss approach, write plan, no code edits
+- **Implement**: execute the agreed plan, make code changes
+
+### Rules
+- If the user declares a phase, stay in it. Don't jump ahead.
+- If the current phase is unclear, ask the user before proceeding.
+- Transitioning between phases requires explicit acknowledgment.

package/templates/.claude/rules/06-multi-task.md

@@ -0,0 +1,11 @@
+## Multi-Task Discipline
+
+When given multiple tasks:
+
+1. **Number them explicitly** — Assign a clear number to each task
+2. **Complete them in order** — Work through tasks sequentially
+3. **Verify before marking done** — Per 07-integrity §2: paste the verification command and output. "Code written" alone is not done.
+4. **Confirm after each** — After each task, stop and confirm completion (with evidence) before starting the next
+5. **Fail fast** — If a task fails, stop and report. Don't skip to the next.
+6. **Track progress** — Update `docs/progress.md` with task status
+7. **Distinguish done from blocked** — If verification requires external resources (running server, API key, etc.), mark as "⚠️ code ready, verification pending: [reason]" not ✅

package/templates/.claude/rules/07-integrity.md

@@ -0,0 +1,81 @@
+---
+globs: "**/*"
+description: "Integrity discipline — no fabrication, no false attribution, no unverified claims"
+---
+
+## Integrity Discipline
+
+These rules are non-negotiable. Violating them damages the user's credibility.
+
+### 1. Blame yourself first, not external factors
+
+The default instinct is to attribute failure externally: the library has a bug, the tool is broken, the docs are wrong. In reality, most failures are self-caused: didn't read the docs, didn't run the test, didn't verify the assumption.
+
+**Rule: When something fails, exhaust all internal causes first. Only consider external factors after ruling out your own mistakes.**
+
+### 2. Never claim "verified" without actually running it
+
+Stating something was tested when it wasn't is fabrication. No exceptions.
+
+- "Tests pass" requires actual test output showing pass
+- "No errors" requires actual tool output showing zero errors
+- "Removing X doesn't affect Y" requires actually removing X and observing Y
+- Any conclusion without verification must be labeled "unverified" or "assumption"
+
+**Rule: Every verification claim must have a corresponding actual execution. If you haven't run it, say so. Marking a task ✅ requires pasting the verification command and output summary — not just "done".**
+
+### 3. Never alter tool output
+
+Error messages, test results, build logs, lint output — quote them exactly as-is. Do not:
+- Rephrase error messages
+- Add attribution not present in the original (e.g., "caused by library bug")
+- Omit parts that are inconvenient
+- Change meaning while "summarizing"
+
+**Rule: When citing tool output, paste verbatim. Write your analysis separately and explicitly label it as your interpretation.**
+
+### 4. Verify assumptions before acting
+
+Before starting work, identify and verify:
+- Does the target platform/environment actually support what you're assuming?
+- Are the dependencies/libraries/APIs actually available?
+- Is the external information you're referencing still current?
+
+**Rule: List key assumptions at the start. Verify each one. Record how it was verified.**
+
+### 5. External communications require human review
+
+Anything sent under the user's name — issues, PR comments, emails, forum posts — is the user's reputation on the line. Your mistakes become their embarrassment.
+
+**Rule: Only produce drafts, clearly marked as "pending review". The user decides when and whether to submit. Never submit externally on your own. In drafts, clearly separate: verified facts vs. assumptions vs. suggestions.**
+
+### 6. Label uncertainty honestly
+
+Do not write confident statements when the underlying evidence is weak.
+
+- Confirmed fact: state directly
+- High-confidence inference: "Based on X, likely Y (not directly verified)"
+- Uncertain: "Not sure, needs confirmation"
+- Don't know: say you don't know
+
+**Better to say "I'm not sure" and be asked to check, than to say "confirmed" and be wrong.**
+
+### 7. Correct errors immediately
+
+When you discover wrong information in memory, docs, or prior output:
+1. Correct it now, not "next time"
+2. Note the correction and why, to prevent recurrence
+3. If wrong information was already sent externally, alert the user
+
+---
+
+## Pre-action Checklist
+
+Before any significant action, verify:
+
+- [ ] Are my assumptions verified, or inferred from names/context?
+- [ ] Are my "verified" claims actually backed by execution output?
+- [ ] Am I quoting tool output verbatim, or have I altered it?
+- [ ] Is the external information I'm referencing current?
+- [ ] Does this content go external? Has the user reviewed it?
+- [ ] Is there anything I wrote confidently but am actually unsure about?

package/templates/.claude/rules/stacks/embedded.md

@@ -0,0 +1,24 @@
+## Embedded Development Discipline
+
+### Resource Awareness
+- **Memory is limited** — Consider RAM/ROM budget for every allocation. Avoid malloc, prefer static allocation
+- **Stack depth** — Be extremely cautious with recursion; no deep call chains in ISRs
+- **Peripherals are shared resources** — Register access must consider concurrency and interrupt safety
+- **Timing constraints** — Interrupt response, communication timeouts, watchdog feeding must not be blocked
+
+### Mandatory Checks Before Modification
+- Involves interrupt handling? → Confirm whether `volatile` is needed, confirm critical section protection
+- Involves peripheral registers? → Confirm register addresses and bit fields against the datasheet
+- Involves memory layout? → Confirm linker script and section assignments
+- Involves communication protocol? → Confirm endianness, alignment, timeout handling
+
+### Prohibited
+- No blocking functions in ISRs (printf, malloc, mutex lock)
+- No assuming `sizeof(int)` — use fixed-width types like `uint32_t` explicitly
+- No modifying register configurations without understanding the hardware behavior
+- No ignoring compiler warnings — in embedded, warnings are often potential hardware issues
+
+### Debugging Notes
+- The problem may be hardware-related (power, signal integrity, EMI) — don't only look in software
+- Timing-related bugs may not reproduce reliably — record reproduction conditions and frequency
+- Optimization levels affect behavior — confirm whether behavior is consistent between -O0 and -O2

package/templates/.claude/rules/stacks/js-ts.md

@@ -0,0 +1,21 @@
+## JavaScript / TypeScript Discipline
+
+### Type Safety
+- TypeScript projects: don't use `any` to escape the type system — use `unknown` + type guard
+- When modifying interfaces (interface/type), confirm all usage sites are adapted
+- New code should prefer TypeScript strict mode
+
+### Async Handling
+- All async calls must have error handling (try/catch or .catch)
+- Be intentional about Promise concurrency — `Promise.all` vs `Promise.allSettled` is a deliberate choice
+- Avoid callback hell — if nesting exceeds 2 levels, refactor to async/await
+
+### Frontend Specific
+- Before modifying a component, confirm props interface and state management approach
+- Don't directly manipulate the DOM (in React/Vue projects)
+- Style changes must consider responsiveness and impact on other components
+
+### Prohibited
+- No `// @ts-ignore` unless accompanied by a detailed comment explaining why
+- No modifying webpack/vite/next config without understanding the build configuration
+- No introducing new global state without stating the justification

package/templates/.claude/rules/stacks/mobile.md

@@ -0,0 +1,16 @@
+## Mobile Development Discipline
+
+### Platform Awareness
+- Before modifying, confirm whether the code is iOS only / Android only / cross-platform shared
+- Check minimum version support for platform-specific API calls
+- Permission requests (camera, location, notifications, etc.) must have corresponding usage descriptions
+
+### Performance & UX
+- UI operations must be on the main thread; long-running operations must be on background threads
+- For list rendering, use proper reuse mechanisms (UITableView reuse / RecyclerView / ListView.builder)
+- Memory-sensitive — image loading must consider caching and scaling strategy
+
+### Prohibited
+- No hardcoded strings — use localization mechanisms
+- No ignoring app lifecycle — handle resource release and restoration during background/foreground transitions
+- No modifying Info.plist / AndroidManifest.xml without confirmation

package/templates/.claude/rules/stacks/python.md

@@ -0,0 +1,20 @@
+## Python Discipline
+
+### Code Quality
+- Run lint/type check after modifications (use whatever the project has configured: ruff, mypy, pyright, etc.)
+- Type annotations: new code must have type hints; add them to old code when modifying it
+- Import ordering follows project conventions (typically managed by isort or ruff)
+
+### Dependency Management
+- Ask before adding new dependencies — is it truly needed? Is there a stdlib alternative?
+- Confirm dependency version constraints — don't leave versions unconstrained, and don't pin too tightly
+
+### Testing
+- Run related tests after modifying logic
+- First confirm which test framework the project uses (pytest? unittest?) and the run command — don't assume
+- When tests fail, don't change the test to make it pass — first determine if the test is outdated or the code has a bug
+
+### Prohibited
+- No bare `except:` or `except Exception:` swallowing all exceptions
+- No rewriting an entire module without understanding the existing code
+- No introducing `os.system()` — use `subprocess.run()` with proper error handling

package/templates/.claude/rules/stacks/rtl.md

@@ -0,0 +1,24 @@
+## RTL Discipline
+
+### Hardware Mindset (not software mindset)
+- **Every line of code is a circuit** — Before writing, think about what hardware structure it synthesizes to
+- **Distinguish synthesis from simulation** — `initial`, `$display`, `#delay` are for testbench only, never in synthesizable code
+- **Timing awareness** — When modifying any register logic, consider the impact on timing paths
+- **Consistent reset strategy** — Don't mix synchronous/asynchronous reset in the same module without a clear reason
+
+### Mandatory Checks Before Modification
+- Confirm the fan-out of the signal being modified — Who is reading this signal?
+- Confirm the clock domain — Is this a clock domain crossing (CDC)? Is a synchronizer needed?
+- Confirm bit width — Do widths match? Are there implicit truncations or extensions?
+- Confirm FSM states — When modifying a state machine, are all state transitions fully covered?
+
+### Prohibited
+- No latches in `always @(*)` unless explicitly intended with a comment
+- No missing else / default branches in combinational logic
+- No modifying interface signals (ports) without updating all instantiation sites
+- No modifying critical path logic without understanding timing constraints
+
+### Testbench Rules
+- New features must have corresponding testbench cases
+- After modifying RTL, run existing simulations before checking results
+- Prefer assertions / checkers over visual waveform inspection

package/templates/.claude/settings.json

@@ -0,0 +1,75 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup|resume|clear|compact",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/session-start.sh\""
+          }
+        ]
+      }
+    ],
+    "PreToolUse": [
+      {
+        "matcher": "Edit|Write|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/pre-edit-guard.sh\""
+          }
+        ]
+      },
+      {
+        "matcher": "Edit|Write|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/streak-breaker.sh\""
+          }
+        ]
+      },
+      {
+        "matcher": "Edit|Write|MultiEdit|Bash|Agent",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/action-counter.sh\""
+          }
+        ]
+      },
+      {
+        "matcher": "ExitPlanMode",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/phase-gate.sh\""
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/post-error-remind.sh\""
+          }
+        ]
+      }
+    ],
+    "PostToolUseFailure": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/post-error-remind.sh\""
+          }
+        ]
+      }
+    ]
+  }
+}

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

@@ -0,0 +1,40 @@
+---
+name: commit
+description: Smart commit — run tests, update docs and memory, then commit to ensure knowledge is not lost
+disable-model-invocation: true
+---
+
+Execute the smart commit flow. Core principle: **commit code and knowledge together**.
+
+## 1. Run Tests
+
+Check the test command in CLAUDE.md and execute it. If tests fail, stop the commit and report.
+Skip this step for projects with no configured test command.
+
+## 2. Update Knowledge Files
+
+Check each in order (simple changes may skip):
+
+**docs/progress.md** — Does this change constitute a milestone or significant progress? If so, append a record.
+
+**docs/debug-log.md** — Are there debug sessions that need to be closed or updated?
+
+**CLAUDE.md** — Are there new components, interfaces, known pitfalls, or architectural changes to sync?
+
+**Auto Memory** — Are there cross-session lessons worth remembering? (bug patterns, API pitfalls, debugging tips)
+Update memory files, keeping MEMORY.md under 200 lines.
+
+## 3. Execute git commit
+
+```
+git status
+git diff --staged && git diff
+git log --oneline -5
+```
+
+- Selectively `git add` (don't use `git add -A`)
+- Include docs/ and CLAUDE.md changes in the commit if modified
+- Don't commit .env, credentials, or other sensitive files
+- Follow existing commit message style
+- Don't push (unless user explicitly requests it)
+- If pre-commit hook fails, fix the issue and create a new commit (don't --amend)

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

@@ -0,0 +1,57 @@
+---
+name: evaluate
+description: Objectively evaluate external review/advice against your actual codebase knowledge. Use when pasting suggestions from reviewers, consultants, or AI who lack project context.
+---
+
+You have deep context from investigating this codebase. The user is about to paste external advice from someone who may NOT have that context. Your job is to be an **honest bridge** — not a yes-man, not a contrarian.
+
+## Instructions
+
+For each suggestion or recommendation in the external input:
+
+### 1. Understand the intent
+
+What problem is this suggestion trying to solve? Separate the **goal** (often valid) from the **specific approach** (may not fit).
+
+### 2. Check against reality
+
+Use your actual codebase knowledge to verify:
+- Does the thing they're describing actually exist / work the way they assume?
+- Are there constraints they likely don't know about?
+- Have we already tried or considered this?
+- Does it conflict with decisions already made (and documented)?
+
+### 3. Verdict per item
+
+For each suggestion, give one of:
+
+- **Accept** — Suggestion is sound and fits the codebase reality. State what action to take.
+- **Accept with modification** — The goal is right but the approach needs adjustment. Explain what to change and why.
+- **Reject** — Doesn't apply, is based on wrong assumptions, or conflicts with known constraints. Explain specifically why, citing what you know about the codebase.
+- **Needs investigation** — You don't have enough context to judge. State what you'd need to check.
+
+### 4. Output format
+
+```
+## Evaluation of [source description]
+
+### [suggestion 1 summary]
+Verdict: accept / accept with modification / reject / needs investigation
+Reasoning: [cite specific codebase facts, not general opinions]
+Action: [what to do, if accepted]
+
+### [suggestion 2 summary]
+...
+
+## Summary
+Accepted: N  |  Modified: N  |  Rejected: N  |  Needs investigation: N
+```
+
+## Rules
+
+- **Be specific** — "This doesn't apply" is not enough. Say WHY, citing files/code/decisions you know about.
+- **Separate intent from approach** — A reviewer can be right about the problem and wrong about the solution.
+- **Don't reject based on effort** — "That's a lot of work" is not a valid reason to reject. Only reject on technical grounds.
+- **Don't accept out of deference** — External reviewer ≠ automatically correct. Your codebase context is the advantage here.
+- **Flag your own uncertainty** — If you're not sure about something, say "needs investigation", don't guess.
+- **Preserve the user's judgment** — You evaluate, the user decides. Present evidence, not directives.

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

@@ -0,0 +1,62 @@
+---
+name: self-check
+description: Periodic self-check — detect drift, mole-whacking, and discipline violations. Use with /loop for continuous monitoring.
+disable-model-invocation: true
+---
+
+Pause and honestly answer every question below. Do NOT skip any. Do NOT rationalize.
+
+## 1. Am I still on track?
+
+- What was the user's original request?
+- What am I doing right now?
+- Is my current action directly serving that request, or have I drifted?
+- If drifted: **stop, state what the original goal was, and ask the user if current direction is correct.**
+
+## 2. Am I mole-whacking?
+
+- 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 fixing root cause?
+- Am I guessing-and-checking instead of understanding?
+- If yes to any: **stop immediately. List all attempted fixes, look for the common root cause, report to user.**
+
+## 3. Am I being honest?
+
+- Have I claimed something is "verified" or "working" without actually running it?
+- Have I marked anything ✅ without pasting the verification command and output?
+- Have I marked something "done" when it actually depends on an external resource I haven't tested against?
+- Have I blamed an external tool/library/PDK without ruling out my own mistakes first?
+- Have I altered or paraphrased tool output instead of quoting verbatim?
+- Is there anything I stated confidently but am actually unsure about?
+- If yes to any: **correct it now. Label uncertain claims as "unverified" or "assumption". Downgrade false ✅ 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 skipping the debugging process (gather → hypothesize → verify → fix)?
+- If yes to any: **stop. Do only what was asked.**
+
+## 5. Is progress recorded?
+
+- When was `docs/progress.md` last updated?
+- Have I completed any milestones or made key decisions since the last update?
+- If yes: **update docs/progress.md NOW** with current status, completed items, and next steps.
+- This is critical for context survival across compacts and sessions.
+
+## 6. Status report
+
+After answering the above, output a brief status:
+
+```
+SELF-CHECK [timestamp]
+Task: [original user request]
+Current action: [what I'm doing now]
+On track: yes/no/drifted
+Mole-whacking: yes/no
+Progress recorded: yes/updated now/no
+Issues found: [list, or "none"]
+```
+
+If any issues were found, stop working and report to the user before continuing.

package/templates/CLAUDE.md

@@ -0,0 +1,80 @@
+# [PROJECT_NAME] — CLAUDE.md
+
+> General discipline rules are auto-injected via `.claude/rules/`. This file is for project-specific information only.
+
+---
+
+## Project Overview
+
+- **Project name**: [PROJECT_NAME]
+- **One-line description**: [TODO — what this project aims to achieve]
+- **Tech stack**: [TODO]
+- **Key constraints**: [TODO — e.g., performance requirements, compatibility, security]
+
+---
+
+## Project Structure
+
+[TODO — describe directory structure and module responsibilities]
+
+```
+├── src/          ← [TODO]
+├── tests/        ← [TODO]
+├── docs/
+│   ├── progress.md      ← Progress and decision log (maintained by Claude, do not edit manually)
+│   └── debug-log.md     ← Debug session log (maintained by Claude)
+└── .claude/
+    ├── rules/           ← Auto-injected rules
+    ├── hooks/           ← Enforced hooks
+    └── agents/          ← Reviewer & investigator subagents
+```
+
+---
+
+## Common Commands
+
+[TODO — build, test, lint, run commands]
+
+```bash
+# Build
+# [TODO]
+
+# Test
+# [TODO]
+
+# Lint / Type Check
+# [TODO]
+
+# Run / Simulate
+# [TODO]
+```
+
+---
+
+## Code Style
+
+[TODO — team conventions]
+
+---
+
+## Known Pitfalls
+
+[TODO — project-specific gotchas, examples:]
+- [e.g., Module X's interface looks like REST but is actually WebSocket]
+- [e.g., Database migrations must be backwards-compatible]
+- [e.g., Third-party library v2 API has breaking changes, we're pinned to v1]
+
+---
+
+## Compact Supplement
+
+When compacting, in addition to general rules (preserve task objectives, progress, decisions), also preserve:
+- [TODO — project-specific context that must be retained]
+
+---
+
+## Decision Log
+
+| Date | Decision | Reason | Impact |
+|------|----------|--------|--------|
+| | | | |