continuous-improvement 3.23.0 → 3.24.0

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

@@ -34,7 +34,6 @@ skill set on disk.
 - `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.
 - `simplicity-review` — Enforces Law 4 (Verify Before Reporting) of the 7 Laws of AI Agent Discipline. Reviews the current diff for over-engineering (code that could reuse an existing file, a stdlib or native feature, or fewer lines) and reports trim findings without touching code, so 'it works' is never mistaken for 'it is the minimum that works'.
 - `skill-distillation` — Enforces Law 7 (Learn From Every Session) of the 7 Laws of AI Agent Discipline. Distills repeated successful tool sequences into reusable draft instincts, so a pattern that worked three times becomes a captured recipe instead of being re-derived from scratch every session.
 - `state-reconciliation` — Enforces Law 4 (Verify Before Reporting) of the 7 Laws of AI Agent Discipline. Pre-dispatch invariant: reconcile DB-vs-disk-vs-memory state before any unit runs, so a stale flag, missing artifact, or out-of-sync row never re-dispatches a unit that already completed or never started.

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

@@ -42,6 +42,8 @@ Before executing, state:
 - Build passes
 - You can explain what changed in one sentence
 
+"Done" is an audit, not a hope: settle the actual result against the Verification you stipulated in Law 2.
+
 ## Law 5: Reflect After Every Session
 
 After non-trivial tasks:
@@ -59,6 +61,8 @@ After non-trivial tasks:
 
 The "Rule to add" field feeds Law 7 — it becomes an instinct with 0.6 starting confidence.
 
+This block is the ledger: what worked and what failed are the session's gains and losses; the rule to add is what you carry into the session you will not be in.
+
 The "Iteration — Next best recommendations" field feeds Law 6. List the **top 3 ranked** core-development moves based on the current code state — what to build, fix, refactor, or investigate next so the feature/system advances. Item #1 is the strongest recommendation; #2 and #3 are alternative directions the user can pick from. NOT git plumbing (commit, push, PR), NOT pure CI ceremony (run tests, type-check), NOT deploy steps. Those belong in the end-of-run summary, not here.
 
 Format per item: `<verb> <object at path:line> (<why, one clause grounded in current context>)`.

package/plugins/continuous-improvement/skills/deploy-receipt/SKILL.md

@@ -157,7 +157,7 @@ The rollback command is **printed**, not run. The skill's job is to give the ope
 - `finishing-a-development-branch` (vendored, third-party/superpowers/) — runs first; reports the merge. This skill runs after.
 - `verification-loop` — same Law 4 family; this skill is the deploy-seam specialization
 - `proceed-with-the-recommendation` — routing-table row for "Merge / close branch" should pair `finishing-a-development-branch` with this skill when the project is auto-deploy
-- `safety-guard` — orthogonal; safety-guard prevents destructive ops, this verifies post-deploy state
+- `gateguard` — orthogonal; gateguard gates the destructive op, this verifies post-deploy state
 
 ## Close-the-Loop Rule
 

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

@@ -77,7 +77,7 @@ Before creating {file_path}, present these facts:
 
 ### Destructive Bash Gate (every destructive command)
 
-Triggers on: `rm -rf`, `git reset --hard`, `git push --force`, `drop table`, etc.
+Triggers on structured rules that ignore flag order and spelling — `rm` with any recursive plus any force flag (`rm -r -f`, `rm -Rf`, `rm --recursive --force`), `git clean` with a force flag and no dry run, `git checkout -- <path>` or `git checkout .`, `git restore <path>` unless it is `--staged` only, `find … -delete`, `git push` with a `+refspec`, `git stash drop|clear` — plus the original substring list (`rm -rf`, `git reset --hard`, `git push --force`, `git branch -D`, `drop table`, `truncate `, `Remove-Item -Recurse`, etc.). Each command is judged after `&&`, `||`, `|`, `;` splitting, and a commit message, PR body or title value is blanked first so prose never trips it. The deny reason prints `Matched rule: <id>` so a block is explainable; the classifier is `lib/destructive-bash.mjs`. Plain file writes through Bash (`cat > file`, `sed -i`) are deliberately not gated.
 
 ```
 1. List all files/data this command will modify or delete
