projmux 0.14.2 → 0.15.0

package/docs/cli-guide.md

@@ -87,13 +87,23 @@ root bridges and reject missing, duplicate, conflicting, or unknown rows.
 
 ## Resource selectors and the active target
 
+Plural Registry reads (`get projects|windows|panes|agents`) default to
+`NAME STATUS ACTIONS`: the route already selects the kind. Removing the previous
+KIND column changes these tables from four columns to three and moves NAME,
+STATUS and ACTIONS one position left, so existing positional parsers can break.
+Use `-o wide` to retain KIND, context, source/observation, owner chain, session,
+termination and age; `-o json` retains each resource's `kind`, full resource and
+invocation context. Mixed Registry/Runtime pickers keep KIND in both profiles.
+Wide stdout preserves full values at every terminal width. See [Column profiles](column-profiles.md)
+for the exact per-kind matrix and migration from the previous default output.
+
 The resource routes (`get`, `describe`, `create`, `rename`, `rebind`, `delete`,
 `agent resume`) address stored resources through one shared selector grammar.
 
 The grammar in one paragraph: a value is either `uid:<uid>` or a bare
 `metadata.name`. There is no bare-uid form, values are never split on commas,
-and a `displayName`, a `spec.root` path, or a raw tmux `%N`/`@N`/`$N` handle
-never resolves anything. `--project`/`-p` occurs at most once and fixes the
+and an ephemeral context value, a `spec.root` path, or a raw tmux
+`%N`/`@N`/`$N` handle never resolves anything. `--project`/`-p` occurs at most once and fixes the
 Project scope; `--window`/`-w` and `--pane` repeat and union in argv order;
 `--selector key=value`
 repeats and ANDs. A singular route also accepts the target as a positional
@@ -182,13 +192,25 @@ their existing meaning and include ControlSession descendants. Outside tmux, an
 omitted root keeps the historical whole-Registry inventory without probing a
 default server.
 
+For the four Registry-backed plural reads, `get
+projects|windows|panes|agents -o json` adds a top-level `context` object to
+every resource item. Its `value`, `source`, and `observed` keys are always
+present, including as empty strings and `false` when no context is available.
+The values come from the same invocation snapshot used to resolve and render
+the item: only an exact UID-bound live Window name or Pane title sets
+`observed: true`; Project and Agent context, Registry fallbacks, and unmatched
+runtime objects remain unobserved. This is a read projection, not stored
+resource state or selector authority. It does not change `-o metadata`, the
+Registry or snapshot schema, singular `describe ... -o json`, or `get pane -o
+json`; an empty plural result remains one List document with `"items": []`.
+
 ### Reference scope: the active Project namespace
 
-A `metadata.name` is unique inside its owner scope, never across the registry: a
-Window name is unique inside its Project, a Pane name inside its Window or
-Agent, an Agent name inside its Window. So inside a managed Project a reference
-is resolved inside the Project that owns the active Window, which is the same
-universe the plural reads use in that context:
+A descendant `metadata.name` is unique across its Project or ControlSession root
+for the same kind, never across the whole registry. Direct ownership remains
+Window-owned for Agents and Window/Agent-owned for Panes. Inside a managed root,
+a bare descendant name is therefore resolved in the root that owns the active
+Window, which is the same universe the plural reads use in that context:
 
 ```
 projmux describe window zsh    # the Window named zsh in *this* Project
@@ -248,17 +270,59 @@ flag alone:
 projmux create codex                       # active Project, active Window, split from the active Pane
 projmux create codex -p alpha -w hi --create-window  # exact Project, new Window "hi"
 projmux create codex -p beta -w main        # everything explicit
-projmux create pane -p alpha                # every Window of alpha; a deliberate fan-out
+projmux create pane -p alpha                # exactly alpha's primary Window
+projmux create pane -p alpha --all-windows  # every Window of alpha; a deliberate fan-out
 ```
 
-One explicit scope occurrence (`--project`, `--window`, `--pane`, or
-`--selector`) makes the whole scope explicit, so naming a Window never picks up
-an anchor from somewhere you did not address. With a scope but no `--pane`, the
+One explicit scope occurrence (`--project`, `--window`, `--pane`, `--selector`,
+`--all-windows`, or `--primary-window`) makes the whole scope explicit, so
+naming a Window never picks up an anchor from somewhere you did not address.
+With a scope but no `--pane`, the
 split anchor is the target Window's role-agnostic `spec.anchorPaneRef`. A
 shell-required offline operation may plan a lazy direct
 `spec.defaultShellPaneRef` without replacing an Agent anchor. A missing or stale
 anchor is exit `2` rather than a silent alternate-Pane repair.
 
