cc-discipline 2.11.0 → 2.12.1

package/bin/cli.js

@@ -1,147 +1,147 @@
-#!/usr/bin/env node
-// cc-discipline CLI entry point (cross-platform)
-// Detects platform and spawns bash with correct paths
-
-const { execSync, spawnSync } = require('child_process');
-const path = require('path');
-const fs = require('fs');
-
-const PKG_DIR = path.resolve(__dirname, '..');
-const args = process.argv.slice(2);
-
-// Find bash executable
-function findBash() {
-    // Unix: bash is always available
-    if (process.platform !== 'win32') return 'bash';
-
-    // Windows: try common Git Bash locations
-    const candidates = [
-        'C:\\Program Files\\Git\\bin\\bash.exe',
-        'C:\\Program Files (x86)\\Git\\bin\\bash.exe',
-        process.env.PROGRAMFILES + '\\Git\\bin\\bash.exe',
-    ];
-
-    for (const candidate of candidates) {
-        if (fs.existsSync(candidate)) return candidate;
-    }
-
-    // Try PATH
-    try {
-        execSync('bash --version', { stdio: 'ignore' });
-        return 'bash';
-    } catch (e) {
-        console.error('Error: bash not found. Please install Git for Windows (https://git-scm.com/download/win)');
-        console.error('Git Bash is required to run cc-discipline on Windows.');
-        process.exit(1);
-    }
-}
-
-const bash = findBash();
-
-// Convert Windows path to Unix-style for bash
-function toUnixPath(p) {
-    if (process.platform !== 'win32') return p;
-    // C:\Users\foo → /c/Users/foo
-    return p.replace(/\\/g, '/').replace(/^([A-Za-z]):/, (_, drive) => '/' + drive.toLowerCase());
-}
-
-// Route subcommands
-const command = args[0] || 'init';
-const restArgs = args.slice(1);
-
-let script;
-let scriptArgs;
-
-switch (command) {
-    case 'init':
-        script = path.join(PKG_DIR, 'init.sh');
-        scriptArgs = restArgs;
-        break;
-    case 'upgrade':
-        script = path.join(PKG_DIR, 'init.sh');
-        scriptArgs = ['--auto', ...restArgs];
-        break;
-    case 'status':
-        script = path.join(PKG_DIR, 'lib', 'status.sh');
-        scriptArgs = [];
-        break;
-    case 'doctor':
-        script = path.join(PKG_DIR, 'lib', 'doctor.sh');
-        scriptArgs = [];
-        break;
-    case 'add-stack':
-        if (restArgs.length === 0) {
-            console.log('Usage: cc-discipline add-stack <numbers>');
-            console.log('  e.g.: cc-discipline add-stack 3 4');
-            process.exit(1);
-        }
-        script = path.join(PKG_DIR, 'init.sh');
-        scriptArgs = ['--stack', restArgs.join(' '), '--no-global'];
-        break;
-    case 'remove-stack':
-        script = path.join(PKG_DIR, 'lib', 'stack-remove.sh');
-        scriptArgs = restArgs;
-        break;
-    case '-v':
-    case '--version':
-    case 'version':
-        const pkg = require(path.join(PKG_DIR, 'package.json'));
-        console.log(`cc-discipline v${pkg.version}`);
-        process.exit(0);
-    case '-h':
-    case '--help':
-    case 'help':
-        const ver = require(path.join(PKG_DIR, 'package.json')).version;
-        console.log(`cc-discipline v${ver} — Discipline framework for Claude Code
-
-Usage: cc-discipline <command> [options]
-
-Commands:
-  init [options]        Install discipline into current project (default)
-  upgrade               Upgrade rules/hooks (shortcut for init --auto)
-  add-stack <numbers>   Add stack rules (e.g., add-stack 3 4)
-  remove-stack <numbers> Remove stack rules
-  status                Show installed version, stacks, and hooks
-  doctor                Check installation integrity
-  version               Show version
-
-Init options:
-  --auto                Non-interactive with defaults
-  --stack <choices>     Stack selection: 1-7, space-separated
-  --name <name>         Project name (default: directory name)
-  --global              Install global rules to ~/.claude/CLAUDE.md
-  --no-global           Skip global rules install
-
-Stacks:
-  1=RTL  2=Embedded  3=Python  4=JS/TS  5=Mobile  6=Fullstack  7=General
-
-Examples:
-  npx cc-discipline                           # Interactive setup
-  npx cc-discipline init --auto               # Non-interactive defaults
-  npx cc-discipline init --auto --stack "3 4"  # Python + JS/TS
-  npx cc-discipline upgrade                   # Upgrade to latest
-  npx cc-discipline status                    # Check what's installed
-  npx cc-discipline doctor                    # Diagnose issues`);
-        process.exit(0);
-    default:
-        console.error(`Unknown command: ${command}`);
-        console.error("Run 'cc-discipline --help' for usage");
-        process.exit(1);
-}
-
-// Run the bash script
-const unixScript = toUnixPath(script);
-const pkgVersion = require(path.join(PKG_DIR, 'package.json')).version;
-const env = {
-    ...process.env,
-    CC_DISCIPLINE_PKG_DIR: process.platform === 'win32' ? toUnixPath(PKG_DIR) : PKG_DIR,
-    CC_DISCIPLINE_VERSION: pkgVersion,
-};
-
-const result = spawnSync(bash, [unixScript, ...scriptArgs], {
-    stdio: 'inherit',
-    env,
-    cwd: process.cwd(),
-});
-
-process.exit(result.status || 0);
+#!/usr/bin/env node
+// cc-discipline CLI entry point (cross-platform)
+// Detects platform and spawns bash with correct paths
+
+const { execSync, spawnSync } = require('child_process');
+const path = require('path');
+const fs = require('fs');
+
+const PKG_DIR = path.resolve(__dirname, '..');
+const args = process.argv.slice(2);
+
+// Find bash executable
+function findBash() {
+    // Unix: bash is always available
+    if (process.platform !== 'win32') return 'bash';
+
+    // Windows: try common Git Bash locations
+    const candidates = [
+        'C:\\Program Files\\Git\\bin\\bash.exe',
+        'C:\\Program Files (x86)\\Git\\bin\\bash.exe',
+        process.env.PROGRAMFILES + '\\Git\\bin\\bash.exe',
+    ];
+
+    for (const candidate of candidates) {
+        if (fs.existsSync(candidate)) return candidate;
+    }
+
+    // Try PATH
+    try {
+        execSync('bash --version', { stdio: 'ignore' });
+        return 'bash';
+    } catch (e) {
+        console.error('Error: bash not found. Please install Git for Windows (https://git-scm.com/download/win)');
+        console.error('Git Bash is required to run cc-discipline on Windows.');
+        process.exit(1);
+    }
+}
+
+const bash = findBash();
+
+// Convert Windows path to Unix-style for bash
+function toUnixPath(p) {
+    if (process.platform !== 'win32') return p;
+    // C:\Users\foo → /c/Users/foo
+    return p.replace(/\\/g, '/').replace(/^([A-Za-z]):/, (_, drive) => '/' + drive.toLowerCase());
+}
+
+// Route subcommands
+const command = args[0] || 'init';
+const restArgs = args.slice(1);
+
+let script;
+let scriptArgs;
+
+switch (command) {
+    case 'init':
+        script = path.join(PKG_DIR, 'init.sh');
+        scriptArgs = restArgs;
+        break;
+    case 'upgrade':
+        script = path.join(PKG_DIR, 'init.sh');
+        scriptArgs = ['--auto', ...restArgs];
+        break;
+    case 'status':
+        script = path.join(PKG_DIR, 'lib', 'status.sh');
+        scriptArgs = [];
+        break;
+    case 'doctor':
+        script = path.join(PKG_DIR, 'lib', 'doctor.sh');
+        scriptArgs = [];
+        break;
+    case 'add-stack':
+        if (restArgs.length === 0) {
+            console.log('Usage: cc-discipline add-stack <numbers>');
+            console.log('  e.g.: cc-discipline add-stack 3 4');
+            process.exit(1);
+        }
+        script = path.join(PKG_DIR, 'init.sh');
+        scriptArgs = ['--stack', restArgs.join(' '), '--no-global'];
+        break;
+    case 'remove-stack':
+        script = path.join(PKG_DIR, 'lib', 'stack-remove.sh');
+        scriptArgs = restArgs;
+        break;
+    case '-v':
+    case '--version':
+    case 'version':
+        const pkg = require(path.join(PKG_DIR, 'package.json'));
+        console.log(`cc-discipline v${pkg.version}`);
+        process.exit(0);
+    case '-h':
+    case '--help':
+    case 'help':
+        const ver = require(path.join(PKG_DIR, 'package.json')).version;
+        console.log(`cc-discipline v${ver} — Discipline framework for Claude Code
+
+Usage: cc-discipline <command> [options]
+
+Commands:
+  init [options]        Install discipline into current project (default)
+  upgrade               Upgrade rules/hooks (shortcut for init --auto)
+  add-stack <numbers>   Add stack rules (e.g., add-stack 3 4)
+  remove-stack <numbers> Remove stack rules
+  status                Show installed version, stacks, and hooks
+  doctor                Check installation integrity
+  version               Show version
+
+Init options:
+  --auto                Non-interactive with defaults
+  --stack <choices>     Stack selection: 1-7, space-separated
+  --name <name>         Project name (default: directory name)
+  --global              Install global rules to ~/.claude/CLAUDE.md
+  --no-global           Skip global rules install
+
+Stacks:
+  1=RTL  2=Embedded  3=Python  4=JS/TS  5=Mobile  6=Fullstack  7=General
+
+Examples:
+  npx cc-discipline                           # Interactive setup
+  npx cc-discipline init --auto               # Non-interactive defaults
+  npx cc-discipline init --auto --stack "3 4"  # Python + JS/TS
+  npx cc-discipline upgrade                   # Upgrade to latest
+  npx cc-discipline status                    # Check what's installed
+  npx cc-discipline doctor                    # Diagnose issues`);
+        process.exit(0);
+    default:
+        console.error(`Unknown command: ${command}`);
+        console.error("Run 'cc-discipline --help' for usage");
+        process.exit(1);
+}
+
+// Run the bash script
+const unixScript = toUnixPath(script);
+const pkgVersion = require(path.join(PKG_DIR, 'package.json')).version;
+const env = {
+    ...process.env,
+    CC_DISCIPLINE_PKG_DIR: process.platform === 'win32' ? toUnixPath(PKG_DIR) : PKG_DIR,
+    CC_DISCIPLINE_VERSION: pkgVersion,
+};
+
+const result = spawnSync(bash, [unixScript, ...scriptArgs], {
+    stdio: 'inherit',
+    env,
+    cwd: process.cwd(),
+});
+
+process.exit(result.status || 0);

