projmux 0.15.0 → 0.15.2

package/docs/claude-coordination-endpoints.md

@@ -208,6 +208,21 @@ real-provider observation is opt-in through
 `scripts/agent-dialogue-live-canary.sh`; each version-stress row must qualify
 independently.
 
+`TestClaudeDialogueStreamReplaysObservedFrameCorpus` pins the reply-only
+validator's verdict on preserved real frame shapes. Neither it nor L20 proves
+installed-provider compatibility, value drift (the corpus keeps top-level key
+shape with placeholder values), or acceptance of unknown frames and fields (the
+closed vocabulary rejects them by design). The L20 fixture emits none of the
+corpus's dropped side frames. Two recorded real shapes are rejected today:
+`result-success-25-keys` (the result allowlist lacks `origin`) and
+`system-init-allowlist-diff` (the init allowlist lacks `memory_paths` and
+`terminal_slash_commands`). Shapes without preserved evidence are gaps, not
+items: `command_lifecycle` keys and values, a non-null assistant
+`context_management`, `system` `thinking_tokens`, hook and user `tool_result`
+frames, the exact real init key set, every nested value, `rate_limit_event`
+envelope keys beyond `type` and `rate_limit_info`, and the lost earlier shape
+inventories.
+
 Provider sources: [SessionStart and Stop hooks](https://code.claude.com/docs/en/hooks)
 and [cross-session messaging](https://code.claude.com/docs/en/cross-session-messaging).
 

package/docs/cli-guide.md

@@ -376,10 +376,16 @@ The generated `MouseDown3Pane` menu treats its Horizontal Split, Vertical
 Split, and Kill entries as Projmux resource actions. Both splits pass the exact
 clicked pane through the popup-origin anchor above and reach the same canonical
 `create pane` materializer as the CLI, so the new pane receives a Registry uid.
-Kill resolves that anchor's mirrored uid and reaches canonical `delete pane`,
-including its printed delete result. The menu never falls back to a raw tmux
-mutation when either route refuses. The reason is displayed on the exact client
-that opened the menu instead of being lost as a `run-shell` exit code.
+Kill on a pane with `@projmux_pane_uid` resolves that anchor's mirrored uid and
+reaches canonical `delete pane`, including its printed delete result; a pane
+without the mirror runs tmux's own `kill-pane` instead of being refused. The
+menu never falls back to a raw tmux mutation when either route refuses. The
+reason is displayed on the exact client that opened the menu instead of being
+lost as a `run-shell` exit code. The app config's `prefix >` and
+`M-MouseDown3Pane` Pane menus follow the same rules, and its `prefix <`,
+`MouseDown3Status`, and `M-MouseDown3Status` Window menus route Kill on a
+mirrored Window to canonical `delete window`; see
+[Managed menus](keybindings.md#managed-menus).
 
 tmux Respawn has no equivalent in the current resource model: it preserves the
 same pane handle, layout, Registry uid, and original command, while canonical
@@ -389,6 +395,23 @@ menu therefore omits Respawn entirely and does not expose a refusal handler or
 invent a replace operation. User-authored tmux bindings remain outside this
 managed-menu contract.
 
+#### Managed close keys
+
+The generated app config routes tmux's `prefix x` and `prefix &` through the
+same resource routes whenever the target carries a Registry identity mirror.
+`prefix x` on a Pane with `@projmux_pane_uid` confirms on the exact client, then
+runs the Pane menu Kill route above: canonical `delete pane` with an
+`intentional` termination receipt. The Agent that owned the Pane stays in the
+Registry as Offline with a `deleted` exit, which Continue never replays.
+`prefix &` on a Window with
+`@projmux_window_uid` confirms, then runs `internal tmux window-delete`, which is
+canonical `delete window` on that exact Window; a Project's last Window leaves a
+zero-Window Project. A refusal is shown on that client and never falls back to
+a raw kill. A target without the mirror keeps tmux's stock `confirm-before`
+prompt and kill, with no Registry write. See
+[Managed close keys](keybindings.md#managed-close-keys) for changing or
+disabling the keys.
+
 ### Rename and rebind live convergence
 
 `rename project|window|pane` commits the selected Registry `metadata.name` and
@@ -537,7 +560,9 @@ generated `pane-exited` hook. The supervisor must have durably journaled a
 same-generation `normal` receipt, the hook must name the exact `%N` Pane and
 the owner Window must carry its exact last-positive `$N/@N` binding on the same
 socket, and fresh preflight plus locked observations must still resolve the
-same Registry owner chain. A non-last Pane is removed while its directly owning
+same Registry owner chain. This includes Windows re-materialized by Project
+start/Continue topology replay: the replay records each Window it materializes
+with its live `$N/@N` in the same commit. A non-last Pane is removed while its directly owning
 Agent is retained Offline with its conversation identity. For a last Pane, that evidence is retained until a
 matching `window-unlinked` hook removes the Window; a final Project Window also
 removes its Window descendants while retaining the exact Project uid, root,
@@ -549,6 +574,14 @@ content, prompt, history, and transcript are never parsed. `abnormal`,
 `killed`, `unknown`, stale/resumed bindings, empty or unavailable inventory,
 permission failure, and foreign-host/window observations keep their diagnostic
 rows and produce no automatic delete plan.
+Every teardown decision on this hook path appends one
+`topology.teardown.decision` journal record (`projmux diagnostics log
+--component topology`) with its `delete-window`/`delete-pane-agent`/`retain`/
+`refuse` decision, `topology.teardown.<reason>` code, Window/Pane UID, and
+termination classification. An unpaired `window-unlinked` records `retain`
+with `topology.teardown.awaiting-pane-exit` when it first waits and again when
+its bounded pair wait is exhausted; `kill-window` closes surface this way,
+because tmux fires no `pane-exited` for them.
 
 For `pane-exited`, tmux supplies `%N` as `#{hook_pane}`. Its current-context
 session/window formats may already name a surviving client Window, so the owner
@@ -760,6 +793,14 @@ Registry-only result reports that no tmux Pane was killed, preserves the owning
 Window/root/socket and all siblings, and repeating the exact apply returns the
 ordinary no-match result.
 
+A name, scope, or active-target delete of a target that carries that evidence
+still refuses with the live-mirror refusal, but the refusal then names the
+typed resource's exact form to run instead —
+`projmux delete pane|agent uid:<uid> --socket-path <server> --dry-run`, then the
+same command with `--yes` — and says which evidence qualifies it. A target the
+`uid:` form would refuse too, such as a Pane without `MissingRuntime` or a
+`Running` or `Failed` Agent, gets no such pointer.
+
 `delete window|pane|agent` names the server its live half addresses the same
 way `reconcile resources` does: `--socket <name>`, `--socket-path <absolute>`,
 or the inherited absolute `$TMUX`. Outside tmux with neither flag it refuses
@@ -1144,7 +1185,9 @@ autosave-session-state`, `window record`, and
 successful `diagnostics log` views do not produce an event. Errors from those
 automatic hook/poll paths still produce one safe `error` outcome. Successful
 direct command help and explicit `--dry-run` preview modes also remain
-read-only and do not produce an event. Journal failures are a best-effort side
+read-only and do not produce an event. The automatic `internal tmux converge`
+route still appends one typed `topology.teardown.decision` record per Window or
+Pane teardown decision it consumes. Journal failures are a best-effort side
 channel and never change command output or exit status. See
 [operational-diagnostics.md](operational-diagnostics.md) for the file,
 retention, concurrency, and privacy contracts.

package/docs/cli.md

@@ -130,7 +130,7 @@ projmux agent app-server upgrade resume|abort --operation <ref>
 projmux agent app-server handover plan|apply --request <absolute-json>
 projmux agent app-server handover resume|abort --operation <ref>
 projmux agent capabilities [<agent-ref> | --provider <codex|claude|antigravity>] [-o json]
-projmux agent message send <agent-ref> [--message-ref <ref>] [--reply-to <ref>] [--ttl <duration>] -- <text>
+projmux agent message send <agent-ref> [--source <agent-ref>] [--message-ref <ref>] [--reply-to <ref>] [--ttl <duration>] -- <text>
 projmux agent message status <message-ref> [-o json]
 projmux agent message qualify <claude-agent-ref> --evidence <absolute-private-json> --confirm-isolated-provider-push -o json
 projmux agent wait <agent-ref> [--until idle] [--timeout <duration>] [-o json]
@@ -150,7 +150,7 @@ Subcommands:
 | [`projmux agent usage`](#projmux-agent-usage) | Read provider account usage quota snapshots |
 | [`projmux agent app-server`](#projmux-agent-app-server) | Manage explicitly requested private Codex app-server generation operations |
 | [`projmux agent capabilities`](#projmux-agent-capabilities) | Read static provider support or one exact Agent's Registry-backed runtime eligibility |
-| [`projmux agent message`](#projmux-agent-message) | Exchange bounded untrusted coordination messages through exact Agent activations |
+| [`projmux agent message`](#projmux-agent-message) | Exchange bounded untrusted coordination messages; --source selects a source Agent anchor, not caller authentication (default: active Pane) |
 | [`projmux agent wait`](#projmux-agent-wait) | Wait read-only for one exact Agent's Registry-backed idle observation |
 
 Canonical spelling: `projmux agent status`, `projmux agent topic`, `projmux agent resume`, `projmux agent turn start`, `projmux agent turn steer`, `projmux agent turn interrupt`, `projmux agent approval review`, `projmux agent review`, `projmux agent integrate`, `projmux agent usage`, `projmux agent app-server upgrade qualify`, `projmux agent app-server upgrade plan`, `projmux agent app-server upgrade apply`, `projmux agent app-server upgrade resume`, `projmux agent app-server upgrade abort`, `projmux agent app-server handover plan`, `projmux agent app-server handover apply`, `projmux agent app-server handover resume`, `projmux agent app-server handover abort`, `projmux agent capabilities`, `projmux agent message send`, `projmux agent message status`, `projmux agent message qualify`, `projmux agent wait`
@@ -736,7 +736,7 @@ Output modes (`-o`): `json`
 
 ### `projmux agent message`
 
-Exchange bounded untrusted coordination messages through exact Agent activations
+Exchange bounded untrusted coordination messages; --source selects a source Agent anchor, not caller authentication (default: active Pane)
 
 Selectorless authority: `refusal` — there is no safe selectorless action; refuse before output or mutation.
 
@@ -752,7 +752,7 @@ Allowed effects:
 - `domain-effect=agent-delivery`
 
 ```
-projmux agent message send <agent-ref> [--message-ref <ref>] [--reply-to <ref>] [--ttl <duration>] -- <text>
+projmux agent message send <agent-ref> [--source <agent-ref>] [--message-ref <ref>] [--reply-to <ref>] [--ttl <duration>] -- <text>
 projmux agent message status <message-ref> [-o json]
 projmux agent message qualify <claude-agent-ref> --evidence <absolute-private-json> --confirm-isolated-provider-push -o json
 ```
@@ -761,7 +761,7 @@ Subcommands:
 
 | Route | Summary |
 | --- | --- |
-| [`projmux agent message send`](#projmux-agent-message-send) | Submit a bounded coordination message from the current exact Agent |
+| [`projmux agent message send`](#projmux-agent-message-send) | Submit bounded peer coordination; --source selects a source Agent anchor, not caller authentication (default: active Pane) |
 | [`projmux agent message status`](#projmux-agent-message-status) | Read a payload-free broker delivery receipt |
 | [`projmux agent message qualify`](#projmux-agent-message-qualify) | Explicitly qualify one exact Claude target using owned current-version isolation evidence and one marker push |
 
@@ -769,7 +769,7 @@ Canonical spelling: `projmux agent message send`, `projmux agent message status`
 
 #### `projmux agent message send`
 
-Submit a bounded coordination message from the current exact Agent
+Submit bounded peer coordination; --source selects a source Agent anchor, not caller authentication (default: active Pane)
 
 Selectorless authority: `explicit-target` — the route or caller must name the exact target.
 
@@ -785,7 +785,7 @@ Allowed effects:
 - `domain-effect=agent-delivery`
 
 ```
-projmux agent message send <agent-ref> [--message-ref <ref>] [--reply-to <ref>] [--ttl <duration>] -- <text>
+projmux agent message send <agent-ref> [--source <agent-ref>] [--message-ref <ref>] [--reply-to <ref>] [--ttl <duration>] -- <text>
 ```
 
 #### `projmux agent message status`
@@ -2003,10 +2003,10 @@ Subcommands:
 
 | Route | Summary |
 | --- | --- |
-| [`projmux get projects`](#projmux-get-projects) | List Project resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context |
-| [`projmux get windows`](#projmux-get-windows) | List Window resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry |
-| [`projmux get panes`](#projmux-get-panes) | List Pane resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry |
-| [`projmux get agents`](#projmux-get-agents) | List Agent resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry |
+| [`projmux get projects`](#projmux-get-projects) | List Project resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context |
+| [`projmux get windows`](#projmux-get-windows) | List Window resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry |
+| [`projmux get panes`](#projmux-get-panes) | List Pane resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry |
+| [`projmux get agents`](#projmux-get-agents) | List Agent resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry |
 | [`projmux get runtime`](#projmux-get-runtime) | List every tmux Session, Window, and Pane on one exact server with its attribution |
 | [`projmux get notifications`](#projmux-get-notifications) | List pending notification rows |
 | [`projmux get snapshots`](#projmux-get-snapshots) | List saved session snapshots |
@@ -2016,7 +2016,7 @@ Canonical spelling: `projmux get projects`, `projmux get windows`, `projmux get
 
 ### `projmux get projects`
 
-List Project resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context
+List Project resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context
 
 Selectorless authority: `explicit-fan-out` — the route spelling is an intentional global or whole-set opt-in.
 
@@ -2041,7 +2041,7 @@ Output modes (`-o`): `uid`, `name`, `ref`, `metadata`, `json`, `none`, `wide`
 
 ### `projmux get windows`
 
-List Window resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry
+List Window resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry
 
 Selectorless authority: `natural-omitted` — omission resolves one predictable current resource or documented contextual read/scope; any selector replaces it.
 
@@ -2066,7 +2066,7 @@ Output modes (`-o`): `uid`, `name`, `ref`, `metadata`, `json`, `none`, `wide`
 
 ### `projmux get panes`
 
-List Pane resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry
+List Pane resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry
 
 Selectorless authority: `natural-omitted` — omission resolves one predictable current resource or documented contextual read/scope; any selector replaces it.
 
@@ -2089,7 +2089,7 @@ Output modes (`-o`): `uid`, `name`, `ref`, `metadata`, `json`, `none`, `wide`
 
 ### `projmux get agents`
 
-List Agent resources as NAME STATUS ACTIONS; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry
+List Agent resources as NAME STATUS ACTIONS AGE; route-implied KIND is omitted, shifting stdout positions; -o wide retains KIND and diagnostics, and -o json retains kind and invocation context; inside tmux defaults to the active managed root, and --all-projects lists the whole Registry
 
 Selectorless authority: `natural-omitted` — omission resolves one predictable current resource or documented contextual read/scope; any selector replaces it.
 

package/docs/codex-generation-pool.md

@@ -217,6 +217,11 @@ handover resume refuses before it drives any effect. A receipt qualifies the one
 pair it names and no other, and the refusal for a pair with no stored receipt
 names the two commands that produce and install one.
 
+`projmux doctor --section integrations` reports the saved version pairs and
+their verdicts even without a generation journal. Text, JSON, and support
+`doctor.json` distinguish an empty store from damaged or misfiled receipts;
+see [Stored Codex version-pair qualification](codex-stored-qualification.md).
+
 The same `receipt.json` also goes verbatim into the `qualification` field of an
 `agent app-server upgrade plan|apply --request <absolute>.json` document. The
 upgrade request requires that receipt's version pair to match the exact current

package/docs/codex-stored-qualification.md

@@ -0,0 +1,45 @@
+# Stored Codex version-pair qualification
+
+`projmux agent app-server upgrade qualify --receipt <absolute-json>` installs
+one measured receipt for its exact old/new Codex version pair. Inspect the
+saved receipts with:
+
+```sh
+projmux doctor --section integrations
+projmux doctor --section integrations --json
+```
+
+The default Doctor report includes the same inventory. Its
+`codex_stored_qualification` JSON field also appears in support `doctor.json`,
+with version pairs, statuses, verdicts, reasons, and readiness preserved.
+The read does not depend on a generation-pool journal or a readable Registry.
+
+```text
+Codex stored version-pair qualification
+  Store: stored
+  0.153.2 -> 0.153.4: stored; verdict: yes; reason: qualified; qualification ready: true
+```
+
+| Store status | Meaning |
+| --- | --- |
+| `stored` | All enumerated receipts decoded and matched their filenames. |
+| `absent` | No saved receipt exists; the directory may be absent or empty. |
+| `damaged` | At least one receipt could not be read as its filename's pair. Other receipts remain visible. |
+| `unavailable` | The store path could not be resolved or the directory could not be read. |
+
+Each `version_pairs` row reports `stored`, `damaged`, or
+`version-pair-mismatch`. A mismatch means a valid receipt names a different pair
+from its filename; its verdict is not reported for the filename's pair. A
+malformed `.json` filename produces a damaged row without exposing that name.
+Non-regular receipt files are damaged; temporary save files are ignored.
+
+For a stored row, `verdict` and `reason` come from the existing strict receipt
+decoder. `qualification_ready` comes from the existing qualification gate:
+a saved `no` or a self-consistent `yes` with unbacked evidence counters remains
+not ready. This field describes only the pair's qualification, and does not
+assert that the generation pool or an upgrade operation is ready.
+
+Schema v2 has no timestamps or expiry policy. A receipt stays reportable until
+it is replaced or removed. Doctor reads it without running qualification,
+writing receipts or journals, restoring upgrade state, or executing lifecycle
+commands.

package/docs/column-profiles.md

@@ -1,13 +1,18 @@
 # Column profiles
 
 Plural Registry reads (`get projects|windows|panes|agents`) now default to
-`NAME STATUS ACTIONS`. The route already selects the resource kind. Runtime
+`NAME STATUS ACTIONS AGE`. The route already selects the resource kind. Runtime
 reads default to their identity, containment, and classification columns. Use `-o wide` (or `--output wide`) to print the full
 column profile. Terminal width and data length never select a profile.
 
-Removing KIND changes these four default tables from four columns to three and
-moves NAME, STATUS and ACTIONS one position left. Existing positional parsers
-can break; request `-o wide` or recover each resource's `kind` from `-o json`.
+Adding AGE changes these four default tables from three columns to four, keeping
+NAME, STATUS and ACTIONS in their existing positions. AGE uses the same stored
+creation timestamp and formatter as wide; unavailable ages remain empty cells.
+The AGE header and a two-cell gap add five display cells when ages fit within
+three cells; longer ages widen the table further. Resource CLI output is not
+clipped at COLUMNS 40/80/112, so narrow terminals can wrap earlier.
+Positional parsers must account for the added field; each resource's `kind`
+remains available in `-o wide` and `-o json`.
 Mixed Registry/Runtime pickers keep KIND in both profiles.
 
 Scripts that need diagnostic columns must request `-o wide` or a structured projection explicitly. Registry JSON items
@@ -18,15 +23,15 @@ projections retain their contracts, as do singular reads and selector cardinalit
 
 | Surface / kind | Default | Wide |
 | --- | --- | --- |
-| Registry Project | NAME STATUS ACTIONS | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED AGE |
-| Registry Window | NAME STATUS ACTIONS | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED PROJECT AGE |
-| Registry Pane | NAME STATUS ACTIONS | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED PROJECT WINDOW AGENT TERMINATION AGE |
-| Registry Agent | NAME STATUS ACTIONS | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED INTERACTION PROJECT WINDOW SESSION TERMINATION AGE |
+| Registry Project | NAME STATUS ACTIONS AGE | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED AGE |
+| Registry Window | NAME STATUS ACTIONS AGE | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED PROJECT AGE |
+| Registry Pane | NAME STATUS ACTIONS AGE | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED PROJECT WINDOW AGENT TERMINATION AGE |
+| Registry Agent | NAME STATUS ACTIONS AGE | KIND NAME STATUS ACTIONS CONTEXT SOURCE OBSERVED INTERACTION PROJECT WINDOW SESSION TERMINATION AGE |
 | Runtime Session | SESSION NAME CLASS | SESSION NAME CLASS UID RESOURCE REASON |
 | Runtime Window | WINDOW SESSION NAME CLASS | WINDOW SESSION NAME CLASS UID RESOURCE REASON |
 | Runtime Pane | PANE WINDOW TITLE CLASS | PANE WINDOW TITLE CLASS UID RESOURCE REASON |
 
-Registry defaults omit KIND, CONTEXT, SOURCE, OBSERVED, AGE and each kind's owner-chain,
+Registry defaults omit KIND, CONTEXT, SOURCE, OBSERVED and each kind's owner-chain,
 INTERACTION, SESSION and TERMINATION diagnostics shown in the wide column above.
 Runtime defaults omit UID, RESOURCE and REASON. Wide retains their full values;
 stdout is unbounded and copyable, including long names, context, provider session

package/docs/heterogeneous-dialogue-canary.md

@@ -337,3 +337,26 @@ The selectorless E2E remains the single deterministic L20 scenario. Actual
 active-tool/human overlap, multiple ordinary requests, same-UID recovery and
 installed smoke remain separate unverified evidence. They are not run by this
 qualification-plus-one-idle transaction and are not inferred from its result.
+
+`TestClaudeDialogueStreamReplaysObservedFrameCorpus` replays the preserved
+Claude Code 2.1.263 frame shapes through the reply-only validator and fails when
+a recorded verdict moves. Neither it nor L20 proves:
+
+- compatibility with the installed provider, which only this canary observes;
+- value drift, because the corpus keeps top-level key shape and fills values
+  with placeholders;
+- acceptance of unknown frames or fields, which the closed vocabulary rejects
+  by design.
+
+The L20 fixture emits none of the corpus's dropped side frames. Recorded real
+shapes the validator rejects today:
+
+- `result-success-25-keys`: the result allowlist lacks `origin`;
+- `system-init-allowlist-diff`: the init allowlist lacks `memory_paths` and
+  `terminal_slash_commands`.
+
+Shapes without preserved evidence are gaps, not corpus items: `command_lifecycle`
+keys and values; a non-null assistant `context_management` value; `system`
+`thinking_tokens` frames; hook and user `tool_result` frames; the exact real init
+key set; nested values of every frame; `rate_limit_event` envelope keys beyond
+`type` and `rate_limit_info`; and earlier shape inventories, which were lost.

package/docs/keybindings.md

@@ -217,6 +217,91 @@ without storing or replacing the transport default. Rename actions no longer
 have a built-in terminal fallback; use tmux's prefix rename flow or configure
 an explicit safe key where the action is editable.
 
+## Managed close keys
+
+The generated app config replaces tmux's stock `prefix x` (kill Pane) and
+`prefix &` (kill Window) with two catalog actions, `pane.delete` (v0 id
+`delete-pane`) and `window.delete` (v0 id `delete-window`). Each binding
+branches on the target's Registry identity mirror:
+
+| Key | Target carries the mirror | Target has no mirror |
+| --- | --- | --- |
+| `prefix x` | `@projmux_pane_uid`: confirm, then the Pane menu Kill route (canonical `delete pane`) | tmux stock `confirm-before -p "kill-pane #P? (y/n)" kill-pane` |
+| `prefix &` | `@projmux_window_uid`: confirm, then canonical `delete window` | tmux stock `confirm-before -p "kill-window #W? (y/n)" kill-window` |
+
+A managed target is always confirmed first. The prompt is localized (en-US and
+ko-KR) when the key is pressed. It says the resource is deleted from the
+Registry and what happens to Agents: deleting a Pane leaves its owning Agent in
+the Registry as Offline with a `deleted` exit, and deleting a Window deletes the
+Agents in it. Neither comes back on Continue. Answering `y` deletes the target
+with an `intentional` termination receipt, so a later Project start does not
+re-materialize it. Deleting a Project's last Window follows `delete window` and
+leaves a zero-Window Project. When the canonical route refuses, the reason is
+shown on the client that pressed the key and nothing falls back to a raw tmux
+kill.
+
+A target without the mirror gets tmux's own stock prompt and kill, unchanged,
+and projmux writes nothing to the Registry. The projmux process never issues
+`kill-pane` or `kill-window` for either key: the stock body is tmux's binding,
+run by tmux. The standalone `~/.tmux.conf` snippet does not carry these
+actions, so a plain tmux server keeps both keys stock.
+
+Both actions follow the ordinary keymap rules. In `keymap.toml`,
+`prefix = "<key>"` moves the managed binding, `prefix = ""` disables it, and
+`keys` adds root-table keys that run the same branching binding:
+
+```toml
+[bindings."pane.delete"]
+prefix = "X"
+
+[bindings."window.delete"]
+prefix = ""
+```
+
+When an action no longer owns its stock key, because it was disabled or moved,
+the generated config unbinds that key and binds tmux's stock body back onto it.
+`prefix x` and `prefix &` therefore return to tmux's own behavior on the next
+apply, including on a server that is already running, instead of being left
+with no binding at all. Two managed actions on one prefix key are rejected.
+Settings > Keybindings adds and removes root-table keys for these actions; their
+prefix key is changed in `keymap.toml`.
+
+## Managed menus
+
+The generated app config also replaces tmux's stock Window and Pane menus. Each
+generated menu keeps tmux's title, position, item names, key shortcuts, and dim
+conditions, and changes only the items that alter topology or identity:
+
+| Menu | Bindings | Kill on a target with the mirror | Kill on a target without it | Typed items | Removed |
+| --- | --- | --- | --- | --- | --- |
+| Window | `prefix <`, `MouseDown3Status`, `M-MouseDown3Status` | `@projmux_window_uid`: `internal tmux window-delete`, canonical `delete window` | tmux stock `kill-window` | Rename: `internal tmux window-rename`; New At End: `internal tmux window-create` | Respawn, New After |
+| Pane | `prefix >`, `M-MouseDown3Pane` | `@projmux_pane_uid`: the Pane menu Kill route, canonical `delete pane` | tmux stock `kill-pane` | Horizontal Split / Vertical Split: `internal tmux pane-menu split-right` / `split-down` | Respawn |
+| Pane context | `MouseDown3Pane` | same as the Pane menus | tmux stock `kill-pane` | Horizontal Split / Vertical Split, as above | Respawn |
+
+Swap Left, Swap Right, Swap Marked, Swap Up, Swap Down, Mark, Zoom, and the
+copy-mode items (Go To Top, Go To Bottom, Search For, Type, Copy, Copy Line)
+are presentation and run tmux's own commands. `MouseDown3Pane` also keeps its
+AI Resume Picker entry.
+
+Selecting Kill is the confirmation, as it is in tmux's own menus, so a managed
+Kill asks nothing more. It deletes the target with an `intentional` termination
+receipt: a Pane's owning Agent stays in the Registry as Offline with a `deleted`
+exit, the Agents of a deleted Window are deleted with it, and deleting a
+Project's last Window leaves a zero-Window Project. When the canonical route
+refuses, for example because the mirror names no Registry resource, the reason
+is shown on the client that opened the menu and nothing falls back to a raw
+tmux kill. A target without the mirror gets tmux's own kill with no Registry
+write; the projmux process never issues `kill-pane` or `kill-window`.
+
+A mouse menu acts on what was clicked, not on what is focused: Kill, Rename, and
+New At End in the status-line Window menu act on the clicked Window, and the
+Rename prompt starts with that Window's name.
+
+The standalone `~/.tmux.conf` snippet keeps tmux's stock `prefix <`, `prefix >`,
+`MouseDown3Status`, `M-MouseDown3Status`, and `M-MouseDown3Pane` menus; it
+carries only the `MouseDown3Pane` menu. A `keymap.toml` that assigns a managed
+action to `prefix <` or `prefix >` keeps that key.
+
 ## Product Requirements
 
 Settings > Keybindings stays a discovery surface. It must continue to expose

package/docs/operational-diagnostics.md

@@ -44,6 +44,20 @@ UIDs and stage labels are bounded control data; root paths, pane content,
 history, prompts, transcripts, and snapshot contents are never identity or
 intent authority.
 
+Automatic Window teardown decisions use `component=topology` and
+`event=topology.teardown.decision`: one `info`/`success` record per decision
+the `internal tmux converge` hook path consumes. An unpaired `window-unlinked`
+records `retain` when its own hook first waits and again when its bounded pair
+wait is exhausted, never for the carried retries between; its Window/Pane UID
+is resolved read-only from the exact `$N/@N` handles and omitted when
+ambiguous. The record adds only
+a closed `decision` (`retain`, `delete-pane-agent`, `delete-window`, `refuse`),
+a `code` from the closed `topology.teardown.<reason>` set that mirrors every
+core teardown reason, an optional closed termination `classification`, and
+optional opaque `window_uid` (`win-…`) and `pane_uid` (`pane-…`) Registry UIDs.
+tmux `%N`/`@N`/`$N` handles, socket paths, session names, cwd, argv, and free
+text are never recorded, and every other event family rejects these fields.
+
 Session State mutations use one outcome-only `session-state.outcome` record
 per selected attempt. The closed operations are `session-state.save`,
 `session-state.autosave`, `session-state.restore`, and `session-state.delete`;

package/docs/replacement-contract.md

@@ -105,7 +105,9 @@ holds the forgery refusal. For the `L2` guarantee above,
 `TestBrokerRuntimeDrainsWhenItsOwnImageWasReplaced` holds the vintage entry
 condition and that a runtime on the installed image is not drained by it,
 `TestReplacementRolePoliciesMatchTheContractDocument` and
-`TestReplacementSessionClientIsNeverADrainTarget` hold the policy table, and
+`TestReplacementSessionClientIsNeverADrainTarget` hold the policy table,
+`TestReplacementRoutesNameARunnableAction` holds that every role's action is a
+runnable `projmux` command or a closed lifecycle event, and
 `TestInstallReplacementPassOutcomesAreFixedByFleetAndRequest` fixes every
 outcome of the install pass.
 
@@ -321,18 +323,46 @@ measurement, and they are fixed here rather than at a call site.
 when it actually goes. `report-only` means no install touches it; the route that
 does replace it is named instead, so a reader of the row knows what would.
 
-`TestReplacementRolePoliciesMatchTheContractDocument` holds this table and the
-code's policy map equal, in both directions.
+`TestReplacementRolePoliciesMatchTheContractDocument` holds this table — its
+operator actions included — and the lifecycle event table below equal to the
+code's policy map and event set, in both directions.
 
-| Role | Disposition | Replacement route |
-| --- | --- | --- |
-| `broker-runtime` | `drain` | `broker-drain` |
-| `lifecycle-observer` | `report-only` | `pane-relaunch` |
-| `supervisor` | `report-only` | `pane-relaunch` |
-| `session-client` | `report-only` | `operator-reattach` |
-| `agent-endpoint` | `report-only` | `pane-relaunch` |
-| `usage-watcher` | `report-only` | `lease-expiry` |
-| `other` | `report-only` | `process-exit` |
+| Role | Disposition | Replacement route | Operator action |
+| --- | --- | --- | --- |
+| `broker-runtime` | `drain` | `broker-drain` | event `install-replacement-pass` |
+| `lifecycle-observer` | `report-only` | `pane-relaunch` | `projmux stop project <project-ref>`, then `projmux start project <project-ref>` |
+| `supervisor` | `report-only` | `pane-relaunch` | `projmux stop project <project-ref>`, then `projmux start project <project-ref>` |
+| `session-client` | `report-only` | `operator-reattach` | event `shell-wrapper-exit`, then `projmux shell` |
+| `agent-endpoint` | `report-only` | `pane-relaunch` | `projmux stop project <project-ref>`, then `projmux start project <project-ref>` |
+| `usage-watcher` | `report-only` | `lease-expiry` | event `usage-demand-lapse` |
+| `other` | `report-only` | `process-exit` | event `invocation-exit` |
+
+**The operator action is the route spelled as something that can happen.** A
+route name says which kind of replacement applies; the action says what carries
+it out, step by step. A step is either a `projmux` command the shipped CLI
+catalog resolves to a runnable verb, or one of the lifecycle events below, which
+replace a role with no command at all.
+`TestReplacementRoutesNameARunnableAction` fails when a command names a route
+the catalog does not have, stops at a verb that refuses without its child, or
+reaches into `internal`, and when an event is outside this list.
+
+| Event | What happens |
+| --- | --- |
+| `install-replacement-pass` | `make install` runs `projmux internal install-replace`, which dials the superseded broker runtime. The runtime drains, closes when its last binding goes, and the next binding starts one on the installed image |
+| `shell-wrapper-exit` | the terminal command that ran `projmux shell` returns. The wrapper waits on its `tmux attach-session` child, so it ends only when that client does |
+| `usage-demand-lapse` | no usage render has refreshed the watcher's demand marker within its 15-second TTL, so the watcher cancels itself and releases its lease; the next render starts one on the installed image. A status line still rendering the usage segment keeps that demand fresh |
+| `invocation-exit` | a short-lived invocation returns on its own, and the next one runs the installed image |
+
+**`pane-relaunch` is a Project runtime cycle.** Each role it covers lives as
+long as one managed Pane: the supervisor is that Pane's own process, the
+lifecycle observer ends once its Pane binding is gone, and the endpoint helper
+ends once its provider process does. `projmux stop project` ends the Project's
+exact tmux session and preserves its Registry graph; `projmux start project`
+materializes that graph again from the installed image, and its Continue
+launches or resumes the Project's declared Agents under the same eligibility
+every Continue uses. It ends every Pane of that Project, which is exactly why
+no install runs it on the operator's behalf. A Pane under the Home control
+session belongs to no Project, and no Project verb reaches it.
 
 **Exactly one role drains, and that is a fact about what exists rather than a
 first instalment.** A drain is a protocol: the runtime has to be able to hear
@@ -350,6 +380,17 @@ typed into. It is report-only and no cutoff reaches it.
 `TestReplacementSessionClientIsNeverADrainTarget` holds that as a property of
 the table rather than of any call site.
 
+**Detaching and reattaching does not by itself finish that replacement.** The
+census counts the `projmux shell` wrapper, not the tmux client. The wrapper
+starts `tmux attach-session` as a child process and waits on it, so the
+wrapper — the process still on the pre-install image — keeps running until that
+client exits and the terminal command that ran `projmux shell` returns. A
+reattach that leaves that command running, such as switching sessions or
+attaching a second client, leaves the wrapper exactly where it was. The required
+action is to end the wrapper by exiting the terminal session running
+`projmux shell`, then start `projmux shell` again, which runs the installed
+image.
+
 **No disposition severs work.** The one hard kill this repository has measured —
 2026-09-05, four panes — brought three of the four back automatically and left
 the fourth wedged on `backlog-overflow`. A recovery asymmetry that large is what