projmux 0.15.2 → 0.16.0

package/README-ko.md

@@ -72,8 +72,8 @@ projmux create claude --project mobile-client -- "마이그레이션 계획 초
 
 - [Resource Inspector](docs/resource-attribution.md) — 프로젝트·창·pane별 CPU와
   RSS를 실시간으로 봅니다.
-- [Session State](docs/session-restore.md) — 창 배치와 작업 디렉터리를 스냅샷으로
-  남깁니다.
+- [Project Startup](docs/session-restore.md) — 닫힌 프로젝트를 Registry에 저장된
+  창 구성으로 이어 열거나 새로 만듭니다.
 - 검색 루트, 키 설정, 업데이트는 설정에서 바꿉니다.
 
 ## 요구 사항
@@ -93,8 +93,7 @@ projmux create claude --project mobile-client -- "마이그레이션 계획 초
 [상태 표시줄](docs/statusbar.md) ·
 [훅](docs/hooks.md) ·
 [사용량 추적](docs/usage-tracking.md) ·
-[운영 진단](docs/operational-diagnostics.md) ·
-[에이전트 작업 흐름](docs/agent-workflow.md)
+[운영 진단](docs/operational-diagnostics.md)
 
 ## 개발
 

package/README.md

@@ -72,7 +72,8 @@ Templates and naming conventions are in
 
 - Live per-project, per-window, and per-pane CPU/RSS in the
   [Resource Inspector](docs/resource-attribution.md).
-- Layout and cwd snapshots in [Session State](docs/session-restore.md).
+- Registry-based Continue project and Clear layout and open in
+  [Project Startup](docs/session-restore.md).
 - Search roots, keybindings, and updates in Settings.
 
 ## Requirements
@@ -92,8 +93,7 @@ Templates and naming conventions are in
 [Statusbar](docs/statusbar.md) ·
 [Hooks](docs/hooks.md) ·
 [Usage tracking](docs/usage-tracking.md) ·
-[Operational Diagnostics](docs/operational-diagnostics.md) ·
-[Agent Workflow](docs/agent-workflow.md)
+[Operational Diagnostics](docs/operational-diagnostics.md)
 
 ## Development
 

package/docs/agent-message-replies.md

