@jeffober/thatch 0.2.6 → 0.2.8

package/docs/dev/features/session-lifecycle.md

@@ -13,6 +13,7 @@ opencode emits bus events for session lifecycle changes. Thatch subscribes to th
 - Sub-agent lifecycle: task-dispatched sub-agents complete accepted entries but are not deleted
 - Session error recovery: child errors requeue parent's accepted entries
 - Session deletion recovery: child deletion requeues; parent deletion completes accepted entries
+- Stranded-session self-heal: sessions whose recorded directory is gone (a merged + deleted worktree) are deleted when machinery (`thatch-extraction` corpses) and moved to the project's canonical checkout when real
 - Wrap-up commands: `/thatch/compact` and `/thatch/exit` arm a greenlight check resolved on the next idle
 
 ## How it works
@@ -118,6 +119,40 @@ first-ever install is invisible until the next server start.
 - Clear the `compacting` flag so chat.message nudges resume
 - See [compaction-recovery.md](compaction-recovery.md)
 
+### Stranded-session self-heal sweep
+
+Why it exists: opencode v2 records a directory on every session row, and
+opening a session whose directory is gone (a merged + deleted worktree) boots
+a dead path and shows the "session location unavailable" recovery dialog.
+Sessions get stranded there in two ways: extraction children leaked by hosts
+older than v2.0.22 (whose session domain had no `remove`, so cleanup was a
+silent no-op) and children whose idle event died with a daemon restart. The
+sweep runs at setup and on an interval (`THATCH_STRAND_SWEEP_MS`), and the
+rehydrate pass finalizes journaled extraction children through the host
+before pruning their rows, so both the corpse population and the leak paths
+are covered.
+
+What it does, decided by `planStrandActions` (pure, unit-tested):
+
+- Sessions in a live directory are never touched, whatever the row looks like
+- Machinery (`thatch-extraction` title) in a dead directory: delete via the
+  host's session delete
+- Real top-level sessions in a dead directory: MOVE to the project's
+  canonical checkout (`project.worktree` in opencode.db) -- the same outcome
+  as the manual recovery dialog, minus the picking; history is preserved and
+  user sessions are never deleted
+- Host-created task children (parentId set): always skipped -- they are
+  opencode's own records of subagent work and deleting them would break the
+  parent transcript's subagent rendering
+- Unresolvable canonical or no move endpoint: skipped and logged
+
+The host supplies the enumeration (v1: `client.session.list`; v2: readonly
+read of opencode.db, since the promise domain has no session list and the
+sweep needs machine-wide rows) plus the move/delete endpoints; every leg
+degrades silently. A summary toast fires only when something was healed. Set
+`THATCH_STRAND_SWEEP=off` to disarm the sweep entirely (tests do, so it can
+never act on a developer's real database through mocks).
+
 ### Internal state maps
 
 - **childToParent**: `Map<childID, parentID>` -- maps child sessions to their parents

package/docs/dev/features/session-tabs.md

@@ -147,8 +147,9 @@ dependency for the TUI entry's runtime resolution.
 ## Testing
 
 - Unit: `tests/session-tab-shared.test.ts` (validators, definition shape,
-  guard logic), `tests/opencode-v2.test.ts` (the execute flows' ordering via
-  the `makeContext` double with `session.move` + the `rpc` domain).
+  guard logic), `tests/opencode-v2-adapter-tabs.test.ts` (the execute flows'
+  ordering via the `makeContext` double with `session.move` + the `rpc`
+  domain).
 - QA: uc-059 (tool list + MCP leak check), uc-014/uc-060 (skill counts),
   uc-119 (the live spawn flow through the docker sandbox).
 - Live smoke (recorded 2026-10-08, ALL SCENARIOS PASSED): headless legs -

package/docs/dev/features/watchers.md

@@ -291,9 +291,11 @@ src/watchers.ts, test-enforced).
   session.status tracking, session.deleted cleanup, dispose
 - `src/prompts.ts` - `watcherNotificationNudge()`, system prompt
   Watchers section
-- `tests/watchers.test.ts` - registry, poll, and diff unit tests
+- `tests/watchers-registry.test.ts` - registry, poll, and death-detection unit tests
+- `tests/watchers-git-state.test.ts` - PR/branch diff and check-run description unit tests
+- `tests/watchers-commands.test.ts` - command watcher and poll-resilience unit tests
   (mocked gh and command runners, no network)