package/init.sh

@@ -367,12 +367,32 @@ cp "$SCRIPT_DIR/templates/.claude/agents/investigator.md" .claude/agents/
 echo -e "${GREEN}Installing skills...${NC}"
 # Install every skill directory under templates/ — no per-skill enumeration,
 # so adding a new skill needs zero changes here.
+#
+# Copy into an EXPLICIT destination directory. Do not use `cp -r "$skill_dir"
+# .claude/skills/` here: the `*/` glob gives $skill_dir a trailing slash, and
+# GNU and BSD cp disagree about what that means. GNU copies the directory;
+# BSD (macOS) copies its *contents*, so every skill's SKILL.md landed on top of
+# the previous one at .claude/skills/SKILL.md and no skill was ever updated.
+# Shipped broken in v2.11.0 (the "directory-driven install" change) and fixed in
+# v2.12.1. Symptom on an affected machine: a stray .claude/skills/SKILL.md plus
+# skill dirs frozen at their first-install date. status/doctor could not catch
+# it because they glob `skills/*/` and a bare file is not a directory.
 for skill_dir in "$SCRIPT_DIR"/templates/.claude/skills/*/; do
     [ -d "$skill_dir" ] || continue
-    cp -r "$skill_dir" .claude/skills/
-    echo "   ✓ /$(basename "$skill_dir")"
+    skill_name=$(basename "$skill_dir")
+    mkdir -p ".claude/skills/$skill_name"
+    cp -R "$skill_dir"* ".claude/skills/$skill_name/"
+    echo "   ✓ /$skill_name"
 done
 
+# Clean up the stray file left behind by the v2.11.0–v2.12.0 bug above. A bare
+# SKILL.md directly under skills/ is never a valid skill (skills live in
+# subdirectories), so this only ever removes that debris.
+if [ -f ".claude/skills/SKILL.md" ]; then
+    rm -f ".claude/skills/SKILL.md"
+    echo -e "   ${YELLOW}✓ removed stray .claude/skills/SKILL.md (v2.11.0 macOS install bug)${NC}"
+fi
+
 # ─── Handle CLAUDE.md ───
 if [ ! -f "CLAUDE.md" ]; then
     # No CLAUDE.md exists — generate from template

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-discipline",
-  "version": "2.11.0",
+  "version": "2.12.1",
   "description": "Discipline framework for Claude Code — rules, hooks, and agents that keep AI on track",
   "bin": {
     "cc-discipline": "bin/cli.js"

package/templates/.claude/hooks/action-counter.sh

@@ -3,8 +3,6 @@
 # Counts action-type tool calls per session, injects self-check every N actions.
 # PreToolUse on Edit|Write|MultiEdit|Bash|Agent — additionalContext injection.
 
-THRESHOLD=25
-
 INPUT=$(cat)
 # Extract session_id with a grep fallback for when jq is unavailable (e.g.
 # Windows Git Bash). Without this fallback, every session collapsed to the
@@ -36,14 +34,29 @@ fi
 
 # Progress.md staleness check: every 50 actions, check if progress.md was updated recently
 if [ $((COUNT % 50)) -eq 0 ]; then
-    CWD=$(echo "$INPUT" | jq -r '.cwd // ""' 2>/dev/null)
+    if command -v jq &>/dev/null; then
+        CWD=$(echo "$INPUT" | jq -r '.cwd // ""' 2>/dev/null)
+    else
+        CWD=$(echo "$INPUT" | sed -n -E 's/.*"cwd"[[:space:]]*:[[:space:]]*"([^"]*)".*/\1/p' | head -1 | sed 's/[\][\]/\//g')
+    fi
     PROGRESS_FILE=""
     [ -f "$CWD/docs/progress.md" ] && PROGRESS_FILE="$CWD/docs/progress.md"
     [ -z "$PROGRESS_FILE" ] && [ -f "docs/progress.md" ] && PROGRESS_FILE="docs/progress.md"
     if [ -n "$PROGRESS_FILE" ]; then