@@ -33,12 +33,33 @@ execution guard, use the existing bounded command without that flag:
 projmux agent message send uid:<original-source-agent> --reply-to <original-request-ref> -- '<corrected reply>'
 ```
 
+Operator input from the web client has no Agent route to reverse, so a reply
+to it is refused with `explicit-reply-operator-origin` and stores nothing.
+
+Within the same provider session, a reply also commits after the Claude lease
+helper was replaced, for example by compact. The new helper did not push the
+original, so it reads the original from the durable store and judges it by the
+same checks. It reads the store only while its own route is the Registry's
+current authority for the Agent; a replaced or unregistered helper reads and
+writes nothing. `broker-reply-original-not-found` means the original is in
+neither the helper nor the store. `invalid-explicit-reply-correlation` means the
+reply's route or conversation does not match the original, or the helper is not
+the current one.
+
 A same-ref call returns the original immutable receipt and never pushes again.
 Changing its payload is refused with the earlier ref and cause. A fresh ref
 allows one new attempt only when every previous attempt is known-zero. Failed
 records and the original request remain available; recovery never deletes or
-resets them. Store capacity can refuse a new attempt rather than discard its
-history.
+resets them.
+
+Store capacity treats the two kinds of attempt differently. A first attempt,
+one whose original has no stored attempt yet, is a new acceptance rather than a
+recovery, so a full store reclaims room for it under the same rule a new
+message uses, while pinning the original and every attempt already stored
+against it. A recovery attempt, which follows an earlier known-zero attempt, is
+still refused with a capacity error rather than discarding the history it is
+recovering from. Either way a reclaimed record moves to the history log below
+instead of being deleted, and a store with nothing reclaimable refuses both.
 
 Delivered replies, partial writes, unknown outcomes, pending attempts, expired
 deadlines, and stale routes must not be resent. Inspect their status and the
@@ -47,3 +68,62 @@ the stored state and specific zero-write reason must agree. These rules also
 apply after store reload and to concurrent callers. Automatic resend is
 disabled, and replies whose delivery target is Codex do not gain a new retry
 policy here.
+
+## Reclaimed records move to a history log
+
+The store is a bounded hot inbox. When it accepts a new message, or a first
+explicit reply attempt, it first reclaims records that went terminal more than
+24 hours ago, and then, if it is still at its record limit, the oldest
+unprotected terminal record. Before either step it expires any accepted or
+held record whose deadline has passed, exactly as a status read would, so such
+a record becomes terminal at that moment and follows the same reclaim rules;
+its 24 hours count from that expiry, not from its deadline. Reclaiming is not
+deleting: every reclaimed record is appended to
+`<state>/agent-messages/history.jsonl`, one JSON object per line, under the same
+file lock and with the same private directory and file permissions as the store.
+
+The append is fsynced before the store renames its own new file into place, so a
+crash in that window can leave a record in both the store and the log, but never
+in neither.
+
+Each line carries the envelope's own key names:
+
+```json
+{"schemaVersion":1,"evictedAt":"…","reason":"retention","adapter":"claude-coordination",
+ "messageRef":"…","conversationRef":"…","replyTo":"…",
+ "state":"delivered","deliveryReason":"unspecified","handoffObserved":false,
+ "acceptedAt":"…","terminalAt":"…","payloadBytes":466,
+ "source":{"agentUID":"…","provider":"…"},
+ "target":{"agentUID":"…","provider":"…"}}
+```
+
+`reason` is `retention` for the 24-hour rule and `capacity` for the record
+limit. `replyTo` is omitted when the record is not a reply. `outcomeUnknown`
+appears, as `true`, only on a failed record whose outcome is unknown; it is
+absent otherwise. `source` and `target` carry only `agentUID` and `provider`:
+the Pane and activation generation fence a live delivery, and the incarnation
+follows the provider conversation; all three mean nothing once the record has
+left the store. The envelope's `deadline` is not written. A line for operator
+input (see [Operator input](claude-coordination-endpoints.md#operator-input)) carries
+`"origin":{"kind":"operator","client":"web"}` in place of `source`; an Agent
+message's line has no `origin`. Every other key is always present.
+
+Lines written by earlier builds may still be in the same file. They carry full
+routes (`paneUID`, `activationGeneration`, `incarnation`), a `deadline`, and
+`outcomeUnknown` even when it is `false`, and they read the same way: a reader
+ignores keys it does not expect and reads an absent key as its zero value, so
+both shapes give the same edges, states and times. Both are `schemaVersion` 1.
+
+`schemaVersion` starts at 1 and follows the same rule as the
+coordination frame's field of that name: an absent or zero value reads as 1, and
+a reader that meets a higher version reads the fields it knows rather than
+discarding the line or failing. It is independent of the durable envelope
+version and of the store file version.
+
+The log does not keep the message body. It records `payloadBytes`, the original
+payload length, and has no `payload` key at all: the log is unbounded in time,
+and its intended consumers need the message graph, not its text.
+
+The active log rotates to `history.jsonl.1` once it would pass 8 MiB, replacing
+any earlier `history.jsonl.1`. At most two generations exist, so the log's disk
+use is bounded even though its history is not complete.

package/docs/ai-agent-shortcuts.md

@@ -53,11 +53,12 @@ Everything after `--` reaches the configured provider executable. Placeholder
 model, permission, and agent flags are private customization examples, not
 project defaults. Omit the separator when there is no payload.
 
-Settings > AI Settings > Enabled providers controls whether Claude, Codex, and
-Antigravity may launch. Canonical create routes respect that setting. There is
-no shared command-line override for a disabled provider; change Settings when
-the provider should become available. For a plain shell split use `projmux
-create pane`, not an Agent provider.
+`Settings > Global > AI > Enabled providers` controls whether Claude, Codex,
+and Antigravity may launch. Canonical create routes respect that setting.
+There is no per-launch override for a disabled provider; enable it in Settings
+or with `projmux config providers --enable <id>` (`--disable <id>` turns one
+off), which goes through the same writer. For a plain shell split use
+`projmux create pane`, not an Agent provider.
 
 Interactive provider and resume selection belong to the app's picker surfaces.
 CLI automation should choose an explicit provider or use `projmux agent resume

