create-claude-cabinet 0.46.0 → 0.48.0

package/templates/briefing/_briefing-template.md

@@ -142,14 +142,9 @@ or if no `briefing` field is present, the system falls back to reading
 
 ## Finding Format
 
-When producing audit findings, use this structure:
-
-```yaml
-finding:
-  cabinet-member: member-name
-  severity: critical | significant | minor | informational
-  category: what domain this falls under
-  description: what was found
-  evidence: specific file:line or observation
-  recommendation: what to do about it
-```
+Do not define a finding format here — the audit system supplies the finding
+contract at audit time. The single source of truth for finding structure and
+the severity vocabulary (`critical` / `warn` / `info` / `idea`) is the audit
+output contract (`output-contract.md`) together with the machine schema
+(`finding-schema.json`), both shipped by the audit module. Point cabinet
+members at those, not at a hand-maintained block in this briefing.

package/templates/cabinet/advisories-state-schema.md

@@ -89,7 +89,7 @@ Document any new advisory's signal source here when you add it, and call out exp
 | `lsp:ruby` | `Gemfile` or `*.rb` | `/plugin install ruby-lsp@claude-plugins-official` (also needs `gem install ruby-lsp` AND `ENABLE_LSP_TOOL=1`) |
 | `mcp:railway` | `railway.toml` and no railway key in `~/.claude.json` (no-probe) | local: `railway setup agent -y` · remote: register `mcp.railway.com` (OAuth) |
 | `plugin:hookify` | `.claude/rules/enforcement-pipeline.md` exists and hookify not in `claude plugin list` (signal is **static**; probe-gated) | `/plugin install hookify` |
-| `briefing-file` | `.claude/briefing/_briefing.md` is **absent** (signal `missing`, **static**; no-probe) | run `/onboard` to create one |
+| `briefing-file` | `.claude/cabinet/_briefing.md` is **absent** (canonical location — where cabinet members read; `.claude/briefing/` holds only installer-seeded templates) (signal `missing`, **static**; no-probe) | run `/onboard` to create one |
 | `registry-orphan` | `~/.claude/cc-registry.json` lists project path(s) that no longer exist (signal = sorted orphan-name set, so it re-arms when the registry changes; no-probe) | remove the dead entr(y/ies) from `~/.claude/cc-registry.json` |
 
 > Note: `mcp:railway` keys on `railway.toml`, which Ring 1 also marker-checks for deploy detection — these are independent reads of the same file for different purposes; do not consolidate them (the advisory adds the `~/.claude.json` registration predicate Ring 1 lacks).

package/templates/cabinet/checklist-stats-schema.md

@@ -19,9 +19,23 @@ state.
 | Writer | When | What |
 |--------|------|------|
 | `/execute` `post-impl-checklist` phase | every run past its no-op guard | increments `runs`; per triggered dimension increments `fires`, sets `last_fired` |
-| `/debrief` `checklist-feedback` phase | when a session bug WAS caught via a surfaced check | appends to that dimension's `catches` |
+| Ring 3 close `checklist-catch` lens (Phase 2p) | session close, when the transcript shows a surfaced check that caught a real bug | appends to that dimension's `catches` |
+| `/debrief` `checklist-feedback` phase (pre-watchtower; retiring) | when a session bug WAS caught via a surfaced check | appends to that dimension's `catches` |
 | `/audit` `checklist-pruning` phase | every pruning verdict (including "keep") | appends to `pruning_reviews` |
 