-        # Check if file was modified in the last 30 minutes
+        # Check if file was modified in the last 30 minutes.
+        # GNU stat (Linux, Windows Git Bash) FIRST, BSD stat (macOS) second —
+        # this order matters and the reverse is broken: in GNU stat, `-f` is not
+        # BSD's "format" flag, it means "show filesystem status". It therefore
+        # SUCCEEDS on Git Bash and prints a multi-line filesystem dump, so the
+        # `||` fallback never ran and $((NOW - FILE_MOD)) died with "syntax error
+        # in expression". `stat -c` is simply an invalid option on macOS, so it
+        # fails cleanly and falls through. The numeric guard below makes the
+        # failure mode silent either way. (fixed 2026-07-30)
         if command -v stat &>/dev/null; then
-            FILE_MOD=$(stat -f %m "$PROGRESS_FILE" 2>/dev/null || stat -c %Y "$PROGRESS_FILE" 2>/dev/null)
+            FILE_MOD=$(stat -c %Y "$PROGRESS_FILE" 2>/dev/null || stat -f %m "$PROGRESS_FILE" 2>/dev/null)
+            case "$FILE_MOD" in
+                ''|*[!0-9]*) FILE_MOD="" ;;
+            esac
             NOW=$(date +%s)
             if [ -n "$FILE_MOD" ] && [ $((NOW - FILE_MOD)) -gt 1800 ]; then
                 STALE_MIN=$(( (NOW - FILE_MOD) / 60 ))
