# Agent coordination — the north star

**What this is:** the objective that the Workspace/Panel work serves — several agents working
concurrently on one body of work, **coordinating with each other rather than through the human**, with
a human authoring the workflow at the top. Written live during the conversation of 2026-08-07, from the
owner's own words; where a section records a decision, that decision is his, not a proposal.

**Read this before ranking, deferring or starting any workspace/panel item.** It is the thing every
other workspace/panel document is ranked *against*:

- `docs/workspace-panels.md` — how the framework works today (descriptive, no opinions)
- `docs/workspace-panel-todo.md` — the work queue, currently ordered by defect severity
- `COMMS/workspace-panel-framework-analysis-2026-08-07.md` — the reasoning behind that queue

Once this document is complete, the todo is to be **re-ranked against the objective** rather than
against severity, and both of the above updated to reflect it. That re-rank is deferred by the owner
until this conversation is finished — it is not to be started early.

---

## 1. The objective

### 1.1 The surface that matters — two routes

Everything that follows is about **`/chat`** and **`/dashboards`**. Verified against
`src/apps/officer-web/App.tsx`:

| route | element | line |
|---|---|---|
| `/chat`, `/chat/new`, `/chat/new/g/*`, `/chat/g/*`, `/chat/:sessionId` | `Dashboard.SessionListPage` | 42–46 |
| `/dashboards` | `Dashboard.DashboardsScreen` | 82 |
| `/dashboards/:id` | `Dashboard.DashboardScreen` | 83 |

One structural fact worth stating early, because it shapes everything: **`/dashboards/:id` is the only
place in the app where a workspace is not `locked`.** Every other screen ships a layout as the product
and forbids the user from splitting, closing, or re-apping panels. Dashboards is where the user composes
their own. So of the two routes named, one is the agent and the other is the only user-authored surface
in the entire platform.

### 1.2 The agent is the centre of gravity

Stated by the owner up front: **the most important things always come back to the Claude chats.** The
dashboards story is being explained first only because it is the easier of the two to describe — not
because it is the more important. Whatever is built for dashboards should be understood as eventually
serving the agent.

There are two agent backends, and they are not equal right now:

- **Claude** — what is actually used. Runs as the `officer-agent` PM2 peer behind
  `officer-anthropic-proxy`.
- **OpenCode** — the `officer-opencode` sidecar. **Development stopped a while ago and is not resuming
  now**; the owner may pick it back up later.

The rule that follows: OpenCode is **dormant, not dead**. Do not spend effort on it, do not build for
it, and do not treat it as a requirement — but equally, do not design something that makes Claude the
only agent that could ever exist. Where the cost of keeping the seam is near zero, keep it. Where
keeping it would distort the design, favour Claude and note the assumption here.

### 1.3 The dashboards scenario — the live example

The owner's chosen illustration is **what he is doing at this moment**: running *two Claude agents in
parallel, in two different chat windows, both working on the platform.*

**Stated as fact by the owner** (not inferred):

- Two agents, two chat windows, same platform, at the same time.
- This is precisely why the standing "never restart the server yourself" rule exists: a
  `pm2 restart officer` is a **shared, destructive-ish event** across every agent working on the
  platform, so it must be *timed* by the owner rather than triggered by whichever agent happens to
  finish first.

**Observed by me during this same session**, as corroborating detail — the frictions this arrangement
actually produces:

1. **The owner is the scheduler.** Each agent independently reaches a point where it needs a restart and
   asks. Nothing in the system knows another agent exists, so the owner is the only thing that can
   serialise it. (He also had to tell me, separately, to stop *repeating* the request once made.)
2. **The owner is the message bus.** Neither agent can see the other's work, so anything one needs to
   know about the other has to be relayed by hand.
3. **Shared tree, shared `master`.** Two agents, one working copy. This produced the session's sharpest
   instruction — *"The problem is committing each other's work. Like, that can't happen, man."* — and
   the mitigation is purely behavioural: each agent must be told, separately, to stage explicit paths
   and never `git add -A`. Nothing enforces it.
4. **Uncertain ownership of a failure.** I hit a real typecheck error (`CodeBlock.tsx:138`) and could not
   tell whether it was mine, and had to ask. The answer was that it belonged to the other agent.

**Unconfirmed inference — to be confirmed or corrected by the owner before it is treated as the
objective:** that the dashboards half of the holy grail is a surface where these parallel agent sessions
are *visible together and manageable together* — one screen, multiple live agents as panels, with the
state they contend over (restarts, the git tree, who is touching what) legible — so the human stops
being both the scheduler and the message bus between them.

### 1.4 The proof of concept — the owner's words, made precise

> A new dashboard with two vertical panels. Each panel is a chat session that I can navigate to whatever
> path I want, to continue or start a new session from a specific path. Each chat panel gets attributed
> some kind of persistent ID related to that dashboard.

And the behaviour that PoC is *for*:

> I can let you both work, and at the end of your turn you ask the other agent "can I restart?", wait for
> his output, restart yourself. And the same from the other side — the other agent, when he finishes his
> turn, is able to communicate with yourself to ask "can I restart?", restart, and let you know that I
> did my restart and I'm going to keep going with something else.

> If we get this to work, the sky is the limit.

Decomposed into the five capabilities it actually requires:

| # | capability | exists today? |
|---|---|---|
| P1 | Two chat panels in one dashboard, each an **independent** session | **No** |
| P2 | Each panel pointed at **its own path** (cwd) | **No** |
| P3 | A **persistent id** per chat panel, scoped to the dashboard, that survives reload | Partly |
| P4 | Agent-to-agent **messaging** between two live sessions | **No** |
| P5 | An agent **surviving the restart** it triggers | **Yes** |

### 1.5 Verified state of the code against those five

Read from source on 2026-08-07, not assumed:

**P1 — the blocker.** `ChatPanelWrapper` (`apps/Chat/ChatPanelWrapper.tsx:45`) is declared
`() => {…}` — **it takes no props at all, not even `panelId`.** Everything it uses comes from
`useWorkspace()`: `dashboardId`, `cwd`, `root`, `promptPrefix` — all of which are *per screen*. Two
chat panels dropped into one dashboard today are therefore **byte-for-byte identical**: same cwd, same
context, same session-resolution path. There is no per-panel anything. It also calls
`useChat(undefined, undefined, …)`, so no session id is passed in — a panel cannot be told which session
to continue.

**P2 — does not exist.** `cwd` is a prop on `<WorkspaceView>`, set once per screen, delivered ambiently
through `WorkspaceContext`. `scoped = cwd !== '~'`. Every panel on a screen necessarily shares one cwd.

**P3 — the good news, with one sharp edge.** Panel ids (`layout-utils.ts:4`,
`` uid = () => `p-${Date.now()}-${++counter}` ``) are generated once and **persisted inside the layout
`jsonb`**, so a panel id *is* already stable across reloads. That makes panel id a viable durable key —
which is the single most load-bearing fact for this PoC. The edge: `movePanel` mints a **new** id
(`layout-utils.ts:192`, `:207`) rather than carrying the old one, so dragging a panel would silently
sever its session binding. That is gap **G2** in the analysis, and it is now on the critical path.

Also already half-built, and worth knowing: for a *user* dashboard the wrapper already derives
`{ context: 'dashboard', contextId: dashboardId }` (`ChatPanelWrapper.tsx:49-55`) — a notion of
dashboard-scoped chat context exists. It is keyed to the **dashboard**, not the panel, which is exactly
one level too coarse for this.

**P4 — does not exist**, in any form. The nearest primitive, `usePanelChannel`, is browser-local and
dies on reload; it cannot carry a message between two agent processes. This is new machinery, and
almost certainly belongs on the sidecar side rather than in the frontend.

**P5 — already true, and it is the reason the rest is worth building.** Per `CLAUDE.md`, verified
2026-07-30: `pm2 restart officer` no longer kills an agent session. The agent is its own PM2 peer
(`officer-agent`), and output produced while `officer` is down survives because the sidecar writes to
`chat_session_events` itself. A restart costs a socket reconnect, not the session. **The single hardest
prerequisite of the owner's scenario is therefore already met.**

### 1.6 Owner's corrections — walked back through §1.5, from the end

**On P5 (restart survival) — my summary was right but incomplete, and the gap is the whole reason the
PoC has the shape it has.**

A lot of work landed today and over the last few days: **a session now survives a server restart with no
refresh and no user action.** One case remains broken, and the owner has **decided not to solve it**:

> *unless the agent is currently outputting — the restart of the server interrupts that output.*

This reframes the PoC entirely. **The by-turn handshake is not merely coordination; it is a deliberate
route around the one failure mode that is not going to be fixed.** Restarts are made safe by
guaranteeing they only ever happen when no agent is mid-output — negotiated, rather than engineered
away. Design consequences:

- The protocol is **turn-boundary only, by construction.** "I have finished my output, you may restart"
  is the entire safety property. A design that lets a restart fire at an arbitrary moment defeats the
  purpose even if it is otherwise more elegant.
- Therefore **an agent must be able to declare turn-end** and another must be able to observe it. That,
  not the messaging, is the load-bearing signal.
- The full owner-described cycle: A finishes → A tells B "I'm done, you may restart" → B restarts → B
  tells A "restarted, continuing" → A resumes. Both directions, symmetric.
- **Do not** spend effort making mid-output restarts survivable. Explicitly out of scope, by decision.

**The second thing it buys, for free — and the owner has been missing it for a long time:**

> a lot of the time when an agent finishes a tool call or whatever, and if I'm not at the computer to
> communicate with them, they don't continue, because they are expecting an input from the human — but
> that input or that trigger can come from the other agent.

So the same primitive is also a **liveness mechanism**: an agent stalled at a turn boundary waiting on a
human can be unblocked by its peer. Today the owner's physical presence is a hard dependency for
progress; this removes it. Recorded properly in §3, because it is not the objective — but it is a strong
signal the direction is right, since it falls out of the PoC at no extra cost.

### 1.7 The actual objective — the software factory

**The restart problem is not the goal, and is barely even a problem.** It exists only because the owner
is currently using the platform to fix the live platform, for velocity. It is a *dogfooding artifact*.
It has been chosen as the proof of concept because it is small, real, and falsifiable — not because it
is the target.

The target:

> I can turn my platform into a **software factory** with agents working together with each other. One
> for the backend, one for the front end, one for the mobile apps. Doing code reviews, making sure all
> the conventions and all the rules are being correctly applied, before merging — code reviews, running
> tests. There's no limit to this vision.

So the north star is: **several specialised agents, working concurrently on one codebase, coordinating
with each other rather than through the human, with quality gates between them and the mainline.**

The dashboards surface is how a human *watches and steers* that factory. The chat panels are the
workers. The restart handshake is the first, smallest instance of the general primitive: agents
negotiating a shared resource without a human in the middle.

### 1.8 Partnership, and the standing instruction to push back

Stated by the owner, and binding from here on:

> I also want you to call me out and say "dude, you're being crazy, this isn't possible, we need to find
> something simpler". Please don't feed my ego and call me out whenever you feel necessary. I am from
> this moment on considering you a partner.

This is a **standing instruction, not a courtesy**. It outranks agreeableness. Where a plan is
over-reaching, where a proof of concept is being over-read, or where an easier path exists, say so
plainly and early — the cost of a late correction here is much higher than the cost of an unwelcome one.

### 1.9 There is always a human orchestrator — and the flow already works manually