package/docs/architecture.md

@@ -131,7 +131,7 @@ procfs collector supplies PID+starttime identity, SID, CPU ticks, RSS, and host
 capacity. Pure aggregation builds pane, unique-window, and project rows without
 using labels, topics, titles, or cwd-derived names as ownership keys.
 
-Resource snapshots are not Session State and are never saved or restored. See
+Resource snapshots are in-memory only and are never saved or restored. See
 [resource-attribution.md](resource-attribution.md) for metric, partial-state,
 host-remainder, privacy, and measurement contracts.
 
@@ -144,7 +144,7 @@ CLI information architecture v2 resource routes.
 Packages:
 
 - `internal/core/metadata` is pure: the resource model, validation, name
-  allocation, schema migration, snapshot reconciliation, and the operation
+  allocation, schema migration, and the operation
   transaction. It performs no I/O; the clock, uid source, and root-directory
   probe are injected through `Mutator`.
 - `internal/core/resourcegraph` is pure: the resolved resource graph that joins
@@ -171,7 +171,7 @@ Packages:
   fills a `resourcegraph.Inventory` from one exact server.
 - `internal/integrations/tmuxopts` is a dependency-free leaf holding the
   canonical spelling of every projmux-owned tmux option name, so the generated
-  tmux config, session-state replay, and the resource mirror cannot drift.
+  tmux config and the resource mirror cannot drift.
 
 Resources and ownership:
 
@@ -216,6 +216,50 @@ Resources and ownership:
   live only in runtime inventory, outside the Project hierarchy. A
   ControlSession is not a counter-example: it is a root resource that *names* a
   session, and the session still carries no identity of its own.
+- `Project.status.session` is the **last recorded** projection, not a live
+  read. It holds `name`, `live`, and `socketPath`: the exact absolute socket
+  path of the tmux server the session was last created or observed live on,
+  as the writing route verified it against the server's own `#{socket_path}`
+  (never derived from a socket name; empty when that route had no verified
+  path). Registration records the name with `live=false` and no path. Create,
+  materialize, Project startup, and legacy import write `live=true` with the
+  path of their route. A successful managed Project stop writes `live=false`
+  only after the exact Session is observed absent, keeping the name and
+  `socketPath`; deleting a Project's last valid primary Window lowers `live`
+  the same way. The full reconciler pass (`refreshSessionProjections`, run by
+  the create routes and by controller convergence) records `live=true` with
+  this pass's path for every Project whose session is on the server it
+  observed. It lowers by absence only a projection recorded on that server or
+  on no server, keeping its name and path; a projection recorded on another
+  server is left as it is, and a pass without a verified path lowers none that
+  record a path. The rule is `SessionAbsenceAttributableTo`.
+  `reconcile resources` scopes that pass to Projects with an observed
+  live Session, and outside that scope it lowers a `live=true` projection
+  whose `socketPath` is exactly the reconciled server's path and whose session
+  is absent there, keeping its name and `socketPath`; Projects with another or
+  no `socketPath` are untouched, because absence from one server is not
+  evidence about a session recorded on another. The one judgement is
+  `Mutator.LowerProjectSessionsEndedOnServer`.
+  The `window-unlinked` hook, which a raw `kill-session` fires, applies the
+  same judgement on its fast path: once its lifecycle stage has observed the
+  host, it lowers a live projection recorded on the hook's exact verified
+  server whose session is gone there, re-reading that server's sessions under
+  the Registry lock. It does not run the full pass, and when no live
+  projection records that server it costs the hook no extra tmux call.
+- When the exact server `reconcile resources` targets is not running (its
+  runtime authority read fails with a missing-server signature, and only
+  then), the same judgement runs with an empty present set against the exact
+  target path: the `--socket-path` or inherited `$TMUX` path itself, or for
+  `--socket <name>` the path tmux would use for that label (the first existing
+  `tmux-<uid>` directory under `$TMUX_TMPDIR`, then `/tmp`, resolved through
+  symlinks). Every projection recorded `live=true` on exactly that path is
+  lowered in one Registry commit, keeping its name and `socketPath`, and the
+  receipt states the absent server and the lowered count; nothing else is
+  planned, written, or reobserved, and `--dry-run` previews the same items.
+  When nothing is left to lower, or the path cannot be resolved, the command
+  fails at the runtime authority stage exactly as before and writes nothing.
+  Any other authority failure (a refused or unreadable socket, a timeout, a
+  server that is not app-owned) never lowers anything.
 - `Window` and `Pane` carry **no stored liveness field**, deliberately. Their
   `status` block holds observed conditions only; live/offline is derived from a
   live tmux observation at read time. See *Runtime observation and resource