@@ -56,10 +69,14 @@ JSONEOF
     fi
 fi
 
-if [ $((COUNT % THRESHOLD)) -eq 0 ]; then
-    cat <<JSONEOF
-{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"Periodic reflection (#${COUNT} actions): Take a moment to check in. ALIGNMENT: (1) Am I still serving the user's current direction? They may have pivoted — follow their latest intent. (2) Am I making changes the user asked for, and only those? QUALITY: (3) Are all my 'verified' claims backed by actual execution output? If not, correct that now. (4) If executing a plan, does what I delivered match what the step asked for? Check acceptance criteria. (5) Am I maintaining quality, or taking shortcuts to avoid difficulty? If tempted to cut corners, ask the user instead. PROGRESS: (6) Am I progressing or circling? (fixing the same area repeatedly suggests a deeper issue worth stepping back to find) (7) Is docs/progress.md up to date? If auto-compact happened now, could a fresh session resume from it? (8) Did I break a task into subtasks and skip some? If the analysis context is fresh, finishing them now is cheaper than rebuilding later. WHAT'S WORKING: (9) Note one thing going well — a good approach, a clean fix, or effective tool use. (10) Any friction from hooks or rules since last check? Note it for /retro. If any answer is concerning, pause and report to the user before continuing."}}
-JSONEOF
-fi
+# The 25-action, 10-question "Periodic reflection" block was removed 2026-07-30.
+# Anthropic's Opus 5 guidance: the model verifies its own work without being told
+# to, and "legacy harness scaffolding that adds separate verification steps"
+# causes over-verification — it compounds with the model's own behavior and adds
+# cost with no quality gain. The block also duplicated rules already injected
+# every session (00-core, 03, 06, 07), at ~299 tokens per firing. The remaining
+# checks above (early-action phase check, progress.md staleness) are kept: both
+# came out of the 112-session insights analysis in v2.4.0 and target failure
+# modes we actually measured, not generic self-review.
 
 exit 0

package/templates/.claude/hooks/git-guard.sh

@@ -3,17 +3,46 @@
 # PreToolUse on Bash — blocks git checkout/restore/reset --hard/clean -f without confirmation.
 
 INPUT=$(cat)
-TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // ""' 2>/dev/null)
 
-if [ "$TOOL_NAME" != "Bash" ]; then
-    exit 0
+# Extract tool_name and command. MUST have a jq-or-grep fallback: jq is absent
+# on Windows Git Bash, and the previous jq-only version left TOOL_NAME empty
+# there, so the `!= "Bash"` check below exited 0 immediately and EVERY guard in
+# this file was dead code. Destructive-git protection never ran on Windows.
+# (fixed 2026-07-30 — verified with jq absent, see docs/progress.md)
+if command -v jq &>/dev/null; then
+    TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // ""' 2>/dev/null)
+    CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""' 2>/dev/null)
+else
+    TOOL_NAME=$(echo "$INPUT" | sed -n -E 's/.*"tool_name"[[:space:]]*:[[:space:]]*"([^"]*)".*/\1/p' | head -1)
+    # The [{,] anchor makes this pick the real "command" field rather than an
+    # escaped \"command\" nested inside it (happens when piping JSON to a hook).
+    # Unescape \n and \" so line-spanning commands still match the patterns below.
+    CMD=$(echo "$INPUT" | sed -n -E 's/.*[{,][[:space:]]*"command"[[:space:]]*:[[:space:]]*"(.*)".*/\1/p' \
+        | sed 's/[\]n/ /g; s/[\]"/"/g')
+    # If the command could not be isolated, scan the whole payload instead of
+    # giving up. For a destructive-git guard the failure directions are not
+    # symmetric: a spurious confirmation prompt costs one turn, a miss costs the
+    # user's uncommitted work. Fail loud.
+    [ -z "$CMD" ] && CMD="$INPUT"
 fi
 
-CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""' 2>/dev/null)
+# Only gate on tool_name when it actually resolved — an unresolvable tool_name
+# must not silently disable the guard (that was the original bug).
+if [ -n "$TOOL_NAME" ] && [ "$TOOL_NAME" != "Bash" ]; then
+    exit 0
+fi
 
 # Normalize: collapse whitespace, trim
 CMD_NORM=$(echo "$CMD" | tr '\n' ' ' | sed 's/  */ /g')
 
+# This guard matches command TEXT, so a command that merely quotes a destructive
+# command trips it. The one recurring legitimate case is feeding JSON into one of
+# these hooks to test them (the workflow documented in CLAUDE.md). Exempt it —
+# piping a payload to a hook script never touches the working tree.
+if echo "$CMD_NORM" | grep -qE 'hooks[/\\][a-z-]+\.sh'; then
+    exit 0
+fi
+
 BLOCKED=""
 SUGGESTION=""
 

package/templates/.claude/hooks/post-error-remind.sh

@@ -29,11 +29,25 @@ if command -v jq &>/dev/null; then
     if [ -z "$OUTPUT" ]; then
         OUTPUT=$(echo "$RAW_INPUT" | jq -r '.tool_response.output // empty' 2>/dev/null)
     fi
+else
+    # jq is absent on Windows Git Bash. Extract the same two fields with sed.
+    # Unescape \n so the line-anchored patterns below (^ERROR, ^Traceback, ...)
+    # still work.
+    TOOL_NAME=$(echo "$RAW_INPUT" | sed -n -E 's/.*"tool_name"[[:space:]]*:[[:space:]]*"([^"]*)".*/\1/p' | head -1)
+    OUTPUT=$(echo "$RAW_INPUT" | sed -n -E 's/.*[{,][[:space:]]*"(error|output)"[[:space:]]*:[[:space:]]*"(.*)".*/\2/p' | head -1 \
+        | sed 's/[\]n/\
+/g; s/[\]"/"/g')
 fi
 
-# Fallback if jq unavailable
+# NEVER match against the raw JSON envelope. The command text lives in there
+# too, so `grep -rn "permission denied" logs/` used to flag itself — and with
+# tool_name unresolved the non-Bash early-exit below never fired either, so this
+# hook lectured on clean Read calls. Both were the old `OUTPUT="$RAW_INPUT"`
+# fallback. If the tool's own output can't be isolated, stay silent: a false
+# positive here costs a turn and misleads, so silence is the safe direction.
+# (fixed 2026-07-30 — verified with jq absent, see docs/progress.md)
 if [ -z "$OUTPUT" ]; then
-    OUTPUT="$RAW_INPUT"
+    exit 0
 fi
 
 # --- Early exits for known non-error situations ---
@@ -97,14 +111,14 @@ fi
 # --- Emit reminder if error detected ---
 
 if [ "$HAS_ERROR" = true ]; then
-    REMINDER="Error encountered — debugging checklist: 1. Resist modifying code immediately 2. Fully understand the error message 3. List >=3 possible causes — label them hypotheses, not root cause 4. Record in docs/debug-log.md 5. Eliminate >=2 hypotheses with evidence before identifying root cause 6. Only then fix. Important: after seeing one error, the first explanation is a hypothesis, not a conclusion. Say 'possible cause' until you have elimination evidence."
+    # Keep this to ONE line. The hypothesis discipline itself lives in the
+    # always-injected rules (00-core §6, 01-debugging) — re-injecting the full
+    # ">=3 causes / record in debug-log / eliminate >=2" ritual on every error
+    # duplicated them and pushed toward over-verification. Trimmed 2026-07-30.
+    REMINDER="Error detected: the first explanation that comes to mind is a hypothesis, not the root cause. Read the actual error before changing code."
 
     if [ "$ERROR_TYPE" = "test" ]; then
-        REMINDER="$REMINDER Note: Test failure — before changing the test, first determine if it's a code bug or an outdated test."
-    fi
-
-    if [ "$ERROR_TYPE" = "crash" ]; then
-        REMINDER="$REMINDER Note: Crash/segfault — may involve memory issues."
+        REMINDER="$REMINDER Test failure — decide whether the code is wrong or the test is outdated before touching either."
     fi
 
     echo "$REMINDER" >&2

package/templates/.claude/hooks/pre-edit-guard.sh

@@ -51,34 +51,54 @@ if [ -n "$DEBUG_LOG" ]; then
     CONFIRMED=$(echo "$CLEAN" | grep -c '| confirmed |' 2>/dev/null) || CONFIRMED=0
 
     if [ "$PENDING" -gt "$CONFIRMED" ] 2>/dev/null; then
