create-claude-cabinet 0.51.0 → 0.53.0

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

@@ -62,7 +62,7 @@ every session:
 When deferring an item that waits on a specific identifiable
 condition — a dependency landing, a stack decision finalizing, a
 referenced file appearing — use `pib_defer_with_trigger` instead of
-plain `status='deferred'`. Orient re-evaluates each trigger every
+plain `status='deferred'`. The session loop re-evaluates each trigger every
 session and surfaces items whose conditions have become true. See
 [pib-db-triggers.md](pib-db-triggers.md) for the full convention:
 result vocabulary, cascade semantics for projects, migration

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

@@ -1,7 +1,7 @@
 # pib-db Deferred Triggers
 
 How to defer work items with structured return conditions and how
-orient re-evaluates them each session.
+the session loop re-evaluates them each session.
 
 ## Purpose
 
@@ -13,8 +13,8 @@ or a `status='deferred'` row and sits there forever. Nobody re-reads
 
 Deferred triggers turn those items into structurally-encoded work:
 each one carries a natural-language condition describing what would
-have to change to reactivate it. Orient surfaces them every session
-and evaluates the condition against the current session's context.
+have to change to reactivate it. The session loop surfaces them every
+session and evaluates the condition against the current session's context.
 The item sits in the queue, not on a reminder list.
 
 ## Schema
@@ -110,29 +110,33 @@ The cascade:
    trigger is the single source of truth.
 
 When the parent reopens (user flips status back to `active`, or
-orient surfaces it as `triggered` and the user accepts):
+the session loop surfaces it as `triggered` and the user accepts):
 
 - Children remain `deferred`.
 - The user decides which children to reopen. Reopening everything
   automatically often resurrects stale subgoals that the deferral
   period should have retired.
 
-## Orient integration
+## Session-loop integration
 
-The `deferred-check.md` phase fires after `work-scan.md`, before
-`auto-maintenance.md`. Every session:
+Under watchtower (the default loop), Ring 1 surfaces deferred/triggered
+items in the project state file's Standing Issues, and the session — or
+`/briefing` — re-evaluates each trigger against current context. On the
+legacy loop, the `deferred-check.md` orient phase does this, firing after
+`work-scan.md`, before `auto-maintenance.md`.
 
-1. Orient calls `pib_list_triggered` (or CLI fallback).
-2. For each item, evaluates the trigger text against the current
-   session's context (new dependencies installed? a referenced file
-   now exists? a stack decision was finalized?).
-3. Records each evaluation via `pib_mark_trigger_checked`. Prefer
+Either way, every session:
+
+1. Call `pib_list_triggered` (or CLI fallback).
+2. For each item, evaluate the trigger text against the current session's
+   context (new dependencies installed? a referenced file now exists? a
+   stack decision was finalized?).
+3. Record each evaluation via `pib_mark_trigger_checked`. Prefer
    `needs-info` over guessing `triggered`.
-4. Items that evaluate to `triggered` appear in the briefing's
-   **Attention Items** section. Orient does not auto-reopen — the
-   user decides.
+4. Items that evaluate to `triggered` surface as **Attention Items**. The
+   session loop does not auto-reopen — the user decides.
 
-Cost control: cap the phase at 30 seconds. If more than 10 items are
+Cost control: cap the evaluation at 30 seconds. If more than 10 items are
 triggered, evaluate only the 5 least-recently-checked.
 
 ## Migration guarantees

package/templates/cabinet/watchtower-contracts.md

@@ -208,6 +208,81 @@ mux descriptor; routine items resolve normally (no QA gate, normal
 expiry — expiry also clears the descriptor). A pending routine item
 blocks refiring of the same routine until resolved or stale.
 