+#### Target cardinality
+
+`create pane|agent|<provider>` targets a *set* of Windows, and the argv says
+which set:
+
+| spelling | target set |
+| --- | --- |
+| whole scope omitted, inside a managed Pane | the active Window, anchored on the active Pane |
+| `--project P` alone | exactly `P`'s `spec.primaryWindowRef` Window |
+| `--project P --primary-window` | the same Window, spelled out |
+| `--project P --all-windows` | **every Window of P**; the opt-in fan-out |
+| `--project P --window W...` | the named Windows, deduplicated in argv order |
+| `--project P --selector k=v...` | the Windows whose labels match; zero matches refuses |
+| `--project P --pane X...` | the owning Window of each named Pane |
+| `--create-window --window <name>` | the ensured Window |
+
+`--project P` with no Window selector means exactly one Window: the Project's
+`spec.primaryWindowRef`. An earlier release spelled the same thing as "every
+Window of P" and spent a release printing a deprecation notice naming this
+default and both flags; the notice is gone now that the default is what it
+named. The whole-Project fan-out is not gone with it -- it is `--all-windows`,
+which resolves the identical set that spelling used to resolve.
+
+Omitting the scope entirely is a different thing and did not change. Inside a
+managed Pane, `projmux create pane` with no `--project` at all still splits the
+Window you are looking at, anchored on the Pane you are in.
+
+`--all-windows` and `--primary-window` each fix the target set outright, so
+neither can be combined with `--window`, `--pane`, `--selector`,
+`--create-window`, or with the other one. Every such pair is exit `2` before any
+Registry write, tmux object, or provider launch. An empty `--all-windows` set
+refuses the same way, and so does a missing, dangling, or cross-Project
+`spec.primaryWindowRef` -- for `--primary-window` and for the bare `--project`
+default alike, since they share one preflight. The refusal names the spelling
+you actually typed.
+
+The `-o receipt` projection reports the target planner's decision in
+`selectedWindowUIDs`, so `create pane`, `create agent`, and the three provider
+shortcuts report the identical selected set for identical argv.
+
 An exact existing Window or Pane can reveal its owner Project through Registry
 `ownerRef`. A Window named with `--create-window` does not exist yet and cannot;
 without `--project` that spelling refuses and names `--project <ref>` as the
@@ -331,13 +395,15 @@ managed-menu contract.
 then updates only its exact UID-bound live transport field:
 
 - Project: `@projmux_project_name` (never the tmux session name)
-- Window: `@projmux_window_name` (never `metadata.displayName` or tmux
-  `window_name`)
+- Window: `@projmux_window_name` (never tmux `window_name`)
 - Pane: `@projmux_pane_label` (never raw `pane_title`)
 
-`rename agent` changes only the Agent's stable Window-scoped `metadata.name`.
+`rename agent` changes only the Agent's stable root-scoped `metadata.name`.
 It does not change the Agent topic, provider, lifecycle state, or managed Pane
-name/title. `rebind project` preserves uid and session name, moves no files,
+name/title. `create agent` derives the managed Pane's name from the Agent's
+once, at create; nothing keeps the two in sync afterwards, so `rename pane`
+stays free to move the Pane name anywhere and `rename agent` still touches
+exactly one resource. `rebind project` preserves uid and session name, moves no files,
 and updates only `spec.root` plus the exact session's
 `@projmux_project_path` anchor.
 
@@ -355,13 +421,77 @@ duplicate UID claims remain fail-closed.
 
 ### Agent topic, interaction, activation, and workspace
 
