The whole composer bar is the target, not just the textarea — a screenshot dragged out of the macOS
corner thumbnail is a small thing to aim with, and the bar is the biggest thing near where the cursor
already is. Paste already worked; this is the same attach path.
Three details, each of which breaks the drop silently if missed. `preventDefault` on dragover, or the
browser refuses the drop, never fires onDrop, and navigates to the file instead — taking whatever was
typed with it. A depth counter rather than a boolean, because dragenter/dragleave fire for every child
crossed and the highlight strobes as you move over the textarea. And only claiming drags that carry
files, so dragging selected text across the composer neither lights it up nor swallows the drop.
Non-image files in the same drag are ignored quietly: refusing the PDF among them with a toast would be
noise when the three screenshots you meant went in fine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Queued prompts are almost always one thought arriving in pieces — a correction, then the thing you
forgot. Answering them one turn at a time made the agent reply to the first without knowing the second
existed, then re-answer once it did. Joined with a blank line between, in the order written, which is
how they read anyway.
The tray is unchanged: they stay separate rows, each removable right up until they go. What merges is
the delivery, not the queue.
Only a lone prompt can still be a slash command. Joined to anything else it is text that happens to
start with a slash, and running it as a command would silently drop everything queued behind it. The
drain now takes the whole queue at once, so it loops twice at most — again only if the batch was a
handled command and something arrived while it ran.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Send no longer refuses mid-turn. The prompt goes into a queue, and each turn's completion delivers the
next — one per turn, which is the whole drain loop. A slash command the client handles itself never
starts a turn, so delivery reports whether it did and the drain keeps going rather than waiting for a
completion that will not come.
Attachments are captured when the prompt is composed, not when it is delivered, so a queued message
keeps the files it was written with instead of picking up whatever is in the tray when its turn arrives.
The composer empties on queue as it does on send — a box that stayed full would read as "it didn't
take", and you would send it twice.
The send button turns amber with a different icon to say the press will not go anywhere yet, and sits
BESIDE stop rather than replacing it: typing a follow-up should not cost you the ability to interrupt.
A tray above the composer lists what is waiting, each item removable — without it a queued prompt is
invisible until its turn, which looks exactly like having lost it.
Stop clears the queue. Ending a turn is precisely the signal the drain waits for, so leaving it alone
fired the next prompt the instant you pressed the button meant to halt things. Nothing is lost: a queued
prompt was recorded in the prompt history when it was written, so Up brings it back.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Shell-style. Up walks back, Down walks forward, and past the newest is the draft you were composing when
you left — stashed on the way in, because losing what you had typed to the key pressed to get back to it
would be the worst version of this.
Up only takes the key from the FIRST line and Down from the last. In a multi-line draft there is a line
to move to, and swallowing the arrow would strand the caret; on the edge there is nowhere to go, which is
exactly when history is what was meant. An empty list, or already at the oldest, leaves the key alone too.
Per tab and shared by every chat in it, in sessionStorage. The prompt most worth reaching for is often
one sent somewhere else — re-asking in a fresh chat, or in the other panel — and scoping it per session
would empty the history exactly when a new chat makes it most useful. Slash commands count; they are
prompts you sent.
The tests caught a real one: `record` wrote state while `step` read a ref that only refreshed on the next
render, so sending and immediately pressing Up walked the list as it was one prompt ago. The ref is
written first now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It was built on a belief carried over from Claude Code's terminal: that interrupting means the agent
never read the prompt, so handing it back lets you say it differently. That is not what happens here —
the prompt is delivered and read before escape can land, the transcript keeps it, and the agent answers
it on the next turn. So the composer refilled with something already sent, and sending it again sent it
twice.
Escape means "stop, I'll say it differently" or just "stop". Neither wants the old text back. Focus
still returns to the composer, which serves both.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two faults, and the visible symptom of both was the same: type a new title, press enter, watch it snap
back unchanged.
The rename 404'd. `useClaudeSessions()` was called with no cwd, so the PATCH went without `?cwd=` and
the server searched the default group — `findTranscript(email, cwd, id)` scopes by directory, so every
conversation living in a project was unfindable. Only chats in the default group could ever have been
renamed. The pane now passes the session's own cwd, as the list already did.
And the title it displayed could not have changed even on success. It came from `selected.title`, which
rides the `chat:selected-session` channel — published once when a row is clicked and never updated —
so the invalidation refreshed the row underneath while the header kept the old name. The title is now
resolved once in `ChatDetailPanel` from the sessions query and passed down, so the pane, the page title
and the row are one source. Renaming from the list's pencil retitles an open pane too, which it never
did before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two things, one title.
The pane's header is now editable and calls the same `renameSession` the list's pencil does, so both
surfaces write the transcript's `summary` line and the invalidation that follows refreshes the row. The
id comes from the URL rather than `resumeSessionId`: they agree for an ordinary conversation and not for
a merged `/clear` chain, where the resume target is the tail while the list and the server address the
chain by its head — renaming the tail would have written a title nothing displays. `/chat/new` has no
transcript yet, so there the title is read-only.
And on `/chat/<id>` the conversation names the page, sitting between a typed tab name and the route
default: `label ?? override ?? titleForPath()`. Naming a window is deliberate and must still win. Not
gated on full screen, though that is where it earns its keep — the nav header is hidden there, so the
browser tab strip is the only thing telling two side-by-side windows apart. Tiled, the same value fills
the header's centre.
The edit interaction is now one `EditableTitle` shared with the nav header instead of a second copy of
it. `allowEmpty` is what keeps the header's "clear it to hand the tab back to the route name" working;
everywhere else empty means keep, since the rename endpoint 400s on it. `SessionList`'s row rename is
deliberately NOT folded in — it opens from a pencil and confirms with a check, so it is a different
interaction wearing the same styling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Maximize could only ever stop below the nav header — the content region is an `absolute z-2` stacking
context and the header a `fixed z-10` sibling, so that was the deepest a panel could get on its own.
Full screen reaches the rest by asking the shell to stand its header down, which leaves the shallow
version as a state nobody picks on purpose.
So it goes, and the two lights with it. `MaximizeMode` and the `{ id, mode }` session value collapse
back to a bare `fullscreenPanelId` — renamed because "maximized" would now be a lie about what it does
— under a new `FULLSCREEN_PANEL:` key, so a tab open across this reads nothing rather than an object
where a string belongs. `MaximizeButton` is gone; locked screens keep only the fullscreen toggle, which
writes no layout and so was always the one control the lock could permit.
Red stays. The amber used to REPLACE it while maximized so the way out could never be a way to delete;
with amber gone that guard would have cost the close button entirely, and red is already absent exactly
where it should be — locked screens render no traffic lights at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Maximize had one depth: fill the content region, leave the nav header visible. That was never a choice
about how much room to take — the region is an `absolute z-2` stacking context and the header is a
`fixed z-10` sibling, so no z-index a panel gives itself can paint over the nav. `top-[56px]` was the
workaround.
So full screen is cooperative rather than a bigger overlay. The panel asks, and the shell hides its own
header for it; `inset-0` is then genuinely the window. Still the same element and the same class swap —
no portal, no remount, so scroll position and playback survive the step between depths the way they
already survived maximize.
The mode rides beside the maximized panel id in sessionStorage as one value, so the two cannot drift;
a tab open across this change reads the old bare string, gets undefined for `.id`, and lands on
"nothing is maximized".
The toggle is offered from every state, so taking the window is one click from a tiled panel, and it
steps back to a maximized panel rather than all the way out. The amber light is present at both depths
and always goes all the way out, so neither is a trap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Also found uncommitted in the shared tree; unrelated to agent panels, so it lands
on its own.
`reset` closed over `initialValue` from the first render, and its `useCallback` dep
list deliberately omitted it — with an eslint-disable to silence the warning that was
correctly pointing at the bug. Any caller whose default is computed (derived from
props, from a fetch, from another piece of state) got reset to whatever that default
happened to be on mount, which after the first render is the wrong value.
Reads through a ref instead, so reset always sees the current default. The
eslint-disable goes away because there is nothing left to suppress — the dep list is
honest now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
a pin on each chip lifts it out of the strip and into a row above it, so the
one task you are actually waiting on stops sliding off the end as newer ones
arrive. more than one can be pinned; the pinned row scrolls like the other.
a pin outranks FINISHED_KEPT and the bulk clear both — it is an explicit
"keep this", and it would be useless if five newer tasks could still evict it.
pinning survives the task finishing, because the outcome is what you pinned it
for.
the tray only had a bulk clear, so getting rid of one finished chip meant
clearing all of them. each finished chip now carries its own close control.
the pill becomes a div wrapping two buttons — a button nested inside a button
is invalid and the browser eats one of the two clicks. running chips stay
undismissable: the tray is the only handle on work still going.
A recovered row was appended, so it landed at the bottom of the conversation instead of beside the
call that spawned it. It has no timestamp, but it does not need one: the harness stamps the task id
into the output of the tool call that started it, and live the task:started event arrives right
after that tool result — so anchoring there reproduces the position the row would have had.
First mention wins, and that is the correctness argument: the id is minted by the call that spawns
the task, so nothing earlier can contain it. Matching the most recent instead was wrong, and real
data caught it — a diagnostic that grepped the transcript printed both live ids and pulled the rows
down beside itself. That case is now a test.
Moved out of the hook into its own module since it is pure and has nothing to do with React.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adding an email account failed with a bare "failed to add account" toast. three
defects stacked, each hiding the next.
the email sidecar's http.ts reconstructs what the platform's middleware used to
provide, but only did two of three — bodyParser was never remounted, so every
write route read ctx.get('body') as undefined and POST /accounts threw on
body.provider before ever reaching the credentials.
its onError then read `.status` off the thrown custom-error, which carries
`statusCode`. every deliberate 4xx fell through to the 500 branch and had its
message replaced with "internal error", so a rejected IMAP login and a genuine
crash looked identical. it also answered JSON where the rest of the api answers
errors as plain text. now mirrors hono.ts's handler rather than inventing a
second shape.
useClient threw a plain object, so the ~33 sites narrowing with
`err instanceof Error ? err.message : <fallback>` always took the fallback and
discarded the server's message. now throws an ApiError subclass keeping both
status and message, so those sites start surfacing real errors.
only email reads ctx.get('body'); every other sidecar is a pure proxy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A task row is officer's own invention, synthesised from the harness's system.task_started, and
nothing corresponding to it is ever written to Claude's transcript. So rebuildTranscript can only
produce user/tool/assistant rows, and sync:live deliberately carries no messages — which left the
background-task tray empty after a mid-task refresh even though the work was still running.
Fold the durable log on attach into started-minus-notified and hand that back on sync:live. The
same read now supplies the cursor, so this costs one query rather than two. Finished tasks are
excluded: replaying those would resurrect rows already seen to resolve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Refreshing mid-turn appeared to kill the agent's output. It never did: the
session survives a dropped socket, the agent keeps generating into it and keeps
committing durable events, and `close` only detaches the socket and arms an
hour-long idle timer. What broke was purely delivery — and the reconnect path
that would have fixed it could not fire, because the browser came back having
forgotten officer's session key. It lived in page state. The only id left was
Claude's transcript uuid in the URL, and nothing accepted that.
So accept it. `attach` carries the uuid, and the agent's on-disk session map —
the single record relating the two — turns it back into the key everything else
is written in terms of. The uuid now also goes out at `system.init` rather than
only at `result`, which is what makes the first turn recoverable at all: until
now a chat had no address until it had finished, and a long first turn is
exactly the one worth reconnecting to.
`sync:live` deliberately carries no messages. The harness writes its transcript
as it goes, so the HTTP load on landing already supplies the past; sending the
server's record of the same messages on top of it would duplicate them, and
there is no shared id to reconcile the two by. Attach hands over the rest of the
turn, the half-written paragraph the transcript cannot hold, and the session's
cursor head — that last one so a *later* drop replays from the head instead of
re-delivering the whole conversation from zero.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tool rows used to close on a five-second timer, so the list shifted under you
while you were reading it and a call you had opened re-collapsed on its own.
open-ness is now derived — a row is open because it belongs to the live turn,
not because it rendered recently — and your own toggle lives above the
virtualiser, which was throwing it away every time a row scrolled out.
the previous turn now folds when you send the next message, and it folds
visibly: the new fold is born holding the rows it replaces, so the height is
unchanged across the swap, then closes over 260ms. reopening an old
conversation still renders collapsed; expanding work is only a service to
someone watching it happen.
autoscroll was failing for three compounding reasons. it was smooth, and a
smooth scroll is by definition away from the bottom for its whole duration,
so new content interrupting it left the view stranded. leaving the bottom was
read as intent regardless of cause, so the interrupted scroll — and any row
measuring past its 150px estimate — silently disarmed pinning until you
scrolled down by hand. and nothing watched for the ResizeObserver correction
that arrives after the estimate, which keeping tool rows open made much worse.
pinning is instant now, intent comes from real gestures, and the list re-pins
when the measured total changes.
25 tests over which controls exist in which mode and whether each calls the handler it is named after. interactive, locked, isMobile, isLastPanel, maximized and an app's own zoomable/transparent flags combine in six separate ternaries; a control present in a mode that should not have it is a way to edit a locked screen, and a control missing from one that should is what the close button was.
Drives PanelSlot directly rather than through WorkspaceView, so the workspace can be put into states a whole view cannot easily be pushed into — maximized, mid-swap, mobile. Nothing new found: the close button is the only defect the chrome had, and it was pinned last commit.
TrafficLights took onRemove and isLastPanel but called onClearApp either way — isLastPanel only chose the tooltip. Closing a panel from its own chrome was impossible: the panel stayed, emptied, and the context menu was the only working path. Worse than cosmetic now that identity lives in the layout — clearing the app drops the config that named the panel's agent while the panel survives to be renamed by whatever is put in it next.
Also wraps the ephemeral pane's sizing effect in a try/catch: react-resizable-panels asserts rather than no-ops when asked to size a group it has not laid out yet, and an assert thrown from an effect aborts the commit — taking the whole dashboard down for a file preview's geometry.
the store every dashboard layout is written through had no tests. writing them found
a live defect on its rollback: the guard asked "does the cache still hold what i wrote?"
by reference, and setQueryData runs react query's structural sharing, which rebuilds an
object rather than storing the one it was handed. verified against 5.101.4 — an object
comes back !==, a string comes back ===. so the check was false for every container the
store exists to hold: every layout, every config.agentName. a refused write kept its
optimistic value while the toast said it had been rolled back, and the change vanished at
the next reload. only primitives ever reverted, which is why it went unnoticed.
replaced with a per-key write sequence, which asks the question the identity check meant
to ask — has anything written this key since — and does not depend on identity at all.
14 tests: readValue's kind guard, the optimistic write and its updater composition, and
five on revert including the object regression pin.
also moves testing-library's cleanup into test-setup. it auto-registers afterEach at
module import time, so bun attaches it to whichever file imports the library first and
every later file silently gets none. adding this test file was enough to break fourteen
assertions in DataTable.test.tsx, which does not import it. preload has no file scope, so
registering there removes the ordering from the question.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The last two selections in Soulseek still held in useState. `?room=` and
`?peer=` now own them, the rails are links, and the leave/close buttons stay
siblings of the anchor.
Both rails auto-selected the first entry on load, which is the reason the
selection was local: there was nowhere to put an answer the user had not given.
The bare section is a real state now — nothing open — and both panels already
had the empty pane to say so. Rooms' pane said "Join a room to start chatting"
unconditionally, which was wrong once you could be joined to rooms with none
open, so it now distinguishes the two.
Join and "message a user" stay buttons: each writes something and *then* opens
it, which a link cannot express.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ui/toaster.tsx` was mounted in frontend.tsx and rendered a permanently empty
list: nothing anywhere imports `useToast`/`toast` from `ui/use-toast.ts`. The
app's real toaster is sonner, which is mounted beside it and has four callers.
`@radix-ui/react-toast` stays declared in the two package.json files on
purpose — installs are frozen, and dropping it means a deliberate
`bun install --no-frozen-lockfile` and a read of the lockfile diff.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Four navigates were flagged; one was real. The two ProjectPreview lines are
void — Projects was deleted in July. Of the two in DashboardPreview, the
create path writes the dashboard and then goes there, which a link cannot
express, so it stays. The Open Dashboard button in the edit form was pure
navigation and is now a link.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The audit said adopt the shared BackButton. It is not shared: zero importers
since the initial commit, no barrel entry, and a label-plus-underline shape
that fits none of the icon-only back controls here. Adopting it would have
redesigned the Jobs header under cover of a navigation fix.
So: a Link, matching what ScriptJobDetail and DownloadJobDetail already do,
and the dead component goes. useNavigate had no other caller in
PipelineJobDetail and goes with it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
audit m7 ranked this medium because "every caller inherits the opaque click". there
are no callers. nothing has imported Combobox since the initial commit, there is no
barrel that re-exports it, and nothing anywhere sets `href` on a SelectOption — so the
navigate, the separator that only appeared for href options, and the href field on both
declarations of the type were all unreachable.
writing anchor semantics into a component that is never rendered is building, not
fixing. the Command primitives it used stay; AIHarnessesSection needs them.
audit m5. the active file is `?file=`, tree file rows and tabs are links, and a
`?file=` naming something that is not open now opens it — which is the part that makes
a pasted link actually work rather than just describe.
the open-tab *set* stays local state and i want that on the record as a choice, not an
omission. it is a working session, not an address: it grows without bound, every entry
costs a read on load, and nobody has ever linked someone else to a tab bar.
opt-in via a prop from the screen rather than the workspace identity the file browser
uses, because /code-editor renders CodeEditorView directly inside a Widget instead of
through the panel wrapper — there is no workspace to ask. a dashboard editor is
unchanged.
tree *folder* rows stay buttons, and unlike the file browser's folders this needs
nobody's call: expanding a directory is disclosure, not navigation.
two things fixed while in here. the tab close control was a role="button" span nested
inside the tab's own button — invalid before, and a nested interactive inside an anchor
after — so it is a sibling button with an aria-label now. and closeFile picked the
next-active file inside a setFiles updater, which is the impurity react double-invokes
in development to catch.
a path that fails to read is remembered, so a broken link errors once instead of once
per render, and the address is left alone rather than rewritten.
the file browser's currentPath was useState, so back and forward did nothing and a
folder could not be linked to. it is `?path=` now on /files, and the breadcrumbs are
real links.
opt-in, keyed on the parsed workspace identity rather than the base path: a dashboard
can hold two file browsers and one shared param would move both, while an unscoped
panel (cwd `~`) sits on dashboards too, so `basePath === '/'` would have caught the
wrong ones.
two things the audit line did not know. `?view=` is ephemeral — useFileViewerPanels
wipes it on mount — so `path` is this screen's first durable param. and four
setSearchParams({...}) calls replaced the whole query string, which would have made
opening any file silently reset the folder to home; they go through a setViewerParams
helper now that carries `path` across.
folder rows stay buttons. cmd/ctrl/shift-click is already multi-select in FileItem and
open is double-click, so anchor semantics collide with a gesture that exists. that is a
product decision, not a defect — written up for the owner rather than guessed at.
/music?path=<rel> replaces the music:cwd channel. Each panel reads the param
itself through useMusicCwd(), so MusicBrowser, MusicDetail and FavoritesView
no longer tell each other where they are, and every drill-in is a <Link>:
library rows, folder rows, album/artist cards, both "up" affordances, the
favorites rows, and the dock's now-playing tile. Track rows stay buttons —
they play, which is a mutation.
A query param rather than a nested route because the location is only one of
the things this screen holds (the lyrics split and the favorites view are the
others), and a splat has to be a route's last segment.
MusicPlayerHost is mounted outside <Routes> and used to write the channel and
then navigate('/music') to make the write visible — the audit's only
navigate-with-a-side-effect. That collapses to one <Link>.
music:resync (a refresh signal) and music:favorites (a view of one panel) stay
channels, deliberately.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The section is /soulseek/:section — nav entries are NavLinks, the view panel reads the same
URL instead of being told, and the dashboard's tiles and recent searches are real links (a
recent search now opens that search, not the search screen's front page).
The peer went in `?user=<name>` rather than the /soulseek/users/:name the audit sketched: a
second path segment would need a nested route just to keep the nav highlight, and `?search=`
had already set the convention there. That deletes the `soulseek:user` channel and with it a
`{username, nonce}` request the Users panel consumed-once and cleared — the nonce existed so
asking for the same peer twice counted twice. A link is idempotent, so there is nothing to
consume and nothing to disambiguate.
`soulseek:refresh` stays: it is a signal, which is what channels are for.
/system-monitor/:scope, the same shape as /photos: route pair, one Navigate guard after the
hooks, scope list as react-router NavLinks, and both panels reading useParams instead of
agreeing over a `monitor:scope` channel. The Dock's isActive is a startsWith, so its
highlight survives the redirect off the bare route.
Each item re-verified before deleting; three of the ten entries were stale
and are corrected in place rather than silently fixed.
- WorkspaceLayout's isMobile/mobilePanelId/onMobileBack: none of its ten
callers set them, so the mobile collapse they fed was permanently off in
that renderer. WorkspaceView passes the same props to WorkspaceRenderer
itself, where they are live.
- fixedHeight on AppRegistryEntry, and getFixedHeight with it: no app has
ever declared one, so it only contributed undefined. The flex-column
branch it shared with fitContent stays, keyed on fitContent alone.
- getDefaults: getAllDashboardState already folds the defaults row into the
one payload the client fetches, which is why it never got a caller.
- upsertScreen's terminals/hostTerminals: never read is right, never
written was not — it inserted them, which is why all 15 rows hold {}.
The columns are left in place; dropping them needs a db:push, and this
tree holds another agent's uncommitted schema file.
- SELECTED_DASHBOARD_KEY: H2 (01365cb) replaced it with ?selected= four
months ago and it has had no reader since.
- ui/sidebar.tsx and the stray ui/hooks/ beside it. use-mobile was not
orphaned as claimed — the sidebar imported it — and the use-toast in
there was a near-identical copy of the live one.
- findChildById's unreachable duplicate condition, and the doc comment that
described the wrong behaviour rather than the code being wrong.
Left deliberately: DragOverlay/LayoutEditor (gated on 5.3, an owner
decision) and the two chat-owned channels, whose docs are fixed here even
though the publishers are not mine to delete.
Four channels were bare string literals repeated across files, with the payload type supplied by each
caller. Neither hole errors: a typo yields a different, empty channel — publisher publishing into nowhere,
subscriber waiting forever — and a publisher and subscriber can simply disagree about the payload with
nothing to check them. defineChannel(name, initial) returns the hook, officerdev/src/channels.ts declares
the four, and every usePanelChannel call site in the repo now passes a shared constant.
files:refresh-signal was bumped two different ways: Date.now() at the Chat sites, setSignal((n) => n + 1)
at the FileViewer ones. The increment is wrong — useGlobal's functional setter applies against the value
captured at render, so two bumps in one render window both compute snapshot + 1 and the second writes the
same number as the first. Nobody re-reads and the file that was just written stays stale. Date.now() has
the same flaw at millisecond scale, and the four FileViewer sites (save, delete, extract, transcribe) sit
close enough to hit it. useFilesRefresh's bump is a module counter that never reads React state, so it is
right however many times it is called between renders, and it is identity-stable through a ref because
useGlobal's setter is a fresh closure every render and this goes into dependency lists.
system-settings:run-command is deleted. It had a writer once — 7c0b11c wired the AI harness installer to
it — and when that install moved server-side to POST /server-settings/chat-providers/install the write
went with it, leaving a channel whose only remaining writes were clears, a terminal pane nothing could
open, and a second layout nothing could select.
PanelComponentEntry's component, header and provider are typed with { panelId: string }, which is what
PanelSlot has always rendered them with. A no-prop component is still assignable, so no screen changed.
chat:active-session and preview:refresh are declared but still have no subscriber. preview:refresh has no
plausible one — the PreviewProvider that read it is gone from the repo — but both are published by the
chat panel, and that is not this branch's to change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`<AppRegistry />` and `<WidgetRegistry />` seeded through `useGlobal`'s `initialData`, which is not a
write: it applies only to whichever component reads the slot first. They worked entirely by sitting
above `<App />` in frontend.tsx — any WorkspaceView that rendered first would have created the slot as
`{}`, with no second chance, and drawn every panel on that screen as an empty box.
Both are now plain functions taking the QueryClient, called before createRoot().render(). They take the
client rather than running as a module-scope side effect because the app list imports every panel app
and every panel app imports the Workspace framework; keeping the call in frontend.tsx, the one module
that is nobody's dependency, is what stops that being an import cycle. Making useAppRegistry default to
the static list was the obvious fix and is exactly that cycle.
registerApp and registerWidget go with the components. Nothing ever called either, and a registry that
can be added to at runtime is a registry whose contents depend on what has mounted so far.
Separately: officerdev/file-viewer was a registration for a provider fed by a `file-viewer:<panelId>`
channel that nothing writes, with availableOnPanel: false so it could not be picked either. The file
viewer users actually see is an ephemeral panel from useFileViewerPanels, which supplies the body and
header itself and reads the path from the URL. No stored layout referenced the key — zero rows across
dashboards, screens, dashboard_defaults, user_state and user_settings — so the meta and its wrapper are
deleted rather than repaired.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The microphone was the loud one: DictateDialog's teardown was guarded by
`if (!showDictate)`, which can never be true, because a cleanup sees the props
of the render that registered it and only the open render registers one. So it
never ran, and the mic, the AudioContext and the rAF loop stayed alive for the
life of the tab. useAudioRecording had no unmount cleanup at all — closing a
Chat panel mid-recording did the same thing, with no way to switch the
recording indicator back off. Both now release on unmount; the second is pinned
by a test that records, unmounts, and asserts the track stopped.
The rest is the same shape. Two sockets registered a listener once and held the
first render's callback forever — usePipelineRunner's carried a captured
streamingText, so a re-render mid-run would have folded every later event into
a stale buffer. PanelSlot built its default header as a component *type* inside
render, which React cannot match against the previous one. WorkspaceView handed
every panel a fresh context object on every render, including each frame of a
maximize animation.
VideoPlayer's comment claimed a dependency list that the code did not have; the
list is fine (sendReport never changes identity) and the comment now says why
that has to stay true.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The remount table in todo §5.2 was reasoned from the code and never observed, so
this mounts the real WorkspaceRenderer against a mount-counting probe and lets
the real layout-utils mutators produce the "after" tree. Eight cases.
It found one the reading had missed, and it is the cheapest of the lot. ChildEntry
returned `<>{children}</>` for the first child and `<><Handle/>{children}</>` for
every other, so the panel sat in fragment slot 0 when it was first and slot 1
when it was not. Remove the leftmost of three panels and the second one finds a
ResizableHandle in the slot it used to occupy — different element type, so React
unmounts a panel that nothing happened to. Scroll position, media playback, a
transcode, and for a chat panel a re-read of the durable log, all thrown away
because a neighbour was closed. Now the handle slot is always there, holding null
when it is not needed.
The other cases confirm what the doc said but for a different reason. Splitting
against the parent direction, and a two-child group collapsing, both change the
element *type* at that position — PanelSlot becomes ResizablePanelGroup, or the
reverse. React reconciles by type before it looks at keys, so the "reuse the id
so the key doesn't flip" fix the doc proposes would not have moved either one.
splitInner and insertPanel both ended with `100 / newChildren.length` applied to
every sibling, so splitting any panel in a group discarded every proportion in
it. A deliberately narrow sidebar became an equal column the first time anyone
split the panel next to it — and there was no way to get it back except by
dragging the splitter again.
The new sibling now takes half of the target's size and nothing else moves. One
helper for both call sites, because the drop path (movePanel -> insertPanel) had
the identical bug and would otherwise have kept it.
Three tests. Two of them were already there asserting the even split, written
against the old behaviour on purpose; they now assert the new one. The move test
is new and documents the interaction worth knowing: removePanel renormalises the
group when the panel leaves, so a move reads as renormalise-then-halve.
Two second implementations, both removed rather than fixed.
DashboardPreview minted template panel ids with its own module-level counter,
tpl-1, tpl-2, no entropy, reset every page load. Two dashboards built from
templates in the same page load held panels with identical ids — and a panel id
is not decorative any more: agent_panels addresses an agent by
(dashboardId, panelId), and terminal-conn-<panelId> and file-viewer:<panelId>
key persisted state by it. The templates now call the core uid(), which is
exported from the Workspace barrel for the first time so there is one minter.
metasToRegistry is Object.fromEntries, so two apps sharing a key means one app
stops existing and every panel holding its appType renders the other. The todo
asked for a throw in dev; a throw takes down every dashboard at runtime for a
mistake made at edit time, so this is a test over the real meta list plus a
console.error. All 44 keys are unique, and the test now says so rather than the
doc.
Getting the real list into a test needed test-setup.ts to provide localStorage:
MusicPlayer/useLyricsOpen.ts reads it at import time, so the whole app graph was
unimportable from a test. That unblocks testing anything that pulls in a panel
app.
Also deletes officerdev/src/useAppRegistry.ts — a stub returning {} with a
different shape from the real hook, imported by nothing.
The edit branch of the dashboard form rebuilt the layout from the template on every submit, then wrote
it. So renaming a dashboard, or fixing a typo in its description, silently threw away however its
panels had been arranged and whichever apps were in them. The template is a seed picked once at
creation; it is not a description of the dashboard as it now stands. It is now only re-applied when
the user actually picks a different one.
A rename also dropped `ws-terminals-<id>` and `ws-host-terminals-<id>` without carrying them over, so
every shell the dashboard held was abandoned: the panels came back empty and the processes stayed
alive with nothing pointing at them. Both maps now move to the new key with the layout.
The order those keys go into the PATCH body is load-bearing and now says so — the server walks the
object in insertion order, `ws-layout-<new>` upserts the row while `ws-terminals-<new>` only updates
one, and `ws-layout-<old>: null` deletes. Written the other way round the terminals 404.
Verified against the running server rather than by reading: seeded a dashboard with a layout and both
terminal maps, sent the rename PATCH exactly as the client now builds it, and read the rows back —
layout, terminals and host terminals all arrived under the new id and the old row was gone. The
no-op case (same id, same template) now writes nothing at all instead of PATCHing the layout back to
itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every locked screen shipped the same recursive normaliser: an ALLOWED_APP_TYPES set, a
normalizeLayout, a useMemo to apply it before the wrong panel could render, and a useEffect to
persist the fix. Fourteen copies, character-for-character identical except the two names — so a
fifteenth screen was a copy-paste, and a bug in the shape was a bug in fourteen places.
It is now `<WorkspaceView appTypes={{ allowed, fallback }} />`. WorkspaceView normalises before it
renders and persists the diff itself, which is the same two effects the screens were writing by hand.
One deliberate behaviour change: the framework normaliser drops `config` when it replaces an app.
The fourteen copies did `{ ...node, appType: fallback }`, keeping the old app's config on the panel
the new app now owns. That is the opposite of what `setApp` does, and a config belongs to whoever
wrote it.
Headscale keeps a local useMemo. Its check is not "is this appType allowed" but "is the server
picker present at all" — a layout saved before that panel existed is discarded for the default
wholesale. That is about a panel being missing, which the allow-list cannot see.
QrTransfer gains a persist-back it never had: it normalised on read and threw the result away every
time.
Tests: normalizeLayout is pinned on reference-identity for a no-op, null always allowed, config
dropped on replacement, rebuilding only changed branches, and idempotence — because a normaliser
that does not normalise to itself makes the persist-back an infinite write loop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The sidecar has always sent `clients` on each session and this list has always dropped it, so a shell
you are typing into and a shell nothing is attached to rendered identically. It is now on the type,
shown as "N attached", and a zero earns the row an orphan badge — the count only helps if you do not
have to read it to notice.
Also records §5.1 and the whole of §1 in the todo, including that the diff-the-layout implementation
§5.1 used to propose is struck and why.
Three wrappers held three copies of the same `panelId -> sessionId` bookkeeping, and one of the three
still had the unmount cleanup the other two had removed: `HostTerminalWrapper` dropped its map entry on
every layout or route change, minted a new uuid on the way back, and left the host shell running with
nothing pointing at it. All three now share `useTerminalSession`, which forgets the session and kills
the shell from `usePanelClose` — a real close, and nothing that merely looks like one.
The kill request goes to `/terminal/_officer/sessions/:id`, which is also a fix. `RunningShells` was
asking for `/terminal/sessions`; the proxy strips `/api/terminal` and forwards the rest verbatim, and
the pty sidecar only answers under `/_officer`, so that route 404s. Verified against the live sidecar:
`/sessions` returns `{"error":"not found"}` and `/_officer/sessions` returns the list. The panel has
therefore always read "No shells running" and its kill button has always been a no-op — which is why
the orphaned shells it exists to surface were never actually visible.
A panel that owns something on the server — a pty, a lock — has had no way to be told it was closed.
`TerminalWrapper` says so in a comment: it cannot kill on unmount, because a drag, a swap, a mobile
panel switch and a genuine close are the same event from inside the component.
So the signal is raised where the intent is, not where the teardown is. `usePanelClose(panelId, fn)`
registers a handler; `WorkspaceView` fires it from `handleRemove` and from `handleSetApp` when the app
actually changes, and from nowhere else. Registration is deliberately never torn down — "unmounted" is
the ambiguous signal being replaced, so honouring it would reintroduce the bug — and handlers are
stamped with the workspace they were registered on so one dashboard's panel id cannot fire another's.
`findPanelApp` is what tells a real app change from re-picking the app already there, which `setApp`
treats as a no-op; without it every pick from the app menu would close a panel that never closed.
No app uses the hook yet. The terminals come next; a chat panel deliberately never will, since a chat
panel is a pointer to a server-side session and closing the window must not delete what it points at.
The panel-close signal (§5.1) was going to be a before/after diff of the layout tree — the todo
document says so. It cannot be. `movePanel` inserts through `newPanelFrom`, which mints a fresh
`uid()`, so a dragged panel's id is gone from the new tree while its app is still on screen; and
`swapPanels` exchanges `{appType, config}` between two ids that both stay put, so a swap reads as
two closes and two opens. Everything downstream of a close signal is destructive — a pty killed, a
session released — so a mechanism that fires on a rearrangement is worse than none.
Two tests, no production change. The signal has to be raised where the intent is known, at
`WorkspaceView`'s `handleRemove`/`handleSetApp` call sites.
`WorkspaceLayout` and the `createContext` default each spelled out the same eleven fields — every
interaction a panel can start, switched off. Two hand-written copies of one list is a list you fall
behind: adding a field to the context type only errors at the call site if it is required, and both
copies have to be found.
Named it. `inertInteraction` is what "this tree cannot be rearranged" means, and both places spread
it. `cwd` and `root` stay out of it deliberately — they say where the workspace is rather than what
can be done to it, and the inert renderer has no answer for `root`: its consumers only read it when
`cwd` is scoped, which no caller makes it.
`promptPrefix` was a workspace-context field: the email and browser screens set it, `WorkspaceView`
put it on the context, and `ChatPanelWrapper` read it back off. Only the chat app has ever understood
what the string is, so the framework was carrying an app's vocabulary between two places that both
know each other.
`components` already exists for this — a screen supplies its own component for a panel id, and
`PanelSlot` prefers it over the registry while still taking header and provider from the registry
entry, so a screen-mounted chat panel keeps its normal chrome. Both screens now do that, and pass the
prefix as a prop. `ChatPanelWrapper` is exported from the barrel for it.
Also removes the same prop from `WorkspaceLayout`, where it had no callers at all: every preview and
settings pane rendering through it was already handing its chat panels an undefined prefix.
`initialPath` and `defaultSort` reached `FileBrowserApp` from nowhere else — the panel wrapper was
their only caller, and it was passing the two context fields that had no setter. Both remaining
callers pass neither, so the whole chain below them was already running on its defaults.
That includes `isolated`, which was `!!initialPath` and therefore always false: the unscoped browser
has been mirroring its folder into `files/currentPath` unconditionally, which is what the comment
beside it describes. Same behaviour, one fewer flag that reads as if it sometimes fires.
`initialFilePath` and `defaultFileSort` were declared on the workspace context, plumbed through
`WorkspaceView`'s props and read by exactly one panel wrapper — and set by zero callers. The sort
shape in particular (`{field: 'name'|'size'|'type'|'date', direction}`) is file-browser vocabulary
sitting in the framework's type file and re-exported from two barrels, so every app that imports the
context could see it.
Nothing changes at runtime: both were always undefined, which is what the wrapper now passes by
omitting them.
pastilhasandClaude Opus 5