@@ -154,10 +154,24 @@ The inline `_gateguard_facts_presented: true` retry still works on harnesses tha
 
 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`.
 
+An exclusion is never silent. When every target of a call is excluded, `hooks/gateguard.mjs` still allows it but prints one stderr line naming the fragment that matched (`gateguard: skipped by CI_GATEGUARD_EXCLUDE (fragment "docs/wiki" matched docs/wiki/page.md)`). A catch-all fragment that every path contains (`/`, `.`, any single character) is honoured too, but the line says what it really is: the file gate is off for this session. Destructive Bash is never excluded. If `/verify-install` reports the probe write went through, check this variable before concluding the hook is not wired.
+
 ### 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.
 
+### Migrating from `safety-guard` (retired 2026-08-07)
+
+`safety-guard` was a prose-only tier-2 skill describing three "modes" it never implemented — no hook, no command, no logger ever shipped with it. Every mode it described is already enforced here by the runtime hook (`hooks/gateguard.mjs`):
+
+| Retired `safety-guard` mode | What enforces it now |
+|---|---|
+| Careful — warn on `rm -rf`, `git push --force`, `git reset --hard`, `DROP TABLE`, `chmod 777`, `--no-verify` … | [Destructive Bash Gate](#destructive-bash-gate-every-destructive-command). Its pattern set is a superset of the retired watch list, and it blocks rather than warns. |
+| Freeze — restrict writes to one directory tree | `CI_GATEGUARD_TARGET_LOCK=block` (above). Canonicalizes the absolute target against the session project root and refuses strays — before the fact gate, independent of clearance. |
+| Guard — careful + freeze together | Both of the above; they compose. Narrow the surface further with `CI_GATEGUARD_EXCLUDE`. |
+
+If you previously opted into `safety-guard` for autonomous or production-adjacent runs, set `CI_GATEGUARD_TARGET_LOCK=block` for that session instead. That is a real refusal, not a checklist the agent can talk itself out of.
+
 ### 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.
@@ -188,5 +202,6 @@ The standalone `gateguard-ai` Python/CLI package referenced in earlier drafts of
 
 ## Related Skills
 
-- `safety-guard` — Runtime safety checks (complementary, not overlapping)
+- `worktree-safety` — validates the worktree root before a source write; this skill gates the write itself
+- `reconcile` — git ground truth before a destructive git action
 - `code-reviewer` — Post-edit review (GateGuard is pre-edit investigation)

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

@@ -177,6 +177,5 @@ git branch -d <type>/<slug>            # delete the merged feature branch (safe
 
 - **`recall`** (Law 1) — before a risky git op, recall whether the same operation failed on this repo before.
 - **`gateguard`** (Law 1) — the runtime gate (`hooks/gateguard.mjs`); `reconcile` is the procedure you run once a destructive git action is in play.
-- **`safety-guard`** — destructive-operation guardrails for production and autonomous runs.
 - **`audit`** (Law 4) — when an audit ends in a fix, `reconcile` is the safe path from branch to landed PR.
 - **`commit-commands:commit-push-pr`** — the external-plugin equivalent of the commit → push → PR tail; `reconcile` reimplements it inline so the flow works with no companion installed. For a TDD-gated single-defect variant, use `/ship`.

package/plugins/expert.json

@@ -1,6 +1,6 @@
 {
   "name": "continuous-improvement",
-  "version": "3.23.0",
+  "version": "3.24.0",
   "mode": "expert",
   "description": "Expert mode: tune confidence, manage instincts, and persist plans on disk. Adds safety, token-budget, and strategic-compact skills plus the /learn-eval command so long sessions stay sharp and learnings survive context resets.",
   "tools": [

package/skills/README.md

@@ -28,11 +28,10 @@ These add concrete enforcement to the 7 Laws. Tier-1 skills are the always-on mi
 
 ## Tier 2 — additional skills for **expert** mode
 
-Tier-2 skills layer on top of tier-1 for users running `npx continuous-improvement install --mode expert`. They cover autonomous-mode safety, response-depth control, and context-window discipline that matter once an agent runs longer or more aggressively.
+Tier-2 skills layer on top of tier-1 for users running `npx continuous-improvement install --mode expert`. They cover response-depth control and context-window discipline that matter once an agent runs longer or more aggressively. Autonomous-mode write safety lives in tier-1 `gateguard` (`CI_GATEGUARD_TARGET_LOCK=block`), which replaced the retired `safety-guard` skill on 2026-08-07.
 
 | Skill | What it does | When it pays off |
 |-------|--------------|------------------|
-| `safety-guard` | Three-mode runtime guard (careful/freeze/guard) that blocks destructive commands and locks edits to a directory | Autonomous loops, prod systems, `--dangerously-skip-permissions` sessions |
 | `token-budget-advisor` | Heuristic input/output token estimator that offers 25%/50%/75%/100% depth choices before answering | Long sessions where response size matters |
 | `strategic-compact` | Manual phase-boundary checklist for deciding when to run `/compact` (research→plan, plan→implement, debug→next) instead of relying on arbitrary auto-compaction | Multi-phase tasks that approach context limits |
 | `wild-risa-balance` | Decision-framing lens that pairs WILD (Wild/Imaginative/Limitless/Disruptive) generation with RISA (Realistic/Important/Specific/Agreeable) execution, used to split recommendation lists into bold pilots above a safe baseline | Multi-item recommendation blocks where bold options keep losing to safe ones in a flat list |

package/skills/deploy-receipt.md

@@ -157,7 +157,7 @@ The rollback command is **printed**, not run. The skill's job is to give the ope
 - `finishing-a-development-branch` (vendored, third-party/superpowers/) — runs first; reports the merge. This skill runs after.
 - `verification-loop` — same Law 4 family; this skill is the deploy-seam specialization
 - `proceed-with-the-recommendation` — routing-table row for "Merge / close branch" should pair `finishing-a-development-branch` with this skill when the project is auto-deploy
-- `safety-guard` — orthogonal; safety-guard prevents destructive ops, this verifies post-deploy state
+- `gateguard` — orthogonal; gateguard gates the destructive op, this verifies post-deploy state
 
 ## Close-the-Loop Rule
 

package/skills/gateguard.md

@@ -77,7 +77,7 @@ Before creating {file_path}, present these facts:
 
 ### Destructive Bash Gate (every destructive command)
 
-Triggers on: `rm -rf`, `git reset --hard`, `git push --force`, `drop table`, etc.
+Triggers on structured rules that ignore flag order and spelling — `rm` with any recursive plus any force flag (`rm -r -f`, `rm -Rf`, `rm --recursive --force`), `git clean` with a force flag and no dry run, `git checkout -- <path>` or `git checkout .`, `git restore <path>` unless it is `--staged` only, `find … -delete`, `git push` with a `+refspec`, `git stash drop|clear` — plus the original substring list (`rm -rf`, `git reset --hard`, `git push --force`, `git branch -D`, `drop table`, `truncate `, `Remove-Item -Recurse`, etc.). Each command is judged after `&&`, `||`, `|`, `;` splitting, and a commit message, PR body or title value is blanked first so prose never trips it. The deny reason prints `Matched rule: <id>` so a block is explainable; the classifier is `lib/destructive-bash.mjs`. Plain file writes through Bash (`cat > file`, `sed -i`) are deliberately not gated.
 
 ```
 1. List all files/data this command will modify or delete
