step 4/4: the docs say permissions too, and capability means one thing again
44 files of prose — CLAUDE.md, AGENTS.md, TODO.md, 20 docs, both plugin design
documents, and the comment surface the earlier steps could not reach.
Applied against an explicit keep-list, not swept, because the word turned out to
have SIX meanings in this repository rather than the three the offscale doc
recorded:
permissions renamed (steps 1–2)
$OFFICER_ROOT/capabilities/ KEPT — the item store, and now the only thing
the word means that is ours
sidecar routing keys renamed to `handles` (step 3)
Lightning wallet KEPT — a domain term, and on the wire to the mobile apps
terminfo queries KEPT — XTGETTCAP, in the pty sidecar
InvoiceShelf KEPT — per-resource { write, bulkDelete } flags
The sweep still falsified two things, both caught by checking rather than by
review, and both in prose that discusses more than one meaning at once:
CLAUDE.md began claiming the item store lives at `$OFFICER_ROOT/permissions`.
It does not; that directory is on disk and full of skills and tools.
And the offscale doc's own note about the collision became
"Named `permissions`, NOT `permissions`" — a sentence that had eaten the thing
it existed to warn about.
Both restored, and the note rewritten to say what is now true: capability means
one thing of ours, and three that belong to somebody else's vocabulary.
Verified live after restart: self and admin permission endpoints 200, gated
route 200, agent-status 200, 9 grants intact with 6 permissions offered.
tsgo clean, 797 tests, 787 pass, same 7.
The rename is done. Four steps, no data lost, no client break that survived
the step it was introduced in.
This commit is contained in:
+129
-129
@@ -6,7 +6,7 @@ a human authoring the workflow at the top. Written live during the conversation
|
||||
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*:
|
||||
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
|
||||
@@ -25,11 +25,11 @@ until this conversation is finished — it is not to be started early.
|
||||
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 |
|
||||
| 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
|
||||
@@ -58,15 +58,15 @@ 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.*
|
||||
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
|
||||
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
|
||||
@@ -74,11 +74,11 @@ 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.)
|
||||
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
|
||||
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
|
||||
@@ -86,7 +86,7 @@ actually produces:
|
||||
|
||||
**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
|
||||
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.
|
||||
|
||||
@@ -96,7 +96,7 @@ being both the scheduler and the message bus between them.
|
||||
> 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*:
|
||||
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
|
||||
@@ -105,15 +105,15 @@ And the behaviour that PoC is *for*:
|
||||
|
||||
> If we get this to work, the sky is the limit.
|
||||
|
||||
Decomposed into the five capabilities it actually requires:
|
||||
Decomposed into the five permissions 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** |
|
||||
| # | permission | 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
|
||||
|
||||
@@ -121,7 +121,7 @@ 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
|
||||
`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
|
||||
@@ -132,12 +132,12 @@ through `WorkspaceContext`. `scoped = cwd !== '~'`. Every panel on a screen nece
|
||||
|
||||
**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 —
|
||||
`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
|
||||
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.
|
||||
@@ -160,7 +160,7 @@ 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.*
|
||||
> _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
|
||||
@@ -190,7 +190,7 @@ 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*.
|
||||
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.
|
||||
|
||||
@@ -204,7 +204,7 @@ The target:
|
||||
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
|
||||
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.
|
||||
|
||||
@@ -226,7 +226,7 @@ plainly and early — the cost of a late correction here is much higher than 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
|
||||
**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.
|
||||
|
||||
@@ -240,14 +240,14 @@ computers. The owner's worked example, verbatim in substance:
|
||||
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."*
|
||||
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.
|
||||
— 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
|
||||
|
||||
@@ -257,8 +257,8 @@ keep in my head*, though enjoyable and exciting.
|
||||
> "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.*
|
||||
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:
|
||||
|
||||
@@ -267,38 +267,38 @@ Structural requirements this adds, beyond the two-panel PoC:
|
||||
- **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
|
||||
- **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
|
||||
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."*
|
||||
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."*
|
||||
- **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."*
|
||||
_"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.
|
||||
**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 |
|
||||
| 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
|
||||
|
||||
@@ -311,8 +311,8 @@ 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
|
||||
**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,
|
||||
@@ -348,30 +348,30 @@ What he expects instead:
|
||||
- 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.
|
||||
- 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
|
||||
_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 —
|
||||
**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
|
||||
### 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
|
||||
- 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."*
|
||||
- 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.
|
||||
@@ -379,7 +379,7 @@ it is not lost, not so it gets picked up. Raising it once was welcomed; raising
|
||||
**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*
|
||||
> 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.
|
||||
|
||||
@@ -395,12 +395,12 @@ settled by the ruling; the right to raise the next one is not affected.
|
||||
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
|
||||
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:
|
||||
work, and they come _after_ the basics are proven:
|
||||
|
||||
1. Does the system survive a **server restart**?
|
||||
2. Does it survive a **page refresh**?
|
||||
@@ -413,7 +413,7 @@ Survey of the chat/agent commits since 2026-08-01, read from diffs and source. *
|
||||
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
|
||||
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.
|
||||
@@ -421,7 +421,7 @@ 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` /
|
||||
**`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,
|
||||
@@ -429,20 +429,20 @@ per-session index, `prevSeq` continuity chain, at-least-once replay from a clien
|
||||
**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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
@@ -454,7 +454,7 @@ 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
|
||||
**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
|
||||
@@ -470,12 +470,12 @@ are large:
|
||||
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
|
||||
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
|
||||
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).
|
||||
@@ -484,25 +484,25 @@ session outliving the socket).
|
||||
against the running system, deliberately looking for the break. Method and raw evidence:
|
||||
`COMMS/handoff-durability-2026-08-07.md`.
|
||||
|
||||
| what was done to it mid-handoff | turn completed | narration durable |
|
||||
|---|---|---|
|
||||
| nothing (control) | ✅ | ✅ |
|
||||
| `pm2 restart officer` | ✅ | ✅ |
|
||||
| **`officer` stopped for 25 s** | ✅ | ✅ **6 events written while the server was down** |
|
||||
| target's `claude` process SIGKILLed | ❌ lost | ⚠️ partial, with an explicit error row |
|
||||
| next handoff to that same agent | ✅ | ✅ same Claude session resumed |
|
||||
| handoff POSTed while `officer` is down | ❌ lost | ❌ no queue, no retry |
|
||||
| what was done to it mid-handoff | turn completed | narration durable |
|
||||
| -------------------------------------- | -------------- | ------------------------------------------------- |
|
||||
| nothing (control) | ✅ | ✅ |
|
||||
| `pm2 restart officer` | ✅ | ✅ |
|
||||
| **`officer` stopped for 25 s** | ✅ | ✅ **6 events written while the server was down** |
|
||||
| target's `claude` process SIGKILLed | ❌ lost | ⚠️ partial, with an explicit error row |
|
||||
| next handoff to that same agent | ✅ | ✅ same Claude session resumed |
|
||||
| handoff POSTed while `officer` is down | ❌ lost | ❌ no queue, no retry |
|
||||
|
||||
Three things follow, and they change how the outstanding work should be read:
|
||||
|
||||
- **The "no browser open" requirement is satisfied, and so is the harder one.** Not one of these runs had
|
||||
a page open, and the middle row is the proof that officer is genuinely off the delivery path: the agent
|
||||
sidecar committed the model's own words to Postgres during a 25-second server outage.
|
||||
- **A restart costs a *turn*, not an *agent*.** After being killed mid-turn, the receiver resumed the
|
||||
- **A restart costs a _turn_, not an _agent_.** After being killed mid-turn, the receiver resumed the
|
||||
identical Claude session on the next handoff and volunteered which work had been lost. Continuity —
|
||||
`sessionKey` minted once, write-through map on disk — does the job it was built for. That makes the
|
||||
outstanding claude **stage 5** a smaller problem than its position on the list suggests.
|
||||
- **The remaining hole is on the *sending* side.** A handoff POSTed while officer is down is refused and
|
||||
- **The remaining hole is on the _sending_ side.** A handoff POSTed while officer is down is refused and
|
||||
dropped, and nothing in the introduction text tells the agent to retry — so the sender can believe it
|
||||
handed off when it did not. That, not the receiving side, is where store-and-forward would earn its
|
||||
keep.
|
||||
@@ -510,7 +510,7 @@ Three things follow, and they change how the outstanding work should be read:
|
||||
One topology fact found while setting this up, worth stating here because it is the practical limit on
|
||||
working unattended: **`officer-agent` is `sidecar/claude/user-instance.ts`, and every `claude` process on
|
||||
the machine is its direct child.** `pm2 restart officer-agent` therefore kills every agent on every
|
||||
dashboard at once, mid-turn. `CLAUDE.md` reassures that restarting *officer* is safe — it is, and that is
|
||||
dashboard at once, mid-turn. `CLAUDE.md` reassures that restarting _officer_ is safe — it is, and that is
|
||||
verified above — but is silent on this one.
|
||||
|
||||
### 1.17 The restart payload is temporary — the protocol is not
|
||||
@@ -518,17 +518,17 @@ verified above — but is silent on this one.
|
||||
> 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
|
||||
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.*
|
||||
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
|
||||
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.
|
||||
|
||||
@@ -542,15 +542,15 @@ Derived from §1. These are the constraints the design must satisfy.
|
||||
|
||||
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*).
|
||||
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 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.
|
||||
@@ -561,7 +561,7 @@ Derived from §1. These are the constraints the design must satisfy.
|
||||
|
||||
- **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.*
|
||||
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.
|
||||
@@ -578,35 +578,35 @@ primitive is the right one.
|
||||
- **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 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."*
|
||||
- **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)*
|
||||
_(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.
|
||||
- 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
|
||||
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*.
|
||||
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
|
||||
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
|
||||
@@ -635,14 +635,14 @@ The chain, verified:
|
||||
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
|
||||
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`).
|
||||
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
|
||||
@@ -658,17 +658,17 @@ it is better than a heartbeat on every axis:
|
||||
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
|
||||
⚠ **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
|
||||
**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*:
|
||||
**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
|
||||
@@ -677,7 +677,7 @@ acquires its Claude session id*:
|
||||
> 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:
|
||||
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.
|
||||
@@ -698,7 +698,7 @@ the rule — but it **does not block this work.**
|
||||
> 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
|
||||
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.
|
||||
|
||||
@@ -720,31 +720,31 @@ Owner, 2026-08-07:
|
||||
> 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
|
||||
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.
|
||||
_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). |
|
||||
| | 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.
|
||||
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
|
||||
_(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.)*
|
||||
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
|
||||
|
||||
@@ -754,7 +754,7 @@ Postgres and on the sidecar's disk. So a panel can remount, re-render, lose its
|
||||
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
|
||||
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.
|
||||
@@ -762,15 +762,15 @@ persistence failure in this list is now a path by which a panel forgets which ag
|
||||
### 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
|
||||
`.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.
|
||||
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
|
||||
`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
|
||||
@@ -799,7 +799,7 @@ 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
|
||||
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.
|
||||
|
||||
@@ -815,22 +815,22 @@ rather than tidy. Not Tier A only because it is stable today and the failure req
|
||||
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
|
||||
"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
|
||||
_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
|
||||
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"*
|
||||
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
|
||||
@@ -846,12 +846,12 @@ this project.
|
||||
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
|
||||
- **§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
|
||||
- **§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
|
||||
@@ -863,7 +863,7 @@ this project.
|
||||
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
|
||||
### 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
|
||||
|
||||
Reference in New Issue
Block a user