**Answering the "you may over-read the PoC" challenge.** The owner's response materially changes the
risk profile, and it is recorded here because it is the strongest single argument in the whole
conversation.

**Constraint, binding:** *there will always be a human orchestrator* — the owner, or whoever later runs
the platform. **The goal is explicitly not agents ping-ponging inputs and outputs with no structure.**
Any design that removes the human from the top of the loop is wrong, not ambitious.

**And the workflow is not hypothetical — it is executed manually today**, with three screens and two
computers. The owner's worked example, verbatim in substance:

1. Hand the git repo to the **platform agent**, plus "there is a Soulseek server on localhost:X, here is
   its API and web-UI documentation." Ask for a sidecar, a route to enter the connection string and API
   key, and as much of the web UI as can be built — **"don't expect me to be here to answer questions,
   just present me a version 0.1 of the whole thing."** The sidecar process itself is by now
   well-documented, and the documentation keeps being updated with new learnings.
2. The owner **shifts focus entirely** to other work — mobile monorepo, platform architecture — for one
   to two hours, without having to hold Soulseek in his head.
3. The platform agent reports: *"Soulseek is up, give it a try, here is how to test it."*
4. The owner restarts, enters credentials, confirms it works, and the agent pushes.
5. The owner pulls on the MacBook and tells the **mobile agent** — which already knows the mobile
   infrastructure — "create me a Soulseek app based on everything the platform has today." It works.

**So the pattern is proven by human execution.** What is being automated is not "can agents collaborate"
— it is the *bridging role*, which the owner currently performs and describes as: *stressful, a lot to
keep in my head*, though enjoyable and exciting.

### 1.10 The midnight scenario — the shape of the target

> It's midnight, I create a dashboard with **four chat panels that are aware of each other**: you are the
> front end, you are the platform backend, you are the mobile app, and you are the **code reviewer** —
> able to coordinate, check one against the other, and say to the front end "change this", to the backend
> "this is not according to spec", to mobile "maybe change this" — and in the end be **responsible for
> the joining of everything, which is currently the work that I'm doing.**

The owner's own framing: *a holy grail by its nature doesn't exist — but I really think we can get
there.*

Structural requirements this adds, beyond the two-panel PoC:

- **N panels, not two.** The handshake generalises to a roster.
- **Panels have roles/identities** ("you are the front end"), not just sessions.
- **Panels are aware of each other** — an agent must be able to enumerate its peers.
- **Panels span repositories** — platform and `monorepo-mobile` are different repos with different
  remotes.
- **The fourth role is different in kind from the first three.** Roles 1–3 are *do the work*, and are
  already proven by the manual flow. Role 4 is *hold the whole picture and judge* — the role the owner
  performs today with human judgement. See §5 for why this is flagged as the research risk rather than
  an engineering task.

### 1.11 Do not design for the examples — the owner's counterpoints

Recorded because every one of these is a correction of *my* over-constraining, and the same mistake will
be easy to repeat later.

- **The Soulseek flow is one example, not the specification.** Other workflows will exist; some need only
  two agents. *"This coordination is the point I want to ultimately reach."*
- **Roles are malleable.** Not every run involves four agents, and not with those roles. Fixing
  "front end / backend / mobile / reviewer" into the design would be inventing a constraint the owner
  does not have.
- **There is no paradigm.** *"It's whatever we want it to be."*
- **The owner's current needs are not the end state.** He has a day job unrelated to mobile that would
  benefit from the same coordination. Designing narrowly around platform+mobile development is a trap.
- **Cross-machine is NOT the hard problem, and I was wrong to raise it as a fork.** The owner has already
  solved it at small scale: a second Claude on the MacBook with a 15-minute timer pulling the latest
  platform changes and replicating them for the mobile apps. Git hooks or cron do the same.
  *"That's the least painful point of all this."*

**The painful point, in the owner's words:** *panel communication inside a single web page, or a single
workspace, on our platform Web UI.* That is the problem to solve. Everything else is downstream.

This yields a natural two-tier split, which the design should respect rather than unify:

| tier | mechanism | status |
|---|---|---|
| Agents in **one workspace** | direct, in-page, turn-boundary messaging | **the hard part — this is the work** |
| Agents across **machines** | the git repo itself, polled on a timer / hook / cron | already solved, cheap, not our problem |

### 1.12 The minimal protocol — and why the PoC is not a toy

The owner's own reduction of what agents need to say to each other:

> I finished this, you can check the latest changes and start building your part, and tell me when you're
> done so I can continue with my part.

Compare it to the restart handshake:

> I finished my output, you can restart the server, and tell me when you're done so I can continue.

**These are the same protocol with a different payload.** Both are: *declare turn-end → hand off →
await the peer's completion → resume.* The restart PoC is therefore not a toy standing in for the real
thing; it is the real protocol, exercised on the smallest possible payload.

The design consequence: **build the primitive general and keep the roles as configuration.** A named,
addressable agent that can send and receive at turn boundaries is the whole mechanism. "You are the
reviewer" is then a prompt, not a feature. That is how "there is no paradigm" becomes buildable instead
of unbuildable.

### 1.13 The crux — the human authors the workflow; agents only execute and hand off

**This is the single most important constraint in the document.** It is what separates this from the
multi-agent designs that fail, and it should be defended against "improvement" later.

The owner explicitly **rejects emergent self-organisation**:

> I don't expect to come and start a new dashboard, open four chat panels and do a small prompt that says
> "implement Soulseek" and each one knows what to do and what to communicate. **No.**

What he expects instead:

> I'm going to tell one: you're the front end developer. You're the back end developer — you're going to
> start by reading the docs from Soulseek, you're going to write a specification and create the API. When
> you're done, pass that work to the front end developer. And **the front end developer is the front end
> developer because I tell him that he is**, and he is expecting work from Agent 2. And so on.