-- `tests/tool-defs.test.ts` - watch tool execute-function tests
+- `tests/tool-defs-watch-chat.test.ts` - watch tool execute-function tests
 - `tests/qa/auto/uc-095-watchers.ts` - end-to-end lifecycle against a
   mocked gh runner
 - `tests/qa/auto/uc-101-command-watchers.ts` - command-watch lifecycle

package/docs/dev/skills.md

@@ -43,6 +43,7 @@ description: Extract durable project facts ... Use when ...
 | `thatch-review-state-flow` | Data flow and contracts: module boundaries, implicit FSMs, error propagation. |
 | `thatch-review-economy` | Design simplicity and maintainability: is the complexity earned? Evaluates both the overall change design (forest) and individual touch points (trees) for unnecessary complexity, redundancy, and simpler available alternatives. |
 | `thatch-review-no-slop` | AI writing anti-patterns: change narration, fourth-wall breaks, em dashes, filler. |
+| `thatch-review-clarity` | Prose clarity in comments, docstrings, error strings, and docs: made-up phrases, buzzwords, untranslated jargon, clause chains, buried leads, doc/code responsibility splits, checked against the project's clear-writing rules regardless of who wrote the text. |
 | `thatch-review-breadcrumbs` | Comment narrative: do comments form a coherent outline of behavior? |
 | `thatch-review-mark-and-sweep` | Mechanical change completeness: whole-repo sweep for stragglers after renames, flag removals, API substitutions. |
 | `thatch-review-highlights` | Positive finding detection: notably clever solutions, cleanup done along the way, documentation that helps. Medium-high bar against generic praise. |
@@ -79,7 +80,7 @@ description: Extract durable project facts ... Use when ...
 
 ## REVIEW_COMMON
 
-The seven problem-finding review specialists share a framework interpolated via `${REVIEW_COMMON}` (the technique and highlights specialists do not use it: technique reports informational notes and highlights finds positive things, each with its own structure):
+The problem-finding review specialists share a framework interpolated via `${REVIEW_COMMON}` (the technique and highlights specialists do not use it: technique reports informational notes and highlights finds positive things, each with its own structure):
 
 - **Static analysis only** — no running tests/linters/compilers.
 - **Scope gathering** — resolve the git range, `git diff --stat`, read changed

package/docs/user/README.md

@@ -202,7 +202,7 @@ requirements.
 | Tool | What it does |
 |------|-------------|
 | `thatch_chat_register` | Join the cross-session chat directory, so other sessions on this machine can message you. Display names are assigned by thatch, never chosen (a pool name plus a never-reused counter), so a name always refers to the same session. Call with no arguments to join, rejoin after unregistering, or check your name. On hosts without session context (Claude Code, Cursor), pass the name your thatch hook printed as `as`. |
-| `thatch_chat_list` | List registered sessions grouped into Active and Stale sections (stale = two missed heartbeats, about a minute; its host process has probably stopped), with how long ago each last checked in, each session's project and checkout kind (project root or linked worktree), its topic, and your unread count. |
+| `thatch_chat_list` | List registered sessions grouped into Active, Recent, and Stale sections (recent = alive but no open tab, so a wake may not be guaranteed; stale = two missed heartbeats, about a minute; its host process has probably stopped), with how long ago each last checked in, each session's project and checkout kind (project root or linked worktree), its topic, and your unread count. |
 | `thatch_chat_send` | Send a message to another registered session, by name or session id. The recipient is nudged when its session is idle. |
 | `thatch_chat_read` | Drain your inbox: all unread messages oldest-first, marked read. Senders identified by display name. |
 | `thatch_chat_unregister` | Leave the chat directory. |
@@ -331,6 +331,7 @@ response, walkthrough, and workflow skills that support the review pipeline:
 | `thatch-review-state-flow` | Data flow and contracts: module boundaries, implicit state machines, error propagation, separation of concerns. |
 | `thatch-review-economy` | Design simplicity and maintainability: is the complexity earned? Evaluates both the overall change design (forest) and individual touch points (trees) for unnecessary complexity, redundancy, and simpler available alternatives. |
 | `thatch-review-no-slop` | AI writing anti-patterns: change narration, fourth wall breaks, em dashes, hedging, filler. |