@@ -154,10 +154,24 @@ The inline `_gateguard_facts_presented: true` retry still works on harnesses tha
 
 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`.
 
+An exclusion is never silent. When every target of a call is excluded, `hooks/gateguard.mjs` still allows it but prints one stderr line naming the fragment that matched (`gateguard: skipped by CI_GATEGUARD_EXCLUDE (fragment "docs/wiki" matched docs/wiki/page.md)`). A catch-all fragment that every path contains (`/`, `.`, any single character) is honoured too, but the line says what it really is: the file gate is off for this session. Destructive Bash is never excluded. If `/verify-install` reports the probe write went through, check this variable before concluding the hook is not wired.
+
 ### 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.
 
+### Migrating from `safety-guard` (retired 2026-08-07)
+
+`safety-guard` was a prose-only tier-2 skill describing three "modes" it never implemented — no hook, no command, no logger ever shipped with it. Every mode it described is already enforced here by the runtime hook (`hooks/gateguard.mjs`):
+
+| Retired `safety-guard` mode | What enforces it now |
+|---|---|
+| Careful — warn on `rm -rf`, `git push --force`, `git reset --hard`, `DROP TABLE`, `chmod 777`, `--no-verify` … | [Destructive Bash Gate](#destructive-bash-gate-every-destructive-command). Its pattern set is a superset of the retired watch list, and it blocks rather than warns. |
+| Freeze — restrict writes to one directory tree | `CI_GATEGUARD_TARGET_LOCK=block` (above). Canonicalizes the absolute target against the session project root and refuses strays — before the fact gate, independent of clearance. |
+| Guard — careful + freeze together | Both of the above; they compose. Narrow the surface further with `CI_GATEGUARD_EXCLUDE`. |
+
+If you previously opted into `safety-guard` for autonomous or production-adjacent runs, set `CI_GATEGUARD_TARGET_LOCK=block` for that session instead. That is a real refusal, not a checklist the agent can talk itself out of.
+
 ### 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.
@@ -188,5 +202,6 @@ The standalone `gateguard-ai` Python/CLI package referenced in earlier drafts of
 
 ## Related Skills
 
-- `safety-guard` — Runtime safety checks (complementary, not overlapping)
+- `worktree-safety` — validates the worktree root before a source write; this skill gates the write itself
+- `reconcile` — git ground truth before a destructive git action
 - `code-reviewer` — Post-edit review (GateGuard is pre-edit investigation)

package/skills/reconcile.md

@@ -177,6 +177,5 @@ git branch -d <type>/<slug>            # delete the merged feature branch (safe
 
 - **`recall`** (Law 1) — before a risky git op, recall whether the same operation failed on this repo before.
 - **`gateguard`** (Law 1) — the runtime gate (`hooks/gateguard.mjs`); `reconcile` is the procedure you run once a destructive git action is in play.
-- **`safety-guard`** — destructive-operation guardrails for production and autonomous runs.
 - **`audit`** (Law 4) — when an audit ends in a fix, `reconcile` is the safe path from branch to landed PR.
 - **`commit-commands:commit-push-pr`** — the external-plugin equivalent of the commit → push → PR tail; `reconcile` reimplements it inline so the flow works with no companion installed. For a TDD-gated single-defect variant, use `/ship`.

package/plugins/continuous-improvement/skills/safety-guard/SKILL.md

@@ -1,77 +0,0 @@
----
-name: safety-guard
-tier: "2"
-description: 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.
-origin: continuous-improvement
-disable-model-invocation: true
----
-
-# Safety Guard — Prevent Destructive Operations
-
-## When to Use
-
-- When working on production systems
-- When agents are running autonomously (full-auto mode)
-- When you want to restrict edits to a specific directory
-- During sensitive operations (migrations, deploys, data changes)
-
-## How It Works
-
-Three modes of protection:
-
-### Mode 1: Careful Mode
-
-Intercepts destructive commands before execution and warns:
-
-```
-Watched patterns:
-- rm -rf (especially /, ~, or project root)
-- git push --force
-- git reset --hard
-- git checkout . (discard all changes)
-- DROP TABLE / DROP DATABASE
-- docker system prune
-- kubectl delete
-- chmod 777
-- sudo rm
-- npm publish (accidental publishes)
-- Any command with --no-verify
-```
-
-When detected: shows what the command does, asks for confirmation, suggests safer alternative.
-
-### Mode 2: Freeze Mode
-
-Locks file edits to a specific directory tree:
-
-```
-/safety-guard freeze src/components/
-```
-
-Any Write/Edit outside `src/components/` is blocked with an explanation. Useful when you want an agent to focus on one area without touching unrelated code.
-
-### Mode 3: Guard Mode (Careful + Freeze combined)
-
-Both protections active. Maximum safety for autonomous agents.
-
-```
-/safety-guard guard --dir src/api/ --allow-read-all
-```
-
-Agents can read anything but only write to `src/api/`. Destructive commands are blocked everywhere.
-
-### Unlock
-
-```
-/safety-guard off
-```
-
-## Implementation
-
-Currently implemented as skill-side discipline: when restricted-mode is active, the agent reads this skill and refuses Bash, Write, Edit, and MultiEdit calls that violate the rules before invoking the tool. There is no bundled tool-call gate today — the same enforcement gap that existed for `gateguard` before issue #106 / PR #108. A future runtime version would track via a follow-up issue.
-
-## Integration
-
-- Enable by default for `codex -a never` sessions
-- Pair with observability risk scoring in continuous-improvement v2
-- Logs all blocked actions to `~/.claude/safety-guard.log`

package/skills/safety-guard.md

@@ -1,77 +0,0 @@
----
-name: safety-guard
-tier: "2"
-description: 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.
-origin: continuous-improvement
-disable-model-invocation: true
----
-
-# Safety Guard — Prevent Destructive Operations
-
-## When to Use
-
-- When working on production systems
-- When agents are running autonomously (full-auto mode)
-- When you want to restrict edits to a specific directory
-- During sensitive operations (migrations, deploys, data changes)
-
-## How It Works
-
-Three modes of protection:
-
-### Mode 1: Careful Mode
-
-Intercepts destructive commands before execution and warns:
-
-```
-Watched patterns:
-- rm -rf (especially /, ~, or project root)
-- git push --force
-- git reset --hard
-- git checkout . (discard all changes)
-- DROP TABLE / DROP DATABASE
-- docker system prune
-- kubectl delete
-- chmod 777
-- sudo rm
-- npm publish (accidental publishes)
-- Any command with --no-verify
-```
-
-When detected: shows what the command does, asks for confirmation, suggests safer alternative.
-
-### Mode 2: Freeze Mode
-
-Locks file edits to a specific directory tree:
-
-```
-/safety-guard freeze src/components/
-```
-
-Any Write/Edit outside `src/components/` is blocked with an explanation. Useful when you want an agent to focus on one area without touching unrelated code.
-
-### Mode 3: Guard Mode (Careful + Freeze combined)
-
-Both protections active. Maximum safety for autonomous agents.
-
-```
-/safety-guard guard --dir src/api/ --allow-read-all
-```
-
-Agents can read anything but only write to `src/api/`. Destructive commands are blocked everywhere.
-
-### Unlock
-
-```
-/safety-guard off
-```
-
-## Implementation
-
-Currently implemented as skill-side discipline: when restricted-mode is active, the agent reads this skill and refuses Bash, Write, Edit, and MultiEdit calls that violate the rules before invoking the tool. There is no bundled tool-call gate today — the same enforcement gap that existed for `gateguard` before issue #106 / PR #108. A future runtime version would track via a follow-up issue.
-
-## Integration
-
-- Enable by default for `codex -a never` sessions
-- Pair with observability risk scoring in continuous-improvement v2
-- Logs all blocked actions to `~/.claude/safety-guard.log`