create-claude-cabinet 0.51.0 → 0.52.0

package/README.md

@@ -18,8 +18,9 @@ and weigh in when their expertise matters:
 - **Briefings** — project context members read before weighing in
 - **Committees** — members grouped by concern so you convene the right
   experts for the right question
-- **The session loop** — `/orient` briefs you at the start, `/debrief`
-  closes the loop for next time
+- **The session loop** — watchtower keeps your project's state current in
+  the background and hands it to you when a session opens; `/close` ends a
+  session (legacy: `/orient` + `/debrief` by hand)
 
 ## Install
 
@@ -56,25 +57,28 @@ it's done, open Claude Code and run `/onboard`.
 
 ## What You Get
 
-### The Session Loop (always installed)
+### The Session Loop (installed by default)
 
-This is the foundation. You run these commands — they don't happen
-automatically.
+Continuity between sessions, so Claude never starts blind. By default this
+is **watchtower** — a background system that keeps your project's state
+current and hands it to Claude when a session opens.
 
-- **`/orient`** — open every session with this. Claude reads project
-  state, checks health, surfaces what needs attention, and briefs you
-  so you never start blind. Think of it as the briefing before the
-  cabinet gets to work.
-- **`/debrief`** — close every session with this. Claude marks work
-  done, records lessons, updates state, and prepares the briefing for
-  next time. Without debrief, the next orient starts with stale
-  information. The loop is what gives Claude memory across sessions.
+- **Sessions start informed** — watchtower's SessionStart hook injects the
+  current state (what you were working on, what's due, what broke). No
+  start-of-session command to run.
+- **`/briefing`** — review what needs attention across the project.
+- **`/close`** (or **`/session-handoff`**) — end a session; the background
+  rings handle inventory, lesson capture, and routing after you walk away.
 
-**The habit matters.** Orient and debrief take 30 seconds each. Skip
-them and sessions start from zero — Claude forgets what happened,
-repeats mistakes, and you spend the first 10 minutes re-explaining
-context. Keep the loop and each session picks up where the last one
-left off.
+Watchtower is installed by default; its background rings start when you run
+**`/watchtower install`**. Until then it ships the skills and a dormant
+SessionStart hook — nothing runs in the background and no API cost is
+incurred.
+
+**Prefer to run it by hand?** Opt out of watchtower and use the legacy
+loop instead — **`/orient`** at the start (reads state and briefs you) and
+**`/debrief`** at the end (marks work done, records lessons). Both still
+ship, but watchtower replaces them.
 
 ### The Cabinet (included in lean)
 
@@ -129,7 +133,7 @@ you already use GitHub Issues, Linear, or something else.
 Claude Code has built-in file memory, but no guardrails around it.
 The memory module adds structure:
 
-- **`/cc-remember`** — write a new memory with automatic indexing. Every memory gets its own file and is made reachable from `MEMORY.md` — by a direct entry or a region pointer — so `/orient` can find it next session.
+- **`/cc-remember`** — write a new memory with automatic indexing. Every memory gets its own file and is made reachable from `MEMORY.md` — by a direct entry or a region pointer — so the session loop can surface it next session.
 - **`/memory`** — browse and search what Claude remembers.
 - **Validation** — `validate-memory.mjs` checks that the index stays within Claude Code's session-start budget and that every memory file is reachable from `MEMORY.md`. A PostToolUse hook flags unreachable writes in real time.
 
@@ -181,14 +185,17 @@ e2e harness.
 
 The rhythm of each session:
 
-1. **Start a session** → `/orient` (get briefed)
+1. **Start a session** → watchtower briefs you automatically; `/briefing`
+   for the full picture (legacy loop: `/orient`)
 2. **Do your work** → talk to Claude, use `/plan` for anything non-trivial
 3. **Build it** → `/execute` to implement approved plans with cabinet oversight
 4. **Check quality** → `/audit` occasionally for a full cabinet review
-5. **Close the session** → `/debrief` (close the loop)
+5. **Close the session** → `/close` (the rings capture the rest after you
+   walk away; legacy loop: `/debrief`)
 
-Steps 1 and 5 are the minimum. Everything in between is yours to use as
-needed. The more you use, the more the cabinet learns about your project.
+Step 5 is the minimum — start is automatic under watchtower. Everything in
+between is yours to use as needed. The more you use, the more the cabinet
+learns about your project.
 
 ## How It Works
 
@@ -243,7 +250,7 @@ npx create-claude-cabinet --frontier-model claude-fable-5  # Designate your fron
 
 ### Frontier-model watchdog
 
-`--frontier-model <model>` records, once, which model your heavy thinking is supposed to run on. The designation is per-operator (stored in `~/.claude/cc-registry.json` under `frontierModel`, not per-project), and the installer prints the effective value on every run. From then on, `/orient` — and, on watchtower installs, the SessionStart hook — compares the session's actual model against it and leads the briefing with a loud warning on mismatch. The key can be an exact model ID (`claude-fable-5`, exact match required) or a family alias (`fable`, matches any model ID containing it). This is **visibility only**: nothing is pinned, blocked, or rerouted — it just makes "you're accidentally on the wrong model" impossible to miss. A stale key after a model-family transition nags loudly by design; update it with the same flag.
+`--frontier-model <model>` records, once, which model your heavy thinking is supposed to run on. The designation is per-operator (stored in `~/.claude/cc-registry.json` under `frontierModel`, not per-project), and the installer prints the effective value on every run. From then on, the SessionStart hook (on watchtower installs, the default) — and `/orient` on the legacy loop — compares the session's actual model against it and leads the briefing with a loud warning on mismatch. The key can be an exact model ID (`claude-fable-5`, exact match required) or a family alias (`fable`, matches any model ID containing it). This is **visibility only**: nothing is pinned, blocked, or rerouted — it just makes "you're accidentally on the wrong model" impossible to miss. A stale key after a model-family transition nags loudly by design; update it with the same flag.
 
 ## What Gets Installed
 
@@ -252,7 +259,7 @@ source code.
 
 ```
 .claude/
-├── skills/          # orient, debrief, plan, execute, audit, etc.
+├── skills/          # watchtower, plan, execute, audit, orient, debrief, etc.
 │   └── cabinet-*/   # 34 cabinet member definitions
 ├── cabinet/         # committees, lifecycle, composition patterns
 │                    #   (incl. pib-db-access.md, pib-db-triggers.md)
@@ -294,10 +301,10 @@ with Claude everywhere.
 - **Your identity** (`~/.claude/CLAUDE.md`) — set up once, carries to
   every project. Claude always knows who you are and what you do.
 - **Project registry** (`~/.claude/cc-registry.json`) — tracks all
-  your projects. `/onboard` asks how they relate; `/orient` flags
+  your projects. `/onboard` asks how they relate; the session loop flags
   when work in one might affect another.
-- **Debrief maintenance** — if you mention something new about yourself
-  or your project evolves, `/debrief` proposes updating your profile
+- **Profile maintenance** — if you mention something new about yourself
+  or your project evolves, session close proposes updating your profile
   and registry so the next session starts current.
 
 Install in each project folder. They're independent but aware of each

package/lib/modules.js

@@ -15,8 +15,8 @@
 // unchanged.
 const MODULES = {
   'session-loop': {
-    name: 'Session Loop (orient + debrief)',
-    description: 'The briefing cycle. Claude starts each session informed, ends by preparing the next briefing.',
+    name: 'Session Loop (shared verbs + legacy orient/debrief)',
+    description: 'The mandatory session verbs (/menu, /session-handoff) plus the legacy orient/debrief skeletons and their -classic reversibility copies. Watchtower (installed by default) is the live session loop; orient/debrief are the opt-out fallback.',
     mandatory: true,
     templates: [
       'skills/orient',
@@ -209,9 +209,9 @@ const MODULES = {
   },
   watchtower: {
     name: 'Watchtower (continuous background state)',
-    description: 'Replaces orient/debrief with continuous background processing. Three rings (mechanical cron, Claude intelligence, session-aware), ambient state injection via SessionStart hook, and an inbox for extracted knowledge and signals. Sessions start informed with minimal context cost.',
+    description: 'The default session loop. Continuous background processing replaces the legacy orient/debrief skeletons: four rings (mechanical cron, Claude intelligence, session-aware, truth reconciliation), ambient state injection via SessionStart hook, and an inbox for extracted knowledge and signals. Sessions start informed with minimal context cost. Installing the module ships the skills + dormant SessionStart hook; the background rings start only when you run /watchtower install. Opt out to fall back to the legacy orient/debrief loop.',
     mandatory: false,
-    default: false,
+    default: true,
     lean: false,
     templates: [
       'scripts/watchtower-validate.mjs',
@@ -251,6 +251,7 @@ const MODULES = {
       'scripts/watchtower-ring4.mjs',
       'scripts/watchtower-ring4-runner.sh',
       'scripts/watchtower-status.sh',
+      'scripts/memory-consolidation-scan.mjs',
       'skills/briefing',
       'skills/threads',
       'skills/catch-up',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-cabinet",
-  "version": "0.51.0",
+  "version": "0.52.0",
   "description": "Claude Cabinet — opinionated process scaffolding for Claude Code projects",
   "bin": {
     "create-claude-cabinet": "bin/create-claude-cabinet.js"

package/templates/CLAUDE.md

@@ -745,7 +745,9 @@ modules total.
 
 ## session-loop (mandatory)
 
-orient + debrief skeleton skills.
+The LEGACY orient + debrief skeleton skills plus shared session verbs.
+Watchtower (default-installed) is now the live session loop; orient/debrief
+are the opt-out fallback, kept shipping via this mandatory module.
 `/orient` leads with the frontier-model watchdog (core phase #0): compares
 the session model against the per-operator `frontierModel` key in
 `~/.claude/cc-registry.json` (set via the `--frontier-model` installer flag;
@@ -776,9 +778,17 @@ dedup-vs-pending discipline as Ring 3 Phase 2m; see "Session Advisor Pass" in
 UNTRACKED marker with neither — and the rendered line cites the filed id;
 debrief's 16b also verifies persistence.
 Ships `/session-handoff`, the **default session-close verb**: a thin wrapper
-over `/debrief` that runs three phases — (1) debrief, whose
-`qa-handoff-sweep.md` instruction phase performs a `/qa-handoff` for every
-worktree→main merge this session still needs one for; (2) propose a
+over `/close` plus the handoff extras the rings can't own after walk-away
+(act:9ce4dfde — repointed off full `/debrief`, whose ring-redundant capture
+was the defect). It runs three phases — (1) `/close` (commit + push, and on
+a worktree its conditional gated-merge offer), then debrief's
+`qa-handoff-sweep.md` phase (a `/qa-handoff` for every worktree→main merge
+this session still needs one for) and `methodology-capture.md` (the one
+capture phase with no ring twin — Ring 3 only DETECTS an already-written
+`.claude/methodology/` record, it can't author one or ask the four-choice
+question, so it stays on the default path); the heavy debrief capture
+(lessons/knowledge/upstream-friction/session-advisors) is NOT run — the
+rings own it after close; (2) propose a
 next-session seed prompt (non-QA work thread only — QA drains belong to
 window 1's standing station), operator approves/rejects, and ONLY on approve
 launch the next session in a **fresh worktree** (via the `mux handoff
@@ -792,7 +802,9 @@ window is already up): it surfaces this project's watchtower threads/cursors
 in plain English (read-only, temporal-labeled, cap 3) and offers at most one
 well-explained inbox decision (drained via `applyBatch`, gated/dispatched
 categories excluded) — strictly skippable, two frozen sections, growth routes