> Every dashboard will hopefully be something **not long lived**, but it will always require an **initial
> human setup**: setting the rules, creating the proper workflow, letting each agent know what they're
> about and what they should expect and when they should start doing their own thing.

**What this means for what we build — the scope collapses dramatically:**

- **No role registry. No orchestration engine. No planner. No task allocator.** None of these are wanted,
  and building any of them would be inventing a paradigm the owner explicitly does not have.
- The **workflow graph lives in the prompts**, authored by the human at dashboard setup.
- The system's entire job is: give each agent a **stable, addressable identity**, and **deliver messages
  between them at turn boundaries**. That is it.
- The failure mode this avoids is the one that kills most multi-agent systems: agents deciding *what* to
  do and *who* should do it. Here, the human decides both, up front, once.

**One consequence worth stating** (observation, not a decision taken): if roles are prompts, then
*addressing* must still resolve. "Pass that work to the front end developer" needs a destination. The
consistent answer is that the **human names each panel at setup** and tells each agent the names of its
peers — so addressing is a string the human chose, and the system merely routes it. A system-maintained
roster of roles would re-import the paradigm through the back door.

**Also note:** *not long lived* lowers the persistence bar for a dashboard's workflow configuration —
but **not** for panel identity, which must still survive a reload for the whole PoC to work (§1.5, P3).

### 1.14 The charter — and what is explicitly *not* mine

**Owner's ruling on the shared-working-tree challenge (my push-back #2). Accepted, not to be
re-litigated.**

- It has been working in practice: three agents at a time on the platform, and *the way the platform was
  modularised means they don't step on each other's toes ~90% of the time.* Nothing is or will be
  perfect.
- Worktrees, branches, everything-on-master: **not the focus.** The owner has ~20 years professional
  experience, has never used a git worktree, and is willing to adopt one when it becomes necessary.
- Explicit division of labour, verbatim: *"that's my problem as a software engineer, as an architect, to
  solve."*

So git isolation is **owner-owned, deliberately deferred, and not a work item here.** It is recorded so
it is not lost, not so it gets picked up. Raising it once was welcomed; raising it again is noise.

**Important clarification from the owner — this is not a narrowing of the push-back instruction (§1.8):**

> Don't take what I said as a restriction on you to push back on things that you think might come up that
> are maybe not directly related with your particular mission. I just want you to understand that I *do*
> know what I'm doing — I've been through all those things my whole career. Those stones in my shoe are
> mine to bear, not yours.

The working rule that follows: **raise anything, once, plainly — including things outside the charter.**
Then the owner rules on it, and the ruling is respected without re-litigation. Ownership of a problem is
settled by the ruling; the right to raise the next one is not affected.

**My charter, in the owner's words:**

> Imagine, architect and build a proper **communication system between panels running on the same page**.
> That's it.

And the expectations around it:

- **Learn to walk first.** The owner does not expect that the night after this works he creates a
  dashboard with four windows and builds a project. The *practice* of using it will be perfected over
  time, separately from the mechanism.
- **This mission will take some time to reach an initial state.** It is not a quick change.

**The problems the owner explicitly wants thought about and documented** — these are the real design
work, and they come *after* the basics are proven:

1. Does the system survive a **server restart**?
2. Does it survive a **page refresh**?
3. **Should state be stored in the database?** — i.e. what part of the coordination is durable, and what
   is legitimately in-memory and disposable.

### 1.15 Recon: what the chat hardening already gives us (2026-08-07)

Survey of the chat/agent commits since 2026-08-01, read from diffs and source. **The foundation is much
further along than assumed.** Load-bearing findings:

**The injection channel already exists.** `sidecar.spawnClaudeStreaming({sessionKey, prompt, …})` called
on an *existing* `sessionKey` does **not** spawn anything — it pushes a user message onto the live input
queue (`claude-manager.ts:380-391` → `pushTurn` → `input.push`). **No browser involved.** Existing
callers: `websocket.ts:354`, `agent-runner.ts:187`, `pipeline-executor.ts:238`. This is how one agent
delivers a message to another.

**The turn-boundary signal already exists.** `result` is the explicit terminal event
(`chat/types.ts:143-153`, emitted `stream-parser.ts:144`), and `onTurnComplete(hadToolCalls)` is already
a public option on `useChat` (`useChat.ts:28`, fired at `:286-314`). Terminal set is
**`result` | `error` | `stopped` | `cut-off`**. Note: the *session outlives the turn* — `task:started` /
`task:notification` arrive **after** `result`, so "turn ended" ≠ "agent idle".

**Durable, cursor-addressed log:** `chat_session_events` — global monotonic `bigserial` cursor,
per-session index, `prevSeq` continuity chain, at-least-once replay from a client-held cursor.
**Caveat: 7-day retention** (`api/chat/retention.ts`) — a replay buffer, not an archive.

**Peer-restart notification:** `onClaudeSidecarStarted` (`sidecar-registry.ts:69-91`) — keyed off the
agent *registering*, not disconnecting. **Liveness oracle:** `claude:is-generating`, answered only by
the process that owns the session, **failing toward alive**.

**Principles this codebase has already paid for — adopt, don't re-derive:**

1. *Never route the durability guarantee over the link expected to break.* The agent writes to
   `chat_session_events` itself, then notifies; officer relays. Write durable, then notify.
2. *Infer liveness from the birth of the new process, not the death of the socket* — socket death fires
   on the innocent case (`pm2 restart officer`).
3. *An availability check must fail toward the less-alarming answer.*
4. *Classify by recoverability, not severity* — `cut-off` (seam + Retry) is a different object from
   `error` (red bubble).
5. *An id that never crosses the process boundary is not an address* (`47d03de`).
6. *Disambiguate at the only site holding the extra bit*, and set the flag **before** the await that can
   race it.