@@ -321,7 +365,7 @@ support reports expose those counts but redact item reasons and identifiers.
 Identity and naming:
 
 - `metadata.uid` is opaque, immutable, and independent of tmux lifecycle. It
-  survives snapshot/restore, runtime creation, and root rebind.
+  survives runtime stop/Continue, runtime creation, and root rebind.
 - `metadata.name` is the stable unique-within-scope query key. Project names
   and ControlSession names are unique within their own root kind across the
   registry. Window, Pane, and Agent names are unique by
@@ -335,6 +379,21 @@ Identity and naming:
   or numeric suffix allocator. An explicit `--name` keeps its original spelling
   after validation; explicit create and rename collisions fail with exit code 2
   and zero Registry, tmux, or provider writes.
+- A newly registered Project is the one exception. `create project` without
+  `--name`, and every implicit registration (first open of a directory,
+  `projmux shell`, Open fresh), name the Project after its root directory: the
+  root basename run through the same sanitizer as any name seed (`my repo`
+  becomes `my-repo`). If that basename sanitizes to nothing (the filesystem
+  root) or another Project already holds it, the Project falls back to the
+  exact-UID rule above -- never a numbered variant, never a `project`
+  placeholder. Legacy/orphan import and every Window, Pane, Agent, and
+  ControlSession keep exact-UID automatic names, and no stored name is ever
+  rewritten.
+- Open fresh replaces the Project and carries its name over only when that
+  name is not shaped like a minted Project UID (`proj-` plus a full canonical
+  UID payload). An operator-chosen name such as `proj-front` survives; a
+  UID-shaped name -- the old exact-UID automatic name, or one copied from a
+  predecessor -- is dropped so the replacement is named after its root.
 - `create agent` supplies an **explicit** name for the Pane its Agent owns:
   `<agent-name>-pane`, derived from the Agent's own name. That used to be a
   documented follow-up `rename pane` a launcher had to remember, so a caller
@@ -359,6 +418,27 @@ Identity and naming:
   context may duplicate and is never a selector, reservation, ownerRef, or
   durable identity input. `metadata.labels` remains key/value classification;
   `metadata.annotations` remains non-identifying metadata such as an AI topic.
