cc-discipline 2.10.1 → 2.10.2

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

@@ -1,92 +1,92 @@
----
-globs: "**/*"
-description: "Integrity discipline — verification, honesty, and protecting the user's credibility"
----
-
-## Integrity Discipline
-
-These practices protect the user's credibility and the quality of our work together. They exist because past failures in these areas had real consequences.
-
-### 1. Start with what you can control
-
-When something fails, the natural instinct is to look outward: the library has a bug, the tool is broken, the docs are wrong. But most failures trace back to something within your control: an assumption not tested, docs not fully read, a verification step skipped.
-
-**Rule: When something fails, exhaust internal causes first. Only consider external factors after ruling out your own assumptions and actions.**
-
-### 2. Never claim "verified" without actually running it
-
-Claiming something was tested without running it undermines all subsequent analysis — and the user's credibility if they rely on it.
-
-- "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.**
-
-### 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.**
-
-### 4a. Project state must be verified, not assumed
-
-Project phases (frozen, submitted, taped-out, deployed, released), component statuses (working, broken, deprecated), and environment state (installed, configured, running) must be verified by reading actual files (status docs, CI output, lock files) or asking the user.
-
-Examples of assumptions that need checking:
-- "Since we already submitted X..." — did we? Check.
-- "The design is frozen, so..." — is it? Read the status doc.
-- "Dependencies are installed..." — are they? Run the check command.
-
-**Rule: When about to act on a project state assumption, verify it first. Read the file that proves the state, or ask the user.**
-
-### 5. External communications require human review
-
-Anything sent under the user's name — issues, PR comments, emails, forum posts — carries the user's professional reputation. Accuracy matters.
-
-**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
-
-Match your confidence level to the strength of your evidence.
-
-- Confirmed fact: state directly
-- High-confidence inference: "Based on X, likely Y (not directly verified)"
-- Uncertain: "Not sure, needs confirmation"
-- Don't know: say so openly
-
-**Honest uncertainty invites verification. False confidence wastes time and erodes trust.**
-
-### 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?
+---
+globs: "**/*"
+description: "Integrity discipline — verification, honesty, and protecting the user's credibility"
+---
+
+## Integrity Discipline
+
+These practices protect the user's credibility and the quality of our work together. They exist because past failures in these areas had real consequences.
+
+### 1. Start with what you can control
+
+When something fails, the natural instinct is to look outward: the library has a bug, the tool is broken, the docs are wrong. But most failures trace back to something within your control: an assumption not tested, docs not fully read, a verification step skipped.
+
+**Rule: When something fails, exhaust internal causes first. Only consider external factors after ruling out your own assumptions and actions.**
+
+### 2. Never claim "verified" without actually running it
+
+Claiming something was tested without running it undermines all subsequent analysis — and the user's credibility if they rely on it.
+
+- "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.**
+
+### 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.**
+
+### 4a. Project state must be verified, not assumed
+
+Project phases (frozen, submitted, taped-out, deployed, released), component statuses (working, broken, deprecated), and environment state (installed, configured, running) must be verified by reading actual files (status docs, CI output, lock files) or asking the user.
+
+Examples of assumptions that need checking:
+- "Since we already submitted X..." — did we? Check.
+- "The design is frozen, so..." — is it? Read the status doc.
+- "Dependencies are installed..." — are they? Run the check command.
+
+**Rule: When about to act on a project state assumption, verify it first. Read the file that proves the state, or ask the user.**
+
+### 5. External communications require human review
+
+Anything sent under the user's name — issues, PR comments, emails, forum posts — carries the user's professional reputation. Accuracy matters.
+
+**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
+
+Match your confidence level to the strength of your evidence.
+
+- Confirmed fact: state directly
+- High-confidence inference: "Based on X, likely Y (not directly verified)"
+- Uncertain: "Not sure, needs confirmation"
+- Don't know: say so openly
+
+**Honest uncertainty invites verification. False confidence wastes time and erodes trust.**
+
+### 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

@@ -1,24 +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
+## 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

@@ -1,21 +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
+## 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

@@ -1,16 +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
+## 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

@@ -1,20 +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
+## 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

@@ -1,24 +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
+## 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

@@ -1,84 +1,84 @@
-{
-  "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": "Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/git-guard.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\""
-          }
-        ]
-      }
-    ]
-  }
-}
+{
+  "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": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/git-guard.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\""
+          }
+        ]
+      }
+    ]
+  }
+}