continuous-improvement 3.16.0 → 3.18.0

package/package.json

@@ -1,18 +1,21 @@
 {
   "name": "continuous-improvement",
-  "version": "3.16.0",
-  "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts. Beginner: one /plugin install command. Expert: adds MCP tools and session hooks.",
+  "version": "3.18.0",
+  "description": "Claude Code that gets sharper every session: the persistent-memory and runtime-discipline layer built on the 7 Laws of AI Agent Discipline. It grounds every edit in real facts before it lands and, through the Mulahazah engine, turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts. Beginner: one /plugin install command. Expert: adds MCP tools and session hooks.",
   "keywords": [
     "claude-code",
+    "claude-code-plugin",
     "claude-code-skill",
+    "claude",
+    "anthropic",
     "ai-agent",
+    "ai-agents",
     "agent-skill",
     "ai-discipline",
     "mulahazah",
-    "instinct",
+    "instinct-learning",
     "hooks",
     "mcp",
-    "mcp-server",
     "github-action",
     "transcript-linter"
   ],
@@ -30,7 +33,9 @@
     "continuous-improvement": "bin/install.mjs",
     "ci-lint-transcript": "bin/lint-transcript.mjs",
     "ci": "bin/unified-cli.mjs",
-    "ci-plan-pack": "bin/plan-pack.mjs"
+    "ci-plan-pack": "bin/plan-pack.mjs",
+    "ci-audit-actions": "bin/audit-actions.mjs",
+    "ci-portfolio-health": "bin/portfolio-health.mjs"
   },
   "scripts": {
     "build": "tsc -p tsconfig.json && node bin/generate-plugin-manifests.mjs && node -e \"const fs=require('node:fs'); for (const f of fs.readdirSync('bin')) { if (f.endsWith('.mjs')) fs.chmodSync('bin/'+f, 0o755); } for (const f of fs.readdirSync('hooks')) { if (f.endsWith('.mjs')) fs.chmodSync('hooks/'+f, 0o755); } for (const f of fs.readdirSync('lib')) { if (f.endsWith('.mjs')) fs.chmodSync('lib/'+f, 0o755); } for (const f of fs.readdirSync('plugins/continuous-improvement/bin')) { if (f.endsWith('.mjs')) fs.chmodSync('plugins/continuous-improvement/bin/'+f, 0o755); } for (const f of fs.readdirSync('plugins/continuous-improvement/lib')) { if (f.endsWith('.mjs')) fs.chmodSync('plugins/continuous-improvement/lib/'+f, 0o755); } for (const f of fs.readdirSync('plugins/continuous-improvement/hooks')) { if (f.endsWith('.mjs')) fs.chmodSync('plugins/continuous-improvement/hooks/'+f, 0o755); } for (const f of fs.readdirSync('scripts')) { if (f.endsWith('.mjs')) fs.chmodSync('scripts/'+f, 0o755); } for (const f of fs.readdirSync('synthetic-checks')) { if (f.endsWith('.mjs')) fs.chmodSync('synthetic-checks/'+f, 0o755); } \"",
@@ -45,6 +50,7 @@
     "verify:skill-law-tag": "node bin/check-skill-law-tag.mjs",
     "verify:skill-count": "node bin/check-skill-count.mjs",
     "verify:skill-count-prose": "node bin/check-skill-count-prose.mjs",
+    "verify:command-count": "node bin/check-command-count.mjs",
     "verify:docs-substrings": "node bin/check-docs-substrings.mjs",
     "verify:everything-mirror": "node bin/check-everything-mirror.mjs",
     "verify:routing-targets": "node bin/check-routing-targets.mjs",
@@ -53,7 +59,7 @@
     "verify:scripts-citation-drift": "node bin/check-scripts-citation-drift.mjs",
     "verify:third-party-shape": "node bin/check-third-party-shape.mjs",
     "verify:tool-count": "node bin/check-tool-count.mjs",
-    "verify:all": "npm run verify:skill-mirror && npm run verify:skill-tiers && npm run verify:skill-law-tag && npm run verify:skill-count && npm run verify:skill-count-prose && npm run verify:docs-substrings && npm run verify:everything-mirror && npm run verify:routing-targets && npm run verify:doc-runtime-claims && npm run verify:test-imports-only && npm run verify:scripts-citation-drift && npm run verify:third-party-shape && npm run verify:tool-count && npm run typecheck"
+    "verify:all": "npm run verify:skill-mirror && npm run verify:skill-tiers && npm run verify:skill-law-tag && npm run verify:skill-count && npm run verify:skill-count-prose && npm run verify:command-count && npm run verify:docs-substrings && npm run verify:everything-mirror && npm run verify:routing-targets && npm run verify:doc-runtime-claims && npm run verify:test-imports-only && npm run verify:scripts-citation-drift && npm run verify:third-party-shape && npm run verify:tool-count && npm run typecheck"
   },
   "files": [
     ".claude-plugin/",

package/plugins/beginner.json

@@ -1,6 +1,6 @@
 {
   "name": "continuous-improvement",
-  "version": "3.16.0",
+  "version": "3.18.0",
   "mode": "beginner",
   "description": "Beginner mode: see what your agent learned, list its instincts, and request a session reflection. Bundles three grounding skills (gateguard, tdd-workflow, verification-loop) so research, memory, tests, and verification happen by default — every edit starts from facts, not guesses.",
   "tools": [

package/plugins/continuous-improvement/.claude-plugin/marketplace.json

@@ -7,8 +7,8 @@
   "plugins": [
     {
       "name": "continuous-improvement",
-      "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
-      "version": "3.16.0",
+      "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
+      "version": "3.18.0",
       "source": "./",
       "author": {
         "name": "naimkatiman"

package/plugins/continuous-improvement/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "continuous-improvement",
-  "version": "3.16.0",
-  "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
+  "version": "3.18.0",
+  "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
   "author": {
     "name": "naimkatiman",
     "url": "https://github.com/naimkatiman"

package/plugins/continuous-improvement/commands/intent-driven-development.md

@@ -0,0 +1,36 @@
+---
+name: intent-driven-development
+description: "Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation. Enforces Law 2 (Plan Is Sacred)."
+argument-hint: "[the change to scope into acceptance criteria]"
+---
+
+# /intent-driven-development
+
+Convert an ambiguous or high-impact request into observable acceptance criteria before you build, so "done" is a fact two people would agree on and the agreed plan is held sacred (Law 2). Produce useful criteria without ceremony: inspect context first, expose only genuine ambiguity, choose verification that fits the risk.
+
+## Trigger phrases
+
+- `/intent-driven-development`
+- `/intent-driven-development <the change>`
+- "define acceptance criteria"
+- "scope this change" / "make this testable"
+- "de-risk this before we build it"
+- "prepare implementation requirements for another agent"
+
+Do not trigger for trivial edits, one-line fixes, active debugging, code review, or requests whose acceptance conditions are already clear.
+
+## What happens
+
+1. **Inspect and scope.** Read the repo, docs, schemas, and tests for technical facts before asking. Capture product or business constraints only from the user or a product artifact, never inferred from code.
+2. **Choose depth.** Quick Capture (3-7 criteria, low or moderate risk) or Full Acceptance Brief (security, data, migration, cross-system, or handoff).
+3. **Write criteria.** Each `AC-NNN` names a scenario, a trigger, an expected observable result, a prohibited side effect when meaningful, a verification method, and a priority. No vague words without defined evidence.
+4. **Proceed or hand off.** Record the criteria and continue for a clear request; present blockers and wait when a change is risky. If a criterion cannot be met mid-build, mark it `[revised]`, increment the revision, and re-present only the changed criteria.
+
+## Skill file
+
+Full behavior is defined in [`skills/intent-driven-development.md`](../skills/intent-driven-development.md).
+
+## Pairs with
+
+- `/grill-me`: grill-me clarifies a fuzzy input; this skill turns the agreed intent into verifiable criteria.
+- `/roast`: roast validates the idea, then scope the survivor into acceptance criteria.

package/plugins/continuous-improvement/commands/reconcile.md

@@ -1,22 +1,22 @@
 ---
 name: reconcile
-description: Establish git ground truth (branch, status, stashes, worktrees, ahead/behind) before any mutation, halt on protected or destructive operations, and verify a push actually landed. Enforces Law 1 (Research Before Executing).
+description: Establish git ground truth (branch, status, stashes, worktrees, ahead/behind) before any mutation, halt on protected or destructive operations, then carry the known-good state through a single-concern commit, a push, an open PR, and — after the PR merges — a fast-forward of the default branch. Enforces Law 1 (Research Before Executing).
 ---
 
-# /reconcile — Ground-Truth Git State Before You Touch It
+# /reconcile — Ground Truth, Then Commit, Push, and Open the PR
 
-Read the repo's real state before acting on it: a branch that shifted, a push that did not land, or another session mid-merge will burn a whole session if you assume instead of check.
+Read the repo's real state before acting on it: a branch that shifted, a push that did not land, or another session mid-merge will burn a whole session if you assume instead of check. Once the state is known, `/reconcile` carries the work through to an open PR and back to an up-to-date default branch.
 
 ## What it does
 
-Snapshots the full git state in one pass, detects a concurrent writer, classifies the upstream relationship, then acts only on the known state — stopping at every operation that is hard to reverse. Backed by the `reconcile` skill.
+Snapshots the full git state in one pass, detects a concurrent writer, classifies the upstream relationship, then acts only on the known state — stopping at every operation that is hard to reverse. When work is ready, it stages by filename, commits one concern, pushes a feature branch, verifies the push landed, and opens a PR. After a human merges, it fast-forwards the default branch and checks it out. Backed by the `reconcile` skill.
 
 ## Establish ground truth
 
 ```
 git branch --show-current
 git status --porcelain=v1                     # but trust git diff --stat for real drift (autocrlf)
-git rev-list --left-right --count @{u}...HEAD  # behind / ahead
+git rev-list --left-right --count '@{u}...HEAD'  # behind / ahead (quote the ref — bare @{u} trips the Bash parser)
 git stash list
 git worktree list
 ls .git/MERGE_HEAD .git/rebase-merge .git/rebase-apply 2>/dev/null  # in-progress op = another actor; do not race
@@ -31,7 +31,22 @@ behind    -> git pull --ff-only
 diverged  -> rebase/merge deliberately; never blind --force
 ```
 
-STOP for authorization before: pushing to a protected branch (this repo = feature branch + PR, never direct push to main), `--force` / `--force-with-lease`, `reset --hard`, `clean -fd`, or removing a dirty worktree. Never stage with `git add -A` on a Windows autocrlf tree (it commits phantom line-ending-only changes) — stage by explicit filename.
+STOP for authorization before: pushing to a protected branch (this repo = feature branch + PR, never direct push to main), merging the PR you opened, `--force` / `--force-with-lease`, `reset --hard`, `clean -fd`, force-deleting a branch (`branch -D`), or removing a dirty worktree. Never stage with `git add -A` on a Windows autocrlf tree (it commits phantom line-ending-only changes) — stage by explicit filename.
+
+## Commit and open the PR (self-contained)
+
+Reimplements the commit → push → PR tail inline, so it works with no companion plugin installed:
+
+```
+git switch main && git pull --ff-only origin main   # branch from a fresh base
+git switch -c <type>/<slug>                          # only if not already on a feature branch
+git add path/one path/two                            # stage by name, one concern
+git commit -m "feat(scope): <observable outcome>"    # single-line -m; never a multi-line here-doc on Windows
+git push -u origin <type>/<slug>
+gh pr create --fill --base main                      # open one PR, then STOP — the merge is a human decision
+```
+
+`/reconcile` never merges the PR, never uses `--admin` / `--force` / `--no-verify`, never auto-merges on green CI, and never deploys.
 
 ## Verify the push landed
 
@@ -39,9 +54,21 @@ STOP for authorization before: pushing to a protected branch (this repo = featur
 git ls-remote origin refs/heads/<branch>   # remote tip must equal local HEAD, else it did not land
 ```
 
+## Sync the default branch after the PR merges
+
+"Latest work on main" is true only once the PR merges, and on a protected branch that merge is a human action. After it lands:
+
+```
+git switch main                        # or master
+git pull --ff-only origin main         # fast-forward only; if it will not ff, main diverged — re-survey, do not force
+git rev-parse HEAD                     # confirm this equals the squash-merge SHA
+git branch -d <type>/<slug>            # delete the merged feature branch (safe -d, never -D)
+```
+
 ## Pairs with
 
 - **`reconcile`** skill — the discipline this command runs.
 - **`gateguard`** / **`safety-guard`** — runtime + destructive-op guardrails.
 - **`recall`** — recall whether the same git op failed here before.
-- **`audit`** — the loop that often produces the fix `reconcile` then ships.
+- **`audit`** — the loop that often produces the fix `/reconcile` then ships.
+- **`/ship`** — the TDD-gated single-defect variant; `commit-commands:commit-push-pr` is the external-plugin equivalent of the commit → PR tail.

package/plugins/continuous-improvement/hooks/gateguard.mjs

@@ -35,7 +35,7 @@
 import { readFileSync } from "node:fs";
 import { dirname, join } from "node:path";
 import { fileURLToPath } from "node:url";
-import { MAX_CLEARED_FILES, canonicalizeFileKey, isCapReached, isFileCleared, loadState, markFileCleared, resolveSessionDir, saveState, } from "../lib/gateguard-state.mjs";
+import { MAX_CLEARED_FILES, canonicalizeFileKey, canonicalizeProjectRoot, isCapReached, isFileCleared, loadState, markFileCleared, resolveProjectRoot, resolveSessionDir, saveState, } from "../lib/gateguard-state.mjs";
 const TOOL_ROUTE = {
     Read: "allow",
     Grep: "allow",
@@ -69,8 +69,20 @@ const DESTRUCTIVE_PATTERNS = [
     "Remove-Item -Recurse",
     "Remove-Item -Force",
 ];
+// Flags whose VALUE is human prose (a commit message, a PR body) or a filename —
+// never a command to execute. Their contents must not trip the destructive scan:
+// `git commit -m "drop the stale format helper"` and `gh pr create --body "…"`
+// were stranding finished work on their own wording. `-c` is deliberately
+// EXCLUDED — `bash -c "rm -rf /"` carries a real command and must still gate.
+const MESSAGE_FLAG_RE = /(^|\s)(-m|--message|-F|--file|--body|--body-file|--title|--notes|-C|--reuse-message)(=|\s+)('[^']*'|"[^"]*"|\S+)/g;
+// Blank the value of every message/body flag so only executable command syntax
+// remains for the destructive-pattern scan. The flag itself is preserved so a
+// flag like `-F` never accidentally merges with its neighbours.
+function stripMessageArgs(command) {
+    return command.replace(MESSAGE_FLAG_RE, (_match, lead, flag) => `${lead}${flag} `);
+}
 function isDestructiveBash(command) {
-    const lower = command.toLowerCase();
+    const lower = stripMessageArgs(command).toLowerCase();
     return DESTRUCTIVE_PATTERNS.some((p) => lower.includes(p.toLowerCase()));
 }
 function classifyTool(toolName, toolInput) {
@@ -95,6 +107,60 @@ function extractFilePaths(toolInput) {
         return [toolInput.command];
     return [];
 }
+// --- Path exclusions -------------------------------------------------------
+// Opt-in: skip the fact-forcing gate for low-risk paths a user edits
+// constantly (an LLM-maintained prose wiki, a generated scratch dir). Set the
+// CI_GATEGUARD_EXCLUDE env var to a comma-separated list of path substrings;
+// each is matched case-insensitively against the forward-slash-normalized file
+// path. Unset/empty (the default) changes nothing — every mutating file call is
+// gated exactly as before. A call whose targets mix excluded and non-excluded
+// paths still gates the non-excluded ones.
+const EXCLUDE_FRAGMENTS = String(process.env.CI_GATEGUARD_EXCLUDE ?? "")
+    .split(",")
+    .map((fragment) => fragment.trim().replace(/\\/g, "/").toLowerCase())
+    .filter((fragment) => fragment !== "");
+function isExcludedPath(filePath) {
+    if (EXCLUDE_FRAGMENTS.length === 0 || typeof filePath !== "string" || filePath === "") {
+        return false;
+    }
+    const normalized = filePath.replace(/\\/g, "/").toLowerCase();
+    return EXCLUDE_FRAGMENTS.some((fragment) => normalized.includes(fragment));
+}
+// --- Target lock (opt-in) --------------------------------------------------
+// A fact-list can't catch a wrong-repo / wrong-worktree write — you can present
+// perfect facts about the wrong file. CI_GATEGUARD_TARGET_LOCK=block denies a
+// mutating call whose ABSOLUTE target canonicalizes outside the session project
+// root. Default (unset) checks nothing, so existing sessions — including
+// legitimate out-of-root edits to ~/.claude or /tmp — are unaffected. This is
+// the warn-first rollout: ship non-enforcing, flip to block per session.
+const TARGET_LOCK_ON = String(process.env.CI_GATEGUARD_TARGET_LOCK ?? "").toLowerCase() === "block";
+// Relative paths resolve under cwd (= the project root) and always pass; only an
+// absolute path into a different tree can be out-of-root. Drive-letter (d:/,
+// D:\), POSIX-absolute (/x), and UNC (\\host) forms all count as absolute.
+function isAbsolutePathString(p) {
+    return /^[A-Za-z]:[\\/]/.test(p) || p.startsWith("/") || p.startsWith("\\\\");
+}
+function isTargetOutsideRoot(filePath, projectRoot) {
+    if (!isAbsolutePathString(filePath))
+        return false;
+    const root = canonicalizeProjectRoot(projectRoot);
+    if (root === "global" || root === "")
+        return false; // no known root — do not guess
+    const target = canonicalizeFileKey(filePath);
+    return target !== root && !target.startsWith(`${root}/`);
+}
+function buildTargetLockReason(strayPath, projectRoot) {
+    return [
+        `Target is outside the session project root — refusing a possible wrong-repo / wrong-worktree write.`,
+        "",
+        `  Target: ${strayPath.replace(/\\/g, "/")}`,
+        `  Session root: ${canonicalizeProjectRoot(projectRoot)}`,
+        "",
+        "If this is intentional, confirm you are in the right worktree (cwd / CLAUDE_PROJECT_DIR),",
+        "or unset CI_GATEGUARD_TARGET_LOCK for this session. Target lock is opt-in; it fires only",
+        "when CI_GATEGUARD_TARGET_LOCK=block.",
+    ].join("\n");
+}
 // The call site only reads this inside the block branch, where at least one
 // path is uncleared; an all-cleared batch returns "" and is never consumed.
 function firstUnclearedFilePath(toolInput, state) {
@@ -144,6 +210,47 @@ function buildMutatingFileReason(toolName, filePaths, stateFilePath) {
         "  `_gateguard_facts_presented: true`; Claude Code's strict schema rejects that, so use A or B.)",
     ].join("\n");
 }
+function findUnquotedBraceRef(command) {
+    let quote = null;
+    for (let i = 0; i < command.length; i++) {
+        const ch = command[i];
+        if (quote) {
+            if (ch === quote)
+                quote = null;
+            continue;
+        }
+        if (ch === '"' || ch === "'") {
+            quote = ch;
+            continue;
+        }
+        if (ch === "@" && command[i + 1] === "{") {
+            // Expand to the whitespace-delimited word that carries this @{ ref, then
+            // single-quote that whole word in the suggested fix.
+            let wordStart = i;
+            while (wordStart > 0 && !/\s/.test(command[wordStart - 1]))
+                wordStart--;
+            let wordEnd = i;
+            while (wordEnd < command.length && !/\s/.test(command[wordEnd]))
+                wordEnd++;
+            const word = command.slice(wordStart, wordEnd);
+            const braceEnd = command.indexOf("}", i);
+            const ref = braceEnd === -1 ? command.slice(i, wordEnd) : command.slice(i, braceEnd + 1);
+            const fixed = `${command.slice(0, wordStart)}'${word}'${command.slice(wordEnd)}`;
+            return { ref, fixed };
+        }
+    }
+    return null;
+}
+function buildBraceRefReason(hit) {
+    return [
+        `Unquoted git ref ${hit.ref} — Claude Code's Bash parser trips on the braces and blocks this`,
+        "post-hoc, costing a retry. Quote the ref and run the SAME command:",
+        "",
+        `  ${hit.fixed}`,
+        "",
+        "Single quotes stop the shell from touching the braces; git reads the ref as-is.",
+    ].join("\n");
+}
 function buildDestructiveBashReason(command) {
     return [
         `Destructive command requested: ${command}`,
@@ -199,6 +306,16 @@ function main() {
     const toolName = typeof payload.tool_name === "string" ? payload.tool_name : "";
     const toolInput = payload.tool_input ?? {};
     const gate = classifyTool(toolName, toolInput);
+    // Unquoted @{…} refs trip the built-in Bash parser — catch them first, for
+    // both routine and destructive commands, so the quoted fix surfaces before the
+    // opaque post-hoc block (and before the destructive rollback demand).
+    if (toolName === "Bash" && typeof toolInput.command === "string") {
+        const braceHit = findUnquotedBraceRef(toolInput.command);
+        if (braceHit) {
+            emitDeny(buildBraceRefReason(braceHit));
+            return;
+        }
+    }
     if (gate === "allow") {
         emitAllow();
         return;
@@ -215,7 +332,24 @@ function main() {
     const sessionDir = resolveSessionDir(sessionId);
     const stateFilePath = join(sessionDir, "gateguard-session.json");
     const state = loadState(sessionDir);
-    const filePaths = extractFilePaths(toolInput);
+    const allTargetPaths = extractFilePaths(toolInput);
+    const filePaths = allTargetPaths.filter((path) => !isExcludedPath(path));
+    if (allTargetPaths.length > 0 && filePaths.length === 0) {
+        emitAllow(); // every target is under a CI_GATEGUARD_EXCLUDE path; skip the gate
+        return;
+    }
+    // Target lock runs before the fact gate and independent of clearance: a
+    // wrong-repo write is wrong even with perfect facts. Excluded paths were
+    // already filtered out above, so an explicitly-excluded scratch dir outside
+    // the root is never target-locked.
+    if (TARGET_LOCK_ON) {
+        const projectRoot = resolveProjectRoot();
+        const stray = filePaths.find((path) => isTargetOutsideRoot(path, projectRoot));
+        if (stray) {
+            emitDeny(buildTargetLockReason(stray, projectRoot));
+            return;
+        }
+    }
     const filePath = firstUnclearedFilePath(toolInput, state);
     const factsFlagged = toolInput._gateguard_facts_presented === true;
     const alreadyCleared = filePaths.length > 0 && filePaths.every((path) => isFileCleared(state, path));

package/plugins/continuous-improvement/lib/gateguard-state.mjs

@@ -59,7 +59,11 @@ function sanitizeSessionId(sessionId) {
         return "";
     return sessionId.replace(/[^A-Za-z0-9_-]/g, "_").slice(0, 64);
 }
-function resolveProjectRoot() {
+// Exported for the target-lock gate (RISA 2 / G2): the hook compares a mutating
+// call's absolute target against this root to catch wrong-repo / wrong-worktree
+// writes. Returns "global" when no CLAUDE_PROJECT_DIR and no git toplevel — the
+// caller treats that as "no known root, do not guess".
+export function resolveProjectRoot() {
     const fromEnv = process.env.CLAUDE_PROJECT_DIR;
     if (fromEnv)
         return fromEnv;

package/plugins/continuous-improvement/lib/plugin-metadata.mjs

@@ -26,7 +26,7 @@ const KEYWORDS = [
     "transcript-linter",
 ];
 const CLAUDE_PLUGIN_CATEGORY = "productivity";
-const SHARED_PLUGIN_DESCRIPTION = "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.";
+const SHARED_PLUGIN_DESCRIPTION = "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.";
 // Four vendored upstream companions registered alongside the CI plugin.
 // Each entry points at a pinned-SHA snapshot under third-party/<name>/.
 // See third-party/MANIFEST.md for refresh recipes and per-snapshot

package/plugins/continuous-improvement/skills/README.md

@@ -29,7 +29,8 @@ skill set on disk.
 - `grill-me` — Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Interview the user relentlessly about a plan or design until shared understanding is reached, resolving every branch of the decision tree before any code is written. Ported from mattpocock/skills under MIT.
 - `grill-with-docs` — Enforces Law 1 (Research Before Executing) and Law 7 (Learn From Every Session) of the 7 Laws of AI Agent Discipline. Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates CONTEXT.md + ADRs inline as decisions crystallise. Ported from mattpocock/skills under MIT.
 - `handoff` — Enforces Law 5 (Reflect After Every Session) of the 7 Laws of AI Agent Discipline. Compact the current conversation into a handoff document for another agent to pick up. Ported from mattpocock/skills under MIT.
-- `reconcile` — Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Establishes git ground truth — branch, status, stashes, worktrees, ahead/behind — before any mutation, halts on protected or destructive operations, and verifies a push actually landed instead of assuming it did.
+- `intent-driven-development` — Enforces Law 2 (Plan Is Sacred) of the 7 Laws of AI Agent Discipline. Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit in/out scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation, so the plan that gets built is the plan that was agreed, not an invented default. Use when clarifying a feature, defining acceptance criteria, de-risking a security/data/migration/integration change, or preparing implementation requirements for another agent. Do not trigger for trivial edits, straightforward fixes, active debugging, or code review.
+- `reconcile` — Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Establishes git ground truth — branch, status, stashes, worktrees, ahead/behind — before any mutation, halts on protected or destructive operations, then carries the known-good state through to a landed PR: stage by filename, commit one concern, push the feature branch, verify the push landed, open the PR, and after the PR merges fast-forward the default branch and check it out.
 - `recovery-classification` — Enforces Law 4 (Verify Before Reporting) of the 7 Laws of AI Agent Discipline. After any failure in the verification ladder or auto-loop, classify the failure class before retrying — provider, tool-schema, deterministic-policy, git, worktree, runtime — so retry-vs-pause-vs-self-heal-vs-stop is an intentional decision, not a generic 'try again'.
 - `roast` — Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Convene a 5-persona adversarial council (Contrarian, Expansionist, Logician, Researcher, Buyer) that attacks an idea from every angle, then a Judge returns one GO / RESHAPE / KILL verdict plus the cheapest 48-hour test to de-risk it — so you pressure-test an idea before sinking time into building the wrong thing.
 - `safety-guard` — Enforces Law 3 (One Thing at a Time) of the 7 Laws of AI Agent Discipline by scoping edits to a directory and blocking destructive shell commands. Use this skill to prevent destructive operations when working on production systems or running agents autonomously.

package/plugins/continuous-improvement/skills/gateguard/SKILL.md

@@ -150,6 +150,14 @@ The block reason prints the exact `gateguard-session.json` path and the clearanc
 
 The inline `_gateguard_facts_presented: true` retry still works on harnesses that forward unknown tool params, but Claude Code's strict tool schema (`additionalProperties: false`) rejects it with `InputValidationError` — use one of the above on Claude Code.
 
+### Excluding low-risk paths
+
+Set the `CI_GATEGUARD_EXCLUDE` environment variable to opt specific low-risk paths out of the gate entirely — an LLM-maintained prose wiki, a generated scratch directory, anything where the fact-forcing pause costs more than it saves. The value is a comma-separated list of path substrings, each matched case-insensitively against the forward-slash-normalized file path, so `/mywiki/` excludes `D:\Vault\MyWiki\notes\x.md`. Unset or empty (the default) changes nothing: every mutating file call is gated exactly as before, and a call that touches a mix of excluded and non-excluded paths still gates the non-excluded ones. Set it per project in `.claude/settings.json` under `env`, or globally in `~/.claude/settings.json`.
+
+### Locking edits to the current repo
+
+A fact-list can't catch a wrong-repo or wrong-worktree write — you can present perfect facts about the wrong file, in the wrong checkout. Set `CI_GATEGUARD_TARGET_LOCK=block` to make the runtime hook (`hooks/gateguard.mjs`) refuse any mutating call whose **absolute** target canonicalizes outside the session project root (`CLAUDE_PROJECT_DIR`, or the git toplevel). Relative paths resolve under the current directory (= the root) and always pass; only an absolute path into a different tree is denied, and the deny reason names both the stray target and the expected root. This runs before the fact gate and independent of clearance — a wrong-repo write is wrong even with facts. Unset (the default) checks nothing, so legitimate out-of-root edits (`~/.claude`, a `/tmp` scratch file, a sibling repo) are unaffected; turn it on per session in a multi-worktree or headless run where cross-repo writes are the real risk. Paths already covered by `CI_GATEGUARD_EXCLUDE` are never target-locked.
+
 ### Limitations and guarantees
 
 - **Honor system.** Clearance is recorded by `ci_gateguard_clear`, the `gateguard-clear.mjs` CLI, a manual state-file write, or the inline `_gateguard_facts_presented` flag where the harness allows it (see "Clearing the gate" above). The hook can't verify the investigation actually happened; the 50-file cap — counted per session — bounds damage from stuck loops or rogue agents.
@@ -175,6 +183,8 @@ The standalone `gateguard-ai` Python/CLI package referenced in earlier drafts of
 - Let the gate fire naturally. Don't try to pre-answer the gate questions — the investigation itself is what improves quality.
 - Customize gate messages for your domain. If your project has specific conventions, add them to the gate prompts.
 - Use `.gateguard.yml` to ignore paths like `.venv/`, `node_modules/`, `.git/`.
+- For the shipped runtime hook, set `CI_GATEGUARD_EXCLUDE` (comma-separated path substrings) to exclude low-risk paths from the gate — see [Excluding low-risk paths](#excluding-low-risk-paths).
+- In multi-worktree or headless runs, set `CI_GATEGUARD_TARGET_LOCK=block` so a write into the wrong repo/worktree is refused — see [Locking edits to the current repo](#locking-edits-to-the-current-repo).
 
 ## Related Skills
 

package/plugins/continuous-improvement/skills/intent-driven-development/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: intent-driven-development
+tier: "2"
+description: "Enforces Law 2 (Plan Is Sacred) of the 7 Laws of AI Agent Discipline. Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit in/out scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation, so the plan that gets built is the plan that was agreed, not an invented default. Use when clarifying a feature, defining acceptance criteria, de-risking a security/data/migration/integration change, or preparing implementation requirements for another agent. Do not trigger for trivial edits, straightforward fixes, active debugging, or code review."
+origin: continuous-improvement
+user-invocable: true
+argument-hint: "[the change to scope into acceptance criteria]"
+---
+
+# /intent-driven-development: scope the change before you build it
+
+Law 2 says the plan is sacred: once a goal and its acceptance conditions are agreed, you do not silently drift from them. The cheapest way to honor that is to make the plan verifiable in the first place. A goal phrased as "make export work" cannot be held sacred because nobody can tell when it is met. This skill converts an ambiguous or high-impact request into observable acceptance criteria (`AC-001`, `AC-002`, ...) with named verification methods, so "done" is a fact two people would agree on, and a criterion can never be quietly dropped mid-build.
+
+It produces useful criteria without turning specification into ceremony: inspect available context first, expose only genuine ambiguity, and choose verification that fits the work and its risk.
+
+## When to activate
+
+- The user asks to clarify a feature, define acceptance criteria, or de-risk a change before implementation.
+- The request touches security, authentication, persistent data, migrations, external APIs, or compliance.
+- The user wants a handoff artifact another agent or team can implement without inventing requirements.
+- The request is ambiguous enough that the expected outcome is not yet observable or testable.
+- The user types `/intent-driven-development`, "define acceptance criteria", "scope this change", or "make this testable".
+
+Do not activate for trivial edits, one-line fixes, active debugging, code review, or implementation requests whose acceptance conditions are already clear.
+
+## How it works
+
+1. **Inspect context first.** Read the repository, docs, schemas, and test infrastructure for technical facts before asking any question. Treat product and business constraints as something only the user or a product artifact can supply.
+2. **Choose depth.** Quick Capture (3-7 criteria, low or moderate risk) or Full Acceptance Brief (security, data, migration, cross-system, or handoff).
+3. **Ask minimally.** Only ask questions whose answers cannot be inferred and that materially change scope or behavior. Group related questions into one batch.
+4. Write observable criteria. Each AC-NNN names a scenario, a trigger, an expected observable result, a prohibited side effect when meaningful, a verification method, and a priority. Do not use "correctly" or "securely" without defined evidence.
+5. **Proceed or hand off.** For a clear request with no blocking risk, record the criteria and continue. For a risky change, present the blockers and wait for confirmation.
+6. **Hold the plan sacred.** If a criterion cannot be met due to a constraint found mid-build, do not silently drop or work around it. Mark it `[revised]`, state the constraint, adjust scope or verification, increment the revision number, and re-present only the changed criteria before continuing.
+
+## Operating rules
+
+1. Inspect available repository, docs, issue, design, and test context before asking for technical facts that can be discovered locally.
+2. Do not infer product or business constraints from code. Business rules, compliance obligations, contractual SLAs, pricing, data-retention policy, prioritization, and target users cannot be read from a repository. Record them as assumptions flagged for confirmation, never as discovered facts. The repository tells you how the system behaves today, not what the business requires it to do.
+3. Ask only questions whose answers are required and cannot be safely inferred.
+4. Do not block implementation by default. When the user has asked to implement a sufficiently clear change, record key assumptions and criteria briefly, then proceed or hand them to the implementation workflow.
+5. Require explicit confirmation before proceeding only when an unresolved decision could create material security exposure, data loss, irreversible migration, contractual or API breakage, meaningful cost, or destructive external action.
+6. Do not write an acceptance document into a repository, alter project files, create a branch, commit, or invoke another skill unless the user requests it or the active workflow requires it.
+7. Treat automated tests as evidence, not truth. Prefer automation when reliable and proportionate; allow manual UX, accessibility, security, legal, or operational verification where automation cannot establish the outcome.
+8. Never include real secrets, credentials, tokens, private keys, personal data, or production payloads in criteria, fixtures, examples, or saved artifacts. Use redacted or synthetic values.
+9. Do not run destructive tests, migrations, security probes, load tests, paid external calls, or operations against production data without explicit authorization and an identified safe environment.
+10. When a criterion cannot be satisfied due to a constraint discovered during implementation, update it (`[revised]`, state the constraint, adjust scope or verification), increment the revision, and re-present only the changed criteria. Require confirmation only if the revision changes a blocking decision or reduces a safety or correctness guarantee.
+
+## Choose the depth
+
+Use the smallest useful output.
+
+### Quick Capture
+
+For a clear but non-trivial change with low or moderate risk. Produce: Goal; In scope and out of scope; Assumptions; 3-7 acceptance criteria with verification methods; blocking questions if any. Do not delay implementation for approval unless a blocking risk exists or the user asked for a spec first.
+
+### Full Acceptance Brief
+
+For ambiguous, cross-system, security-sensitive, data-changing, migration, compliance, or high-cost changes, or when the user wants a handoff artifact. Produce the full template below and request confirmation for unresolved blocking decisions before risky implementation.
+
+### Existing specification review
+
+When the user already supplied a PRD, issue, plan, or criteria: review it instead of restarting discovery. Identify missing scope boundaries, unsafe assumptions, contradictions, and unverifiable requirements. Return corrected or supplemental criteria.
+
+## Write acceptance criteria
+
+Use `AC-001`, `AC-002`, and so on. Criteria and tests need not map one-to-one. For each applicable criterion include: scenario or starting condition; action or trigger; expected observable behavior; prohibited side effect when meaningful; verification method (automated test, integration check, manual UX review, accessibility check, security review, operational check, or stakeholder acceptance); environment or safety constraint when verification could affect data, services, cost, or secrets; priority (Required, Important, or Optional).
+
+Do not use "correctly", "securely", "fast", "intuitive", or "robust" without defining observable evidence or recording them as a human-review judgment.
+
+Cover only the boundaries that apply:
+
+| Category | Include when | Typical evidence |
+| --- | --- | --- |
+| Happy path | New or changed user-visible behavior | Successful workflow or state transition |
+| Validation | The change accepts input | Malformed or boundary value rejected without mutation |
+| Authorization/privacy | Data or actions have access boundaries | Denied access and no sensitive disclosure |
+| Persistence/migration | Stored data or schemas change | Backward read, migration, rollback, or backup behavior |
+| Compatibility | Public APIs, files, events, or clients may break | Existing contract or fixture stays valid |
+| Failure recovery | Network, service, or async failure exists | No partial state, or clear retry and degraded behavior |
+| Idempotency/concurrency | Repeats or simultaneous writes are plausible | No duplicate side effect or invalid final state |
+| Performance | A user or service threshold matters | Defined measurement conditions and threshold |
+| UX/accessibility | A person interacts with the result | Keyboard, feedback, error recovery, visual or manual review |
+
+## Output template (Full Acceptance Brief)
+
+Omit irrelevant sections for Quick Capture.
+
+```markdown
+# Acceptance Brief: <Change Name>
+
+**Status:** Draft | Approved | Implemented | Verified
+**Revision:** <number>
+**Prepared for:** <user/team/agent, when known>
+
+## Goal
+<One observable outcome sentence.>
+
+## Scope
+**In scope:** <behavior included>
+**Out of scope:** <adjacent work excluded>
+
+## Context
+**Discovered facts** (technical, verified from repository or artifact)
+**Product/business constraints** (supplied by user or artifact, never inferred from code, or "none supplied yet")
+**Assumptions** (unverified claims to confirm)
+**Dependencies and constraints**
+
+## Risk Review
+| Risk area | Applies? | Required handling |
+| --- | --- | --- |
+| Security/privacy | Yes/No | <redaction, authorization, review> |
+| Persistent data/migration | Yes/No | <compatibility, backup, rollback> |
+| External effects/cost | Yes/No | <sandbox, test environment, authorization> |
+| Compatibility/API | Yes/No | <contract to preserve or version> |
+| UX/accessibility | Yes/No | <manual or automated evidence> |
+
+## Acceptance Criteria
+### AC-001: <observable behavior>
+- **Scenario:** <starting condition>
+- **Action:** <single trigger>
+- **Expected:** <observable result>
+- **Must not:** <prohibited side effect, if applicable>
+- **Verification:** <method and intended evidence>
+- **Environment/safety:** <constraints, if applicable>
+- **Priority:** Required | Important | Optional
+
+## Blocking Decisions
+- [ ] <only decisions that prevent safe or correct progress>
+
+## Verification Plan
+| Criterion | Verification evidence | Status |
+| --- | --- | --- |
+| AC-001 | <test, check, or review command or evidence type> | Pending |
+```
+
+## Pass/fail rubric
+
+A brief passes only if every answer is "yes". Any "no" means revise before returning it.
+
+- [ ] Does every required criterion have a scenario, an observable expected result, and a named verification method?
+- [ ] Are vague terms ("correctly", "secure", "fast", "robust") either replaced with observable evidence or marked as human judgment?
+- [ ] Are product and business constraints listed as supplied or assumed, with none silently inferred from code?
+- [ ] Is scope explicit, with out-of-scope items named?
+- [ ] Are blocking decisions limited to choices that actually affect safety or correctness, not preferences?
+
+A failing criterion: `AC-001: The export works correctly and is secure.` (no scenario, no observable result, no verification, "correctly" and "secure" undefined). A passing one names the scenario, the expected result, the prohibited side effect, and the verification method, so two people would agree it was met.
+
+## How it fits the 7 Laws
+
+| Law | Role of this skill |
+|---|---|
+| Law 2 (Plan Is Sacred) | The acceptance brief **is** the sacred plan: observable criteria, explicit scope, and a `[revised]` protocol that forbids silently dropping or working around a criterion mid-build. |
+| Law 1 (Research Before Executing) | Rule 1 inspects repo, docs, schemas, and tests for technical facts before asking, and refuses to infer business rules from code. |
+| Law 4 (Verify Before Reporting) | Every criterion carries a named verification method and a pass/fail rubric, so "done" is falsifiable rather than asserted. |
+
+## Pairs with
+
+- [`grill-me`](./grill-me.md): interviews a fuzzy request to a shippable spec. Reach for `grill-me` when the input is unclear, then this skill to turn the agreed intent into verifiable criteria.
+- [`roast`](./roast.md): validates whether the idea should exist at all. Roast first, then scope the survivor into acceptance criteria.
+- [`goal-monitor`](./goal-monitor.md): the runtime drift gate. The `## Goal` and criteria this skill produces are what goal-monitor scores a session against.
+- [`verification-loop`](./verification-loop.md): runs the per-project verify ladder. The criteria's verification methods feed its evidence step.