+| `thatch-review-clarity` | Prose clarity in comments, docstrings, error strings, and docs: made-up phrases, buzzwords, untranslated jargon, clause chains, buried leads, doc/code responsibility splits, checked against the project's clear-writing rules regardless of who wrote the text. |
 | `thatch-review-breadcrumbs` | Comment narrative: do comments form a coherent outline of the code's behavior? |
 | `thatch-review-mark-and-sweep` | Mechanical change completeness: whole-repo sweep for stragglers after renames, flag removals, API substitutions. |
 | `thatch-review-highlights` | Positive finding detection: notably clever solutions, cleanup done along the way, documentation that helps. Medium-high bar against generic praise. |
@@ -406,7 +407,7 @@ specialist in sequence, then synthesize:
 ```text
 1. Load thatch-review-pedantic, review branch feature-x, report findings.
 2. Load thatch-review-acceptance, review the same branch.
-3. ... repeat for state-flow, no-slop, breadcrumbs, mark-and-sweep ...
+3. ... repeat for state-flow, no-slop, clarity, breadcrumbs, mark-and-sweep ...
 4. Load thatch-review-synthesizer, verify and aggregate all findings.
 ```
 

package/docs/user/cli.md

@@ -4,6 +4,10 @@ Thatch ships with a command-line tool for inspecting memories and
 running maintenance tasks outside the agent. It requires `bun` on your
 PATH.
 
+`thatch --help` (or `-h`) prints the full command list and exits 0.
+The flag works anywhere in the command line: `thatch chat list -h`
+shows help instead of running the command.
+
 ## Memory inspection
 
 ```bash
@@ -45,7 +49,8 @@ Read-only access to the chat directory your opencode sessions share
 (see [cross-session-chat.md](cross-session-chat.md)):
 
 ```bash
-thatch chat list               # who is registered: name, age, project, topic
+thatch chat list               # who is open now: name, age, project, topic
+thatch chat list --recent      # also show alive sessions with no open tab
 thatch chat list --stale all   # also show stale sessions older than a day
 thatch chat tail               # follow sent and read events, live (JSONL)
 thatch chat tail --once        # print the last 20 messages and exit