+`projmux agent capabilities --provider <codex|claude|antigravity>` prints the
+static action matrix without opening the Registry or consulting tmux, provider
+transport, or an app-server process. Passing an Agent reference (or omitting it
+inside an Agent-owned Pane) adds current Registry-backed eligibility and the
+exact Pane activation generation; Codex rows also expose the stored connection
+and binding epochs. The runtime object reports `evidence=registry`,
+`registryReady`, and `liveVerified=false`; capability reads do not claim a
+live check that mutating routes must perform for themselves. Static `mode`,
+current Registry-backed `available`, and
+`completionPrecision` are separate fields. Use `-o json` for the stable machine
+projection.
+
+The closed static modes are `generic-registry`, `provider-resume`,
+`native-exact-control`, `provider-hook`, `read-only-adapter`, and
+`unsupported`. `message.send`, `message.status`, and `wait.idle` are provider-neutral commands whose availability is decided from
+the exact Agent's provider and current activation capability. There is no
+provider-specific `agent codex`, `agent claude`, or `agent antigravity`
+namespace.
+
+```sh
+projmux agent message send [--message-ref <ref>] [--ttl 10m] uid:<target-agent> -- "coordination text"
+projmux agent message status <message-ref> [-o json]
+projmux agent message qualify uid:<claude-agent> --evidence /absolute/owned/private-init.json --confirm-isolated-provider-push -o json
+projmux agent wait uid:<agent> [--timeout 30s] [-o json]
+```
+
+Message send requires an exact current managed source and target and never
+creates an Agent. The envelope is untrusted coordination data, not a user turn,
+tool request, approval, interrupt, or model-history write. A Claude target must
+first have a current exact registration and helper-memory qualification for the
+frozen frame on Claude Code 2.1.263. Qualification is a dedicated opt-in push
+using same-process sanitized public-init evidence and an exact Stop marker; a
+version string alone is never proof. Claude delivery ends at one full-frame
+auth+user-frame provider handoff plus helper receipt, not model processing. A
+correlated model reply is a separate envelope with the original
+`conversationRef` and `replyTo`. Codex delivery ends when the exact target Agent
+self-claims that envelope. Message lifecycle updates neither Agent interaction
+state nor tmux badges.
+
+Claude messaging is opt-in through `projmux agent integrate claude`. The
+integration installs no receiver waiter or `asyncRewake`; ingress is immediate
+through the exact registered provider socket. Capability JSON keeps Claude
+source send/status availability tied to its registration lease and reports
+target ingress qualification separately under
+`runtimeEligibility.coordination`. If an existing pre-install session has no
+lease, preview and enable integration, let that process exit normally, then run
+`projmux agent resume uid:<same-agent-uid>`; the UID is preserved and no Agent
+is recreated. Delivery remains zero until registration and a fresh qualification
+are ready. Use `projmux agent integrate claude --remove` to remove only managed
+hooks.
+
 `agent turn start`, `agent turn steer`, `agent turn interrupt`, and
 `agent approval review` use the live Codex app-server connection only when the
 selected Agent, its owned Pane, activation generation, thread, current turn,
 and connection epoch still match exactly. `start` sends only the exact thread
-id and one text input; `steer` supplies the current expected turn id; and
-`interrupt` supplies that exact turn id. These commands never install sticky
-model, effort, cwd, sandbox, permission, or collaboration overrides.
+id and one text input. Immediately before that write it reads one bounded,
+content-free lifecycle snapshot: fresh active/in-progress returns
+`turn-in-progress`, fresh idle/terminal repairs stale cached state and starts
+once, and an unavailable or inconsistent snapshot returns
+`turn-state-unavailable` with no turn mutation. `steer` also reads that
+content-free snapshot before any write and submits exactly once only when it
+still proves the same exact active turn. Fresh idle, terminal, or different-turn
+state returns `no-active-turn`; an unavailable or inconsistent read, including
+a fence mismatch after the read, returns `turn-state-unavailable`. Both are
+nonzero exits with zero `turn/steer` writes. A successful steer prints the exact
+machine-readable receipt `acceptance=provider delivery=unconfirmed`. Exit zero
+means the provider accepted the body-free `turn/steer` request; it does not
+confirm TUI display, model consumption, or goal continuation. `interrupt`
+supplies the cached exact turn id without adopting the steer preflight in this
+phase. These commands never install sticky model, effort, cwd, sandbox,
+permission, or collaboration overrides.
 
 Approval review shows only the safe one-shot intersection supplied by the
 exact pending request. Command, file, and network requests are limited to
@@ -581,9 +711,13 @@ A retained graph keeps descendant UIDs; a
 zero-Window Project atomically receives a new canonical Window/shell UID chain.
 A deleted Project may use only the exact usable snapshot compatibility path;
 an unavailable Continue is an explicit zero-write refusal with no Fresh
