feat: Declarative pane pinning via RunPane CLI

[parsakhaz]

---

type: feature-ticket
id: pane-pinning-cli
status: ready
zone: 2
pr:
github: #357

Feature: Declarative pane pinning via RunPane CLI

Intent

An orchestrator (Pane Chat) can create background/no-focus panes through RunPane, but
cannot set or read the Pane UI's pinned state. In a four-workstream dogfood run
(issue #353), all four panes were created correctly in the background — and the user
still had to find and pin each one manually in the UI. The orchestrator should be able
to declare the desired workspace layout (pinned, unfocused) at creation time and
reconcile it later, without stealing the user's focus.

Peeled from #353 during capture of epic #356 as a standalone quick win with its own PR;
nothing in the epic depends on it.

Desired end state

• runpane panes create ... --pinned --no-focus --json creates a pane that is already
  pinned and not focused; the JSON response carries the effective pinned state.
• An existing pane can be pinned/unpinned through RunPane, idempotently.
• Pane list/status responses expose pinned, so an orchestrator can reconcile desired
  vs actual layout.
• The state persists and matches the Pane UI after app restart.

Before: orchestrator creates 4 panes → user manually pins 4 panes in the UI.
After: orchestrator creates 4 pinned background panes → user's workspace is already
arranged.

Key architecture directions

• D1 — The public CLI contract is a declarative set (pinned: true|false),
  never a toggle: repeating the same request is idempotent. The existing
  sessions:toggle-favorite command may be reused internally, but toggle semantics
  must not leak into the CLI surface (an orchestrator retrying after a transport
  failure must not flip the state back).
• D2 — Pinning never implies focus; --pinned --no-focus is a supported and
  primary combination.
• D3 — Additive and parity-kept: existing commands/JSON untouched, npm CLI /
  daemon schema / generated contracts / Python wrapper updated together
  (scripts/test-runpane-contract.js), machine-readable output stays stdout-clean.
  (Matches epic feat: Event-driven RunPane orchestration #356 D7.)

Proposed approach

• The persistence already exists: sessions.is_favorite + favorite_pinned_at
  (main/src/database/schema.sql:28), and session creation already accepts
  startPinned (main/src/services/sessionManager.ts:322) — create-time --pinned
  is mostly plumbing that flag through the RunPane create path.
• sessions:toggle-favorite is registered in the shared command registry
  (main/src/ipc/session.ts:1461), updates the DB and emits session-updated, and is
  daemon-reachable today; add a set-style command (or extend with a target-state
  parameter) rather than exposing the toggle.
• Surface the new option/command in the RunPane channel list
  (main/src/ipc/runpane.ts:70) and both wrapper dispatch tables
  (packages/runpane/src/cli.ts, packages/runpane-py/src/runpane/cli.py), and add
  pinned to pane list/status serialization.
• Verb shape (panes update --pinned true|false vs panes pin/panes unpin) is
  /do's call — pick whichever fits the existing command design; feat: add event-driven RunPane orchestration and reliable agent startup #353 accepted either.
• Note from the gate: the internal naming is "favorite" (is_favorite,
  favorite_pinned_at) while the CLI says "pinned" — pick the mapping deliberately and
  note it in contract help text; and implement the set-style command as a direct DB
  write, not a read-then-toggle wrapper (racy against concurrent UI toggles).

Verification criteria

• AC1 — WHEN panes create --pinned --no-focus --json completes, the response
  shall include pinned: true and focused: false, and the created session row shall
  have is_favorite set with a non-null favorite_pinned_at.
• AC2 — WHEN the pin mutation sets pinned true on an unpinned pane, the response
  shall report pinned: true and the DB row shall be updated.
• AC3 — WHEN the same pin state is requested twice in a row, the second request
  shall succeed and leave the state unchanged (declarative idempotency, D1).
• AC4 — WHEN panes are listed or queried for status through RunPane, each pane's
  effective pinned state shall be present in the JSON output.
• AC5 — WHEN the Pane app is restarted after a CLI pin, the pane shall remain
  pinned (state read back from the DB matches the last CLI-declared state).

Criterion	Method	Command / flow	✓
AC1, AC2, AC3	automated	main-process integration tests (pattern: main/src/ipc/runpane.test.ts)	[ ]
AC4	automated	list/status serialization test	[ ]
AC5	automated	persistence assert against sessions row across manager re-init	[ ]
all	automated	scripts/test-runpane-contract.js npm/Python parity run	[ ]

Out of scope

• Panel-level pinning (ToolPanelState.isPinned — editor-panel state only today).
• Any Pane UI changes — the UI already renders favorite/pinned state.
• Pin-related lifecycle events (epic feat: Event-driven RunPane orchestration #356 phase 2 owns event emission).
• Changing archive/unpin interactions or pin ordering semantics.

Justification

• Fast pass, zero questions (Socratic gate, 2026-07-21). What convinced it: a concrete
  recurring incident (four hand-pinned panes), every technical claim file:line-verified,
  the one real design risk (toggle vs declarative) pre-argued in D1 with the
  retry-flip rationale, and scope boundaries explicitly drawn. Socrates independently
  verified in-repo that --no-focus/focused already exist end-to-end and that the
  toggle handler has no focus side effect (so D2 holds on the mutation path).

References (in refs/)

• refs/discussion.md — decision log from the 2026-07-21 discussion (split decision,
  research findings with file:line evidence).

[parsakhaz]

Event-driven RunPane orchestration (issue #353) — decision log

Date: 2026-07-21
Participants: parsakhaz, Claude (code research via Codex code-researcher)

Context

Issue #353 specifies an event-driven, resumable orchestration surface for RunPane so a
long-lived Pane Chat orchestrator can sleep until meaningful agent transitions instead of
polling panels screen / panels wait. Follow-up to #277 / PR #278.

Key research findings (all file:line-verified)

• Push transport already exists. The daemon socket protocol defines event frames
  (shared/types/daemon.ts:27) and the server broadcasts session/panel/terminal events to
  all connected socket clients (main/src/daemon/server.ts:66, fanout at
  main/src/daemon/bootstrap.ts:245). Node/Python CLI clients discard event frames and
  close after one response (packages/runpane/src/daemonClient.ts:134,
  packages/runpane-py/src/runpane/daemon_client.py:62). panels watch is a client +
  semantics problem, not a new transport.
• activityStatus is a byte-silence heuristic: first PTY output → active, 30s silence
  → idle (main/src/services/terminalPanelManager.ts:1111). Not agent semantics.
• No canonical attention state exists to reuse. Activity lives in main, session status
  in sessionManager, unread + notification debounce (60s + focus gating) renderer-only
  (frontend/src/hooks/useNotifications.ts:20,166). Issue scope item 6 ("reuse the
  attention state powering human notifications") is not implementable as written — the
  semantic state must be created in main process as new canonical truth; renderer
  notifications can consume it later.
• No event cursors exist; only session_outputs.id is monotonic
  (main/src/database/schema.sql:33). Daemon event frames carry no sequence numbers.
• ready + active coexistence confirmed: isCliReady latches permanently after
  first CLI response (terminalPanelManager.ts:981), independent of activity.
• Pinning is nearly free: sessions.is_favorite + favorite_pinned_at exist in DB,
  startPinned exists on session creation (sessionManager.ts:322), and
  sessions:toggle-favorite is already in the shared daemon command registry
  (main/src/ipc/session.ts:1461) — the CLI just doesn't expose it.
• Slash-command hardening builds on existing submit-composer (verifiedSubmitted,
  blocker/nextCommand at shared/types/runpaneOrchestration.ts:389,
  main/src/ipc/runpane.ts:1128).
• Output-cursor gotcha: raw terminal scrollback is not 1:1 with session_outputs rows;
  panels output --since must pick which stream it reads.

Decisions

1. Split the issue (decided): peel two small, independent, dogfood-unblocking tickets
   out of feat: add event-driven RunPane orchestration and reliable agent startup #353 —

   • (a) declarative pane pinning (--pinned on create, pin/unpin mutation, pinned in
     list/status output);
   • (b) slash-command-aware initial prompt submission (semantic submit + verify +
     bounded retry for /do TM-x-style prompts).
     The remainder becomes an epic: phase 1 = semantic state model on byte-silence signal,
     phase 2 = event persistence + cursors + watch/await CLI, phase 3 = verified startup /
     interstitial handling + multi-target/pane watch. Milestone emission (events emit) and
     MCP-warning severity ride in later phases as specced.

2. agent_idle detection = byte-silence debounce only for phase 1 (decided; user
   rationale: it generalizes — works for any agent without per-agent adapters, keeping
   the base event contract agent-agnostic instead of privileging Claude/Codex).

   • Accepted limitation, to be stated in the epic contract: a TUI that repaints while
     semantically idle reads as active, and an agent thinking silently past the debounce
     emits a false agent_idle. The acceptance criterion "spinner frames never satisfy
     the wait" holds only to the extent the debounce absorbs them.
   • Upgrade path: optional per-agent screen-aware adapters (same bounded screen-scan
     machinery as blocker detection, main/src/ipc/runpane.ts:968) may later refine the
     signal but must never become load-bearing for base events.
   • Debounce should be longer/configurable than the current 30s.

3. Command shape (recommended, unobjected): panels watch (JSONL subscription over
   the existing event channel) as core primitive; panels await / await-any as
   exit-on-first-match sugar. panels wait frozen as legacy polling surface. No
   orchestrate command group; reconciliation is panes status --changed-since.

4. Cursor scope & retention (recommended, unobjected): one global daemon-scoped
   monotonic sequence, persisted in a new SQLite events table (survives app restart =
   daemon restart), bounded retention by count + age. Lifecycle-event and output cursors
   are separate namespaces (output already has session_outputs.id).

5. Attention source of truth (recommended, unobjected): promote semantic transitions
   into the main process as the new canonical layer (phase 1); renderer notification
   logic can migrate onto it later rather than the CLI borrowing renderer state.

Open questions

• Which stream panels output --since reads (session_outputs vs scrollback) — resolve in
  epic phase 2 planning.
• Exact debounce default/configurability for byte-silence idle.
• Whether feat: add event-driven RunPane orchestration and reliable agent startup #353 is edited down to the epic scope or superseded by new items linking back.

[parsakhaz]

<!doctype html>

<title>Declarative pane pinning via RunPane CLI — Explainer</title> <style> :root { --paper: #FAF8F5; --ink: #1F2328; --ink-soft: #5A5F66; --line: #E4DFD7; --panel: #FFFFFF; --accent: #0E7569; --accent-soft: #E3F0EE; --warn: #B45309; --warn-soft: #F7EBDD; --out: #9F3A38; --out-soft: #F6E8E7; --mono: ui-monospace, "SF Mono", SFMono-Regular, Menlo, Consolas, monospace; --serif: Georgia, "Iowan Old Style", "Times New Roman", serif; --sans: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif; } @media (prefers-color-scheme: dark) { :root { --paper: #15191D; --ink: #E8E6E1; --ink-soft: #9BA1A8; --line: #2C3237; --panel: #1C2126; --accent: #2FA79A; --accent-soft: #16302D; --warn: #D98E3D; --warn-soft: #32271A; --out: #CF6F6C; --out-soft: #33211F; } } * { margin: 0; padding: 0; box-sizing: border-box; } body { background: var(--paper); color: var(--ink); font-family: var(--sans); line-height: 1.6; font-size: 16px; } .page { max-width: 720px; margin: 0 auto; padding: 3rem 1.25rem 5rem; } header.masthead { border-bottom: 1px solid var(--line); padding-bottom: 1.75rem; margin-bottom: 2.5rem; } .meta-row { display: flex; flex-wrap: wrap; gap: .5rem .75rem; align-items: center; margin-bottom: 1rem; } .badge { font-family: var(--mono); font-size: .72rem; letter-spacing: .06em; padding: .2rem .55rem; border-radius: 3px; text-transform: uppercase; } .badge.type { background: var(--accent-soft); color: var(--accent); } .badge.status { border: 1px solid var(--line); color: var(--ink-soft); } .badge.zone { border: 1px solid var(--warn); color: var(--warn); background: var(--warn-soft); } h1 { font-family: var(--serif); font-weight: 500; font-size: 2.1rem; line-height: 1.2; letter-spacing: -.01em; text-wrap: balance; margin-bottom: .75rem; } .standfirst { color: var(--ink-soft); font-size: 1.05rem; max-width: 60ch; } .links { margin-top: 1rem; font-size: .85rem; display: flex; gap: 1.25rem; flex-wrap: wrap; } .links a { color: var(--accent); text-decoration: none; border-bottom: 1px solid var(--accent-soft); } section { margin-bottom: 2.75rem; } .eyebrow { font-family: var(--mono); font-size: .72rem; letter-spacing: .1em; text-transform: uppercase; color: var(--accent); margin-bottom: .6rem; } h2 { font-size: 1.25rem; margin-bottom: .75rem; letter-spacing: -.01em; } p { margin-bottom: .9rem; max-width: 65ch; } code { font-family: var(--mono); font-size: .85em; background: var(--panel); border: 1px solid var(--line); padding: .08em .35em; border-radius: 3px; } .before-after { display: grid; grid-template-columns: 1fr 1fr; gap: 1rem; margin: 1.25rem 0; } @media (max-width: 560px) { .before-after { grid-template-columns: 1fr; } } .panel { background: var(--panel); border: 1px solid var(--line); border-radius: 6px; padding: 1.1rem 1.2rem; } .panel h3 { margin-bottom: .6rem; font-size: .78rem; font-family: var(--mono); letter-spacing: .08em; text-transform: uppercase; color: var(--ink-soft); } .panel.after { border-color: var(--accent); } .panel.after h3 { color: var(--accent); } .panel ul { padding-left: 1.1rem; font-size: .92rem; } .panel li { margin-bottom: .4rem; } .diagram { margin: 1.5rem 0 2.5rem; } .diagram svg { display: block; max-width: 100%; height: auto; } .diagram figcaption { margin-top: .5rem; font-size: .8rem; color: var(--ink-soft); } .pipeline { display: flex; align-items: stretch; margin: 1.5rem 0; overflow-x: auto; padding-bottom: .5rem; } .stage { background: var(--panel); border: 1px solid var(--line); border-radius: 6px; padding: .75rem .9rem; min-width: 130px; flex: 1; } .stage .name { font-family: var(--mono); font-size: .78rem; font-weight: 600; margin-bottom: .25rem; } .stage .desc { font-size: .78rem; color: var(--ink-soft); line-height: 1.45; } .arrow { align-self: center; padding: 0 .5rem; color: var(--ink-soft); flex: none; } .strip-note { margin: -.5rem 0 0; font-size: .8rem; color: var(--ink-soft); } .decision { border-left: 3px solid var(--accent); padding: .2rem 0 .2rem 1.1rem; margin-bottom: 1.25rem; } .decision .tag { font-family: var(--mono); font-size: .78rem; font-weight: 700; color: var(--accent); } .decision p { margin: .3rem 0 0; font-size: .95rem; } .decision .rejected { color: var(--ink-soft); font-size: .85rem; } .decision .rejected::before { content: "rejected — "; font-style: italic; } .scope { display: grid; grid-template-columns: 1fr 1fr; gap: 1rem; } @media (max-width: 560px) { .scope { grid-template-columns: 1fr; } } .scope .panel.in { border-top: 3px solid var(--accent); } .scope .panel.outof { border-top: 3px solid var(--out); } .scope .panel.outof h3 { color: var(--out); } .vgroup { margin-bottom: 1.6rem; } .vgroup-head { font-family: var(--mono); font-size: .72rem; letter-spacing: .06em; text-transform: uppercase; color: var(--accent); margin-bottom: .7rem; } .vlist { list-style: none; } .vlist li { position: relative; padding-left: 1.9rem; margin-bottom: .55rem; font-size: .92rem; line-height: 1.45; max-width: 66ch; } .vlist li::before { content: ""; position: absolute; left: 0; top: .18em; width: 15px; height: 15px; border: 1.5px solid var(--ink-soft); border-radius: 4px; } .dials { border: 1px solid var(--line); border-radius: 8px; background: var(--panel); padding: 1.15rem 1.3rem; } .dial { display: grid; grid-template-columns: 118px 1fr; gap: 1rem; align-items: start; padding: .8rem 0; border-bottom: 1px solid var(--line); } .dial:last-child { border-bottom: none; } .dial-label { font-family: var(--mono); font-size: .72rem; letter-spacing: .05em; text-transform: uppercase; color: var(--ink-soft); padding-top: .3rem; } .dial-opts { display: flex; gap: .45rem; flex-wrap: wrap; align-items: center; } .pill { font-size: .82rem; padding: .32rem .72rem; border-radius: 999px; border: 1px solid var(--line); color: var(--ink-soft); } .pill.on { border-color: var(--accent); background: var(--accent-soft); color: var(--accent); font-weight: 600; } .dial-why { flex-basis: 100%; font-size: .8rem; color: var(--ink-soft); margin: .4rem 0 0; } .dials-note { font-size: .8rem; color: var(--ink-soft); margin: .9rem 0 0; } footer { border-top: 1px solid var(--line); margin-top: 3rem; padding-top: 1.25rem; font-size: .8rem; color: var(--ink-soft); } </style>

feature ready zone 2 — contained

Declarative pane pinning via RunPane CLI

Let an orchestrator declare "pinned, not focused" at pane creation — instead of making the user hand-pin every background pane it spawns.

epic #356 (sibling) · origin: #353

runpane CLI create --pinned --no-focus daemon registry set-style pin command sessions.is_favorite already in the schema All three layers exist; the change is plumbing an idempotent set through them and echoing pinned back in list/status output.

01 · Why

Background panes arrive unpinned

In the four-workstream dogfood run behind #353, RunPane created all four panes correctly in the background — and the user still had to find and pin each one manually. The persistence (sessions.is_favorite), a creation flag (startPinned), and a daemon-reachable command (sessions:toggle-favorite) all already exist; RunPane just doesn't expose them. No UI is touched — the UI already renders pinned state.

Before

• Orchestrator spawns 4 background panes
• User hand-pins 4 panes in the UI
• No pinned in list/status — layout not reconcilable

After

• panes create --pinned --no-focus — arranged on arrival
• Pin/unpin existing panes idempotently via CLI
• pinned in list/status; survives restart, matches UI

02 · Direction

Locked directions and shape of the work

D1 — declarative set, never a toggle

The CLI contract is pinned: true|false; repeating a request is idempotent. sessions:toggle-favorite may be reused internally, but toggle semantics must not leak — an orchestrator retrying after a transport failure must not flip the state back.

exposing the existing toggle directly — retries would invert state.

D2 — pinning never implies focus

--pinned --no-focus is the primary agent-orchestration combination.

D3 — additive, npm/Python parity kept

Existing commands and JSON untouched; both wrappers and the generated contract updated together; stdout stays machine-clean. (Matches epic #356 D7.)

set command

set-style pin in the daemon registry

→

create flag

--pinned plumbed to startPinned

→

surface + echo

both wrappers, pinned in list/status

→

proven

integration + parity tests green

Indicative sequence — /do's plan stage owns the real plan. Verb shape (panes update --pinned vs pin/unpin) is /do's call; #353 accepted either.

03 · Scope

In / out

In scope

• --pinned on pane creation
• Idempotent pin/unpin mutation for existing panes
• pinned in pane list/status JSON
• npm + Python wrapper + contract updates

Out of scope

• Panel-level pinning (ToolPanelState.isPinned)
• Pane UI changes
• Pin lifecycle events (epic feat: Event-driven RunPane orchestration #356 phase 2)
• Archive/ordering semantics changes

04 · Verification

What we'll check

Backend / CLI (all automated)

• AC1 — create --pinned --no-focus --json responds pinned: true, focused: false; DB row has is_favorite + favorite_pinned_at
• AC2 — pin mutation on an unpinned pane updates response and DB
• AC3 — same state requested twice: second call succeeds, state unchanged
• AC4 — list/status output carries each pane's pinned
• AC5 — state survives restart (read-back matches last declared state)
• npm/Python contract parity run stays green

05 · Run config

How /do will run this

Zone

0123

Contained CLI/daemon addition exposing existing persistence — no schema change, no zones.md escalator; blast radius limited and cheap to reverse.

Derived

single lane — Codexcaps 1/1direct researchfrontend verifier: n/a

Estimated by /create-plan; dials derive from references/zones.md. You set the final zone at capture.

zone 2 — contained · Generated by /create-plan · This page is the alignment surface; item.md remains the contract /do executes against.

[parsakhaz]

Postmortem — 357 (ops-only)

---

type: postmortem
item: 357
pr: #359
mode: ops-only

Postmortem — 357 pane pinning via RunPane CLI (ops-only)

Run operations

Wall clock: 1:22:26 (05:53:30Z → 07:15:56Z, single session, no compaction).
Agent-active vs human-idle: ~69% active / 31% idle — one idle block of
25:36 (06:46:48 → 07:12:23), ended by a human "continue". No
post-completion idle to carve out; the run was mid-Step-5 when it stalled.

Per-phase pacing (from transcript + dispatch marker mtimes):

Phase	Span	Notes
Step 0 preflight + load	05:53–05:58 (~5m)	issue fetch, artifact harvest, branch ff, install refresh
Step 1 research + plan	05:58–06:10 (~12m)	direct research (zone 2, no dossier); plan-reviewer dispatch 1:43
Plan fixes	06:10–06:15 (~5m)	3 MF + 2 SF folded in
Step 2 implement	06:15–06:24 (~9m dispatch)	Codex implementer, 202k tokens
Step 3 verify + fix + re-verify	06:24–06:44 (~20m)	verifier fail (dry-run rubric) → resume fix (6:42) → scoped re-verify pass
Step 4 commit + PR	06:44–06:47 (~3m)	PR #359 opened, closing line verified
Step 5 review ∥ diagram	06:34–06:47 (overlapped)	code-reviewer ran parallel to diagram authoring — good overlap
Stall	06:47–07:12 (25:36)	turn ended after the QA-drive command returned; no ScheduleWakeup
Step 5 QA publish + Step 6	07:12–07:16+	body update, QA comment, wrap-up, label, notify

Ranked stalls:

1. 25:36 human-idle at the QA-drive boundary. The QA command-shaped run
   (vitest + contract checks) returned green and the turn ended without
   publishing the results or scheduling a wakeup — exactly the "idle-waiting
   on a human nudge is a pipeline bug" case the /do charter names. The
   fix that removes it: treat the QA drive's own command results like a
   verifier report — the same turn must publish (body edit + evidence
   comment) before ending, and any turn that ends mid-run must carry a
   ScheduleWakeup.
2. ~2:00 wasted on a hung compound Bash: a stray sed with no input file
   read stdin until the 2-minute tool timeout. Self-inflicted; the dispatch
   itself was unaffected.
3. ~1:30 wasted on a code-reviewer launch whose role-instructions path
   (.claude/agents/code-reviewer.md) doesn't exist in this repo — the
   existence check and the launch ran in the same shell command, so the
   check couldn't prevent the launch. Killed and relaunched against
   ~/.claude/agents/code-reviewer.md.

Blocker inventory: no AskUserQuestion gates, no rate limits, no red-tier
gates. Legitimate background waits: 6 Codex dispatches totaling ~24 min,
all polled in-turn.

Dispatch health: 6/6 dispatches completed exit 0; one classified failure
loop (verify → fix → re-verify) worked as designed and caught a real
contract gap (mutating commands shipped without functional --dry-run) —
that loop's ~20 min bought a genuine fix, not churn.

Dial record (from wrapup.md)

zone: 2, lanes: single-codex, passes: {plan: 1/1, post_pr: 1/1}
findings: {plan_pass1_codex: 5 (3 MF), post_pr_pass1_codex: 0}
verifiers: {frontend: skipped, qa_pass: trimmed}, qa_findings: 0
wall_clock: "1:22", pr_size: {files: 18, +1466, -24}
tokens: {codex: 643916, overseer: 338751, claude_subagents: 0, total: 982667}
spend_ratio: 659.5

Judgment: right-sized. The plan pass was high-yield (3 Must Fix, one of
which — the atomic-write race — materially changed the design). The post-PR
pass found nothing, but at 85k tokens it was cheap assurance on a 1.5k-line
diff; no dial change is supported by one data point. The verify-stage rubric
(cli-script) earned its keep — it caught the only real defect. Zone 2's
trimmed QA (no app driving) was correct: no UI ACs existed, and the live-app
checks are honestly parked on the human's checklist.

Outcome

Deferred — ops-only run at wrap-up. On the automated evidence the run is
on-target (all 5 ACs proven, review Approve with zero findings); the outcome
half runs after the human's PR review and live-app manual pass.

What to change so it doesn't recur

1. claude/skills/do/SKILL.md (dcouple/orchestra) — Step 5's publishing
   rule says "The turn in which a reviewer or verifier report arrives
   publishes its results (body edit, evidence comment) before ending."
   The 25-minute stall slipped through because the QA drive's results came
   from the Overseer's own command run, not a sub-agent report. Proposed
   edit — extend the sentence: "The turn in which a reviewer or verifier
   report arrives — or in which the QA drive's own checks complete —
   publishes its results (body edit, evidence comment) before ending."
2. claude/skills/codex/SKILL.md (dcouple/orchestra) — Step 1 says to
   confirm the instruction/format files exist before dispatching. The wasted
   launch happened because the check and the launch shared one shell command,
   so a failed check couldn't stop the launch. Proposed edit — add to the
   path-resolution note: "Run the existence check as its own command and read
   its result before writing the launcher; a check-and-launch combined in
   one shell invocation cannot prevent a bad dispatch."
3. Consumer-repo sync (dcouple/Pane) — .claude/agents/ in this repo
   carries only 6 of the orchestra agent charters; code-reviewer.md (and
   others, e.g. discussant.md, frontend-verifier.md) are missing, forcing
   home-directory fallback paths. Not an orchestra edit — re-run the
   orchestra→Pane sync so repo-relative charter paths resolve.

System changes recorded here for /postmortem-loop; nothing applied.
Published as comments on issue #357 and PR #359 (URLs added post-publish).