**⚠ Flagged for the chat owner — NOT mine to fix (§1.14 rule).** `sessionKey` (officer's uuid, the key
for `chat_session_events`) and `claudeSessionId` (the transcript uuid, the URL permalink) reportedly only
converge once a conversation has been resumed at least once — so an event appended by `sessionKey` may
not be found by a session reopened under the transcript uuid. Reported from
`docs/chat-ui-walkthrough.md:589-593`, not independently tested. **This sits directly on the addressing
path for agent-to-agent messaging.** To be written up in `COMMS/` and handed off.

### 1.16 The real optimisation target: unattended continuity, not parallelism

**Correcting a wrong assumption of mine.** The owner does *not* want three or four agents running flat
out at once:

> I don't expect to have three or four agents running at the same time like crazy. **What I want is to be
> able to sleep at night.**

The goal is **progress without a human present**, not throughput. Consequences for the design, and they
are large:

- **Latency is nearly free.** Seconds or minutes between handoffs is fine. Do not optimise for speed.
- **Concurrency is not the point.** Sequential handoff — A works, hands to B, B works, hands back — is a
  perfectly good and probably preferred shape. Do not build for contention that will not occur.
- **Durability is everything.** A handoff that fires at 03:00 must survive whatever the environment does
  between then and morning.

**And the consequence that dominates the architecture — flagged for the owner to confirm (§5):** if the
owner is *asleep*, **the dashboard page is closed.** A handoff must therefore work with **no browser
open**. That rules out every browser-resident mechanism — `usePanelChannel`, React state, anything in the
document — not on elegance grounds but because the document will not exist when the message is sent.

This does not contradict the owner's framing of the problem as *"panel communication inside a single web
page"*; it refines it. **The panels are the view; the mechanism must live server-side.** The page is how
a human watches and steers a conversation that continues without it — which is also precisely what
§1.15 shows the chat system was rebuilt to support (durable event log, cursor replay, agent-as-writer,
session outliving the socket).

### 1.17 The restart payload is temporary — the protocol is not

> The restart thing is giving me pain right now. Pretty soon that won't be a problem, because I won't
> have the necessity of editing the platform in real time from the platform as I'm doing today.

Further confirmation that the PoC is **scaffolding**: the *payload* is disposable, the *protocol* is the
deliverable. Reinforces §1.12 — build message passing, not a restart-negotiation feature. If the restart
case disappeared tomorrow, nothing built should need to be deleted.

### 1.18 Ruling on push-back #3 (agents reviewing agents)

Same ruling as §1.14: **not our problem, not related to the mission.** The owner's framing — *that is
assuming the owner is dumb, which is important sometimes, but not for this mission.*

Correct, and worth stating why so the boundary is understood rather than merely obeyed: **the quality of
an agent's review is a *usage* concern, downstream of the mechanism.** Whether the reviewer is any good
is a property of the prompt the human wrote, not of the transport. The mechanism is the postal service;
it is not accountable for what is in the envelopes.

---

## 2. What it implies structurally

Derived from §1. These are the constraints the design must satisfy.

**Build exactly this:**

1. **A stable, addressable identity per chat panel**, persisted, surviving reload. Panel id is the
   natural key (§1.5, P3) — subject to the `movePanel` hazard.