-fallback. `Open fresh` is one step with no danger styling, confirmation, or
-delete counts: it atomically replaces the same-root graph with a new Project
-UID and new canonical Window/shell UIDs, then hands off only after ordinary
+fallback. `Recreate Project` is the one startup row that replaces identity, and it asks
+before it does. Choosing it opens a confirmation naming the exact old Project
+UID and its Window/Pane/Agent counts; declining returns to the startup rows
+with zero Registry writes, and an unreadable confirmation declines rather than
+proceeds. An unregistered root has no identity to replace and is not asked.
+Confirmed, it atomically replaces the same-root graph with a new Project UID
+and new canonical Window/shell UIDs, then hands off only after ordinary
 materialization. A repeat replaces identity again. The root, git/worktrees,
 trust decision, unrelated roots, and snapshot bytes remain unchanged.
 
@@ -642,7 +776,7 @@ it, rather than because it crashed.
 ## get runtime
 
 ```text
-projmux get runtime sessions|windows|panes [--socket <name> | --socket-path <absolute>] [-o json|none]
+projmux get runtime sessions|windows|panes [--socket <name> | --socket-path <absolute>] [-o wide|json|none]
 ```
 
 `get runtime` is the read-only escape hatch onto one exact tmux server. The
@@ -672,7 +806,10 @@ one difference at the end:
   reason, and zero tmux calls. There is no default-socket guess, and a sibling
   socket is never read.
 
-The default projection is a table preceded by a header line naming the host mode
+The default table contains identity, containment and classification columns;
+`-o wide` adds UID, RESOURCE and REASON with full, unbounded values. The
+[exact profiles](column-profiles.md) do not change with terminal width. Each
+human projection is preceded by a header line naming the host mode
 and the exact transport, plus one line per scope that could not be observed. The
 header is always printed, even when the table is empty: "no sessions" is only
 trustworthy next to which server was asked and whether the answer could be taken
@@ -746,10 +883,12 @@ An explicit path gets exactly the same verification as a bounded copy.
 Verification is fail closed. Malformed JSON, an empty file, an envelope newer
 than this build, and a graph with a duplicate uid, a dangling `ownerRef`, or a
 broken name reservation are all refused with the current Registry byte-identical.
-The verified bytes are then published **verbatim**, so uids, owner relations, and
-name reservations are preserved exactly rather than re-encoded, and a
-known-older-but-valid envelope stays readable through the normal safe read and
-migrates on the next semantic write.
+A verified current-v4 source is published **verbatim**. A verified v3 source is
+instead imported as one atomic compatibility migration: the exact source bytes
+are written to a versioned backup, a checksum-bearing content-free migration
+report is published beside it, and the deterministic canonical v4 bytes are
+staged and committed as the live Registry. A repeat restore compares against
+the canonical publish checksum and writes no new Registry, backup, or report.
 
 The bytes being replaced are kept first, at
 `recovery/replaced-<stamp>-<seq>.json`. Unlike the write-side copies this keeps
@@ -852,6 +991,12 @@ sub-verbs are entry hooks invoked by tmux keybindings (e.g.
 `sidebar-focus` is wired to the sidebar's focus binding so navigation keeps
 the active session in sync).
 
+`switch` composes the canonical Project routes rather than aliasing one of
+them: a live row focuses, an offline row is `open project`, and an unregistered
+candidate row is `create project` followed by `open project`. That is why its
+canonical spelling is those two routes and not `focus project`, which never
+materializes anything.
+
 Settings > Labs remains available for experimental settings, but picker
 selection/source rows have been retired. The native picker is always used, and
 there is no picker selection configuration or migration behavior.
@@ -918,7 +1063,12 @@ versions, paths, confidence/source metadata, and displayed remediation.
 dependencies, `integrations` selects AI notify integrations, and
 `session-state` selects resume metadata plus retention guidance. `runtime`
 selects the fixed `tmux` backend, an actual one-second read-only probe of the
-app socket, and generated-versus-live config digest state. `logs` selects the
+app socket, generated-versus-live config digest state, and a
+`projmux_process_vintage` census of this executable's live children by role and
+image age. That census is provider-neutral and counts every child, naming
+per-pane supervisors and keeping an `other` remainder so a route it has no name
+for cannot shrink the total; on a platform with no process table it reports
+`unknown` rather than claiming currency. `logs` selects the
 state/log/journal presence, private permissions and metadata-only writability
 checks plus a bounded aggregate of recent safe operational error codes. These
 sections expose only closed status codes and counts: no path, socket name,
