agent-pbx 2.2.0__tar.gz → 2.3.0__tar.gz

{agent_pbx-2.2.0/src/agent_pbx.egg-info → agent_pbx-2.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: agent-pbx
-Version: 2.2.0
+Version: 2.3.0
 Summary: Runtime-grounded control plane for durable Codex Agent and Operator sessions.
 Author: Agent PBX contributors
 License-Expression: Apache-2.0
@@ -109,7 +109,7 @@ origin policy, and versioned product-site contract.
 
 See [the architecture overview](https://github.com/m4xx3d0ut/agent-pbx/blob/dev/docs/architecture.md),
 [the project wiki](https://github.com/m4xx3d0ut/agent-pbx/wiki),
-[the v2.2 release notes](https://github.com/m4xx3d0ut/agent-pbx/blob/dev/docs/releases/v2.2.0.md), and
+[the v2.3.0 release notes](https://github.com/m4xx3d0ut/agent-pbx/blob/dev/docs/releases/v2.3.0.md), and
 [the accepted architecture decisions](https://github.com/m4xx3d0ut/agent-pbx/blob/dev/docs/adr/README.md) for the complete
 control-plane and compatibility boundaries.
 
@@ -471,7 +471,9 @@ Campaign state is stored in dedicated SQLite tables for fast TUI/API queries:
 `operator_campaign_events`. Fork state and optional planning DAG links are
 stored in `operator_forks` and `operator_fork_edges`. Knowledge-link context is
 stored in `operator_knowledge_links` and `operator_knowledge_turns`; executable
-operator-to-operator handoffs are stored in `operator_handoffs`. Handoffs track
+operator-to-operator handoffs are stored in `operator_handoffs`; durable
+source-addressed terminal receipts are stored in
+`operator_handoff_completion_deliveries`. Handoffs track
 approval, required target fork launch, delivery evidence, receiver
 acknowledgement, started/running state, TTL expiry, artifact summaries, and
 terminal status without creating fork edges or changing source-session
@@ -524,16 +526,67 @@ should provide needed domain context through the first prompt, KB context, or a
 knowledge handoff. Set `AGENT_PBX_TUI_REVIEW_FORK_LAUNCH_MODE=fresh_context`
 to skip transcript continuation for new review forks.
 
+Linked Git worktrees receive one additional launch preflight for trusted
+default/edit forks. Agent PBX validates the canonical checkout, `.git`
+indirection and reverse backpointer, per-worktree admin directory, common object
+database, attached local branch, ownership, symlink posture, and approved-root
+boundary. A qualifying branch must use a dedicated namespace such as
+`pbx-operator-N/<fork-id>` with no sibling refs in that namespace. For a simple
+compatible base profile, the generated Codex permission profile adds write
+access only to the active worktree admin directory, shared object database, and
+that branch's dedicated ref/reflog directories. These are sandbox filesystem
+grants, never Codex workspace roots or `--add-dir` inputs. The profile never
+grants the common `.git` root, sibling worktree admin directories,
+configuration, or hooks. Standalone repositories and non-Git projects retain
+their existing behavior; review/read-only forks never receive this profile.
+
+Codex 0.166 cannot safely compose those direct writes with a base profile that
+contains split secret/read/deny filesystem rules. Agent PBX does not flatten or
+weaken that policy. Instead, a stopped, inactive edit fork can use the local
+TUI's root-confirmed `/operator git commit` action. The broker accepts an exact
+enumerated leaf subset—never add-all—shows each leaf's state, mode, raw SHA-256,
+raw Git blob OID, and prior index identity, then binds confirmation to the
+transaction, branch, HEAD/tree/index, upstream, ref, and reflog receipt. It
+commits the approved raw bytes without clean filters while leaving unapproved
+dirty paths unenumerated and unopened. The fork remains stopped after commit.
+
+The broker uses a private crash journal and object quarantine. Ref, index, and
+reflog changes are compare-and-swap guarded and exactly completed or restored
+when their recorded identities still match. A failed transaction can leave
+only the journaled immutable Git objects derived from the approved blobs, tree,
+and commit; they remain unreachable and are left for normal Git garbage
+collection because deleting shared objects during rollback is unsafe. Use
+`/operator git recover` after a TUI/process interruption. Ambiguous, detached,
+bare, malformed, symlinked, unapproved, partial-clone/promisor, object-alternate,
+external-config-include, staged, sparse/split-index, or unmerged topologies fail
+before mutation. Broker execution is unavailable through HTTP, API, or MCP and
+is never an alternate commit path for direct-compatible forks.
+
+The broker validates Git indexes structurally rather than scanning arbitrary
+index bytes for extension names. It parses supported `DIRC` v2-v4 entries using
+the repository's SHA-1 or SHA-256 object-ID width, verifies pathname and padding
+boundaries plus the trailing checksum, and then parses the actual extension
+table. Ordinary path or object data containing `link` or `sdir` is safe; real
+split/sparse extensions, unknown mandatory extensions, malformed layouts, and
+ambiguous boundaries still fail closed.
+
 Review forks should treat the source checkout as read-only and write only under
 their configured `work_root`. If a finding requires edits in the source repo,
 route it with `pbx_operator_route_review_escalation` so the root operator or an
 idle default/edit fork can handle it. If review work needs a new sibling
 project, call `pbx_operator_request_project_spawn` with the project name,
 instructions, and `mode` of `empty` or `clone_source`. The TUI/root operator
-approves the oldest pending request with `Spawn P` or `/operator project spawn`;
-Agent PBX then creates the sibling project at the same parent depth as the
-source repo, starts a normal tmux caller Codex session there, and attaches it to
-the Agents pane when it registers.
+inspects the oldest pending request with `/operator project spawn inspect`, can
+cancel it without launching through `/operator project spawn cancel`, and
+approves it with `Spawn P` or `/operator project spawn`. Agent PBX validates the
+source and target before accepting the request and revalidates immediately
+before approval. A non-empty target is never copied over or initialized; select
+another empty sibling target or use the managed workspace launcher for an
+existing canonical Git repository. `clone_source` requires the review source to
+be the canonical Git root, and an explicit `metadata.repo_root` must match it.
+After validation, Agent PBX creates the sibling project, starts a normal tmux
+caller Codex session there, records its exact runtime mapping, and attaches it
+to the Agents pane when it registers.
 
 If review work needs to transfer domain context to another operator, the review
 fork can call `pbx_operator_propose_knowledge_handoff` with the source review
@@ -549,7 +602,16 @@ The root operator/TUI uses
 `/operator handoffs` to inspect pending handoffs and
 `/operator handoff preflight` to dry-run pane readiness, queue/nohup routing,
 required target-fork state, and attached KB context without sending anything.
-Use `/operator handoff approve` to approve the oldest pending handoff. If the
+Use `/operator handoff approve` to open the durable handoff approval center.
+It lists pending requests by immutable handoff ID, preflights the selected IDs,
+and requires an explicit confirmation before delivery. `Cancel selected`
+withdraws source-owned `proposed`, `approved`, or `pending_launch` requests
+without deleting their records. Cancellation requires a reason, records the
+prior state and actor in handoff metadata and the event journal, and requires
+replacement handoff IDs when the reason is `superseded`. It fails closed once
+delivery, acknowledgement, or execution has started. The top banner reports
+`APPROVALS N` until the underlying records leave a pending state; reading the
+Operator's latest report does not clear this approval alert. If the
 target operator needs a caller fork that has not been launched, the handoff
 moves to `pending_launch`; use `/operator handoff launch` to launch the
 required fork and retry delivery. Agent PBX then sends a normal `send_input`
@@ -566,6 +628,76 @@ success by itself. Tmux evidence records the resolved pane, target command,
 paste/send-key steps, and whether the target looked Codex-like; `submitted` is
 only true for a Codex-like target.
 
+A terminal handoff update creates one idempotent completion receipt for the
+exact source root Operator or source fork. The Operators pane keeps semantic
+`State` and `Flow` separate from tmux `Live`; pending results appear as
+`⇠ REVIEW` with an `RCPT` marker. The top banner reports `RECEIPTS N`, and F8
+opens the completion center after pending approvals and before guarded actions.
+Reviewing and acknowledging a receipt stops retry/attention state without
+changing the completed, failed, blocked, or canceled handoff. Nohup recipients
+receive an exact queued command. Report-mode terminal injection requires an
+exact managed runtime mapping or recorded pane; otherwise the durable receipt
+remains pending rather than using global pane discovery.
+
+New executable handoffs should also include a machine-readable
+`execution_scope`. It records an `action_class`, `mutation_mode`, campaign and
+workspace-set identity, allowed roots, exact paths, and explicit denied actions.
+The `exact_git_commit_broker` class additionally requires the expected Git
+parent and exact commit subject. An optional ordered `expected_git_parents`
+list supports an exact merge commit; its first entry must equal the stopped
+fork's HEAD, every entry must be a complete unique commit object ID, and the
+broker verifies the order before and after writing the commit. Multi-parent
+requests also require an `expected_git_tree`; the broker reconstructs that tree
+from the approved raw-byte path set and refuses a mismatch before changing the
+index or branch. Active merge, cherry-pick, revert, rebase, bisect, or sequencer
+state is rejected. Requests that omit the list retain the original
+single-parent behavior. Absolute or parent-traversing path entries are rejected.
+The legacy free-form
+`allowed_mutation_scope` remains readable but is never sufficient for delegated
+approval.
+
+The public/default broker flow remains guided: the TUI exposes one reviewed
+stop, broker, resume, or validation step at a time. A dedicated single-user
+host may enable root-supervised checkpoints. A root Operator can then create a
+durable request for its own activated Trusted Workbench edit fork. The local
+TUI revalidates the exact handoff and campaign, stops the managed fork, commits
+only the pinned paths with the pinned parent and subject, resumes the same Codex
+session, and returns an auditable receipt. Root validation remains a separate
+step. Edit and review forks are not given the request tools, remote observers
+cannot control it, and the executor endpoints accept only loopback clients.
+The normal controller bearer remains an administrator credential and must not
+be exposed to untrusted processes.
+
+```bash
+export AGENT_PBX_OPERATOR_BROKER_MODE="guided" # guided|root_operator|disabled
+export AGENT_PBX_OPERATOR_BROKER_CONTROL_MODE="editable" # editable|read_only|hidden
+export AGENT_PBX_OPERATOR_BROKER_REQUEST_TTL_SECONDS="900"
+export AGENT_PBX_OPERATOR_BROKER_MAX_IN_FLIGHT="1"
+```
+
+`root_operator` is intentionally a local administrator choice; it is not the
+committed default. Requests survive TUI replacement, use a bounded executor
+lease, recover commit evidence from durable action receipts, and fail closed on
+scope, workspace, session, pane, Git parent, or path drift.
+
+The committed default remains manual approval. On a trusted local workstation,
+the approval center's `Trust & approve` action can grant a one-hour,
+use-limited campaign lease and approve the selected structured handoffs. Source
+and target Operators must share the same activated `trusted-workbench`
+workspace-set digest. The lease is pinned to the selected source-owned
+campaigns, targets, action classes, roots, and exact paths. Matching future
+handoffs may then pass preflight and deliver without another modal. Legacy or
+unstructured handoffs are rejected before the lease confirmation and remain
+eligible for one-time `Approve selected`; create a structured successor when
+future automatic approval is required. Agent PBX preflights every selected
+handoff before creating the lease and revokes or rejects an incomplete lease
+when activation fails.
+Credentials, provider/cloud operations, deployment, publication, push, tag,
+release, repository/worktree/fork creation, workspace expansion, authority
+elevation, destructive mutation, and unstructured legacy requests always stay
+manual. Leases are audited, expire automatically, have a bounded use count,
+and can be revoked through the controller API.
+
 When a knowledge link or handoff produces reusable operating guidance, review
 forks and operators can propose KB entries with `pbx_operator_kb_propose` or
 `pbx_operator_kb_propose_from_link`. Proposed entries stay scoped to the
@@ -646,6 +778,11 @@ not receive a review task during creation. When the review fork requests a
 sibling project, select the operator and use
 `Spawn P` or `/operator project spawn`; the spawned project should then appear
 as a normal caller in the Agents pane after its Codex session registers. When a
+request is obsolete or points at pre-existing work, use
+`/operator project spawn inspect` followed by
+`/operator project spawn cancel`; cancellation is idempotent and does not touch
+the target. Existing-workspace adoption remains the `F10` managed-launch path
+rather than a project-spawn mode in this release candidate. When a
 review fork proposes a knowledge handoff, select the logical operator and run
 `/operator handoffs` to inspect workflow state, `/operator handoff preflight`
 to verify the target route, `/operator handoff approve` to approve delivery,
@@ -767,14 +904,182 @@ export AGENT_PBX_WORKERBEE_SWITCHER_STATUS_BIN="$HOME/.local/bin/wb-mcp-status"
 export AGENT_PBX_WORKERBEE_SWITCHER_BIN="$HOME/.local/bin/wb-mcp-switch"
 ```
 
+Agent PBX treats backend selection, access policy, workspace placement, and
+appliance snapshot content as separate controls. Exactly one backend is
+selected at a time:
+
+| Backend | Workspace domain | Current posture |
+|---|---|---|
+| `oss` | The exact host Git root | Supported |
+| `platform_debug` | A content-addressed import under the debug appliance workspace | Supported |
+| `user_appliance` | A separate managed appliance volume | Contract reserved; live image qualification deferred |
+
+Every TUI-launched or resumed Agent, Operator, edit fork, and review fork gets a
+private gateway lease bound to the selected backend fingerprint, generation,
+project, and workspace receipt. A backend change invalidates the old lease;
+restart or resume the affected Codex session through Agent PBX to materialize
+and verify a fresh binding. The daemon does not merge host OSS status into an
+appliance-backed session.
+
+Platform-debug needs the repository-installed materializer plus the private
+WorkerBee staging contract:
+
+```bash
+export AGENT_PBX_WORKERBEE_WORKSPACE_HELPER_BIN="$(command -v agent-pbx-workerbee-workspace)"
+export AGENT_PBX_WORKERBEE_DEBUG_STAGE_PYTHON="/path/to/k1s-workerbee-private/.venv/bin/python"
+export AGENT_PBX_WORKERBEE_DEBUG_STAGE_SCRIPT="/path/to/k1s-workerbee-private/scripts/dev/stage_platform_debug_workspace.py"
+export AGENT_PBX_WORKERBEE_DEBUG_CONTAINER="workerbee-mcp-debug"
+export AGENT_PBX_WORKERBEE_DEBUG_IMPORT_ROOT="/workspace/imports"
+```
+
+Tracked files, including initialized submodule trees, are staged automatically.
+If a session deliberately needs dirty or untracked submodule content, approve
+only the required paths in private host configuration. The policy is bound to
+both Agent ID and exact source root and is never read from Agent-controlled
+registration metadata:
+
+```bash
+export AGENT_PBX_WORKERBEE_WORKSPACE_INCLUDES_JSON='{"agent-id":{"source_root":"/absolute/project","include_paths":["business-site/product-pages/agent-pbx","business-site/docs/agent-pbx-product-site.md"]}}'
+```
+
+The snapshot rejects `.git`, secret-sensitive paths, escaping links, special
+files, commit-mismatched or nested submodules, and paths outside that explicit
+allowlist. Ordinary tracked repository content requires no include policy.
+
+The three access profiles are `observe-local`, `review-readonly`, and
+`local-deploy`. Deployment authority requires durable entity metadata that
+explicitly sets `workerbee_mcp_profile=local-deploy`; a launch candidate cannot
+self-select that profile. Review forks always receive the read-only profile.
+Gateway bearer tokens are passed only in the child process environment and are
+not stored in Agent or Operator metadata.
+
+Use `Access` in the WorkerBee tab or `/workerbee access` to select inspect-only
+or bounded local build/deploy authority for one Agent or Operator. The change
+is durable but takes effect only after a safe Agent PBX restart/resume. This
+keeps authority changes explicit and prevents a running process from broadening
+its own lease.
+
+Operator coordination role is separate from execution authority. The
+`/operator authority` palette command manages four server-enforced profiles:
+
+| Profile | Intended use |
+|---|---|
+| `scoped-edit` | Safe public default for one working checkout |
+| `trusted-workbench` | Exact, versioned multi-project workspace set with LAN network access and bounded WorkerBee local deployment |
+| `full-access` | Exceptional local-only profile, available only when the administrator ceiling permits it |
+| `review-readonly` | Immutable profile for review forks |
+
+Trusted Workbench sets contain canonical Git toplevels. A collection such as
+`~/git/k1s-wt` may discover candidate repositories, including linked
+worktrees, but the reviewed snapshot stores each selected checkout explicitly.
+The collection itself never becomes a wildcard writable root. Agent PBX
+qualifies linked-worktree Git metadata, rejects shared branch collisions,
+deduplicates exact administration paths, and resumes the Codex thread before
+recording the new profile as active. Edit forks inherit the root Operator's
+profile; review forks never do.
+
+The public default remains `scoped-edit`. Dedicated single-user workstations
+can select `trusted-workbench` as their local default while retaining an
+administrator root ceiling:
+
+```bash
+export AGENT_PBX_OPERATOR_AUTHORITY_CONTROL_MODE="editable"
+export AGENT_PBX_OPERATOR_AUTHORITY_PROFILE_CEILING="trusted-workbench"
+export AGENT_PBX_OPERATOR_AUTHORITY_DEFAULT_PROFILE="trusted-workbench"
+export AGENT_PBX_OPERATOR_AUTHORITY_ROOT_CEILING_JSON='["/home/user/git"]'
+export AGENT_PBX_OPERATOR_AUTHORITY_WORKFLOW_LABEL="Trusted Workbench"
+```
+
+The complete profile, workspace-set, inheritance, and rollback contract is in
+the [Operator authority wiki guide](https://github.com/m4xx3d0ut/agent-pbx/wiki/Operator-Authority-and-Workspace-Sets).
+
+Workspace mobility is a separate daemon policy. The committed default is
+`pinned` with controller approval: an Agent may refresh the content of its
+current checkout but cannot silently bind WorkerBee to another repository.
+The WorkerBee tab's `Workspace` action and `/workerbee workspace` palette
+command show the effective policy, preview a canonical Git root and subpath,
+apply an approved binding, review pending requests, and revert the latest
+applicable transition.
+
+| Policy | Allowed target |
+|---|---|
+| `pinned` | Current Git checkout only |
+| `same-repository` | Worktrees and subdirectories sharing the same Git common directory |
+| `scoped-workbench` | Git checkouts and subdirectories beneath controller-approved roots |
+
+Request mode is independently `approval`, `automatic`, or `disabled`.
+Changing a workspace never changes the lease token, selected WorkerBee
+backend, generation, or tool profile. A `review-readonly` fork therefore
+remains read-only after a move, while `local-deploy` remains limited to its
+existing bounded tool allowlist. A supplied scenario label becomes a
+deterministic, namespaced WorkerBee project.
+
+Administrators can constrain or remove this UI without trusting client-side
+settings:
+
+```bash
+export AGENT_PBX_WORKERBEE_WORKSPACE_CONTROL_MODE="read_only" # editable|read_only|hidden
+export AGENT_PBX_WORKERBEE_WORKSPACE_POLICY_CEILING="same-repository"
+export AGENT_PBX_WORKERBEE_WORKSPACE_ROOT_CEILING_JSON='["/srv/engineering"]'
+export AGENT_PBX_WORKERBEE_WORKSPACE_REQUEST_MODE="approval"
+```
+
+The environment values are hard ceilings. A TUI or Agent cannot expand them.
+Allowed roots and transition paths are stored by the daemon and are omitted
+from ordinary status events. `agent-pbx doctor` reports the effective policy
+without printing its host paths.
+
+For appliance-backed sessions, `Content` or `/workerbee content` independently
+selects `tracked`, explicit `approved-paths`, or a bounded
+`safe-working-tree` snapshot. Safe working tree excludes common secret paths,
+keys, links, special files, virtual environments, dependency caches, and
+oversized content. It is intended for trusted single-user workstations;
+high-assurance environments should use tracked or explicitly approved paths.
+OSS direct-host sessions do not use appliance snapshot policy.
+
+The setup assistant can install reviewed workflow defaults without selecting a
+backend or granting deployment tools:
+
+```bash
+agent-pbx setup plan \
+  --project-root "$HOME/git" \
+  --workerbee-preset trusted-platform-workbench
+```
+
+Committed new-user behavior remains observe-only, pinned plus approval, and
+tracked content. Administrators may independently constrain or hide Access,
+Workspace, and Content controls. The complete preset and environment reference
+is in the [WorkerBee wiki guide](https://github.com/m4xx3d0ut/agent-pbx/wiki/WorkerBee-Integration).
+
 `/workerbee switch oss` and `/workerbee switch debug` always begin with the
 switcher's real non-mutating `--dry-run` result. Apply requires an unexpired
 private transaction, unchanged backend evidence, exact typed confirmation, and
 an additional privileged confirmation for platform-debug. Agent PBX verifies
 both backend provenance and WorkerBee MCP capabilities after apply, attempts
 automatic restoration on failure, and provides `/workerbee switch rollback`
-for the last verified transaction. The change applies only to future sessions;
-running Codex sessions remain pinned to their existing MCP binding.
+for the last verified transaction. Switching is blocked while a gateway
+mutation is active. Existing generation-bound sessions fail closed with a
+rebind diagnostic after a completed switch; Agent PBX never silently retargets
+a running session to the new backend.
+
+Platform-debug posture is a separate, host-owned setting. The committed
+default remains loopback-only. A workstation whose qualified debug appliance
+owns local LAN DNS and HTTPS may opt in explicitly:
+
+```bash
+export AGENT_PBX_WORKERBEE_PLATFORM_DEBUG_POSTURE="native_lan"
+```
+
+The setting is included in preview and rollback evidence and must agree with
+the source-owned switcher's durable platform-debug profile. The normal
+`switch-debug` transaction consumes that profile, and the observed posture must
+match before Agent PBX marks the switch verified. Selecting the same backend no
+longer hides a loopback/native-LAN posture drift.
+
+This is an Agent PBX host-control setting. It does not select a different
+WorkerBee appliance for clients, alter the OSS/PaaS protocol, or affect PaaS
+users that do not run Agent PBX. A user-appliance rollout remains a separate
+WorkerBee release decision.
 
 ## Pull Request Review
 
@@ -866,8 +1171,10 @@ after writes, enable `AGENT_PBX_JOPLIN_SYNC_ON_WRITE=1` and provide a Joplin CLI
 path/profile. After each create, edit, delete, COPY note, or LOG append, Agent
 PBX records a durable SQLite sync job and a background worker runs
 `joplin --profile <profile> sync`. Note writes return before WebDAV sync
-finishes. Leave this off if a separate Joplin client or background process
-already syncs the profile.
+finishes. In managed-profile mode the status surface reports the queued sync
+before the worker briefly stops the Data API, preserves the locally saved note
+in the Joplin tab, and restores the API after success or failure. Leave this off
+if a separate Joplin client or background process already syncs the profile.
 If WebDAV sync uses E2EE, the dedicated profile must have its master key loaded;
 otherwise Joplin may exit successfully while reporting `Master key is not
 loaded`, and Agent PBX will surface that as a sync failure.
@@ -896,7 +1203,10 @@ validation, for example `Writes: ok | Profile: E2EE locked 17`. Press
 `Validate` or use `/joplin validate profile` to run the strict whole-profile
 check. `/joplin sync` remains a compatibility alias. Historical failures remain
 in Agent PBX status/events for audit; they do not roll back a note write that
-completed successfully.
+completed successfully. After correcting a remote write failure, use
+`/joplin retry write` to requeue the selected Agent or Operator's latest failed
+targeted write without creating a duplicate note or invoking strict
+whole-profile E2EE validation.
 
 Encrypted items are shown as `🔒 decryption pending`, never as empty notes.
 Agent PBX does not return encrypted payloads through its API and blocks edit,
@@ -990,6 +1300,15 @@ never stops an ambiguous or foreign process. Unrelated encrypted items remain
 visible as a separate profile-health warning without failing a verified targeted
 write.
 
+At daemon startup, `managed_cli` also verifies the configured profile's Data API
+process and starts it when the recorded process is absent and the API is not
+reachable. This restores Joplin after a host restart without a competing service
+manager. An already-live server must pass the same PID, owner, executable,
+command, and profile checks; an unverified listener or process fails closed and
+does not block the rest of Agent PBX from starting. Do not run an independent
+restart loop against the same managed profile because it could relaunch the Data
+API server during Agent PBX's exclusive CLI sync window.
+
 The managed decrypt pass uses only Joplin's own cached master-key credential.
 Agent PBX does not receive or persist the E2EE password. If the credential is
 missing or Joplin's crypto worker fails, the validated API server is restored
@@ -1052,8 +1371,10 @@ an optimistic lock using the loaded file hash or mtime and reports a conflict if
 the file changed on disk. Returning from Neovim to a clean Textual buffer
 refetches the file, so native-editor writes do not leave a stale editable copy.
 A dirty Textual buffer must be saved or reverted before its project can open in
-the native editor. `F9` or `Full F9` toggles an editor-fullscreen layout that
-keeps the TUI title and footer visible.
+the native editor. `F9`, `Full F9`, or `/view fullscreen` toggles the complete
+active right-side workspace full width while keeping the TUI title and footer
+visible. The selected right tab and its terminal/editor state are preserved;
+the compatibility command `/editor fullscreen` invokes the same layout action.
 
 `Native` or `/editor terminal` starts or attaches a project-rooted managed
 editor without requiring a file to be staged in Textual. `/editor workspace`
@@ -1265,7 +1586,9 @@ commands such as `/detail`, `/ping`, `/esc`, `/ctrlc`, `/restart`, `/tmux`,
 `/operator kb`, `/operator kb detail`, `/operator kb proposed`,
 `/operator kb proposed detail`, `/operator kb seed`, `/operator kb compile`,
 `/operator kb reindex`, `/operator kb promote`, `/operator kb reject`,
-`/operator kb retire`, `/operator project spawn`, `/codex update`, `/pr`, `/pr refresh`,
+`/operator kb retire`, `/operator project spawn`,
+`/operator project spawn inspect`, `/operator project spawn cancel`,
+`/codex update`, `/pr`, `/pr refresh`,
 `/pr review`, `/pr validate`, `/pr url`, `/pr merge`, `/issue`, `/issue refresh`, `/issue mitigate`,
 `/issue url`, `/issue clear`, configured `/joplin`, `/joplin new`,
 `/joplin rename`, `/joplin delete`, `/joplin copy`,
@@ -1291,7 +1614,22 @@ explicit restart creates a fresh pane on the configured managed tmux server,
 resumes the preserved Codex session, registers and verifies the new mapping,
 and leaves the stale or absent pane reference behind. Agent PBX refuses to
 create a pane when the daemon cannot verify mapping state, preventing an
-unreachable runtime from being duplicated. Use `/codex update` to ask the Agent
+unreachable runtime from being duplicated. Existing-pane stop, purge, restart,
+and resume actions require an exact executable/socket/server/session/window/pane
+match and never fall back to the process-default tmux server; colliding pane IDs
+therefore fail safely. For a canceled, inactive edit fork, a durable mapping in
+`missing` state is treated as historical local evidence only after a fresh
+daemon probe agrees with the Agent's recorded server mode/ID, tmux session and
+pane, and Codex session; the writer lease is empty; and the recorded process is
+conclusively absent. A fresh local/outer tmux listing must also contain no pane
+owned by that Agent. A same-number pane on another tmux server does not revive
+that stale mapping. Unreadable process evidence, missing provenance, a live
+process with matching start identity, an active writer, embedded-terminal
+state, and every
+non-missing runtime state continue to block reconciliation. A readable PID with
+different start ticks proves that the registered process identity is gone;
+an existing but unreadable or malformed `/proc/<pid>` remains ambiguous. Use
+`/codex update` to ask the Agent
 PBX daemon to run the allowlisted npm update for
 `@openai/codex`, then use `/restart` or `/codex restart` to move long-lived
 caller, root-operator, and fork panes onto the updated executable. TUI-owned
@@ -1449,6 +1787,22 @@ default edit fork. `/agent launch` remains an alias for the same picker, while
 caller. Plain `F10` remains PBX-owned under embedded-terminal focus;
 `Shift+F10` sends F10 to Codex.
 
+Managed caller launch now includes a deterministic, audited registration
+bootstrap in the initial Codex command. It disables the startup update check so
+an upgrade interstitial cannot consume that prompt, exposes only the caller
+registration/report Agent PBX tools, auto-approves those explicitly enabled
+tools, and leaves unrelated approval escalation disallowed by the caller's
+normal launch policy. Retries with the same Agent, repository, profile, runtime
+mode, and source Codex session return the existing ready mapping rather than
+creating a second pane. The source session identifier and bootstrap digest are
+retained as launch provenance.
+
+TUI-created root Operators, edit forks, and review forks launch on the selected
+runtime tmux server and immediately register the exact server socket, session,
+window, pane, process, Codex-session evidence, and outer-client provenance.
+This avoids a manual reconciliation window before handoff preflight can address
+the new pane.
+
 Agent PBX v2 enables the native local tmux path by default when the TUI uses a
 loopback daemon and `tmux` is available. `Latest` embeds a PTY-backed normal
 tmux client attached to the selected PBX-managed runtime. Codex keeps its native
@@ -1483,9 +1837,14 @@ terminal access; the WSS client is the observer/control path.
 
 Plain configured function keys remain global PBX navigation even under terminal
 focus: `F1` Agents, `F2` Events, `F3` view, `F4` input, `F5` Operators,
-`F6/F7` fork navigation, `F8` next alert, `F9` editor, `F10` workspace launch,
+`F6/F7` fork navigation, `F8` next alert, `F9` right-pane fullscreen, `F10` workspace launch,
 and `F11/F12` navigation back/forward. Repeated F8 presses
-focus and acknowledge one displayed Agent/Operator alert at a time.
+focus and acknowledge one displayed Agent/Operator alert at a time. Approval
+centers are single-flight: F8 never stacks duplicate modals. Pressing F8 while
+the approval center is frontmost closes that reviewed center and advances to
+the next unreviewed approval or report alert. An unresolved approval remains
+durable and can be reopened after the alert cycle; a nested confirmation must
+be completed or dismissed before cycling.
 Shift+F1–F12 is translated to unmodified child F1–F12. Thus F2
 always focuses Events while Shift+F2 opens Codex warnings. The input layer also
 recognizes xterm F13–F24 aliases, and the key probe documents terminal-specific