+**Moment expiry for `time-of-day` routines (act:ea23b3a5).** A daily
+routine's value is bound to its day: a morning briefing delivered
+tomorrow is not a briefing. `stale_after_hours` only supersedes at the
+NEXT due firing, which for a daily routine is 24 hours later, so a
+missed firing held a queue slot and a lit desk badge all day. Ring 1's
+tick now supersedes a pending `time-of-day` item once the calendar day
+it was FILED on has ended.
+
+End of day, not a fixed number of hours, and the difference is
+measured rather than tasteful: across six weeks the portfolio's one
+time-of-day routine had ten real pickups — eight within four hours and
+two after, at 4.4h and 8.6h. A four-hour window would have destroyed two
+genuine pickups to clear one stale item. End-of-day preserves all ten,
+needs no tuning constant, and matches what a daily routine means to a
+person: you can still want your morning briefing at 4pm; you do not want
+it tomorrow.
+
+Three scoping rules, each load-bearing:
+
+- **Ring 1's portfolio tick only.** Ring 3 also calls `runRoutinePass`,
+  with a single-project `session-close` event. An unscoped sweep there
+  would have every session close in any project superseding every OTHER
+  project's routine items — and one portfolio sweep per replayed session
+  during a `--reprocess-failed` drain.
+- **Classify from the ITEM, not from config.** `dispatchRoutine`
+  persists `evidence.trigger` at filing, so a routine whose declaration
+  was later removed still classifies. A config lookup would find nothing
+  and leave it pending forever.
+- **An unparseable `filed_at` abstains, loudly.** The `stale_after_hours`
+  path treats the same input as stale (NaN comparisons fall through to
+  supersede); this one refuses and logs. Two mechanisms disagreeing
+  silently is worse than one abstaining out loud.
+
+Consequences, named rather than discovered later: for a `time-of-day`
+trigger the moment sweep pre-empts the `stale_after_hours` supersede
+(same outcome, more honest reason), a missed briefing is no longer
+re-delivered by the SessionStart missed-routine section on a LATER day,
+and the sweep has no in-flight awareness — a routine picked up by `mux
+qa drain` very close to midnight could be superseded mid-run, which
+end-of-day narrows to minutes where a fixed-hour window would have
+opened it to hours. `interval`, `path-nonempty`, and `session-close`
+routines have no moment and are untouched.
+
+## Upstream-Friction Actionability (Phase 2g)
+
+A friction report with no party who could act on it is not a report.
+Five of the 2026-07-26 dismissals were observations like "Claude made
+iterative browser tweaks without writing to file" — true, and addressed
+to nobody, aging in the queue for weeks.
+
+Phase 2g now classifies each finding into three arms (act:ea23b3a5),
+copying Phase 2f's verification-gate shape (which files a methodology
+capture only when the claimed artifact verifiably exists on disk, after
+11 of 11 unverified captures were dismissed over three weeks):
+
+1. **A named route** — `evidence.route.type` from the CLOSED vocabulary
+   `cc-feedback | project-tracker | config-change`, plus a non-empty
+   `detail` naming who acts and how ⇒ files `upstream-friction`, with the
+   route rendered into the summary so the operator sees it without
+   opening the evidence.
+2. **Durable, no route** — a platform constraint or environment quirk
+   nobody can fix, whose WORKAROUND is worth remembering ⇒ files
+   `knowledge-extraction`. This arm is not theory: of the five friction
+   items the operator KEPT, four exited as `captured-to-memory`. A
+   two-arm gate would have discarded the useful half of the lens.
+3. **Neither** — a transient incident or a general observation about
+   Claude's behavior ⇒ files nothing, and is COUNTED. All three counts
+   are logged every run; silence would be indistinguishable from a lens
+   that never ran, and the drop count is the number this change exists to
+   move.
+
+An invented route type or an empty `detail` falls to arm 3. The
+vocabulary is closed precisely so "someone should fix this" cannot
+become an escape hatch.
+
 ## Session Advisor Pass (re-homed standing advisors)
 
 The standing session advisors (historian, system-advocate,
@@ -336,6 +411,125 @@ each owning its tier. Flag: `defaults.recall_canary` (opt-out).
   extraction never proposed (M2 under-extraction). The canary states
   this blindness in its own output.
 
+## Reach 1 — Pending-Relation Proposals (act:5182beda, N3 of grp:retro-remeaning)
+
+The first shippable instance of **retrospective temporality** (`act:ef5a3842`,
+MANIFESTO principle 4): new understanding reaching BACK to recolor what came
+before, at the earliest and safest reach — the still-pending inbox, where
+nothing is believed yet. Every specimen that motivated the program had its
+counterpart sitting pending at the moment the second one was written; Phase
+2d's extraction call now sees that pending pile and can propose a relation.
+
+**Mechanism.** `selectNearbyPendingItems` (ring3-close.mjs) shortlists the
+pending inbox drafts most relevant to THIS session's transcript (same
+relevance-scoring recipe as `selectNearbyMemoryTitles`, a SEPARATE corpus
+with its OWN cap, `PENDING_RELATION_CAP` — never a shared budget with
+memory's, or a large pending pile would evict memory titles and degrade the
+M1b novelty gate). The extraction prompt's `PENDING IN INBOX` block is
+injected as its OWN section, distinct from `ALREADY SAVED TO MEMORY`. For
+each item, the model may set `relates_to` (the exact pending title) and
+`relation` (`pairs_with` | `answers` | `contradicts`) — fields the model
+outputs ALONGSIDE, never IN, `covered_by`. This separation is load-bearing:
+`covered_by` stays scoped to memory titles and feeds `modelRescues`/
+`isDuplicate` exactly as before; `relates_to`/`relation` are never read by
+either — naming a pending title in `covered_by` instead would flip the
+rescue gate into a suppressor (a filed-today item wrongly read as "covered
+by," and suppressed, because it topically resembles a merely-PENDING draft
+that isn't believed yet — the exact failure the Meta question/answer
+specimen would have suffered).
+
+**Filing.** A relation proposal is its own inbox item, category
+`pending-relation`, filed via `fileRelationProposal` AFTER the newly-
+extracted item's own `createItem` call succeeds (its id isn't known until
+then). Deduped by `evidence.relation_key` (sorted ids + the relation verb) —
+one pending item per (pair, verb), so the same relation proposed from either
+side, or in a later session, never refiles. The proposal never changes
+anything about the item that prompted it: no suppression, no home change, no
+urgency change — it is strictly additive.
+
+**The M5 suppression ledger is blind to this channel.** `recordSuppression`
+(the Suppression Ledger above) only sees LEXICAL suppressions — the
+deterministic `isDuplicate` corpus matches. The model's real per-item
+inclusion/omission decision happens INSIDE the extraction call, in a channel
+the ledger cannot observe at all: if the model chose to silently omit an
+item from its output array (rather than including it with `relation: none`),
+no suppression record is ever written, because nothing was suppressed BY A
+CORPUS — it was never proposed. This is why the prompt carries an explicit,
+load-bearing instruction that a pending item is grounds for a RELATION only,
+never grounds to omit or demote anything — the instruction is the entire
+defense, because the suppression ledger cannot audit it.
+
+**Retraction.** Registered in `INBOX_DETECTOR_REGISTRY` with a reconciler:
+`autoReconcilePendingRelations` (ring1.mjs, one global pass per tick — purely
+queue-internal, no per-project pib-db access, unlike `completion-review`'s).
+Retracts via `autoReconcileItem` when EITHER cited side (`evidence.from_id`
+/ `evidence.to_id`) leaves pending — a relation between two open questions
+no longer applies once one resolves. Fails toward KEEPING: an id that no
+longer resolves via `getItem` (deleted/migrated) is ambiguous, not evidence
+the relation resolved.
+
+## Reach 2 — Significance-Change Proposals (act:bcb7edd4, L1 of grp:retro-remeaning)
+
+The second reach of the retrospective-temporality motion (`act:ef5a3842`,
+MANIFESTO principle 4), extending Reach 1's inbox-range reach-back to the
+recently-absorbed thread trail. When Ring 3 closes a session, the new
+understanding it captured reaches BACK into the prior cursor history of the
+threads THIS session touched, and may PROPOSE that an earlier entry now
+means something different: `reframes` (significance change — what looked
+like friction was the seed of the architecture; the class a contradiction
+scan is structurally blind to), `answers` (a real earlier uncertainty is
+settled), or `contradicts`. Category: `significance-change`.
+
+**Mechanism.** Inside Phase 2b2, AFTER the cursor appends land: the prior
+trail of each earned thread is snapshotted from disk BEFORE this session's
+entry is appended (last `PRIOR_HISTORY_CAP` entries), and one focused
+follow-up model call (`significanceReachBack`) sees the new understanding
+beside each prior trail. It fires only when at least one earned thread has
+prior history — a routine or first-touch session costs nothing. It cannot
+ride the capture call the way Reach 1 rode extraction: the reach-back
+corpus (which threads matter) IS that call's output. EVENT-DRIVEN by
+construction — never a periodic sweep (the shape the cabinet killed).
+
+**Proposals are validated, then durably deduped.** A proposal must cite an
+ACTUAL prior entry — session_id + date checked against the on-disk snapshot
+(`validateRecolorProposals`); a hallucinated anchor drops, logged, never
+filed. Filing (`fileSignificanceProposal`) dedups by
+`evidence.relation_key` (`thread|prior_session|new_session|verb`) across
+ALL queue statuses with NO time window: a dismissed or expired judgment
+about a static corpus never re-nags — not after `RESOLUTION_CORPUS_DAYS`,
+not ever — and a reprocess replay of the same session produces the same key
+and files nothing. (The same unwindowed-exclusion discipline was backported
+to Reach 1's `fileRelationProposal`, whose original pending-only dedup
+left a post-dismissal refile hole.)
+
+**The gate is real, not ceremonial.** Both relational categories
+(`significance-change`, `pending-relation`) are in `GATED_CATEGORIES`:
+`applyBatch` structurally refuses them, so each reinterpretation is
+confirmed or dismissed individually — a rubber-stamped batch of re-meanings
+is how a system gaslights its operator. On CONFIRM, /inbox applies the
+recolor via `appendThreadRecolor` (watchtower-lib): an entry in the
+thread's additive `recolor_log` array. The recolor ANNOTATES history — it
+never rewrites `cursor_history`, and no ring ever writes `recolor_log`;
+the rings propose, only the operator's confirmation applies.
+
+**Retraction.** `autoReconcileSignificanceItems` (ring1, per tick):
+retracts when the cited thread file is POSITIVELY gone from
+`state/threads/` (dir readable, file absent — a recolor of deleted history
+is moot); keeps on any read error, and keeps EVERYTHING when the dir is
+unreadable (a mount hiccup must not mass-retract).
+
+**The honest metric that gates Reach 3.** Every real-work close appends one
+line to `state/significance-ledger.jsonl` (`recordSignificanceEvent`,
+fail-open, same discipline as the suppression ledger): session, threads
+touched, threads with history, entries shown, proposals filed.
+`readSignificanceRate` (watchtower-lib) combines the ledger (denominator,
+replay-deduped by session_id) with the queue's per-category dispositions
+(numerator) into `{sessions, proposals_per_session, keep_ratio, …}` — with
+null ratios when a denominator is zero, never fabricated 0s. This is the
+L2 gate's named reader: Reach 3 (`act:a8b372a7`) is built only when an
+observed significance-change rate on real data warrants it — replacing the
+contradiction-density measurement the plan retired as the wrong instrument.
+
 ## Detector Symmetry (no detector without a retraction path)
 
 The 2026-07-12 inbox drain (893→194 pending) hit the same disease four
@@ -404,16 +598,133 @@ branch-diverged item for it — the branch stays visible on the attention
 line / git-attention sidecar / summary / Standing Issues (the exclusion
 gates filing ONLY), and the consumer overrides the list in config.
 
-**Standing-debt aggregation (coverage-warning first):** a detector
-whose finding is a STANDING condition (recurs while a debt persists)
-files ONE item per (project, debt-class) and APPENDS evidence to the
-pending item (path union + per-path counts + session count), carrying
-`evidence.first_seen` (oldest evidence date) so aging reads the debt's
-true age, with an urgency escalation at a session-count threshold.
-Resolving the item closes the accumulated view; if the debt persists,
-the next tick files FRESH — post-disposition recurrence is a new
-signal, not a refile loop (act:e888dd63; 49 identical coverage-warning
-items for one month-old debt was the live specimen).
+**Standing-debt aggregation (coverage-warning, memory-budget):** a
+detector whose finding is a STANDING condition (recurs while a debt
+persists) files ONE item per (project, debt-class) and APPENDS evidence
+to the pending item, carrying `evidence.first_seen` (oldest evidence
+date) so aging reads the debt's true age. Resolving the item closes the
+accumulated view; if the debt persists, the next tick files FRESH —
+post-disposition recurrence is a new signal, not a refile loop
+(act:e888dd63; 49 identical coverage-warning items for one month-old
+debt was the live specimen).
+
+Three rules the second adopter (memory-budget, act:ea23b3a5) added, each
+learned from a live failure mode:
+
+1. **The occurrence key must be the operator's unit of time, not the
+   ring's.** coverage-warning keys on the session; memory-budget keys on
+   the CALENDAR DAY, because Ring 2 slow runs ~48 times a day. A per-run
+   key makes the replay guard dead code, grows the key list by ~17,500
+   entries a year inside one JSON file, renders a count no human can
+   read, and — because the backlog-rot reader weighs standing debt by
+   that count — poisons the `keeping` / `losing` / `not-consumed` verdict
+   `/inbox` and `/briefing` lead with.
+2. **Reuse an evidence spelling the readers already know.** The rot
+   weigher (`itemSessionWeight`, watchtower-inbox-assessment) accepts
+   `session_count` / `session_ids` / `sessions` and silently weighs
+   everything else as 1. A new adopter that invents a fifth spelling
+   reintroduces the blind spot the fourth was added to fix. memory-budget
+   writes `session_count`.
+3. **Prefer `annotateItemEvidence` over a direct item write, and do not
+   bump `filed_at` without a reason.** The append gets a fresh read, a
+   pending fence checked at write time, and a deep-equal skip for free.
+   Bumping `filed_at` has three side effects worth choosing
+   deliberately: it strips an `[AGING]` prefix the escalation pass added
+   (and prevents its return), it re-escalates urgency the decay pass
+   de-escalated, and — since `listPending` sorts by `filed_at` — it pins
+   the item to the top of every pending list permanently. coverage-warning
+   bumps on purpose (its expiry clock should measure the last
+   recurrence); memory-budget does not.
+
+**What does NOT aggregate.** `doc-drift` carries a per-claim,
+mutually-exclusive fix-doc / fix-code decision, so N claims folded into
+one item pose a question the operator cannot answer, and any reconciler
+over the aggregate could only fire when every claim cleared.
+`raised-unhandled` is free text: recognizing "this loose end restates
+that one" needs a similarity matcher, and `proposeFolds`'
+`overlapCoefficient` at `FOLD_SIMILARITY_THRESHOLD = 0.22` folds two
+three-token titles that share ONE word — calibrated for advisory
+retrieval, not for a destructive merge. Both instead route through Ring
+2's `runDraftAnnotationSweep`, which annotates both sides with
+`possible_duplicate_of` and demotes them out of batch sign-off. **A
+lexical matcher may propose; it may never silently suppress.**
+
+## Category Expiry
+
+Every pending item ages out on a per-category policy. The table and its
+helpers live in `watchtower-queue.mjs` (`expiryDaysFor`,
+`categoryNeverExpires`, `CATEGORY_EXPIRE_DAYS`) — read the constants
+there for the numbers; mirroring them into this document would be a
+count claim that drifts, in a repo whose Ring 4 files `doc-drift` items
+for exactly that.
+
+**There are TWO expiry engines and both must delegate.** Ring 2's
+`escalateQueueItems` runs on the 5-minute cron; `runExpiry` is called by
+`/inbox` and `/briefing`. Before act:ea23b3a5 each hardcoded 30 days and
+inlined its own qa-handoff carve-out, so a per-category policy set in one
+would be silently violated by whichever engine reached an item first.
+
+**The qa-handoff exemption is structural, not a preference.**
+`expireItem` THROWS on a qa-handoff by the recipient-gate contract, so
+`categoryNeverExpires` lives beside that throw: returning anything but
+null for it would crash the caller's loop. One fact, one place.
+
+**A shortened expiry can open a refile loop.** completion-review expires
+at 14 days, which equals `COMPLETION_REVIEW_DEDUP_DAYS`. An item
+therefore leaves the dedup window at exactly the moment it expires — so
+Phase 2c's dedup corpus must include `expired` and `superseded`, or the
+fid is in no corpus at all and the next session refiles it forever. That
+is Detector Symmetry §2's named failure, reached from the other
+direction: **when you shorten a category's expiry, check what its filing
+site dedups against.**
+
+## Queue Items Require a Decision; Ambient State Describes Conditions
+
+A queue item asks the operator to decide something. A per-project state
+file describes a condition. Filing a condition as an item spends the
+operator's scarcest resource — a triage slot — on something they can
+only acknowledge.
+
+**The axis is who is judging, not whether the value is recomputable.**
+Recomputability is the wrong test and would contradict a rule this
+system already ships: derivable and perishable facts (act:471dd701,
+act:a69c21f8) are recomputable *by definition*, and they are **always
+filed** — routed to their derivation or the session record, never
+dropped — because that routing is a per-item MODEL judgment, and
+dropping one would be silent model auto-suppression. A deterministic
+ring measurement is different in kind: the operator routes it once, by
+category, and the routing holds.
+
+**The functional test: does waiting cost something irreversible?**
+`worktree-unmerged` is the calibrating counter-example. Ring 1
+recomputes it from git every five minutes, so by a recomputability rule
+it would be pure ambient state — and it must stay in the queue, because
+the worktree gets cleaned up and the work is gone. A recomputable
+condition with decay belongs in the queue; a recomputable condition that
+is stable belongs in ambient state.
+
+**The calibrating pair (act:ea23b3a5).** The cabinet-roster review
+produces three signals. `uncovered-tech` names a specific per-project
+gap and proposes adding a cabinet seat — a decision, so it stays a queue
+item. `dormant-skill` and `stale-briefing` are measurements, so they
+moved to `state/roster-review.json` and render in Ring 1's Standing
+Issues.
+
+Three obligations come with moving something to ambient state:
+
+- **Fix the measurement first.** The dormant-skill count was a saturated
+  display cap: every project ever measured reported exactly "12 dead",
+  because the title was built from an array already sliced to
+  `ROSTER_DORMANT_LIST_CAP`. Moving that into seven state files would
+  have given a constant the authority of a fact.
+- **Render on change, or give it a firing threshold.** Ambient state has
+  no dismiss verb — the queue item at least had one. A number that never
+  moves in a file read at every briefing is furniture by the third read.
+  The precedent is the recall canary, which Ring 1 renders only on alert.
+- **Retire what is already filed.** The filing site was usually the only
+  code that ever touched those items. Removing it without a one-shot
+  supersede leaves them displaying a stale count for weeks beside a live
+  ambient line saying something different — dual existence.
 
 **Known limitation (named, not hidden):** reconcilers run per
 configured project — items whose project was deleted or de-registered

package/templates/engagement/pib-db-patches/pib-db-mcp-server.mjs

@@ -176,7 +176,7 @@ const TOOLS = [
   },
   {
     name: 'pib_defer_with_trigger',
-    description: 'Defer an action or project with a free-text trigger condition describing what would reactivate it. Orient re-evaluates triggers each session. Use this INSTEAD of pib_update_action with status=deferred when the deferral is waiting for a specific condition.',
+    description: 'Defer an action or project with a free-text trigger condition describing what would reactivate it. Each session re-evaluates triggers and surfaces those whose condition has fired. Use this INSTEAD of pib_update_action with status=deferred when the deferral is waiting for a specific condition.',
     inputSchema: {
       type: 'object',
       properties: {
@@ -199,7 +199,7 @@ const TOOLS = [
   },
   {
     name: 'pib_mark_trigger_checked',
-    description: 'Record that a trigger was evaluated. Use after orient\'s deferred-check phase evaluates triggers against session context. Result must be one of: triggered | still-waiting | needs-info | condition-obsolete.',
+    description: 'Record that a trigger was evaluated. Use after a session evaluates triggers against session context. Result must be one of: triggered | still-waiting | needs-info | condition-obsolete.',
     inputSchema: {
       type: 'object',
       properties: {

package/templates/memory/patterns/_pattern-template.md

@@ -35,7 +35,7 @@ Descriptive slug. Convention: `pattern-{domain}-{topic}` or just
 `pattern-{topic}`.
 
 ### `description`
-One-line summary. Used by orient/debrief to decide whether to load
+One-line summary. Used by the session loop to decide whether to load
 the full pattern. Be specific — "deployment issues" is too vague;
 "silent deployment failures and stale build log output" is useful.
 

package/templates/mux/bin/mux

@@ -28,6 +28,11 @@ in_tmux() { [[ -n "${TMUX:-}" ]]; }
 
 slugify() {
   local input="$*"
+  # Flatten to one line FIRST — sed/cut below process input line-by-line,
+  # so a multi-paragraph prompt would otherwise yield a multi-line "slug"
+  # (one line per input line) that mangles or empties out every caller's
+  # branch/directory name instead of collapsing to a single slug.
+  input="${input//$'\n'/ }"
   # If prompt has "name. rest", use only the name part
   if [[ "$input" == *". "* ]]; then
     input="${input%%". "*}"

package/templates/mux/config/mux-server.py

@@ -2,6 +2,7 @@
 """MCP server for mux — lets Claude manage desks, windows, and notes."""
 
 import json
+import shlex
 import subprocess
 import sys
 import os
@@ -192,11 +193,12 @@ def handle_tool(name, args):
     elif name == "mux_new":
         prompt = args.get("prompt", "")
         if prompt:
-            out, _, _ = run(f'{os.path.expanduser("~/.local/bin/mux")} new "{prompt}" 2>&1')
-            return out or f"New window '{prompt}' created."
+            out, _, rc = run(f'{os.path.expanduser("~/.local/bin/mux")} new {shlex.quote(prompt)} 2>&1')
         else:
-            out, _, _ = run(f'{os.path.expanduser("~/.local/bin/mux")} new 2>&1')
-            return out or "New window created."
+            out, _, rc = run(f'{os.path.expanduser("~/.local/bin/mux")} new 2>&1')
+        if rc != 0:
+            return f"Failed to open new window: {out or '(no output — check tmux/mux state)'}"
+        return out or (f"New window '{prompt}' created." if prompt else "New window created.")
 
     elif name == "mux_note_add":
         text = args["text"]
@@ -236,7 +238,7 @@ def handle_tool(name, args):
     elif name == "mux_status":
         project = args.get("project", "")
         if project:
-            out, _, _ = run(f'{os.path.expanduser("~/.local/bin/mux")} status "{project}" 2>&1')
+            out, _, _ = run(f'{os.path.expanduser("~/.local/bin/mux")} status {shlex.quote(project)} 2>&1')
         else:
             out, _, _ = run(f'{os.path.expanduser("~/.local/bin/mux")} status 2>&1')
         return out or "No desks open."

package/templates/rules/enforcement-pipeline.md

@@ -107,10 +107,10 @@ promotion candidates (specific rules ready for promotion).
 
 | Step | Owner | When |
 |------|-------|------|
-| Capture + Classify | /debrief | Every session |
+| Capture + Classify | watchtower Ring 3 (or /debrief) | Every session |
 | Pattern analysis | Periodic review | As feedback accumulates |
 | Promotion checkpoint | Review cadence | When patterns mature |
-| Enforcement health | /orient or /pulse | Regular check |
+| Enforcement health | /briefing or /pulse | Regular check |
 
 ## Audit Findings as Promotion Input
 

package/templates/rules/memory-capture.md

@@ -17,12 +17,12 @@ write it to memory without asking whether to save it.
 `/cc-remember` ensures:
 - The new memory lands at `~/.claude/projects/<slug>/memory/<slug>.md`
 - `MEMORY.md` gets a new entry in the "Curated entries (hand-authored)"
-  section, so next session's `/orient` can find the memory
+  section, so the next session can find the memory
 - Filename collisions are handled (suffix with date if needed)
 - The write is atomic (temp + rename — safe under concurrent sessions)
 
 Direct flat-`.md` writes work but skip the indexing step. The memory
-becomes invisible to `/orient` until you manually update `MEMORY.md`.
+becomes invisible to the next session until you manually update `MEMORY.md`.
 The `memory-index-guard` PostToolUse hook will flag this when it
 happens, but it's better to avoid the issue: **use `/cc-remember`**.
 

package/templates/scripts/__tests__/absorption-no-prune.test.mjs

@@ -0,0 +1,89 @@
+// absorbThreadSessions (act:6f93a1f1, N4 of grp:retro-remeaning) — the
+// age-only session-record pruning gate (ABSORPTION_SESSION_AGE_DAYS = 90)
+// is RETIRED. Structural contract under test:
+// A1: an active thread's session record survives a slow-tier run, even when
+//     the session is far older than the old 90-day cutoff (the deleted
+//     constant no longer exists to prune it).
+// A2: dormant-marking is UNCHANGED — a thread untouched for 30+ days still
+//     flips to 'dormant'.
+// A3: the retired constant is gone from the module's exports/source.
+//
+// Hermetic per qa-handoff-gate.test.mjs: WATCHTOWER_DIR points at a temp dir,
+// set BEFORE the dynamic import. No Anthropic calls — absorbThreadSessions
+// touches only the filesystem.
+
+import { test } from 'node:test';
+import assert from 'node:assert/strict';
+import { mkdtempSync, mkdirSync, writeFileSync, readFileSync, existsSync, rmSync } from 'node:fs';
+import { join } from 'node:path';
+import { tmpdir } from 'node:os';
+
+const root = mkdtempSync(join(tmpdir(), 'absorption-no-prune-'));
+process.env.WATCHTOWER_DIR = root;
+
+const ring2 = await import('../watchtower-ring2.mjs');
+const { absorbThreadSessions, DORMANT_THREAD_AGE_DAYS } = ring2;
+
+test.after(() => rmSync(root, { recursive: true, force: true }));
+
+function isoDaysAgo(days) {
+  return new Date(Date.now() - days * 86400000).toISOString();
+}
+
+test('A1: an active thread carrying a >90-day-old session record survives a slow-tier run', async () => {
+  const threadsDir = join(root, 'state', 'threads');
+  mkdirSync(threadsDir, { recursive: true });
+
+  const thread = {
+    schema_version: 2,
+    thread: 'fixture-thread',
+    display_name: 'Fixture thread',
+    cursor_history: [{ date: isoDaysAgo(2), session_id: 'sess-recent', cursor: { what: 'x', where_left_off: 'y', open_questions: [] } }],
+    // Fixture must pin active + recent last_updated, or this hits the
+    // dormant branch and the survival assertion is vacuous.
+    sessions: [{ id: 'sess-old', project: 'fixture-proj', date: isoDaysAgo(200) }],
+    related_fids: [],
+    last_updated: isoDaysAgo(2),
+    status: 'active',
+  };
+  writeFileSync(join(threadsDir, 'fixture-thread.json'), JSON.stringify(thread, null, 2));
+
+  const sessionsDir = join(root, 'state', 'projects', 'fixture-proj', 'sessions');
+  mkdirSync(sessionsDir, { recursive: true });
+  const sessionFilePath = join(sessionsDir, `${isoDaysAgo(200).slice(0, 10)}-sess-old.md`);
+  writeFileSync(sessionFilePath, '# Session sess-old\n\nDate: ' + isoDaysAgo(200) + '\n\n- did a thing\n');
+
+  await absorbThreadSessions();
+
+  assert.ok(existsSync(sessionFilePath), 'the 200-day-old session record must survive — age-only pruning is retired');
+  const stored = JSON.parse(readFileSync(join(threadsDir, 'fixture-thread.json'), 'utf8'));
+  assert.equal(stored.status, 'active', 'a recently-updated thread must stay active, not be pruned into dormant');
+});
+
+test('A2: dormant-marking is unchanged — a thread untouched 30+ days flips to dormant', async () => {
+  const threadsDir = join(root, 'state', 'threads');
+  mkdirSync(threadsDir, { recursive: true });
+
+  const thread = {
+    schema_version: 2,
+    thread: 'stale-thread',
+    display_name: 'Stale thread',
+    cursor_history: [],
+    sessions: [],
+    related_fids: [],
+    last_updated: isoDaysAgo(DORMANT_THREAD_AGE_DAYS + 5),
+    status: 'active',
+  };
+  writeFileSync(join(threadsDir, 'stale-thread.json'), JSON.stringify(thread, null, 2));
+
+  await absorbThreadSessions();
+
+  const stored = JSON.parse(readFileSync(join(threadsDir, 'stale-thread.json'), 'utf8'));
+  assert.equal(stored.status, 'dormant');
+});
+
+test('A3: the retired ABSORPTION_SESSION_AGE_DAYS constant is gone', () => {
+  assert.equal(ring2.ABSORPTION_SESSION_AGE_DAYS, undefined);
+  const src = readFileSync(new URL('../watchtower-ring2.mjs', import.meta.url), 'utf8');
+  assert.ok(!src.includes('ABSORPTION_SESSION_AGE_DAYS'));
+});

package/templates/scripts/__tests__/assessment-recalibration.test.mjs

@@ -373,9 +373,7 @@ test('R8: the draft-sweep sidecar has a reader — assessRingsAlive surfaces its
     last_run: daysAgo(2),
     projects_scanned: 3,
     items_scanned: 41,
-    freshness_annotated: 2,
     fold_annotated: 4,
-    skipped_projects: [],
     unscanned_items: 0,
     errors: 0,
   }));