+The **catch side is recorded automatically at session close** by the
+Ring 3 `checklist-catch` lens (`watchtower-ring3-close.mjs`, Phase 2p)
+for watchtower-installed projects — it reads the transcript, attributes
+catches to a named dimension, and writes them via the protocol below.
+`/debrief`'s `checklist-feedback` phase did this interactively and is
+retired by the watchtower burn-in (its sharpening side — proposing new
+checks for bugs that *slipped through* — needs operator approval and
+cannot move to a background ring; only the catch tally moved). The two
+writers are mutually exclusive in practice: a watchtower project closes
+through Ring 3, a non-watchtower project through debrief, and both
+follow the same atomic, fail-open write protocol — so the catches a
+later audit prunes against are recorded the same way regardless.
+
 ## Schema (`schema_version: 1`)
 
 ```json

package/templates/cabinet/eval-protocol.md

@@ -5,18 +5,35 @@ their job. Adapted from Anthropic's skill-creator eval framework for manual
 assessment. This is not an automated test suite — it's a structured way to
 ask "is this skill working?" and get an evidence-based answer.
 
-## When This Runs
-
-Two trigger mechanisms ensure this protocol doesn't just sit as a document:
+> **STATUS — pull-only reference (auto-assessment retired, act:62608a5d).**
+> The full manual assertion-scoring framework below has never run on a
+> recurring boundary (0 Assessment Log entries across the tree; /pulse has 0
+> lifetime standalone invocations). Rather than claim a discipline that
+> doesn't run, it is now explicitly **on-demand only** — invoke it when
+> refining a specific skill (the Pull trigger). The one part that DOES run on
+> a schedule is the mechanical dead/stale-skill signal (`skill-usage.mjs`),
+> now wired into the `/audit` structural-checks phase (workflow-cop-0006). The
+> heavyweight per-skill assertion scoring is not automated and is not claimed
+> to be.
 
-1. **Pull (via prompt refinement):** When reviewing a skill's definition,
-   run the assessment before proposing changes. The assessment grounds the
-   refinement in evidence rather than intuition.
+## When This Runs
 
-2. **Push (via process-therapist):** During audits, process-therapist checks whether
-   any skill's last assessment is older than 30 days. If so, it surfaces
-   an "eval overdue" finding, which enters the normal triage flow. The
-   user decides whether to act on it.
+1. **Pull (via prompt refinement) — the live path:** When reviewing a
+   skill's definition, run the assessment before proposing changes. The
+   assessment grounds the refinement in evidence rather than intuition. This
+   is on-demand; nothing schedules it.
+
+2. **Mechanical signal (via /audit) — the automated half:** The
+   dead/stale-skill reader (`skill-usage.mjs`) runs in the audit
+   structural-checks phase and surfaces never-invoked/stale skills on audit
+   cadence (workflow-cop-0006). That is the running boundary; the full
+   assertion-scoring assessment above is not auto-triggered.
+
+   > Retired: an earlier "Push (via process-therapist): during audits,
+   > check whether any skill's last assessment is >30 days and surface an
+   > 'eval overdue' finding" mechanism was documented here but never fired —
+   > process-therapist does not run per-skill assessments. The honest
+   > replacement is the mechanical signal above.
 
 ## The Assessment Framework
 

package/templates/cabinet/memory-lifecycle-contract.md

@@ -0,0 +1,135 @@
+# Memory Lifecycle Contract
+
+The shared contract for how built-in memory stays bounded as it grows.
+Every component that reads or writes the memory dir follows this:
+`validate-memory.mjs`, `write-memory-file.mjs`, the `/cc-remember` and
+`/memory` skills, the `memory-index-guard` hook, and (Stage 2) the
+lifecycle verbs. Full design + cabinet critique: see
+`.claude/plans/cross-store-memory-redesign.md` (act:02d15a70 = Stage 1,
+this contract; act:45fb9169 = Stage 2, gated).
+
+## The core principle
+
+`MEMORY.md` is loaded **in full at every session start** — it competes
+for the model's context window, so it has a hard budget (≤200 lines /
+≤25KB). The disease this contract cures: the old rule required the
+eagerly-loaded index to enumerate EVERY memory file (one line each), so
+its size tracked total memory count and it overflowed forever — the
+prune→overflow→prune treadmill.
+
+The fix decouples the eager index from total volume: `MEMORY.md` is a
+bounded **working set**, not a complete catalogue. Total memory can grow
+without bound (disk and search both scale for decades); only what loads
+eagerly is bounded. This is the same shape watchtower threads already
+use — surface the current cursor, leave the history on disk.
+
+## The three blocks of MEMORY.md
+
+A well-formed `MEMORY.md` working set has three kinds of content:
+
+1. **Pinned tier (decay-exempt).** Load-bearing knowledge a fresh
+   session needs surfaced *unbidden* — hard constraints, identity, hard
+   preferences, active-project pointers. These are valuable precisely
+   because they are stable and often OLD; they must never decay out on
+   recency. The defining test: *would a session that has never seen this
+   fail without it, and would it not know to go looking?* (e.g. "CC
+   hooks read tool input from stdin, not `$CLAUDE_TOOL_INPUT`".) Mark a
+   pinned entry with `pinned: true` in its file frontmatter (the Stage-1
+   default authority; revisit in Stage 2).
+
+2. **Recency block.** The recent window of curated entries, newest
+   first, filling the remaining budget to roughly 80% of the cap.
+   Recency is a fine proxy for "likely relevant next session" for
+   episodic material — and a BAD proxy for load-bearing constraints,
+   which is exactly why they go in the pinned tier instead.
+
+3. **Region pointers.** The cue-based-retrieval tier (see below) that
+   lets everything outside the working set stay reachable without a line
+   each.
+
+## Reachability replaces enumeration
+
+The validator invariant is no longer "every file has its own index
+line." It is: **every on-disk memory file is reachable from
+`MEMORY.md`** — by one of:
+
+- a direct working-set or `MEMORY-archive.md` index line, OR
+- a **region pointer** whose glob matches the file.
+
+A file that is none of these is an orphan and fails validation.
+"Present on disk" alone is **not** reachable — that test would be
+vacuous (every file is grep-able), which would silently delete the
+guarantee rather than relax it. The point of relaxing enumeration is to
+allow *bounded* indexing (a region covers N files with one line), not to
+allow invisible files.
+
+## Region pointers
+
+A region pointer declares that a whole class of files is reachable
+without enumerating them. Format — the **backtick-quoted glob is the
+only part the validator reads**; the rest is free-text guidance:
+
+```
+- region `lesson_*.md` → older lessons; grep the memory dir
+- region `session_summary_*.md` → past session records; grep by date
+```
+
+Rules:
+
+- **Globs use `*` and `?` only**, matched against the bare filename.
+- **Region pointers are DERIVED, never authoritative.** They are
+  regenerated from what's actually on disk (by hand in Stage 1, by the
+  consolidation pass in Stage 2). A pointer whose glob matches **zero**
+  files on disk is a stale, confidently-wrong retrieval cue — *worse
+  than no map* — and **fails validation**. Fix the glob or remove it;
+  never hand-edit a pointer to claim a region that isn't there.
+- **Region pointers are for recoverable history you'd think to search**
+  (old session narratives, cooled lesson archives). They are the WRONG
+  home for latent constraints — those stay in the pinned tier, eagerly
+  present, because their value is that you retrieve them *without*
+  knowing to look.
+
+## Spill-rate instrumentation (the Stage-2 gate)
+
+`validate-memory.mjs` appends a working-set pressure sample to
+`<memoryDir>/.memory-pressure.jsonl` (a dotfile — invisible to the
+orphan scan) at most once per day, only when utilization is ≥90% of the
+budget. This measures how often the working set actually runs near its
+limit, so Stage 2 (the lifecycle verbs + a background forcing function)
+is built only if the data shows recurring pressure on authored files —
+not on a felt "it keeps overflowing" metaphor. Stage 1 alone stops the
+acute treadmill; the sampler decides whether Stage 2 is warranted.
+
+## Stage 2 (designed, gated — NOT yet built)
+
+The lifecycle verbs and their forcing function are specified in the plan
+but gated on the spill-rate data. When built they will carry these
+already-decided constraints (recorded here so Stage 1 doesn't paint them
+into a corner):
+
+- **decay** — drop an entry from the working set; the file stays
+  reachable (via a region pointer or the archive). Reversible.
+- **consolidate** — merge a cluster into one gist that ALWAYS keeps a
+  lossless `consolidated_from:` provenance pointer (lossy = dropped from
+  the working set, never erased from disk). A cluster containing a
+  pinned/load-bearing entry files to the inbox; it never auto-applies,
+  because the *gist* becomes the retrieved truth and a wrong gist erases
+  a load-bearing detail.
+- **supersede** — mark an entry false/obsolete so retrieval stops
+  surfacing it as live truth (kept on disk for audit, with a reverse
+  breadcrumb in its successor). Deferred until the frontmatter-parsing
+  question is resolved (line-scan vs. a deliberately-added dependency —
+  the repo currently refuses a YAML parser; see
+  `lesson_parsefrontmatter_flow_sequences`). supersede is a reference
+  graph: dangling targets, cycles, and re-pointing working-set/region
+  references to the superseded slug must all be validated.
+- **Cross-store fold** — for session-summaries carrying design
+  reasoning, the durable target is a committed `.claude/methodology/`
+  gist, NEVER the thread cursor (which holds understanding, not
+  narration) and NEVER a delete-in-the-same-pass (the memory dir and
+  threads are both local-only/ungit'd; append-verify-then-mark
+  `folded_into:`, reclaim in a separate idempotent sweep).
+- **Forcing function** — memory hygiene (decay/consolidate) extends
+  Ring 2-slow's existing `runMemoryHygiene`; only drift-supersede is the
+  Ring 4 memory pass. No new ring for hygiene. First passes run
+  dry-run-with-report.

package/templates/cabinet/pib-db-access.md

@@ -23,6 +23,19 @@ Check: are pib_* MCP tools available?
   NO  → use node scripts/pib-db.mjs list-projects, etc.
 ```
 
+### MCP invocation specifics (read before first use, not after a failure)
+
+Two details that otherwise cost a failed call + a `ToolSearch` round-trip
+every session:
+
+- **Full tool names are prefixed `mcp__pib-db__`** (e.g.
+  `mcp__pib-db__pib_query`). When loading deferred tools via `ToolSearch`,
+  query `select:mcp__pib-db__pib_query,mcp__pib-db__pib_list_actions` —
+  the bare `pib_*` names will not match.
+- **`pib_query`'s parameter is `sql`, not `query`.** Calling it with a
+  `query` argument fails (and can fail quietly). The CLI form is
+  `query "SQL"`; the MCP form is `{ "sql": "SELECT ..." }`.
+
 ## Available Operations
 
 | MCP Tool                   | CLI Equivalent                                  | Description                    |