@@ -1045,6 +1195,79 @@ numbers as numbers. Numeric routing fields such as `window_index` and
 must treat this support projection as redacted evidence rather than decoding it
 back into the unredacted Doctor Go types.
 
+## Project runtime lifecycle
+
+```
+projmux start project <ref> [-o receipt|none]
+projmux open project <ref> [-o receipt|none]
+projmux attach project <ref>
+projmux focus project <ref>
+projmux stop project <ref> [-o receipt|none]
+projmux unregister project [<ref>...] [--all] [--dry-run] [--yes]
+```
+
+Five verbs that address one Project and change one thing each. They are
+separate spellings because a Project has two independent states -- it is
+registered in the Registry, and its persistent tmux session is or is not
+running -- and one verb that moved both was the reason it was never obvious
+which of them a command had touched.
+
+| Verb | Registry | Runtime | Client |
+| --- | --- | --- | --- |
+| `create project` | creates or reuses the Project, its canonical Window, and its shell | not started | not moved |
+| `start project` | unchanged | materialized when offline | not moved |
+| `open project` | unchanged | materialized when offline | moved to the Project |
+| `attach project` | unchanged | materialized when offline | the outside caller attaches |
+| `focus project` | unchanged | never materialized | moved to the Project |
+| `stop project` | unchanged | the exact session ends | existing safe fallback |
+| `unregister project` | the Project subtree is removed | **preserved** | not moved |
+
+`open project` and `attach project` are the same operation seen from the two
+sides of a tmux client. Inside tmux, `open` moves the client you are in and
+`attach` refuses with a pointer at `open`; outside tmux, `attach` attaches the
+caller and `open` refuses with a pointer at `attach`. Both refusals happen
+before anything is materialized.
+
+`stop project` refuses an offline target rather than succeeding silently: it
+declares exactly one runtime outcome, and reporting `runtime=stopped` for a
+session that was never running would be false. `unregister project` is the
+inverse -- it removes the Registry graph and deliberately leaves the running
+session, the root, Git/worktrees, and snapshots exactly as they were.
+
+`delete project` is a deprecated alias of `unregister project`. It keeps its
+exact behavior and its exact stdout; it adds one deprecation line on stderr and
+one `compatibilityWarnings` entry in the receipt. It is not scheduled for
+removal in this release.
+
+The reference for a Project can be `uid:<uid>`, a bare `metadata.name`, or the
+absolute root path the Project claims.
+
+### Operation receipts
+
+Every create, rename, delete, and Project lifecycle route reports what it did
+as one `OperationReceipt/v1` record. The default human result prints it as a
+trailing line; `-o receipt` prints the same record as JSON.
+
+```
+receipt operation=open.project identity=unchanged address=unchanged topology=unchanged \
+  desired-state=unchanged runtime=materialized focus=moved-current-client \
+  projects=1 windows=0 panes=0 agents=0
+```
+
+The six effect axes use the same enum values `projmux <route> --help` and the
+generated reference advertise as *allowed*, so a result can be compared against
+the contract without translating between two vocabularies. A receipt whose
+actual tuple is not one the route declares is refused before it is printed.
+
+The JSON projection adds `target`, `selectedWindowUIDs`, `affectedUIDs` (every
+resource the operation touched and what happened to it), `compatibilityWarnings`,
+and a `domainEffect` slot that is `null` for every route today. The existing
+`-o uid|name|ref|metadata|json|pane-id|none` projections are unchanged.
+
+One consequence is visible immediately: registering a root that is already a
+Project now says `reused`, not `created`, and its receipt says
+`identity=reused` with address, topology, and desired state unchanged.
+
 ## focus
 
 ```
@@ -1332,12 +1555,14 @@ supplied window.
 projmux create agent --provider <claude|codex|antigravity> [--project <ref>] [--window <ref>]... [--create-window] [--placement right|down] ...
 projmux create pane [--project <ref>] [--window <ref>]... [--create-window] [--placement right|down] ...
 projmux config edit [--get|--set <mode>]
-projmux agent status set <thinking|waiting|idle> [pane]
-projmux agent topic ...
+projmux agent status [get [<agent-ref>] | set <unknown|idle|in_progress|approval_required|input_required|response_complete> [<agent-ref>]] [--agent <ref>]
+projmux agent topic get|clear [<agent-ref>] [--agent <ref>]
+projmux agent topic set <text> [<agent-ref>] [--agent <ref>]
+projmux agent capabilities [<agent-ref> | --provider <codex|claude|antigravity>] [-o json]
 projmux internal agent-hook watch-title [pane]
-projmux internal agent-hook ingest codex-hook < payload.json
-projmux internal agent-hook ingest claude-hook < payload.json
-projmux internal agent-hook ingest antigravity-hook [--event <PreInvocation|PostInvocation|PostToolUse|Stop|Statusline>] < payload.json
+projmux internal agent-hook ingest codex-hook [--pane <pane_uid|pane_id>] < payload.json
+projmux internal agent-hook ingest claude-hook [--pane <pane_uid|pane_id>] < payload.json
+projmux internal agent-hook ingest antigravity-hook [--event <PreInvocation|PostInvocation|PostToolUse|Stop|Statusline>] [--pane <pane_uid|pane_id>] < payload.json
 projmux internal agent-hook ingest bell --pane <pane_id>
 projmux diagnostics agent-hook [--tail N] [--json] [--path]
 projmux agent integrate codex [--dry-run] [--remove]
@@ -1365,7 +1590,25 @@ default. Concrete provider invocations create a new Agent and a new managed
 Pane every time; existing managed AI panes in the same project/session are
 not selected or reused, and rebinding an existing conversation is `agent
 resume`, a different verb. The scope of the new resources follows
-[Create scope](#create-scope). The provider picker remains available through
+[Create scope](#create-scope).
+
+The managed Pane is named `<agent-name>-pane`. With an explicit `--name
+reviewer` that is `reviewer-pane`; with no `--name` the Agent's own name is its
+exact full UID, so the Pane is `<agent-uid>-pane` -- readable as *that Agent's
+pane*, and still never the Pane's own UID. A launcher no longer has to issue a
+follow-up `rename pane` to get that spelling, and one that still does gets a
+successful no-op. Two consequences are worth knowing:
+
+- If `<agent-name>-pane` is already used by another Pane anywhere in the same
+  Project or ControlSession, the create refuses with exit code 2 and zero
+  Registry, tmux, and provider writes. No suffix is invented.
+- An Agent name may be the full 128 bytes a name allows, which would make the
+  derived Pane name 133 bytes and invalid. That single case falls back to the
+  ordinary automatic Pane name -- the Pane's exact full UID -- rather than
+  refusing a create that works today.
+
+`rename pane` remains unrestricted on a managed Pane, and renaming the Agent
+afterwards does not move the Pane name. The provider picker remains available through
 `internal agent-pane picker`. Arguments after `--` are extra arguments appended to
 the resolved `claude`, `codex`, or `agy` executable inside the managed wrapper;
 projmux still sets the context directory, tmux title, AI pane metadata, and
@@ -1925,14 +2168,15 @@ human configuration work should prefer `config render` and `config apply`.
   the app session directly after resolving the target app session name and
   startup directory. With no saved startup preference, Alt-1 sidebar project
   open defaults to a two-action picker containing exactly `Continue project`
-  and `Open fresh`; Esc returns to Projects without writing config. Saved `on`
+  and `Recreate Project`; Esc returns to Projects without writing config. Saved `on`
   keeps that picker, while saved `off` skips it and preserves the existing
   automatic registered-Continue/unregistered-Fresh decision. `Continue
   project` restores a deleted Project only from its usable exact snapshot and
-  otherwise refuses with zero Registry writes. `Open fresh` is a neutral,
-  confirmation-free one-step action that atomically replaces the Project with
-  a new Project/Window/shell UID chain and one same-root claimant. Repeating it
-  allocates another new identity. Neither action modifies snapshot
+  otherwise refuses with zero Registry writes. `Recreate Project` confirms the
+  exact old Project UID and its counts, then atomically replaces the Project
+  with a new Project/Window/shell UID chain and one same-root claimant. A
+  declined confirmation returns to the startup rows and writes nothing.
+  Repeating it allocates another new identity. Neither action modifies snapshot
   bytes, the project directory, git/worktrees, unrelated roots, or trust state.
 - `quit` — open an action picker with `Save Project snapshots and quit`, `Quit
   without saving`, and `Cancel`. The safe first action takes one complete,