-to `/briefing`. Plain `/debrief` stays the "nothing queued" close. The sweep
+to `/briefing`. Plain `/close` is the "nothing queued" close; plain
+`/debrief` is the opt-in heavy synchronous capture (kept, off the default
+path — act:9ce4dfde). The sweep
 self-skips without watchtower; the launch degrades to a saved seed path
 without mux; the epilogue self-skips without watchtower.
 Also ships `/orient-classic` and `/debrief-classic` (act:6fa60c7d):
@@ -855,11 +867,16 @@ provider-agnostic email/MCP/file/API transport). 3 primary skills
 for old skill names. `requires: ['work-tracking']` (the pib-db adapter is the
 engine's data source). Evolved from the former handoff module.
 
-## watchtower (opt-in, off by default)
+## watchtower (default-installed, opt-out)
 
-Continuous background state management replacing orient/debrief with four
+THE default session loop. Continuous background state management replacing
+the legacy orient/debrief with four
 processing rings (mechanical cron, Claude intelligence, session-aware,
-periodic truth reconciliation). All four rings implemented: Ring 1
+periodic truth reconciliation). Installing the module ships the skills + a
+dormant SessionStart hook; the metered background rings start only on
+`/watchtower install`, so a fresh default install incurs no API cost until
+the operator activates them. Opt out to fall back to the legacy
+orient/debrief loop. All four rings implemented: Ring 1
 (mechanical heartbeat, 5-min cron; also delivers the global CC feedback
 outbox every tick via `flushFeedbackOutbox()`, ticks declared-routine
 triggers via `runRoutinePass()`, surfaces a READ-ONLY
@@ -1015,9 +1032,13 @@ mid-session awareness refresh — diffs current watchtower state against a
 per-session baseline captured at session start and shows only what CHANGED
 since; new inbox items, advanced/new threads, new/cleared git attention,
 freshly-due deferrals; thin orchestrator over `watchtower-snapshot.mjs`;
-act:a8057f87), `/close` (fast session-end verb — commit + push only; the
-background rings handle inventory/capture/routing after you walk away;
-targets 15–30s, never `--no-verify`; act:8bf86966), and `/qa-handoff`
+act:a8057f87), `/close` (fast session-end verb — commit + push, plus on an
+ORPHANED worktree only (unmerged content AND no qa-handoff filed) a
+conditional offer to land the branch via the existing `/execute` Step 8 /
+qa-handoff merge-now recipe, so the rings don't file `worktree-unmerged`
+(act:9ce4dfde) — `/qa-handoff` stays the primary merge path; the background
+rings handle inventory/capture/routing after you walk away; targets 15–30s,
+never `--no-verify`; act:8bf86966), and `/qa-handoff`
 (package a worktree branch into a surfaced `qa-handoff` inbox item — what
 merged, what the worktree could NOT runtime-verify, what hangs on the next
 step — then push it to the desk's main window via `mux qa dispatch`; usually

package/templates/EXTENSIONS.md

@@ -15,6 +15,13 @@ You and Claude will make different choices for your project. These
 examples show what choices Flow made and why — not what you should do,
 but what's possible.
 
+> **Note — orient/debrief are legacy.** Watchtower is CC's default session
+> loop now; the orient/debrief skeletons used as examples below are the
+> opt-out fallback, and Flow itself has since moved to watchtower. These
+> tables are preserved as a worked example of the **phase-file extension
+> mechanism**, which applies to any skeleton skill — not as a
+> recommendation to build new work on orient/debrief.
+
 
 ## Flow's Phase File Overrides by Skill
 

package/templates/README.md

@@ -47,8 +47,8 @@ templates, see [EXTENSIONS.md](EXTENSIONS.md).
 | `skills/memory/` | Browse, search, validate, and manage built-in memory at `~/.claude/projects/<slug>/memory/`. Writing happens via /cc-remember. |
 | `skills/menu/` | Dynamically discover and display all available skills. Reads from `_index.json`. |
 | `skills/onboard/` | Conversational onboarding. Interviews you, generates briefings, wires the session loop. Re-runnable. 8 phase files. |
-| `skills/orient/` | Session start. Load context, sync data, scan work, run health checks, spawn cabinet consultations, show skills menu. 7 phase files. |
-| `skills/orient-quick/` | Quick orient variant — core phases only, skip presentation. |
+| `skills/orient/` | Session start (legacy loop — watchtower is the default). Load context, sync data, scan work, run health checks, spawn cabinet consultations, show skills menu. 7 phase files. |
+| `skills/orient-quick/` | Quick orient variant (legacy) — core phases only, skip presentation. |
 | `skills/plan/` | Structured planning with cabinet critique. Research, overlap check, draft, critique, completeness, present, file. 9 phase files. |
 | `skills/cc-publish/` | Publish workflow (CC source repo only, not shipped to consumers). |
 | `skills/pulse/` | Self-description accuracy check. Count freshness, dead references, staleness. 3 phase files. |
@@ -173,7 +173,7 @@ into your project's `.claude/` directory. The minimum viable adoption:
 
 You now have git safety and skill discovery. Add more modules as needed:
 
-- **Session loop:** `skills/orient/`, `skills/debrief/`
+- **Session loop (default):** `skills/watchtower/` + the SessionStart hook. Legacy fallback: `skills/orient/`, `skills/debrief/`
 - **Planning:** `skills/plan/`, `skills/execute/`
 - **Audit:** `skills/audit/`, `skills/pulse/`, `skills/triage-audit/`, plus `cabinet/` infrastructure and `scripts/`
 - **Cabinet members:** Copy individual `skills/cabinet-*/` directories for the experts you want

package/templates/briefing/_briefing-template.md

@@ -54,7 +54,7 @@ Template: `_briefing-cabinet-template.md`.
 
 ### `_briefing-work-tracking.md` — Work Tracking
 How the project tracks planned work — storage, query interface,
-mutation interface. Referenced by /plan, /execute, /orient, /debrief.
+mutation interface. Referenced by /plan, /execute, and the session loop.
 Template: `_briefing-work-tracking-template.md`.
 
 ### `_briefing-api.md` — API Configuration

package/templates/briefing/_briefing-work-tracking-template.md

@@ -1,7 +1,7 @@
 # Work Tracking — [Your Project Name]
 
 How this project tracks planned work. Skills that manage work items
-(/plan, /execute, /orient, /debrief) reference this file.
+(/plan, /execute, and the session loop) reference this file.
 
 ## Work Item Storage
 *Where work items live.*
@@ -27,8 +27,8 @@ already tracking. It sits quietly until you unblock it yourself.
 
 **Trigger-gated deferral** is for work waiting on an identifiable
 external condition — a dependency landing, a stack decision
-finalizing, a referenced file appearing. Every session, orient
-re-evaluates each trigger against the current session's context
+finalizing, a referenced file appearing. Every session, the session
+loop re-evaluates each trigger against the current session's context
 and surfaces items whose conditions have fired. Use
 `pib_defer_with_trigger` (or `defer-with-trigger` CLI). See
 `cabinet/pib-db-triggers.md` for the full convention.

package/templates/cabinet/_cabinet-member-template.md

@@ -26,11 +26,13 @@ briefing:
   # Add other briefing files relevant to this member's domain
   # Common: .claude/cabinet/_briefing-architecture.md, _briefing-jurisdictions.md, _briefing-api.md
 standing-mandate: audit
-  # Add plan, execute, orient, debrief if this member should activate
-  # in those contexts. Most members are audit-only. Two session-boundary
-  # contexts exist for standing advisors (watchtower installs):
-  # session-close (Ring 3's automatic transcript-fed advisor pass) and
-  # briefing (/briefing's live advisor panel).
+  # Add plan or execute if this member should activate in those contexts.
+  # Most members are audit-only. Two session-boundary contexts exist for
+  # standing advisors (watchtower is the default loop): session-close
+  # (Ring 3's automatic transcript-fed advisor pass) and briefing
+  # (/briefing's live advisor panel). The legacy orient/debrief contexts
+  # still work on projects that opted out of watchtower, but new advisors
+  # should use session-close/briefing.
 tools:
   # List every external tool/command this member uses.
   # Format: "tool-name (scope -- what it does)"
@@ -40,8 +42,9 @@ tools:
   #   - grep patterns (all projects -- dead code detection)
   # Use "tools: []" for pure-reasoning members with no tool stage.
 directives:
-  # Only if standing-mandate includes plan, execute, orient, debrief,
-  # session-close, or briefing. Each directive is a one-sentence focused
+  # Only if standing-mandate includes plan, execute, session-close,
+  # briefing, or (legacy loop) orient, debrief. Each directive is a
+  # one-sentence focused
   # task for that context. A mandate without a matching directive is a
   # data error — consumers skip the member and say so.
   # plan: >

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

@@ -115,6 +115,22 @@ into a corner):
   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.
+
+  **Evidence this verb has real work (act:421a8ab2, N5 of
+  grp:retro-remeaning):** two blind reads of the maginnis durable-memory
+  corpus (2026-07-19) found ~47-60% of sampled files involved in a hard
+  duplicate — overwhelmingly outage-recovery extractions and the
+  2026-07-14 read-pass, both bulk-written without a MEMORY.md index line
+  (region-pointer-covered instead), which made the dedup structurally
+  blind to them. `templates/scripts/memory-consolidation-scan.mjs` is the
+  dry-run PROPOSAL half of this verb, built ahead of the full Stage 2 gate:
+  it reuses the (now overlap-coefficient, dual-scored — see
+  `proposeFolds` in `watchtower-queue.mjs`) fold detector over an actual
+  memory directory's files instead of the pending inbox queue, and reports
+  candidate pairs with a `consolidated_from` pointer. It never merges or
+  writes — the human decides. Running the full MERGE half (rewriting
+  files, folding gists) is still gated on the spill-rate data per this
+  contract; the scan only proposes what the merge would act on.
 - **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

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

@@ -336,6 +336,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

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/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