-        cat >&2 <<EOF
-docs/debug-log.md has $((PENDING - CONFIRMED)) unverified hypotheses.
-Please complete the debugging process (verify or eliminate hypotheses) before editing source code.
-If you have confirmed the root cause, update debug-log.md first.
-EOF
-        exit 2
+        # Downgraded from a hard block (exit 2) to a note, 2026-07-30.
+        # As a hard block this combined with 01-debugging Phase 2 to form a trap:
+        # follow the rule, write 3 hypotheses into debug-log.md, and you were then
+        # forbidden from editing source until 3 were marked confirmed — including
+        # for unrelated planned work. It is the "legacy harness scaffolding that
+        # adds separate verification steps" Anthropic's Opus 5 guidance calls out.
+        # The hypothesis discipline itself stays in rules 00-core §6 / 01-debugging
+        # (56 measured wrong-approach incidents); only the enforcement is relaxed.
+        cat <<JSONEOF
+{"hookSpecificOutput":{"hookEventName":"PreToolUse","additionalContext":"DEBUG-LOG NOTE: docs/debug-log.md has $((PENDING - CONFIRMED)) hypotheses still marked pending. If this edit is the fix for one of them, update its status first so the log stays truthful. If this edit is unrelated work, carry on."}}
+JSONEOF
+        exit 0
     fi
 fi
 
 # ─── Large diff warning ───
-HAS_JQ=false
-command -v jq &>/dev/null && HAS_JQ=true
-
-if [ "$HAS_JQ" = true ]; then
-    NEW_STRING=$(echo "$INPUT" | jq -r '.tool_input.new_string // ""')
-    OLD_STRING=$(echo "$INPUT" | jq -r '.tool_input.old_string // ""')
-    NEW_LINES=$(echo "$NEW_STRING" | wc -l | tr -d ' ')
-    OLD_LINES=$(echo "$OLD_STRING" | wc -l | tr -d ' ')
-    DIFF_LINES=$((NEW_LINES > OLD_LINES ? NEW_LINES : OLD_LINES))
-    if [ "$DIFF_LINES" -gt 200 ]; then
-        echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"additionalContext\":\"LARGE EDIT NOTE: This edit involves ${DIFF_LINES} lines. Consider: is this the minimal change needed? Could it be broken into smaller, more focused edits?\"}}"
-        exit 0
-    fi
+# Counts `content` too, not just new_string/old_string: Write sends `content`, so
+# the previous version silently never fired on a large Write. Has a no-jq path so
+# the "every jq read has an else" invariant holds repo-wide (see CLAUDE.md).
+if command -v jq &>/dev/null; then
+    NEW_LINES=$(echo "$INPUT" | jq -r '.tool_input.new_string // .tool_input.content // ""' | wc -l | tr -d ' ')
+    OLD_LINES=$(echo "$INPUT" | jq -r '.tool_input.old_string // ""' | wc -l | tr -d ' ')
+else
+    # Newlines arrive as the two-character sequence \n inside the JSON string.
+    count_lines() {
+        c=$(echo "$INPUT" | sed -n -E "s/.*[{,][[:space:]]*\"$1\"[[:space:]]*:[[:space:]]*\"(.*)\".*/\1/p" \
+            | grep -o '[\]n' | wc -l | tr -d ' ')
+        echo $((c + 1))
+    }
+    NEW_LINES=$(count_lines new_string)
+    [ "$NEW_LINES" -le 1 ] && NEW_LINES=$(count_lines content)
+    OLD_LINES=$(count_lines old_string)
+fi
+DIFF_LINES=$((NEW_LINES > OLD_LINES ? NEW_LINES : OLD_LINES))
+if [ "$DIFF_LINES" -gt 200 ]; then
+    echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"additionalContext\":\"LARGE EDIT NOTE: This edit involves ${DIFF_LINES} lines. Consider: is this the minimal change needed? Could it be broken into smaller, more focused edits?\"}}"
+    exit 0
 fi
 
 # ─── New tool/script detection ───
 # When creating a script file via Write, remind to register in CLAUDE.md
-TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
+# jq-or-sed: the previous jq-only line left TOOL_NAME empty on Windows Git Bash,
+# so this detection never fired there. (fixed 2026-07-30)
+if command -v jq &>/dev/null; then
+    TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name // empty' 2>/dev/null)
+else
+    TOOL_NAME=$(echo "$INPUT" | sed -n -E 's/.*"tool_name"[[:space:]]*:[[:space:]]*"([^"]*)".*/\1/p' | head -1)
+fi
 if [ "$TOOL_NAME" = "Write" ] && echo "$BASENAME" | grep -qiE "\.(sh|py|js|ts|rb|pl)$"; then
     # Check if file already exists (new file = tool creation)
     FULL_PATH="$FILE_PATH"

package/templates/.claude/hooks/session-start.sh

@@ -4,9 +4,15 @@
 # stdout → context (Claude can see and act on it)
 # Fires on: startup, resume, clear, compact
 
-# Reset action counter for this session
+# Reset action counter for this session.
+# jq-or-sed: jq is absent on Windows Git Bash, and the previous jq-only version
+# left SESSION_ID empty there, so the reset below never ran. (fixed 2026-07-30)
 INPUT=$(cat)
-SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"' 2>/dev/null)
+if command -v jq &>/dev/null; then
+    SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // "unknown"' 2>/dev/null)
+else
+    SESSION_ID=$(echo "$INPUT" | sed -n -E 's/.*"session_id"[[:space:]]*:[[:space:]]*"([^"]*)".*/\1/p' | head -1)
+fi
 if [ -n "$SESSION_ID" ] && [ "$SESSION_ID" != "unknown" ]; then
     rm -f "/tmp/cc-discipline-${SESSION_ID}/action-count"
 fi
@@ -31,14 +37,14 @@ Verify project status by reading files or asking — don't assume beyond what is
 EOF
 fi
 
+# Only the skill pointer is injected here. The four rule restatements that used
+# to follow it (pre-edit checks, 3-failure rule, confirm-before-implementing,
+# verify project state) were removed 2026-07-30: all four are already in the
+# rules injected every session (02, 00-core §4, 05, 07 §4a), so repeating them
+# here bought nothing. Skills are the one thing rules don't announce.
 cat <<'EOF'
 
-Reminders:
-- /self-check available for periodic monitoring. For complex tasks: /loop 10m /self-check
-- Before editing: root cause identified? scope respected? change recorded?
-- 3 consecutive failures → pause and regroup with the user
-- Confirm the approach with the user before starting implementation
-- Verify project state (phase, status, dependencies) by reading files or asking
+/self-check is available for periodic monitoring — for long tasks: /loop 10m /self-check
 EOF
 
 exit 0

package/templates/.claude/hooks/streak-breaker.sh

@@ -4,8 +4,8 @@
 # Pauses for reflection when the pattern suggests circling
 #
 # Design:
-#   - Source code files (.java/.ts/.py/.go etc): warn at 3, stop at 5
-#   - Config/doc files (.md/.json/.yaml/.xml etc): warn at 6, stop at 10
+#   - Source code files (.java/.ts/.py/.go etc): warn at 6, stop at 10
+#   - Config/doc files (.md/.json/.yaml/.xml etc): warn at 10, stop at 16
 #   - docs/ directory: exempt (always allow)
 #
 # Exit 0 + no output = silent allow
@@ -41,13 +41,20 @@ fi
 BASENAME=$(basename "$FILE_PATH")
 
 if echo "$BASENAME" | grep -qiE "\.(md|json|yaml|yml|toml|xml|cfg|ini|properties|gitignore)$"; then
-    # Config/doc files: higher thresholds (many independent sections to fill)
+    # Config/doc files: higher thresholds (many independent sections to fill).
+    # Raised 6/10 -> 10/16 on 2026-07-30 to keep this tier above the source tier
+    # after source was raised to 6/10.
+    WARN_THRESHOLD=10
+    STOP_THRESHOLD=16
+else
+    # Source code files: repeated edits may indicate circling.
+    # Raised from 3/5 to 6/10 on 2026-07-30. Opus 5 completes multi-file features
+    # and larger refactors end-to-end rather than in one pass per file, so 5 edits
+    # to one source file is now common in legitimate feature work — the old
+    # thresholds fired on progress, not on circling. Circling that is actually
+    # worth interrupting still shows up well before 10.
     WARN_THRESHOLD=6
     STOP_THRESHOLD=10
-else
-    # Source code files: strict thresholds (repeated edits may indicate circling)
-    WARN_THRESHOLD=3
-    STOP_THRESHOLD=5
 fi
 
 # Counter logic

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

@@ -5,7 +5,7 @@ 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
+1. **Understand before acting** — Know what you're changing, why, and what it affects before you edit. State the reasoning when it isn't evident from the change itself; don't narrate routine edits
 2. **Don't lock onto the first explanation** — After finding a suspected cause, list >=2 alternative hypotheses before acting
 3. **Minimal change, minimal complexity** — No large-scale refactors unless explicitly requested. When proposing solutions, prefer the simplest approach that meets requirements. If a lightweight solution exists, choose it over a heavyweight one unless the user asks for more.
 4. **3 consecutive failures → pause and regroup** — Report current state, attempted solutions, and points of confusion. Fresh perspective from the user often unblocks what repetition cannot.

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

@@ -9,14 +9,3 @@ Before modifying this file, confirm each of the following:
 - [ ] **I know how to verify after the change** — Per 07-integrity: run it, paste output, or mark unverified
 
 If any item is uncertain, resolving it first will make the edit smoother and avoid rework.
-
-## Post-Edit Checklist
-
-After writing or modifying code, before running it:
-
-- [ ] **Syntax check** — Does the code compile/parse without errors? (e.g., `python -m py_compile`, `tsc --noEmit`, `go vet`)
-- [ ] **Obvious errors** — No undefined variables, no wrong function signatures, no missing imports?
-- [ ] **API correctness** — Are function/method calls using the right arguments, types, and return values? If unsure, read the API docs or source first.
-- [ ] **Edge cases in your changes** — Did you handle empty inputs, None/null, off-by-one, etc.?
-
-A 10-second syntax check catches errors that would otherwise cost 10-minute debug cycles. Always worth it.

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

@@ -5,13 +5,12 @@
 - During debugging → update `docs/debug-log.md` (hypotheses, evidence, elimination results)
 - When making architectural decisions → record the decision and reasoning in progress.md
 