+- Creator provenance: when an explicit `create agent` (every spelling,
+  `--create-window`, and each Agent of a fan-out) or `create window --provider`
+  runs inside an Agent's managed Pane, the new Agent and its managed Pane carry
+  `projmux.io/creator-agent` (the creator Agent's bare UID),
+  `projmux.io/creator-pane` (that Agent's managed Pane's bare UID), and
+  `projmux.io/creator-basis: pane-chain`, written in the same transaction that
+  commits the Agent. They are recorded only when the unmasked ambient
+  `%N` (`__PROJMUX_RUNTIME_ANCHOR_PANE`, then `TMUX_PANE`) is exactly one live
+  Registry Pane, that Pane round-trips with its owning Agent's
+  `status.paneRef`, one `display-message` confirms it on the create's own
+  app-owned socket and server pid, and the create process descends from its
+  `#{pane_pid}`. Any failed check writes none of the keys and changes nothing
+  else about the create. Stderr gets one `creator not recorded: <reason>` line
+  only when the ambient Pane is a live Agent Pane but a later check fails; an
+  ambient Pane that is malformed, unregistered, or a Window-owned shell is
+  silent. These keys are provenance, not
+  authentication, like a message `--source`. An absent key does not mean a
+  human created the Agent: UI intent creates (picker, pane menu, `ai split`,
+  launch choice) and creates a Codex Agent issues (its
+  commands run under the app-server, not below the Pane's process) leave them
+  empty, and nothing backfills older Agents.
 
 Root lifecycle:
 
@@ -519,7 +599,8 @@ Exit reconciliation and lifecycle projection:
 - Abnormal, killed, unknown, whole-host absence, missing/empty server inventory,
   permission failure, foreign Window observation, stale generation, and an
   Agent that now binds a resumed Pane all produce delete-plan zero. They keep the
-  retained lifecycle projection and canonical explicit Offline delete recovery.
+  retained lifecycle projection and the canonical exact-uid Registry-only
+  delete recovery of a paneless Offline or Failed Agent.
 - The closed Agent transition table stays the authority. An Agent that may not
   reach the implied phase keeps its phase, its `paneRef`, and its managed Pane;
   only the evidence is recorded. A refused transition is not a reason to discard
@@ -736,9 +817,8 @@ Registry file and schema:
   directory-existence and uid adapters.
 - The canonical anchor is a schema-v2 write invariant. Until the separately
   planned Project-start projection lands, the legacy `New` startup path's
-  prune-to-zero transaction fails validation and commits zero Registry bytes.
-  The Registry verdict precedes snapshot deletion, so that rejection also
-  preserves the latest snapshot byte-for-byte and performs no tmux mutation.
+  prune-to-zero transaction fails validation and commits zero Registry bytes
+  and performs no tmux mutation.
   This fail-closed ordering is not Phase 3 authority to redesign Project start.
 - Downgrade writes remain unsupported. Unversioned, malformed, and future
   envelopes still fail closed before backup, staging, or replace.
@@ -967,21 +1047,11 @@ Resolved resource graph (`internal/core/resourcegraph`):
   process, and no tmux, so the same inputs always produce byte-identical output
   and a read can never materialize state.
 
-Session State interoperability:
-
-- Session snapshots carry resource identity through additive `omitempty`
-  `metadata` blocks at the unchanged snapshot `version: 1` — one for the owning
-  Project at the top level, one per Window, and one per Pane, each with
-  `uid`, `name`, `labels`, `owner_kind`, and `owner_uid` in the snapshot's own
-  snake_case spelling. No schema bump was needed, and a snapshot written
-  without resource metadata still serializes byte-identically to the older form.
-- Snapshots written before resource metadata existed still project
-  deterministically into an explicitly selected, closed Registry Project:
-  existing Windows and Panes are reused positionally in Registry order and any
-  additional descendants receive new stable identities. Restore validates a
-  pure Project-scoped plan, atomically commits that desired subtree, and only
-  then invokes the ordinary Project materializer. It never directly replays
-  snapshot topology into tmux and never replaces the global Registry.
+Saved Project state:
+
+- The Registry is the only saved Project state. projmux keeps no separate
+  Project snapshot store, and a closed Project starts only from its Registry
+  desired state through the ordinary Project materializer.
 
 tmux transport mirror:
 
@@ -1000,7 +1070,7 @@ tmux transport mirror:
   every other mirror goes through, on the same plain `tmux` transport the session
   was created on. The write is gated strictly on "this open registered the
   Project": every already-registered Project converges through the Registry
-  topology engine, including desired state previously committed from a snapshot,
+  topology engine,
   and opening `$HOME` mints no managed identity at all, so neither writes a mirror
   option through this first-open gate. That gate is also what makes repeating an
   open write nothing. Repairing a session that is already live without its
@@ -1008,10 +1078,14 @@ tmux transport mirror:
   recovery route.
 - `rename pane` changes `Pane.metadata.name` and its `@projmux_pane_label`
   mirror only. It never writes the raw tmux `pane_title`.
-- `rename window` is the explicit stable-identity path: it changes only
-  `Window.metadata.name`, its root-scoped same-kind name reservation, and the
-  exact live `@projmux_window_name` transport mirror. It does not change tmux
-  `window_name`.
+- `rename window` is the explicit stable-identity path: it changes
+  `Window.metadata.name`, its root-scoped same-kind name reservation, the exact
+  live `@projmux_window_name` transport mirror and, when the invocation has a
+  proven runtime route, the tmux tab `window_name` through the canonical
+  `rename-window -t @N -- <name>` -- the same argv shape the rename key and the
+  Window menu Rename item go through. With no route it stays Registry-only and
+  says on stderr that the tab did not converge. It never changes
+  `metadata.displayName`.
 - `rename project` likewise writes only `Project.metadata.name` and the exact
   live session's `@projmux_project_name`; it never renames the tmux session.
   `rebind project` preserves the Project uid and session name while updating
@@ -1064,8 +1138,8 @@ Runtime observation and resource status:
   precedence contract is unchanged, and it now applies to a Window or Pane whose
   owning Project lost its root even while tmux is still running them.
 - A **Project** is the one kind whose runtime object is a tmux *session*, which
-  has no `@projmux` uid of its own, so Project status still reads
-  `status.session` as refreshed by the reconciler.
+  has no `@projmux` uid of its own, so Project status still reads the stored
+  `status.session` projection (see *Resource metadata model* for its writers).
 - An **Agent** owns no tmux object of its own — there is no `@projmux_agent_uid`
   and there must not be one, because an Agent outlives the managed Pane it is
   bound to. Its runtime object is **that managed Pane**, named by
@@ -1280,7 +1354,7 @@ Lifecycle trigger convergence:
   transaction deletes exactly that Window, its Panes, its owned Agents, and
   their reservations. A non-last Project Window reanchors to its existing
   sibling. The last Project Window leaves the exact Project uid, root,
-  reservation, pins, and snapshot bytes in the valid zero-Window state. A
+  reservation, and pins in the valid zero-Window state. A
   ControlSession likewise loses only the Window and keeps its root uid.
   Abnormal/killed/unknown exits, stale generations, unpaired or foreign handles,
   unavailable/empty observations, and missing-server or permission failures
@@ -1294,11 +1368,9 @@ Lifecycle trigger convergence:
   managed runtime and preserves every desired UID. Continue on retained-window
   writes only runtime and materializes the same descendant UIDs; Continue on
   zero-window atomically allocates one canonical Window/shell below the same
-  Project UID before runtime materialization. The deleted+Continue cell accepts
-  only a usable-snapshot precondition, then atomically creates a new Project UID
-  and restores new descendant UIDs from that snapshot; without the precondition
-  the same cell is an unavailable zero-write refusal and never falls back to
-  Fresh. Fresh atomically replaces either
+  Project UID before runtime materialization. The deleted+Continue cell is
+  always an unavailable zero-write `project-is-not-registered` refusal that
+  points to Fresh and never falls back to it. Fresh atomically replaces either
   registered state with a new Project/Window/shell UID chain and exactly one
   same-root claimant. Within this runtime/startup lifecycle table, canonical
   `delete project --yes` alone unregisters the Project graph; the separately
@@ -1366,6 +1438,25 @@ Projmux split UI:
   The provider and shell branches render the exact argv an operator would type,
   so a UI action and a typed command cannot disagree about what `--placement
   down` means.
+- A split picker running in a popup does not call that route itself. tmux
+  closes a popup only when the process inside it exits, so the picker hands its
+  intent to a detached `run-shell -b` continuation on the same server
+  (`internal agent-pane launch-selection`, carrying the origin Pane, client,
+  and context directory as env) and exits. The continuation
+  calls the same create funnel; a success writes nothing and anything else is
+  one bounded line on the pressing client. Every selection travels: it is a
+  plain value with no live handle left in the picker process.
+- A generated Window create asks before it commits. It opens the split picker in
+  answer mode (`internal tmux popup-toggle --answer <file>`) on the Pane the key
+  was pressed in; the picker writes the selection -- the same argv the
+  continuation carries, read back by the same parser -- to a 0600 file its
+  producer made, and creates nothing. The producer then commits the Window and
+  the answer in one Registry transaction -- for an Agent, the same shape
+  `create window --provider` commits: the Agent Pane splits off the new shell
+  and the shell is retired -- and moves the pressing client onto it last. An
+  Agent that cannot be opened rolls the whole Window back and leaves one line on
+  the pressing client. A cancelled picker leaves the file empty and nothing is
+  created.
 - Only the materializer runs `split-window`. Before this convergence the saved
   default and both pickers descended into a legacy split that called tmux
   directly, so a pane opened from the UI was a runtime object the Registry had
@@ -1677,15 +1768,14 @@ Explicit Registry topology materialization:
   deletion removes that desire. Exact uid/name/owner mirrors are retained. Stored
   Pane CWD drives only that Pane's detached runtime cwd, while Project root
   remains the session path anchor and `PROJMUX_CWD` hook value.
-  `Pane.spec.command`, snapshot recipes, notifications, and ephemeral sessions
+  `Pane.spec.command`, notifications, and ephemeral sessions
   are never execution inputs.
 - An Agent whose managed Pane is not live is replayed into a new managed Pane on
   its Window's proven anchor, through the same allocation, activation ledger,
   ownership-checked adoption, and rollback the shell half uses. The **only**
   replay identifier is Registry `status.sessionRef`: no provider conversation
   store is read, `ClaudeSessionRef.TranscriptPath` in particular is never
-  consulted, and snapshot recipe `resumeID` is a separate value that never feeds
-  this path. The launch argv comes from the two seams `create agent` already
+  consulted. The launch argv comes from the two seams `create agent` already
   owns -- `PlanAgentResume` for a ref that names a conversation, `PlanAgentLaunch`
   with no payload otherwise -- so the topology engine holds no launch builder of
   its own and the Settings enabled-agents gate still applies. An Agent that
@@ -1699,14 +1789,7 @@ Explicit Registry topology materialization:
   the Window from it, and then replays the anchor Agent while preserving the
   Agent Pane uid. The default shell is bootstrap, not a replacement anchor. A
   successful repeat is a Registry-write-free and topology-write-free no-op.
-- Snapshot restore is a target-Project subtree projection, never a Registry
-  restore. Metadata-bearing v1 snapshots preserve surviving final-v2
-  anchor/default refs; metadata-free snapshots choose the first Window-local
-  Pane as anchor and the first direct shell as optional default. Agent-only
-  desired Windows remain Agent-anchored and acquire a shell only through the
-  ordinary materializer. Source snapshot bytes and unrelated roots are never
-  rewritten, and a second projection is byte-stable.
-- `Recreate Project` replaces the exact same-root Project graph, after an
+- `Clear layout and open` replaces the exact same-root Project graph, after an
   explicit confirmation, in one Registry
   commit. It always allocates a new Project UID plus one new canonical Window
   and direct shell UID, whether the old Project retained Windows or had zero.
@@ -1780,7 +1863,10 @@ Plan-only runtime mutation boundary:
   arbitrary Pane as invocation evidence. Generated popup/menu producers pass an exact Pane anchor which is
   reobserved on that same socket rather than trusting a targetless current
   Pane. Before a stage writes, the same `-S` runner refuses path, generation,
-  class, or containment drift. Only a create-session
+  class, or containment drift, and names which of them happened: tmux answers a
+  `display-message -t %N` for a Pane that is gone with exit 0 and blank
+  `$N`/`@N`/`%N` columns, so an absent anchor Pane is reported as absent rather
+  than as drift on a socket and a server generation that both still match. Only a create-session
   stage may accept the typed no-server observation, because its explicit route
   and absent-session ownership preflight are the facts required to create the
   first server.
@@ -1906,7 +1992,13 @@ Resource-first create:
   touched.
 - **Everything is detached.** No create path issues `switch-client`,
   `select-window`, `select-pane`, or `attach-session`. `focus pane` and
-  `-o pane-id` are how a caller ends up in the new pane.
+  `-o pane-id` are how a caller ends up in the new pane. One exception: the
+  human intent route `internal tmux window-create` (`window.create` key, Window
+  menu New At End) asks for the saved launch default before its create
+  commits, fills the committed shell Pane with the answer -- an Agent through
+  the same canonical create funnel a split uses plus a canonical delete of the
+  shell -- and then moves exactly the pressing client to the new Window; public
+  `create` stays detached and never reads that saved default.
 - **Focus is navigation-only.** `focus project|window|pane` reads live tmux
   inventory and may move an existing client, but has no Registry store and
   issues no session/Window/Pane creation, identity-marker, rename, respawn, or
@@ -1948,8 +2040,8 @@ Selector and the implicit active target:
   hit. The describe family remains the intentional Project-only difference;
   Phase 14 extends only the generic rename family to ControlSession.
   `get projects`, `describe|rename project`, `delete`, `rebind`, and `agent
-  resume` are outside that reference scope, and notifications and snapshots
-  belong to separate stores. Delete's exact live preflight nevertheless follows
+  resume` are outside that reference scope, and notifications belong to a
+  separate store. Delete's exact live preflight nevertheless follows
   either root kind through the selected descendant's owner chain.
 - `--all-projects` is the explicit registry-wide escape for those three reads.
   It is deliberately different from destructive `delete --all`, whose existing
@@ -2004,9 +2096,11 @@ Selector and the implicit active target:
 
 Projmux keeps visible naming separate from source metadata:
 
-- **User pane label** is persistent pane-scoped metadata stored in
-  `@projmux_pane_label`. The Rename Pane action sets or clears only this field;
-  it does not write the AI topic or raw pane title.
+- **User pane label** is pane-scoped metadata stored in `@projmux_pane_label`,
+  the live mirror of the Pane's Registry `metadata.name`. The Rename Pane action
+  renames the Registry Pane through the same owner as `rename pane`, which
+  writes this mirror; an empty response changes nothing, and the action never
+  writes the AI topic or raw pane title.
 - **Pane border label** is the primary visible pane name. In the app tmux
   config and native previews it resolves to user pane label first, agent AI
   topic second, known interactive shell command (`zsh`, `bash`, `fish`, `sh`,
@@ -2024,14 +2118,6 @@ Projmux keeps visible naming separate from source metadata:
   user pane labels.
 - **Git branch** belongs in the statusbar git segment. Branch-based terminal
   title overwrites are not promoted to the primary Projmux pane or window name.
-- **Session snapshots** store source metadata separately: `window_name`, raw
-  `pane_title`, user `label`, `@projmux_ai_topic`, manual topic ownership, and
-  agent resume metadata. Old snapshots decode with an absent label and absent
-  ownership; title/topic equality never infers either. Replay writes each
-  semantic field to the exact pane id returned by tmux creation and restores
-  raw title from `Pane.Title` after launch/startup replay. Snapshots do not
-  store a resolved `display_label`; visible labels are recomputed by display
-  policy.
 
 ## Notify queue
 
@@ -2174,7 +2260,7 @@ The maintained product table in `internal/app/runtime_mutation_surface.go` maps
 generated catalog/menu producers, native provider/resume picker selections,
 sidebar/session-picker stops, and app lifecycle entrypoints in both directions
 to their handler and plan verb. It also records exact semantic exemptions for
-focus, labels, operator-requested layout, mouse forwarding, snapshot replay,
+focus, labels, operator-requested layout, mouse forwarding,
 ephemeral maintenance, app quit, and human runtime maintenance. Managed argv
 verbs are selected only by the typed executor seam; generated Window
 create/rename, Pane-menu create/delete, and automatic post-split layout writes