2. **Message passing between named sessions at turn boundaries.** Messages carry *content* (a handoff of
   work), not just signals (§1.12, and the owner's escalation: work handoff is *the whole crux*).
3. **Loud failure** when a message is dropped, a peer does not exist, or a handoff never lands (§1.8 as
   refined; already a value in this codebase — `9eb8fa1`).

**Do not build:**

- No role registry, orchestration engine, planner, or task allocator (§1.13).
- No restart-negotiation feature — restart is a *payload* (§1.17).
- No git, repo, branch, build, or test awareness. **No knowledge of software at all** (§1.11 + the
  domain-agnosticism constraint): the mechanism must be as ignorant of the work as a postal service is
  of what is in the envelope.
- No guardrails against the operator (§1.8 clarification).
- No worktree/branch isolation — owner-owned (§1.14).

**Hard constraints:**

- **Turn-boundary only.** The safety property comes from negotiation, not robustness (§1.6).
- **Must work with no browser open.** The owner's goal is to sleep; the page will be closed. The
  mechanism is server-side; panels are the view (§1.16). *Pending owner confirmation — see §5.*
- **N-way from day one.** Parallelism is not the current target but must not be foreclosed — no "the
  other agent" singular anywhere, no single-writer ordering assumptions (§1.16 correction).
- **Durability over latency.** Seconds or minutes between handoffs is fine; a lost 03:00 handoff is not.
- **Human authors the workflow.** Always a human orchestrator at the top (§1.9, §1.13).

## 3. What it unlocks — the nice-to-haves

Not the objective. Recorded because each falls out at little or no extra cost, which is evidence the
primitive is the right one.

- **Unblocking a stalled agent** (§1.6). An agent waiting on a human at a turn boundary can be woken by
  a peer. Removes the owner's physical presence as a hard dependency for progress.
- **Unattended overnight progress** — the owner's stated wish to sleep (§1.16).
- **Automatic handoff of cross-domain findings** — e.g. this document's own §1.15 chat defect, which the
  owner must currently carry by hand to the chat agent (§1.14). The rule and the mission are the same
  shape.
- **The software factory** (§1.7) — several specialised agents with quality gates, as *usage* built on
  the primitive rather than as features of it.
- **Non-software domains entirely**, and other users with unrelated goals.
- **True parallelism**, later — *"the literal definition of heaven on earth."*

## 4. Constraints and rules laid down

*(ground rules stated by the owner for this body of work, verbatim in substance)*

- Nothing is started — including trivial fixes — until the picture is complete and played back to the
  owner, and the owner has confirmed it is correct.
- This document is kept live *during* the conversation, not written up afterwards.
- Re-ranking the existing todo waits until the conversation is finished, and is then reflected both here
  and in the documents that already exist.

### 4.1 Explicitly de-scoped — not wrong, just not now

Stated by the owner before the objective itself, and it is a *priority* judgement, not a correctness
one. These are acknowledged as poor architecture and are nonetheless **not to be worked on**:

- **Everything downstream of the file browser at `/files`** — the ephemeral-panel machinery
  (`ephemeral` prop, `useFileViewerPanels`, the search-param-driven viewer/player/side-chat that opens
  beside the browser without entering your saved layout). The owner's words: *horrible architecture*,
  and *everything is working as much as I need it*.
- The query-string-driven sub-panel approach generally.

The rule that follows: **do not open these as work items, and do not let a fix wander into them.** If
one of them is genuinely blocking the objective, that is a finding to raise with the owner — not a
licence to start. Some of them will likely improve *inadvertently*, as a side effect of work done for
the objective, and that is the expected and acceptable way for them to get better.

This section is a live list. Anything else the owner de-scopes gets added here rather than being
silently dropped from the todo — a de-scoped item stays visible, it just stops being ranked.

## 5. Open questions

Not to be guessed at. Ranked by how much they would change the design.

**Q1 — RESOLVED by the owner, 2026-08-07. Server-side mechanism; the page is a view.**

> Ultimately I don't care if the web page is open or closed. I care that if I come back and open a
> specific dashboard that was created for a specific mission — one Claude on one side and another on the
> other — whatever is happening server side, I load that page and see the continuation or the result of
> it. Everything is managed by the Claude architecture: session, saving, etc.

So the dashboard is a **window onto server-side work already in progress**, never the place the work
lives. This is settled and is a hard constraint (§2).

**Q2 — RESOLVED by reading the code, 2026-08-07. Let sessions be reaped; resume on delivery. No
heartbeat.**

The chain, verified:

- Idle GC is real: `IDLE_TIMEOUT_MS = 30 * 60 * 1000` (`claude-manager.ts:39`); `armIdle` (`:225-236`)
  calls `killClaudeSession` after 30 idle minutes, sparing only a session that is generating or has
  pending tasks.
- **But `killClaudeSession` (`:411-427`) does not clear the resume pointer.** It aborts the query, closes
  the input queue and drops the in-memory entry — and deliberately does *not* call
  `clearClaudeSession`. That is a separate function (`clearSession`, `:430`) on the explicit-disconnect
  path.
- The `sessionKey → claudeSessionId` map is **write-through to disk** (`state.ts:86-102`, at
  `DATA_PATH/<email>/sidecar/claude-state.json`), specifically so it survives a crash or SIGKILL —
  commit `f4be4fd`.
- On a fresh spawn, `createSession` reads it back: `resumeId = getClaudeSession(sessionKey) ??
  params.resumeSessionId` (`:258`), passed as `resume` to the query (`:295`).

**Therefore `spawnClaudeStreaming` on a reaped `sessionKey` transparently re-creates the session with
`resume: <claudeSessionId>`, context intact from the on-disk transcript.** This is the good answer, and
it is better than a heartbeat on every axis:

- **Zero cost between handoffs.** A dormant panel holds no process, no memory, no query. Ten dashboards
  left open overnight cost nothing.
- **Survives everything** — idle GC, `pm2 restart officer`, an agent-sidecar restart, a crash, a SIGKILL.
  A heartbeat survives none of those; it would only paper over the idle timer while remaining fragile to
  the cases that actually happen.
- **Costs only latency**, which §2 already declares free.

Design consequence: **a panel is a pointer to a transcript, not a held resource.** The smallest possible
durable object. Delivery is "resume that transcript and push a turn."

⚠ **The one hazard to respect:** the explicit `disconnect` path *does* call `clearClaudeSession`, which
destroys the resume pointer and orphans the transcript. Coordination must never ride that path, and
whatever closes a panel must not trigger it.

**Q3 — RESOLVED by the owner, 2026-08-07: *"Yes, we can do that. I name them all."*** The human assigns
each panel a name at setup; the system routes a string the human chose and knows nothing about its
meaning. **The name is the address; the panel id is merely where it currently lives** — which also
disarms the `movePanel` hazard (§1.5, P3), since dragging changes position, not identity.

**Q6 — RESOLVED, and downgraded from blocker to report-only.** The owner's answer to *how a panel
acquires its Claude session id*:

> We can wait for the first conversation with a certain agent to start and get the first output, so we
> get the session id from Claude and add it to our session key. Or basically we **fire up each session
> with an initial introduction prompt** — so when I'm creating the dashboard I'm saying "this is front
> end, this is back end", and that introduction can be our first message to Claude, sent automatically on
> dashboard creation or session creation.

**Adopt the second.** It is strictly better, because it collapses two problems into one act: the role
prompt the human must write anyway *is* the message that brings the session into existence. Consequences:

- The **address book is fully populated at dashboard-creation time** — no lazy state, no "panel exists
  but has no session yet" hole, no first-handoff race.
- Every panel has a real, resumable transcript from the moment it is created.
- It is not a feature: it is the human's setup prose, delivered.

**And this removes the `sessionKey` / `claudeSessionId` divergence from our critical path.** Our address
book is `panel name → our sessionKey`; the sidecar privately owns `sessionKey → claudeSessionId`
(`state.ts`, write-through) and resolves it on resume (§5 Q2). **We never address by `claudeSessionId`.**
The reported divergence therefore affects the chat UI's permalink path, not coordination.

Still to be written up for the chat owner per §1.14 — it is a real reported defect and reporting it is
the rule — but it **does not block this work.**

**Q4 — RESOLVED by the owner, 2026-08-07. The payload is opaque text.**

> What the receiving agent will see will be a resulting `prompt.md` kind of thing, which the previous
> agent will be instructed to write at the end of its work, having in mind to whom that prompt is going
> to be delivered. **For proof of concept it could just be a dot character.**

So: the sending agent *composes* the message; the system carries it and does not parse it. Same rule as
roles — semantics in the prose, mechanism dumb. **PoC success criterion collapses to: did a turn land in
the other panel.** A single `.` is a sufficient payload to prove the mechanism.

**Q5 — RESOLVED. Coordination gets its own record; it does not ride `chat_session_events`.** See §5.1.
The 7-day retention question is therefore moot for coordination state.

**Q6 — `sessionKey` vs `claudeSessionId` divergence** (§1.15). Reported, not independently tested. Sits
on the addressing path. **Chat-owned — to be written up in `COMMS/` and handed off, not fixed here.**

### 5.1 The ledger — wanted, and explicitly **version 2**

Owner, 2026-08-07:

> It would be nice to have the whole flow — and I'm not talking about all the outputs, just **who did
> what, who handed off what to whom**. Recorded as a session in the database, **completely independent
> from what Claude records itself.** Every dashboard would be a session id, with a clear recording of who
> did what, who passed what prompt to whom. Just the basics — I don't need the whole output, Claude is
> already recording that. So the proper structure would be a collection of Claude session ids and the
> sequence that worked from start to finish, what were the prompts passed from one to another.
> **But this is something for version 2.**

Shape: one row per *dashboard run*, holding the roster of Claude session ids and an ordered list of
handoffs (from, to, prompt, timestamp). Deliberately **not** an output log — Claude's own transcripts and
`chat_session_events` already hold the content, and duplicating them is the mistake to avoid.

**Do not build this in v1.** But do not preclude it either: v1 must emit enough that the ledger is purely
*additive* later.

### 5.2 The distinction that keeps v1 small: address book vs ledger

These are two different things and conflating them would inflate v1 into v2:

| | what it is | when |
|---|---|---|
| **Address book** | the durable mapping *panel → session*, so a message can be delivered at all | **v1 — required.** Without it there is no delivery. |
| **Ledger** | the durable *history* of who handed what to whom | **v2 — deferred** (§5.1). |

v1 needs the address book and nothing more. Provenance recorded in v1 should be the minimum that makes a
handoff *visible and its failure loud* (§2), not a history feature.

## 6. How the found defects map onto the path

*(the re-rank. Written 2026-08-07 after the MVP was built and proven running, so it is ranked against
what the mechanism turned out to need, not against what it was predicted to need. `workspace-panel-todo.md`
is ordered by defect severity; this section says which of those defects the **objective** actually cares
about. Where the two disagree, this section wins for prioritisation and the todo keeps the severity note.)*

### 6.1 The headline: most of the panel defect list is not on this path

That is the finding, and it follows directly from Q1 and §1.16. **The mechanism is server-side; the
panels are a window onto it.** An agent's identity, its session, its transcript and its inbox all live in
Postgres and on the sidecar's disk. So a panel can remount, re-render, lose its React state, be dragged
across the dashboard, or not be rendered at all — and the work continues. Whole sections of the todo that
rank high on severity rank near-zero here.

The corollary, and it is the useful half: the defects that *do* matter are almost all the same defect
wearing four hats — **a write that silently does not persist.** Panel identity is the one piece of
coordination state that lives in the layout jsonb rather than in a table of its own, so every silent
persistence failure in this list is now a path by which a panel forgets which agent it is.

### 6.2 Tier A — on the critical path

**A1. Stop swallowing persist failures.** (§1, third item — `state/src/useDashboardState.ts:46`,
`.catch(() => {})`.) *The single highest-value item in the whole list against this objective.* The
panel's agent name is written through this path. A swallowed 500 leaves the optimistic cache correct, so
the panel shows its name, answers to its name, and **forgets it on the next reload** — the failure is
invisible for exactly as long as the human is not looking, which is the entire window this project
exists to serve. §2 requires *loud failure*; this is the loudest silence in the codebase.

**A2. The PATCH dispatcher's missing `else`.** (§2, first item.) The server half of A1. `ws-layout-*` is
matched today so panel `config` does persist — verified, the demo dashboard round-tripped with
`config: {agentName: …}` intact — but a chain of `if (…) continue` with no fallback means the *next* key
family added for coordination is a silent no-op that returns 200. Add the 400.

**A3. Validate the layout on read, and fix the `'[]'` default.** (§4, items 2 and 3.) Panel `config` is
new unvalidated jsonb inside an already-unvalidated tree. `normalizeLayout` calling `.children.map` on a
stored `[]` throws, and with no error boundary (A4) that is a white screen where the dashboard should be.

**A4. Add an error boundary around `WorkspaceRenderer`.** (§4, item 1 — the repo has none, anywhere.)
Ranked here for one specific reason: this is the **last mile of the whole objective.** Work proceeds
overnight; the owner opens the dashboard at 07:00 to see it. A malformed row turning that into a white
screen loses the result at the only moment it is consumed. The work itself is safe — it is in
`chat_session_events` — which is exactly why the recovery path must offer "restore default layout"
rather than requiring SQL.

**A5. The resize-debounce items.** (§5.5, first two.) Both are lost-update bugs against the layout, and
the layout is now where a panel's identity lives. The 500 ms timer closing over a pre-drag tree does not
merely resurrect a deleted panel — it **re-writes an older `config`**, so a panel that was just named
reverts to anonymous. Concurrent same-key writes clobbering has the same effect from a window resize.
The prescribed fix (an updater-form `setValue` + cleanup) fixes identity loss as a consequence.

**A6. Test `layout-utils.ts`.** (§9.) Promoted from "cheapest high-value target" to critical path, and
the reason is mine to own: `e588524` put agent identity inside those pure functions —
`setContents`, `swapPanels`, `movePanel`, `setPanelConfig`, `collectPanelConfigs`, `newPanelFrom` — and
shipped them with **no tests**. A regression in `swapPanels` now silently swaps two agents' identities
between panels, which is worse than any layout glitch it could previously cause. 214 lines of pure
functions over a serialisable tree; there is no excuse.

**A7. Two windows must not disagree about the roster.** (§5.5, "the cache is never invalidated" —
`staleTime: Infinity`, no `invalidateQueries` anywhere, and every PATCH already returns a fresh state
blob the client throws away.) Q1 makes the dashboard *a window onto server-side work*. Two windows onto
the same work that permanently diverge, and neither told, is a direct contradiction of that. Cheap:
consume the response that is already being computed.

### 6.3 Tier B — needed for the surface, not for the mechanism

**B1. `dashboardId` is a bag whose format is parsed by its consumers.** (§5.9, third item.) Promote —
and note a hazard this document's own MVP introduced. The agent address book is keyed on `dashboardId`,
which is literally `workspace.key` (`WorkspaceView.tsx:163`) — so the demo dashboard's agents are stored
under `ws-layout-agent-mvp`. **Renaming a screen key, or changing that derivation, silently orphans
every agent row on that dashboard.** The rows survive, the sessions survive, and the panels can no longer
find them. The prescribed fix — give the context `{kind, id}` instead of the raw key — is now load-bearing
rather than tidy. Not Tier A only because it is stable today and the failure requires someone to change
the derivation.

**B2. Panel lifecycle — but the ranking inverts.** (§5.1.) Against the terminal-orphan objective this was
"the highest-value change here." Against *this* objective the priority is the opposite one: **closing a
chat panel must never destroy the agent.** §5 Q2 records the hazard precisely — the explicit `disconnect`
path calls `clearClaudeSession`, which destroys the `sessionKey → claudeSessionId` pointer and orphans the
transcript, whereas idle reaping deliberately does not. So what is wanted from `onClose` here is a
*guarantee that nothing rides that path*, not an eager cleanup hook. Build the hook for the terminal by
all means; do not let a chat panel be wired into it without deciding that question first. A panel is a
pointer, and closing a window should not delete what it points at.

**B3. `normalizeLayout` as framework, not convention.** (§5.4.) Matters for one consequence: a panel
whose appType is allow-listed but no longer in the registry renders, on a `locked` screen, as an
unrecoverable empty box. A chat panel in that state is a *visible* agent the human cannot reach — though
note its peers still can, because the mechanism does not go through the browser. Real, but a display
failure over a live agent rather than a lost one.

**B4. The mobile collapse decision.** (§6 of the todo, first item.) Genuinely undecided against this
objective, and worth putting to the owner rather than guessing: *"I want to be able to sleep at night"*
raises the obvious question of whether the 03:00 check-in happens on a phone. If yes, a user-created
dashboard rendering only its left column forever is a Tier A problem wearing a mobile hat. If the answer
is "I check on the laptop, and mobile web is being retired for the native app" — which is what
`CLAUDE.md` currently says — it stays Tier C. **One question, one answer, large ranking swing.**

### 6.4 Tier C — orthogonal to this objective, keep them ranked by severity

Not dismissals. These are real defects and several are severe; they simply do not touch agents
coordinating with each other, and should be scheduled on their own merits rather than pulled forward by
this project.

- **§1's Running Shells items and §5.1's pty follow-ups.** The terminal orphan leak is its own worthwhile
  problem. It is not this one.
- **§3, multi-user correctness.** Ranks on its own timer (a second member creating a dashboard), which is
  unrelated to this path.
- **§5.2, the remount table.** *The largest downgrade in this re-rank.* A remount used to threaten
  whatever the panel was holding; a panel now holds nothing. A chat panel that remounts re-runs
  `resume-cursor` from its stored cursor and replays the durable log — it costs latency, and §2 declares
  latency free. Fix these for the interaction quality they are actually about; do not fix them for this.
- **§5.3, drag-to-move.** *The second-largest downgrade, and it was on the critical path when the north
  star was written* (§1.5, P3: "dragging a panel would silently sever its session binding"). Two things
  disarmed it. Q3 made the **name** the address and the panel id merely where it currently lives; and
  `e588524` made `swapPanels`/`movePanel` carry `{appType, config}` as one unit, so the name travels with
  the panel. `useAgentPanel` resolves by name and re-anchors the row's `panelId` afterwards. The
  finish-or-delete decision is still open and still worth taking — it is ~180 lines of dead code — but it
  is no longer gating anything.
- **§5.6 registry, §5.7 effect hygiene, §5.8 navigation, §5.10 channel hygiene, §8 dead code.** All
  orthogonal. Two notes in passing: §5.10's observation that `preview:refresh` and `chat:active-session`
  are written by `ChatPanelWrapper` and read by nobody survives the MVP rewrite unchanged — I kept both
  writes rather than widen the diff. And §5.8 is not a prerequisite here; the mechanism never goes
  through a channel, because it never goes through the browser at all.

### 6.5 What the re-rank did *not* find, and that is the result

No defect in `workspace-panel-todo.md` blocked building the MVP. It was built, and it ran unattended, on
the framework as it stands. The framework needed exactly one addition — per-panel config that survives a
move — and that is now `e588524`.

So the honest summary is: **this list is not the bottleneck, and it should stop being treated as the
prerequisite queue for the objective.** Tier A is seven items, five of which are the same "a write
silently did not land" defect, and all seven are small. Everything else in the list should be scheduled
for its own reasons, on its own timetable, by severity — which is what the file was already ordered by.