@@ -55,21 +60,28 @@ thatch chat tail --from al --to bob        # substring match on names
 thatch chat tail --since 2026-09-12 --until "2026-09-13 09:00"   # a window
 ```
 
-`chat list` shows every registered session in two sections, Active and
-Stale, each as aligned columns under a header row: how long since its
-last heartbeat, its status (`open` - a tab is open now - or `recent` -
-host alive, no open tab - for opencode sessions;
-`active` or `idle` for Claude Code and Cursor sessions, which only beat
-when a prompt runs), its project, and its topic (the session's title) -
-the fastest way to answer "which session should I talk to about X?"
-Rows are grouped by project (alphabetical; sessions with no project
-last), most recently seen first within each project. A
-stale session has missed two heartbeats, about a minute: the opencode
-process hosting it has probably stopped. The stale section shows rows
-up to one day old by default; older ones collapse into a hidden-count
-note so long-dead sessions cannot bury the fresh signal. Pass
-`--stale N` (days) to widen the window or `--stale all` to see every
-stale row. Color is added only when the
+`chat list` renders the chat roster in three sections - Active, Recent,
+and Stale - each as aligned columns under a header row: how long since its last heartbeat, its status (`open` - a tab is open now - or
+`recent` - host alive, no open tab - for opencode sessions; `active` or
+`idle` for Claude Code and Cursor sessions, which only beat when a
+prompt runs), its project, and its topic (the session's title) - the
+fastest way to answer "which session should I talk to about X?" Rows
+are grouped by project (alphabetical; sessions with no project last),
+most recently seen first within each project.
+
+The default view shows the sessions you can wake or reach now: open
+sessions plus Claude Code and Cursor rows, which read mail at their
+next prompt. A recent session - its harness is alive but its tab is
+closed, so a wake may not reach it until the tab reopens - collapses
+into a muted hidden-count note pointing at `--recent`, which reveals
+the Recent section. A stale session has missed two heartbeats, about a
+minute: the opencode process hosting it has probably stopped. Its
+section is hidden too, behind `--stale`, but without a count note - the
+default view simply drops stale rows. The stale section
+shows rows up to one day old by default; older ones collapse into a
+hidden-count note so long-dead sessions cannot bury the fresh signal.
+Pass `--stale N` (days) to widen the window or `--stale all` to see
+every stale row. Color is added only when the
 output is a terminal; a pipe prints plain aligned text.
 
 `chat tail` prints the conversation as a JSONL event log: one JSON

package/docs/user/code-review.md

@@ -25,7 +25,7 @@ the review:
 3. **Research affected workflows**: load `thatch-code-archaeology`,
    trace the code paths the change touches.
 4. **Estimate complexity**: partition the diff into review units.
-5. **Dispatch specialists**: fan out the nine specialists as
+5. **Dispatch specialists**: fan out the specialists as
    parallel sub-agents, each with the context brief.
 6. **Synthesize**: the synthesizer reads all specialist output,
    verifies each finding (cited text exists, claim is accurate,
@@ -38,7 +38,7 @@ the review:
    sibling is not a defect, and inconsistencies between connected
    PRs surface as cross-PR notes.
 
-## The nine specialists
+## The specialists
 
 | Skill | What it checks |
 |-------|-------------|
@@ -47,6 +47,7 @@ the review:
 | `thatch-review-state-flow` | Module boundaries, implicit state machines, error propagation, separation of concerns. |
 | `thatch-review-economy` | Design simplicity and maintainability: is the complexity earned? Evaluates both the overall change design (forest) and individual touch points (trees) for unnecessary complexity, redundancy, and simpler available alternatives. |
 | `thatch-review-no-slop` | AI writing anti-patterns: change narration, fourth wall breaks, em dashes, hedging, filler. |
+| `thatch-review-clarity` | Prose clarity in comments, docstrings, error strings, and docs: made-up phrases, buzzwords, untranslated jargon, clause chains, buried leads, doc/code responsibility splits, checked against the project's clear-writing rules regardless of who wrote the text. |
 | `thatch-review-breadcrumbs` | Comment narrative: do comments form a coherent outline of the code's behavior? |
 | `thatch-review-mark-and-sweep` | Mechanical change completeness: whole-repo sweep for stragglers after renames, flag removals, API substitutions. |
 | `thatch-review-highlights` | Positive finding detection: clever solutions, cleanup done along the way, documentation that helps. Medium-high bar. |
@@ -61,7 +62,7 @@ Two slash commands run the same pipeline with the findings weighted for
 whose work is under review.
 
 - `/thatch/self-review` reviews your own completed work before you
-  submit it. The slop, technique, and breadcrumbs lenses weigh
+  submit it. The slop, clarity, technique, and breadcrumbs lenses weigh
   heaviest, simplicity is overweighted on shared projects, and
   technique or highlights findings that would simplify the design are
   surfaced for an adopt-or-dismiss decision rather than left as

package/docs/user/cross-session-chat.md

@@ -25,11 +25,12 @@ explicitly with `thatch_chat_register` (no arguments) - useful after
 `chat_unregister`, or just to check your assigned name. Once registered:
 
 - `thatch_chat_list` shows every registered session on the machine, grouped
-  into Active and Stale sections: active sessions' harness is alive; stale
+  into Active, Recent, and Stale sections: active sessions either have an
+  opencode tab open right now or are Claude Code and Cursor rows, which
+  read mail at their next prompt; recent ones are alive but have no open
+  tab, so a wake may not reach them until the tab reopens; stale
   ones have missed two heartbeats, about a minute (the opencode process
-  hosting them has probably stopped). Each active row also carries a
-  liveness verdict: `open` means the session has an opencode tab open
-  right now, `recent` means the harness is alive but no tab is open. Each
+  hosting them has probably stopped). Each
   row carries how long ago the session last
   checked in, its project, whether it runs in the project root or a linked
   git worktree, its topic, and your unread count

package/docs/user/skills.md

@@ -43,6 +43,7 @@ Skills are split into shared (all hosts) and opencode-only:
 | `thatch-review-state-flow` | Data flow and contracts: module boundaries, implicit state machines, error propagation, separation of concerns. |
 | `thatch-review-economy` | Design simplicity and maintainability: is the complexity earned? Evaluates both the overall change design (forest) and individual touch points (trees) for unnecessary complexity, redundancy, and simpler available alternatives. |
 | `thatch-review-no-slop` | AI writing anti-patterns: change narration, fourth wall breaks, em dashes, hedging, filler. |
+| `thatch-review-clarity` | Prose clarity in comments, docstrings, error strings, and docs: made-up phrases, buzzwords, untranslated jargon, clause chains, buried leads, doc/code responsibility splits, checked against the project's clear-writing rules regardless of who wrote the text. |
 | `thatch-review-breadcrumbs` | Comment narrative: do comments form a coherent outline of the code's behavior? |
 | `thatch-review-mark-and-sweep` | Mechanical change completeness: whole-repo sweep for stragglers after renames, flag removals, API substitutions. |
 | `thatch-review-highlights` | Positive finding detection: notably clever solutions, cleanup done along the way, documentation that helps. Medium-high bar. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jeffober/thatch",
-  "version": "0.2.6",
+  "version": "0.2.8",
   "description": "Persistent memory for AI coding agents — local embeddings, SQLite stores, zero config. Works with OpenCode (as a plugin), Claude Code (as an MCP server), and Cursor (as an MCP server).",
   "type": "module",
   "main": "src/index.ts",

package/src/capabilities.ts

@@ -77,6 +77,28 @@ export interface HostCapabilities {
   sessionGet(id: string): Promise<{ title?: string } | null>;
   /** List sessions in this directory. Null when unavailable (v2 degrade). */
   sessionList(): Promise<{ id: string; parentID?: string; time?: { updated?: number } }[] | null>;
+  /**
+   * Enumerate every session the host knows (id, title, directory, parent
+   * link, project link) plus each project's canonical checkout directory,
+   * for the runtime's stranded-session sweep. v1 maps client.session.list();
+   * v2 reads opencode.db readonly (its promise domain has no session list
+   * and the sweep needs machine-wide rows, not per-directory ones). Null
+   * when the host has no enumeration surface or the read fails - the sweep
+   * treats null as "nothing known, do nothing".
+   */
+  enumerateSessions(): Promise<{
+    sessions: { id: string; title: string; directory: string; parentId: string | null; projectId: string | null }[];
+    canonicalByProject: Record<string, string>;
+  } | null>;
+  /**
+   * Move a session to another directory. The strand sweep's self-heal for
+   * real sessions stranded in a deleted worktree (deletion is reserved for
+   * machinery sessions); moving is exactly what opencode's own
+   * "session location unavailable" recovery dialog does, minus the
+   * directory picking. Optional: the v1 SDK has no move endpoint, so the
+   * v1 adapter omits it and the sweep degrades to machinery-only deletion.
+   */
+  sessionMove?(id: string, directory: string): Promise<void>;
   /**
    * Fetch a session's message list (wrap-up greenlight check, alert round
    * classification). Null when unavailable. v2 reads them via
@@ -148,6 +170,20 @@ export function capabilitiesFromClient(client: PluginInput["client"]): HostCapab
       const { data } = await client.session.list();
       return data ?? null;
     },
+    enumerateSessions: async () => {
+      const { data } = await client.session.list();
+      if (!data) return null;
+      return {
+        sessions: data.map((s) => ({
+          id: s.id,
+          title: s.title ?? "",
+          directory: (s as { directory?: string }).directory ?? "",
+          parentId: (s as { parentID?: string }).parentID ?? null,
+          projectId: null,
+        })),
+        canonicalByProject: {},
+      };
+    },
     sessionMessages: async (id) => {
       const { data } = await client.session.messages({ path: { id } });
       // Map the message-level error (if any) to its name - the alert

package/src/chat.ts

@@ -389,31 +389,41 @@ export function sortChatRoster(rows: ChatSessionRow[]): ChatSessionRow[] {
   });
 }
 
-/** Splits the roster for the two-section display: Active (wake-able or
- *  reachable - fresh opencode rows and every MCP row, which read mail at
- *  their next prompt) and Stale (opencode rows whose harness has stopped
- *  reporting; mail to them waits until they resume).
+/** Splits the roster for the three-section display: Active (wakeable or
+ *  reachable - opencode rows with an open tab, plus every MCP row, which
+ *  read mail at their next prompt), Recent (fresh opencode rows with no
+ *  open tab: the harness is alive and beating, but a wake may not reach
+ *  the session until its tab reopens - headless subordinates may still
+ *  read mail on their own turns), and Stale (opencode rows whose harness
+ *  has stopped reporting; mail to them waits until they resume).
+ *  openTabs refines fresh opencode rows into open versus recent; when
+ *  omitted every fresh opencode row degrades to recent, never a false
+ *  open (chatLiveness's rule).
  *  staleCapMs bounds how old a stale row the roster displays, so
  *  long-dead sessions cannot bury the fresh signal; hidden rows come
  *  back only as the staleHidden count, so the CLI can say what it left
  *  out. null (the default) shows every stale row - the tool surface has
  *  no cap, only the CLI applies one. */
-export function splitChatRoster(rows: ChatSessionRow[], now = Date.now(), staleCapMs: number | null = null): { active: ChatSessionRow[]; stale: ChatSessionRow[]; staleHidden: number } {
+export function splitChatRoster(rows: ChatSessionRow[], now = Date.now(), staleCapMs: number | null = null, openTabs?: ReadonlySet<string>): { active: ChatSessionRow[]; recent: ChatSessionRow[]; stale: ChatSessionRow[]; staleHidden: number } {
   const active: ChatSessionRow[] = [];
+  const recent: ChatSessionRow[] = [];
   const stale: ChatSessionRow[] = [];
   let staleHidden = 0;
   for (const row of rows) {
-    if (chatLiveness(row, now) === "stale") {
+    const verdict = chatLiveness(row, now, openTabs);
+    if (verdict === "stale") {
       if (staleCapMs !== null && now - Date.parse(row.last_seen) > staleCapMs) {
         staleHidden++;
       } else {
         stale.push(row);
       }
+    } else if (verdict === "recent") {
+      recent.push(row);
     } else {
       active.push(row);
     }
   }
-  return { active, stale, staleHidden };
+  return { active, recent, stale, staleHidden };
 }
 
 /**

package/src/commands.ts

@@ -192,7 +192,7 @@ ${reviewPipelineCouching}
 
 ## Self review mode rules
 
-- The reputation lenses weigh heaviest. NoSlop, Technique, and Breadcrumbs findings outrank same-severity findings from the other lenses. AI-writing tells, vague comments, and a missing narrative are exactly what this review exists to catch before anyone else sees them.
+- The reputation lenses weigh heaviest. NoSlop, Clarity, Technique, and Breadcrumbs findings outrank same-severity findings from the other lenses. AI-writing tells, unclear prose, and a missing narrative are exactly what this review exists to catch before anyone else sees them.
 - Overweight simplicity on shared projects. Prefer findings that make the design easier to understand, easier to test, and more reliable: fewer assumptions, less surface area for bugs and side effects.
 - Technique and highlights findings are decisions, not footnotes. Each one that would produce a simpler, clearer, or more reliable design is surfaced for an adopt-or-dismiss decision before submission. Work through them with the user one at a time; do not leave them as informational asides.
 - Iterate rounds. After each round, work the findings with the user: fix each, or explicitly decline it with a reason. Then run another full round on the updated state. A round is meaningful when it produces a MEDIUM or higher finding, or a technique or slop finding worth adopting. A round producing only LOW mechanical findings gets them fixed but does not trigger another round. Stop at the first round with no meaningful findings, and never run more than three rounds.`,