-### Parallel Execution
-- **Don't do everything single-threaded.** When a task has independent parts, use subagents or tasks to work on them in parallel. Examples:
-  - Investigating 3 debug hypotheses → spawn 3 agents, each verifies one
-  - Researching multiple files/modules → one agent per area, summarize results
-  - Independent subtasks in a plan → parallel agents for non-dependent steps
-- **Keep the main conversation for decisions, not research.** Subagents do the reading and exploring; the main conversation synthesizes and decides.
-- **When to parallelize:** if two subtasks don't depend on each other's output, they should run concurrently, not sequentially.
+### Delegation
+- **Delegate for isolation and genuine parallelism — not by default.** A subagent earns its cost when the work is sizeable, genuinely independent, and would otherwise flood the main conversation: a wide multi-file investigation, one agent per area of a broad survey.
+- **Work directly** on single-file edits, short sequences of tool calls, and anything where you need to carry context across steps. If you can finish it in a handful of tool calls, don't delegate it.
+- **Never delegate verification.** Don't spawn agents to double-check or re-verify your own work.
+- **Keep spawn counts low.** If one subagent can do the job, use one rather than several.
+- **Keep the main conversation for decisions.** When you do delegate research, the subagent reads and reports; the main conversation synthesizes and decides.
 
 ### Compact Strategy
 - Avoid proactively suggesting compacting or warning about "context running low." The system auto-compacts when context hits 0% — there is no advance warning, and you cannot see the percentage. With 200K-1M context, most sessions never hit the limit. The urge to say "this session is getting long" is understandable in a long session, but it's not based on information you have access to — the system will handle it. Focus on the work.

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

@@ -77,16 +77,3 @@ 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/skills/retro/SKILL.md

@@ -3,11 +3,11 @@ 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.
+Find friction. Remove friction. Record what the rules actually caught.
 
 ## 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:
+Quickly scan what just happened — `git log --oneline -10` and any hook triggers you remember. Then output in this format:
 
 ```
 RETRO — [date]
@@ -15,6 +15,9 @@ RETRO — [date]
 Friction:
 - [what got in the way] → fix: [specific actionable change]
 
+Saves:
+- [rule/hook] caught [the specific real problem] — without it: [what would have shipped]
+
 Insights:
 - [something learned that should survive this session]
 
@@ -23,18 +26,24 @@ Framework:
 ```
 
 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 actionable friction** — 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.
+- **Keep it short** — 3-5 items per section max. If you can't find friction, say "no friction found" and move on. An empty friction list is a good sign.
+
+Saves — read this before filling that section in:
+- **A save is not "what went well."** Log a save only when a rule or hook *changed the outcome*: it caught a real mistake, blocked a real loss, or stopped a wrong turn that was already in motion. "The rules kept me disciplined" is not a save. "git-guard blocked `git reset --hard` while 40 min of uncommitted work was in the tree" is.
+- **"no saves" is a real answer, and it is data.** Write it plainly rather than manufacturing one.
+- **Why this section exists:** friction is visible and saves are invisible — a rule that works silently suppresses the very failure it was written for, so the only naturally measurable signal is its cost. With cost-only data every rule eventually looks like pure overhead and gets cut, including the ones that are still load-bearing. The save log is what makes it possible to judge, later and with evidence, whether a given rule still earns its place.
 
 ## After output
 
-Present the items. User decides:
+Append both Friction and Saves to a `## Rule Ledger` section in `docs/progress.md` (create the section at the end of the file if it isn't there yet), one dated line each. This accumulates the record across sessions — a single retro proves nothing, twenty of them decide which rules stay.
+
+Then 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.
+Do not auto-apply fixes. Do not pad. Do not turn this into a report. (Appending to the ledger is not a fix — do that without asking.)

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

@@ -73,7 +73,7 @@ Rules:
 - 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.
+- **Note real dependencies** — Mark which steps depend on which. Don't annotate steps for parallel delegation by default; see 03-context-mgmt "Delegation" for when a subagent is actually warranted.
 
 ## Step 4: Self-review
 

package/templates/docs/progress.md

@@ -70,3 +70,25 @@
 | # | Decision | Reason | Impact Scope | Date |
 |---|----------|--------|-------------|------|
 | | | | | |
+
+---
+
+## Rule Ledger
+
+<!--
+Appended by /retro. Two columns of evidence about the discipline rules themselves:
+
+- SAVE  — a rule or hook changed the outcome: caught a real mistake, blocked a
+          real loss, stopped a wrong turn already in motion.
+- FRICTION — a rule or hook got in the way and cost time for no benefit.
+
+Why keep this: friction is visible, saves are invisible. A rule that works
+silently suppresses the very failure it was written for, so cost is the only
+signal that shows up on its own. Judging rules on cost alone eventually cuts the
+load-bearing ones. This ledger is the counterweight — with enough dated entries,
+"should this rule stay?" becomes a lookup instead of a guess.
+-->
+
+| Date | Kind | Rule / Hook | What happened |
+|------|------|-------------|---------------|
+| | | | |