package/src/opencode/v2.ts

@@ -5,6 +5,7 @@ import type { ToolContext as V2ToolContext } from "@opencode/plugin/promise/tool
 import type { ThatchDB } from "../db";
 import type { HostCapabilities, PromptPart, ToastInput } from "../capabilities";
 import { createRuntime } from "../runtime";
+import { enumerateSweepSessions } from "../session-db";
 import { wrapUpCommandContent, wrapUpCommandDescription } from "../commands";
 import { deriveTitle } from "../extraction";
 import { detectRepo, detectWorktreeKind } from "../git";
@@ -929,6 +930,20 @@ function buildCapabilities(
       return (await session.get({ sessionID: id })) ?? null;
     },
     sessionList: async () => null,
+    enumerateSessions: async () => {
+      // The promise domain has no session list, and the strand sweep needs
+      // machine-wide rows (dead-worktree sessions belong to no live
+      // instance), so this reads opencode.db directly - the same readonly
+      // pattern the -c inheritance resolution already uses. Null on any
+      // schema drift; the sweep treats that as "nothing known".
+      return enumerateSweepSessions();
+    },
+    sessionMove: async (id, directory) => {
+      // The pinned dev types carry move on the SessionDomain pick (the
+      // session_tab spawn flow uses it), so this is a typed call, unlike
+      // remove/compact above.
+      await session.move({ sessionID: id, directory });
+    },
     sessionMessages: async (id) => {
       // The pinned promise domain has no message-list endpoint (no `message`
       // accessor; compact/remove exist on newer SDK builds but not here).

package/src/prompts.ts

@@ -19,6 +19,7 @@ export const REVIEW_SPECIALISTS: readonly string[] = [
   "thatch-review-state-flow",
   "thatch-review-economy",
   "thatch-review-no-slop",
+  "thatch-review-clarity",
   "thatch-review-breadcrumbs",
   "thatch-review-mark-and-sweep",
   "thatch-review-highlights",