a3fd3ade01625e6f658c439efb8423f03d139e56
671
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  pastilhasandClaude Fable 5
|
a3fd3ade01 |
minesweeper: hold the client in a ref, not in a dependency list
confirmed playable after this. useClient() rebuilds its verbs on every render, so `refresh` — which listed `client` — got a new identity every render, its mount effect re-ran every render, and each run set state and caused another render. an endless fetch loop that starved the socket, so onReady never ran and the panel sat at 'connecting…' forever. the backend was never at fault: the relay completed a full rfb handshake through wss://platform.officer.dev with a real token before this was found. ruling the server out is what left only the client. same trap and same fix as the jellyfin playback reports, which CLAUDE.md already warned about. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
3837af657d |
live sessions default to agents only, and you ask by name for a commander
`?kind=` was opt-in, so a client that said nothing got everything — which is the wrong default for the one caller that cannot cope. The phone swipes between live chats one at a time, has no room for tabs and no way to skip a row, so a commander in that list is a commander you are stuck on. Defaulting to `agent` means forgetting the parameter can only ever under-report. The two callers that want both now say `kind=all` explicitly, and that is a fair price: they are few, they are on screens built to show both kinds, and they are the ones positioned to notice when the answer is wrong. `counts` still describes every live session whatever the filter, so a filtered caller renders both tab numbers from one request rather than two. Also corrects useLiveSessions' comment, which said `isCommander` was derived from the cwd. It stopped being true when a commander gained the right to choose its own working directory — it comes from the `command_hq_sessions` row, and the directory answers nothing. Unrelated but caught by docs:check on the way past: the registry gained a nineteenth entry (minesweeper, execution) and CLAUDE.md still said eighteen, which also left the generated platform skill two lines stale. Both corrected; the check is green again. The minesweeper feature itself is half-landed and not mine — `rfb.ts` fails typecheck and its registry test fails on a websocket that is not served. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Fable 5
|
af918251d3 |
/minesweeper — a wine session streamed to the browser over RFB
a websocket byte relay onto x11vnc's tcp socket, the same shape as the terminal's relay onto the pty sidecar. this is the piece plugins/desktop could not have: a plugin cannot claim a websocket provider. the rfb client is ours rather than vendored novnc — raw and copyrect, one pixel format we dictate so a rectangle memcpys into ImageData. we control the server, so the other eight encodings are surface we would carry and never run. execution, so owner-only: wine runs as the owner, which makes the game's menus file dialogs over the owner's home. two bugs worth keeping. the token key is BEARER_TOKEN, not token, so the upgrade 401'd before any rfb byte moved. and the /status health check opened a tcp connection to prove liveness — libvncserver blocks its accept loop peeking for a websocket handshake, so a polled health check filled the backlog and locked out the real viewer. a liveness check must not be indistinguishable from a client; it reads /proc/net/tcp now. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
fc8ce04f2b |
the commander's name shows the moment it is typed, not after a refresh
Naming works — confirmed on a live commander, which now carries `{"type":"summary","summary":"Inbox
Summarizer"}` in its transcript. The instrumentation showed exactly the predicted shape: two attempts 2.8
seconds apart, the first on `session:claude` before the transcript file existed and the second on `result`,
which is the one that landed. The retry was the fix; the guess about WHY was right and the evidence was worth
having rather than assuming.
What was left was cosmetic and looked like the same bug: the pane still read "Untitled commander" until a
refresh. It could not have read anything else — the rename lands at the end of the first turn, and this bar
has no fetched title because a brand-new commander has nothing to resume. So it showed the one thing on
screen nobody had chosen, while the chosen name sat in a field two inches above it.
It takes the name from state now, which is where it already was.
Instrumentation removed. It earned its place: three attempts at this bug were reasoned and two of them were
wrong, and the log settled it in one run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
f065e2c0f8 |
the disabled composer says why, instead of inviting you to type
Caught in a screenshot before any testing: the new-commander composer was correctly disabled and still read "Type a message...". `placeholder` was declared TWICE on the same textarea — the reason I added, and the original below it — and JSX takes the last one. So the gate worked and was completely invisible, which is the worst version: an input that refuses you without saying what it wants. One placeholder now, carrying the reason when disabled and the usual text otherwise. Fourth prop-shaped mistake today, and a new variant: not a prop that does not exist, but a real prop silently overwritten by a second copy of itself. A typecheck cannot see either. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
1c47d0bba7 |
a commander is named and given a directory before it can be spoken to
The third of the three, and the one the owner will actually see. The new-commander card now collects both
decisions above the guide, and the composer refuses input until they are made — with the reason in the
placeholder rather than a validation message after the fact.
Both are chosen first because neither is cheap afterwards. The directory decides where every relative path in
every turn resolves and which project group holds the transcripts, so changing it later strands a
conversation away from its own history. The name has to reach the transcript the moment it exists, because
Claude Code names a new session from its first prompt and the platform's rename only wins by getting there
first.
The directory is a BUTTON, not a text field: it is an absolute server path, and typing one is how a commander
ends up running somewhere that does not exist. `DirPickerModal` already existed for /chat and browses the
account's own tree.
CAUGHT BEFORE SHIPPING, and only by checking: I first passed `cwd` and `commanderName` as `useChat` options
and `disabled` as an EmbeddableChat prop. None of the three existed. It typechecked anyway, because object
SPREADS bypass excess-property checking — `...(cwd ? { cwd } : {})` is invisible to it. That is the fourth
time today a silently-ignored prop has cost something, so the props are real now:
- `commanderName` is a `useChat` option on the send payload, and rides EVERY turn rather than only the first.
The server applies it once; sending it again costs bytes. Sending it once would lose it if that turn failed
and was retried — and a commander named after its second prompt is exactly what this prevents.
- `disabled` is a real EmbeddableChat prop carrying a reason, threaded to the textarea's NATIVE disabled —
which also removes it from the tab order and blocks a paste, neither of which a guard on send would do.
- the directory goes to EmbeddableChat's existing `cwd` prop, because that is what feeds `sendPrompt`'s
`cwdParam`. Two values chosen in one place travelling by two paths, noted where somebody would otherwise
have to discover it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
1c7619e184 |
the permalink goes through the router, so the open chat learns its own name
Third attempt at this bug, and the first two were fixes to the wrong component. The /chat screen renders
ChatDetailPanel, not ChatHeader — so invalidating the sessions list and correcting which id the panel records
were both real improvements to a surface that is not the one showing "New chat".
The actual cause is one line. The permalink was written with `window.history.replaceState`, which changes the
address bar and tells react-router nothing. On that screen BOTH the title and the rename control come from
`useParams().sessionId` — see the note in DetailBar about renaming the chain's head rather than the tail — so
the router kept reporting no session, the title stayed "New chat", and rename stayed absent. Navigating away
and back forced the router to re-read the location, which is why that appeared to be the cure and why the fix
looked like it belonged in a list.
Now a `navigate(..., { replace: true })`. Replace rather than push, so Back still leaves the conversation
instead of stepping through the same one under a succession of names.
Worth recording for the next one: three separate "the UI did not update" bugs today were all a URL or an id
not reaching the thing that reads it — two of them the officer-key/transcript-id pair, this one the router.
`useQueryState` still writes `history.replaceState` directly; same trap, different hook, left alone rather
than widened into this change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
3f1ba38f19 |
the chat panel's header names a new conversation too
The list learned the name and the panel header did not, which narrowed it to one lookup: the panel records its session id, and ChatHeader resolves the title by finding that id in the sessions LIST. The panel was recording `chat.sessionId` — OFFICER's session key — and the list is keyed on Claude's TRANSCRIPT id. Two id spaces on either side of one `find`, so it never matched: a new chat's header read "New chat" for the whole life of the conversation and offered no rename, because rename is a per-row action on a list the session was not found in. Selecting the conversation from the list fixed it, which is exactly why navigating away and back looked like the cure. Same trap as the Command HQ pane on 2026-08-21, third time this pair has caused a bug: officer's handle and the harness's transcript id are not interchangeable, and every place that keys one lookup on the other fails silently rather than loudly. The "only a REAL id, never null" rule is unchanged and still needed — both ids are null for a moment while a resumed session connects, and writing that null would turn "this panel has never chosen" into "the user asked for a new chat", so the next reload would open blank. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
59f600d34d |
a new chat gets its name without a refresh — this time with the import
Re-lands
|
||
|
pastilhas
|
cbedfed2ba |
Revert "a new chat gets its name without a refresh, and can be renamed"
This reverts commit
|
||
|
pastilhasandClaude Opus 5
|
f9a3699603 |
a new chat gets its name without a refresh, and can be renamed
Start a chat and the header said "New chat" until you navigated away and back, and the rename control was missing entirely. Both halves came from one cause, and it was not the titling. The header resolves its own title by finding the session in the cached LIST — `sessions.find((s) => s.id === sessionId)` — and a newborn conversation is not in that list. It has staleTime 30s and nothing invalidated it, so `current` was undefined: the label fell through to "New chat", and rename was absent because rename is a per-row action on a list the session was not in yet. Navigating away and back refetched it, which is exactly what made this look like a rendering bug. Verified first that the titling itself is fine and needs no change. Claude Code writes an `ai-title` entry early — line 8 in a real transcript, after the user message and BEFORE the first assistant line — and Officer's own `title: summaryTitle || firstUserText || '(untitled)'` means a session is never nameless once its transcript has a user message. The server could always answer; nothing asked it. So the conversation announces itself. On `session:claude` — the START of the turn, when the transcript becomes real on disk — and again at the end of every turn, because the harness may have bettered the name while it ran. The second call sits OUTSIDE the id check deliberately: that is true whether or not a particular `result` happened to carry the id. Cost is one small request per turn per open chat, which is the honest price of a list that is right. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
b7112f6e5d |
a commander records what it is and what it spawned, so deleting one means it
Without this record a commander cannot be stopped or fully deleted, and the delete route's comment claimed otherwise: "the running background process (if any) dies on its own". It does not. Nothing in that route touched a process, so a deleted commander left its loop running — still polling, still able to fire, still able to spawn a deploying agent, with no chip to stop it from and no row left to disarm. THE RECORD, and why the loop has to write it. Three ways to recover the link were tried and none works: the PROCESS holds nothing (no open transcript descriptor, nothing identifying in its environment — tested); the TRANSCRIPT is indistinguishable, because queue-operation/ai-title/last-prompt look like platform markers and are the harness's own, appearing in every session equally; CONTENT matching finds ordinary chats that quote a procedure as readily as the agent following it. So the loop records, because it is the only party that knows. Two files under DATA_PATH/<email>/commander-state/<session>/: `loop-pid` and `spawned`. The reader is deliberately tolerant — a truncated write or a stray line is dropped, not fatal, because a record that failed closed would make a commander undeletable over one bad line. STOPPING needs no new mechanism, only the pid: descendantPids + SIGTERM from the loop takes the loop and any agent under it, which is exactly what that helper was written for. A commander with no recorded pid stops nothing and SAYS so — the honest answer for one armed before this existed. DELETE now cascades in a deliberate order: stop the processes, then the children's transcripts, then the commander. Stopping first because a live agent writing to a transcript being deleted is a race, and because the loop could otherwise spawn a replacement between the last two steps. It returns counts rather than a bare ok — this is the one irreversible action here. The children's transcripts are deleted with the EXISTING deleteClaudeSession: its cwd argument is documented as "a hint, not an authority", so it locates a child that ran in the platform checkout rather than the commanders directory. No new function. THE CHAIN'S WEAK LINK was that the loop cannot know which commander it belongs to. The paths are now handed to it in the background-job prompt, fetched from a new endpoint because they are rooted in DATA_PATH — a server fact. Paths rather than an upload endpoint on purpose: a shell redirect needs no credential, and a background job has no business holding one. The prompt rule is numbered properly rather than landing on 7.5, and the output rule shifts down one when it is present. Verified both shapes produce consecutive numbers. The manager now exposes claudeSessionId, because a commander is keyed on the TRANSCRIPT id everywhere and officer's own session handle is not interchangeable — that mismatch is what once rendered a working commander as an empty pane. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
ee9106ef54 |
the new-commander card gets a slot for example prompts
Requested, and deliberately not written: an example opening prompt is a promise about what the flow accepts, and the flow is being rebuilt. Written now, all three would need rewriting — and a wrong example is worse than none, because a user copies it and blames themselves when it does not work. The note records what they should be when they are written: two or three differing in SHAPE rather than subject — one where the trigger is obvious, one that needs a conversation to pin down, and one that is plainly not a commander at all, so the boundary is visible from the examples rather than only from prose. Marked provisional, so it renders with the draft badge until somebody writes it. That is what the flag is for: this ships on every deploy whether the copy is ready or not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
29d998b6c3 |
a new commander pane explains itself, in skeleton
Starting a commander currently means knowing to open the background-job dialog and arm a watcher from it. That is not discoverable, and it reads as configuration when the real answer is "talk to it" — so the dialog stops being the way in, and the pane explains the way in instead. EmbeddableChat's own empty state is "Send a message to start". True, and it tells a first-time user nothing about what to send. The copy is NOT written, by agreement: the instructions have to describe a flow that does not exist yet, and writing them first produces text that is wrong in a way nobody notices. What is here is the structure, plus the parts already true whatever the flow becomes — what a commander is, and that it begins as an ordinary conversation. Sections carry a `provisional` flag that renders a visible "draft" marker. That is the load-bearing detail: this ships on every deploy whether the copy is ready or not, so a half-written guide must not be able to look finished. Clearing the flag is the last step of writing a section, not a formatting choice. Data rather than JSX, so filling it in later is editing one array instead of hunting through markup — the same shape as the shortcuts registry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f586d748d6 |
ctrl+space opens spotlight, and ctrl+? tells you everything else
Fourth chord for the launcher, and the last move is a return: ctrl-space → shift-space → alt-space → ctrl-space. Every one was the owner naming a real collision, and this one is the interesting direction — alt-space is the GNOME window menu, he rebound the desktop to keep it, disliked what he rebound it to, and would rather move the app than the window manager. ctrl-space was ruled out on 2026-08-20 as "focuses the address bar in Brave". That observation was made before anything preventDefault'ed it, and the trade has changed: rebinding a browser is cheaper than rebinding a desktop. Written down in the file, because if the address bar still wins the key never reaches the handler and nothing in this repository can help — the fix would be in Brave. `!ev.shiftKey && !ev.altKey` matters: ctrl+SHIFT+space is the theme browser, and one chord opening both is the bug that needed a capture-phase listener to fix on the theme side. Verified in the built bundle that the two conditions are disjoint. CTRL+? renders every shortcut from a registry, ported in shape from vimazing's gameInfo.ts — controls declared as data, help screen renders them. Its renderer was a recursive `any` walk, right for a game whose help also carries rules and scoring; here the content is one shape, so the renderer is typed and boring and the value is in state/shortcuts.ts. The registry is deliberately NOT authoritative yet, and says so: the handlers still hold their own conditions, so changing a chord here does not move it. Each entry names the file that implements it, so the pair is one search apart. Making it the source of truth is the configurable-shortcuts work, and doing it now would rewrite three handlers for nothing visible. Also removed a line I put in the theme dropdown yesterday promising "alt+space to search every theme by name". Themes are not Spotlight items — that was an instruction for a feature nobody built, sitting in the UI as though it worked. It now points at ctrl+?, which exists. Two comments naming ctrl+alt+space for the theme browser were corrected to ctrl+shift+space with the older chord noted as still accepted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
bcdc769083 |
commanders are one per line, not a grid
sm:grid-cols-2 xl:grid-cols-3 was reasonable when this panel owned 34% of the screen. It owns part of a 24% column now, so two columns of card inside it left each one too narrow for its title — every card truncated and the cost line wrapped. A grid of one. The card is untouched: same rounded pill, same border and hover, same p-4, same gap-3 between them. It simply stops being asked to share a row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
430f058a6d |
command hq: two columns, with the navigation stacked
It was 16 / 34 / 50 — a category column, a commander column, and the transcript. So half the screen was navigation for a list holding a handful of commanders (one, on this machine) while the only thing anybody reads got the other half. Now the two navigation panels are stacked into one 24% column — commanders on top, categories beneath — and the transcript takes 76%. Categories BELOW the commanders, not above: the commanders are what you came for and the categories are how you narrow them. Above, the filter would push the list down the screen and be read first; below, the list is at the top where a list belongs, and the categories can grow their own scrollbar without taking room from it. The categories panel lost seventy pixels of branding — a Radar tile, "Command HQ", "Watchers & long-running jobs" — which made sense when it owned a column and does not now that it sits at the foot of one. The screen's own header says Command HQ two inches above it. `All commanders` and `Uncategorised` moved INTO the scroll box with the categories. They are the same kind of thing, a filter over the list, and splitting them into a separate nav block above made the second look like a different mechanism. The heading and the + button stay pinned; only the list scrolls — the same rule as the theme dropdown. MIGRATION, and it is the part that could have gone wrong. This key is persisted per account, so the default alone moves nobody who has opened the screen. No appType was retired either, so `hasAppType` cannot see it the way the /chat migration could — the test is structural instead: a horizontal root with three children is the old shape. It terminates because the replacement has two, and replacing outright is safe on a `locked` screen where the only user contribution is column sizes. Same reasoning, and same trap, as ChatHistory/index.tsx. Two of my edits silently did nothing first, because I searched for `officerdb` where the module is `officerdev` and used replace without an assertion. Both are asserted now. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
dd6135cac1 |
favourite a theme from anywhere, and the browser stops fighting the menu
Three reported faults and two additions, all from one keystroke's worth of use. THE MENU OPENED BEHIND THE OVERLAY. The theme pill is a Radix DropdownMenuTrigger, and a focused trigger opens on Space — so ctrl+shift+space opened the browser AND the dropdown behind it. preventDefault could never have fixed it: React attaches its handlers at the root, which bubbles before window, so the trigger saw the key first whatever this listener did with it. The listener now runs in the CAPTURE phase and stops the event dead. THE VIM KEYS DIED WHEN OPENED FROM AN INPUT. Same shape as the Spotlight bug earlier tonight: the guard that refuses to steal keys from a text field was still true after the overlay opened, because focus had never left the field. Opening now blurs, and the guard no longer applies once the list is open — there is no input in it, so there is nothing left for it to protect. Only the GLOBAL bindings defer to a text field now, which is the case it was written for. f STARS WHAT IS FOCUSED, inside the list, so a browse and a shortlist are one pass rather than two. ctrl+shift+f STARS THE CURRENT THEME FROM ANYWHERE, and deliberately without the typing guard the arrows beside it need: word selection is what ctrl+shift+←/→ collides with in a text field, and ctrl+shift+f collides with nothing — no character, no browser binding. Guarding it would only break it in the composer, which is where you are when a theme starts annoying you. The header pill now shows a star when what you are wearing is one of yours — only when true, because a hollow star on every theme is chrome that says nothing two hundred times. The row star in the overlay is a span with role="button", not a button: it sits inside the row's own <button>, and nesting one is invalid HTML that browsers resolve by dropping one of them. useThemeKeys takes the toggle as a callback rather than reaching for it. Favourites are per account and live behind an API, which is app knowledge; this hook owns keys and selection and nothing else. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
bd15a186b5 |
themes: rotate to the one you are wearing, star the ones you like
Four changes for 200+ themes, and one mistake worth recording. ORDERING IS A ROTATION, not a sort. The registry order is the list's only structure — families sit together in it — so lifting the selected theme to the top answers "which am I on" by destroying "what is next to it". Rotating keeps every neighbour and moves the starting point. Both lists use the same `ordered` array, which is the point: "the one below the one I have on" has to mean the same thing in the dropdown and in the ctrl+shift+space browser, or one teaches an order the other contradicts. FAVOURITES are a table, not a JSON column. theme_favorites is a row per star, so a toggle is an INSERT or a DELETE and cannot race with itself; an array in user_settings would be read-modify-written and two tabs would lose one. No foreign key to a theme, because themes are not rows — most are compiled in, the rest are directories discovered at request time — so a star can outlive its theme and the reader intersects with the live registry rather than trusting the table. Favourites-first is a second rotation-preserving pass rather than a filter, so the list can still answer "what else is there". Filtering to favourites only is a separate, explicit toggle. THE INSTRUCTIONS NO LONGER SCROLL AWAY. DropdownMenuContent carried overflow-y-auto itself, so the one line telling you the shortcuts exist was visible for half a second and then gone under two hundred entries — which is the same as not having written it. Header and footer are now siblings of a scroll box instead of passengers in it, and the header names alt+space too. THE MISTAKE: the routes went on /themes first, and that prefix is deliberately UNAUTHENTICATED — the sign-in screen paints in the chosen theme, before any account exists to ask. An anonymous GET answered 500, which was the consequence arriving politely. They now live on /theme-favorites, claimed by the `account` permission, which is core and already owns /user, /dock and /api-keys: a starred theme is the same shape as a dock preference. I then mounted it one line off, in the unprotected block beside the thing I was moving it away from, and caught that by reading rather than by testing. Verified after: /api/theme-favorites is 401 unauthenticated on both verbs, and /api/themes still answers 200 so the login screen keeps its colours. 10 tests on the pure ordering — including the property that makes a rotation a rotation: every adjacency in the original survives it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
0c2ff88c88 |
a commander is a commander wherever it is opened
Fixing a regression I introduced last night. Commander rows in the Live list were changed to open in /chat rather than navigating to Command HQ — right, and it cost the composer its commander controls, because `isCommander` was computed from the ROUTE: `manager.context === 'command-hq'`. So the same commander, rendered on a different screen, silently lost "exit and hand back, then re-arm" — the only fire behaviour a watcher wants, and the one the dialog makes default inside a commander. GET /chat/sessions/:id now reports isCommander, derived from the session's own cwd by the same isCommandersDir already used by the sessions list and /chat/live. The answer travels with the conversation. The composer reads one value, manager.isCommander, true when EITHER source says so — and both are needed. The screen knows when Command HQ starts a commander, before a session or a transcript exists for any route to report on. The session knows once it does, wherever it is opened. Screen-only was this bug; session-only would have broken the brand-new composer, which is where the whole thing starts. Verified on a real commander rather than by reading: 172cdd8c resolves cwd=…/commanders and isCommander=true. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8e181ddf3c |
any key after a recall ends it, and Left is the one that proves the point
A recalled prompt you have started moving around in is a prompt you have adopted, so the next Up must not walk further back over it — the same fault as recalling over a fresh draft, arrived at from the other side. Left and Right are why this cannot be inferred from the text. They change nothing, so any rule watching for edits would miss them entirely, and arrowing into the middle of a recalled prompt is the clearest statement of intent available: you are working on this one now. So the composer leaves the history on any keystroke that is not Up or Down. Bare modifiers are excluded — holding Shift to capitalise the next letter is not editing, and treating it as such would end a recall between two presses of Up. `Dead` is in that set too: a pending accent on a composing layout is not a finished keystroke. leave() clears the stashed draft as well as the position. That draft belonged to the composing session being left, and handing it back after you have started editing something else would paste an older draft over a newer one. Six tests, three of them on the interaction between this and the emptiness rule from the commit before — together they are what stops Up from eating an edited prompt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
02df4ac61c |
prompt history only takes the arrow key from an empty composer
Up replaced what you were typing. The guard was a caret-position test — Up only recalls from the first line — which is correct for a multi-line draft and useless for a one-line one: the caret IS on the first line, so every check passed and a half-written thought was swapped for something from last week. A draft is not recoverable from anywhere and the history is, so the tie goes to the draft. "Only when empty" alone would have made the feature useless, though, and that is the part worth writing down: once a recalled prompt is in the box, the box is not empty, so an emptiness test allows exactly one step back and then refuses. usePromptHistory already knew the difference — indexRef null means composing — it just never told anyone. It now exposes isRecalling(), so the rule is "no text OF YOURS" rather than "no text". Whitespace counts as empty: a composer holding two spaces is not a draft anybody would miss, and an invisible character silently blocking Up is worse than losing it. A draft that merely STARTS with whitespace is still protected. The line tests stay on top of it — in a recalled prompt spanning three lines, Up from the middle moves the caret, because there is a line above to go to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f9dfd05676 |
header cluster and breadcrumb colour
Breadcrumb links rested at duck-forest and hovered to duck-teal; they now sit at the hover colour, so the hover and its transition go with it. One shared component, so the full browser and the dashboard widget both pick it up. The current folder stays duck-dark semibold, keeping clickable and current distinct. Header: the theme control leads the right cluster and names the theme it is wearing rather than showing a palette glyph — with 227 of them, which one is on is worth reading. It takes JobsIndicator's pill styling so the cluster stays one shape, and keeps its colour on --header-fg rather than hardcoding white. The jobs indicators and the rescan button are Super Admin only now. Cosmetic, and the comment says so: /jobs stays reachable by URL and rescan is gated server-side, so nothing here is load-bearing. Uses the same user?.role check UserMenu already makes in this folder rather than adding a second convention. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
cbcd8d65df |
fix accent/secondary foreground derivation; 202 community themes
The nine remaining contrast failures all had the same cause, and it was a real bug in map.ts rather than a limit of the source palettes: --accent and --secondary are both s.high, but their foregrounds were taken from fgRaised, which is checked against s.raised. That is precisely the near-miss the file already documents and fixes for --muted-foreground, one token over. Deriving them against s.high instead rescues all nine (every Solarized variant among them) and is provably a no-op for the official 22 — each already clears 4.5:1 on s.high by 1.3x or more, and ensureContrast returns its input untouched when it passes. Measured all 22 before the change; generate-themes.ts --check reports 0 changes after it. Also: GitLab-hosted repos are now discoverable (one theme lives there, and the raw-URL and default-branch shapes differ from GitHub's), and sourceFor probes a directory named after the theme's own slug, for the packs that nest one directory per theme. An exact slug match is the only prefix tried on purpose — a pack whose variants have names of their own has no single theme that is "the" one, so guessing would be wrong. Every community theme is regenerated in this commit, not just the new ones. aura turned up generated under an older pickAccent rule than its neighbours, because it was ported before that rule changed — the same drift generate-themes.ts was written to prevent, and the reason both halves are written from one source. All 202 now come from one mapping version. Verified afterwards: 227 stylesheets, 227 imports, 227 registry entries, no orphans in either direction. Still out: 14 repos that 404 (deleted or renamed since the site indexed them), grimdark-solarized (no source link at all), cobalt2 (its page links an awesome-list README with no theme in it), and oasis (a six-variant pack with no variant named oasis — porting it means inventing six slugs the site does not list, which is a naming decision). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Sonnet 5
|
861fc4a58b |
add colors.toml and 0x-hex support, rescuing 44 more community themes
Poked at the 62 "no parseable source" skips from the first pass and found two things the pipeline didn't handle: several community repos genuinely ship colors.toml too — some in Omarchy 4's own semantic schema (best case, no derivation needed at all, same quality as the official 22), others reusing the filename for an unrelated flat color0..color15 scheme — and a handful of alacritty.toml files use 0xrrggbb instead of #rrggbb. palette.ts's loadPalette is now a thin wrapper over two exported pieces (parseTomlText, paletteFromRecord) so the community pipeline can attempt the real schema first without duplicating the reader; falls through to the color16 or ANSI-derived paths otherwise. generate-themes.ts --check still reports 0 changes for the official set — the refactor is behavior-preserving there, the lowercase-hex normalization it picked up along the way touched 7 official theme files cosmetically (their source colors.toml has uppercase hex), regenerated for real rather than left inconsistent with their own source. 147 -> 191 community themes ported. Of the original 62 unparseable repos, most turned out to be simply gone (404 on GitHub — repos deleted or renamed since the site listed them); the rest needed one of the two format additions above. 20 themes remain stuck: 16 dead repos, 2 with no repo link at all, and the same handful of genuinely low-contrast source palettes (mostly Solarized variants) where fixing contrast would mean changing the author's actual colours rather than porting them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Sonnet 5
|
a58f4d2b32 |
port 147 community Omarchy themes from omarchythemes.com
The official 22 themes come from basecamp/omarchy's own colors.toml, contrast-checked by generate-themes.ts. A community theme has no such file — it ships per-app configs (alacritty.toml, ghostty.conf) in the older 16-ANSI-slot style, so this adds a sibling pipeline: from-ansi.ts derives the same 24-key Palette shape by role (accent, three background depths, three foreground weights) from those 16 slots, then runs through the same mapPalette + contrast checks the official themes use. Nothing about the official generator changed — verified generate-themes.ts --check still reports 0 changes. port-community-themes.ts discovers each theme's GitHub repo from its omarchythemes.com page, fetches alacritty.toml (preferred) or ghostty.conf, and is idempotent via community-manifest.json so a re-run only fetches what's missing. Community themes get their own registry/index.css marker block, separate from the official GENERATED THEMES block, so the two pipelines can never clobber each other. 121 of 212 attempted made it through cleanly; a second pass tightening accent selection and nudging --input recovered 20 more borderline cases (147 total). The rest failed for real reasons: 62 repos had no parseable colour source, 7 had an accent colour whose own luminance can't clear 4.5:1 against either black or white text, a handful were narrowly under threshold even after the rescue pass, and 2 pages had no repo link at all. Every generated file's header states its source repo and whether it's a light or dark theme. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
b10a49c082 |
an account with no saved sign-in gets a chip you can read, not one you can use
Three chip states now, and the third is a different question rather than a broken version of the second: filled the account you are plain an account you can become — click switches dashed outline an account you can only look at — click shows its last known usage "Has my other allowance come back yet" is answerable from a snapshot, and the machinery for it was already right: a reset time is an absolute instant, and currentLimit rolls a past window forward and zeroes it instead of showing a stale percentage. Phase one was hiding a correct answer. What you cannot do is act on it without a /login, so the chip says that before it is clicked (in its title and in its border) and the panel says it again while you are reading one. Naming the fix rather than the problem: "No saved sign-in — run /login to use this one". Viewing is deliberately NOT a general tab selection. Only an account with no credential can be viewed, because for any other one the useful gesture is switching to it and then reading live numbers — which keeps phase one's invariant intact: if the panel shows a signed-in account, it is THE signed-in account. Switching clears the view for the same reason, so the numbers and the chips can never disagree. Replaces the count line, which was a fact about somewhere else. The staleness line that was already in this file — "Not signed in · as of 20 minutes ago" — now finally has a case that reaches it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
4b2cb3d266 |
the account chips show the whole address, because the local part is the shared half
Two chips both read `andre.padez`. They are andre.padez@gmail.com and andre.padez@pertento.ai — one person's personal and work accounts, which is the entire case this switcher exists for. The chip showed the local part on the reasoning that the domain is what accounts have in common. That is true of accounts belonging to different people and exactly backwards here: the local part is the half they share and the domain is the half that tells them apart. So the strip wraps instead of scrolling, and the address is not truncated. The "N other accounts not shown" line was also lying. It counted stored usage READINGS minus the one being displayed, which since the switcher landed includes accounts whose chip is two lines below — it said "2 other accounts not shown" with both of them on screen. It now counts only accounts with a reading and no saved credential: an old login you can look at and cannot return to, which is the thing actually worth saying. On this machine that is one, jrg.conceicao@gmail.com. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7d7a80782e |
switch Anthropic accounts from the usage pills
The owner keeps a personal account and a company one and moves between them during a day — by what the work
is, and sometimes because one has hit a limit and the work has to carry on. /login handles ARRIVING at an
account. It could not go back to one, because the credential it overwrote was gone.
ai_provider_usage already answered "which of my accounts has room". This answers what immediately follows:
"then use that one". The chips under the numbers stop selecting whose stats you read and start selecting who
you ARE — which turned out to be the useful half of the same gesture, since reading the other account's
percentages was only ever a prelude to using it.
anthropic_accounts holds each login's OAuth object encrypted, keyed (user_id, account_uuid).
One key per ACCOUNT, not one for the table: encryptSecret('anthropic-account:<uuid>', …), so the secret
store mints a separate key each and one leak is one account. Same reasoning that split VAULT_STORE_KEY into
purposes. The uuid comes from Anthropic and survives a re-login; the email is stable too but is editable at
the provider.
What is stored includes a REFRESH token, deliberately — the access token lives hours and the refresh token
is what makes a switch work a week later. So a row plus its key is thirty days of acting as that account.
That was accepted knowingly; the per-account key narrows it, and refreshExpiresAt is a column so a dead
credential gets purged on read rather than sitting here for ever. An expired one cannot be switched to at
all: reveal returns null, because writing an expired credential would sign the owner out with no message.
Capture happens on login AND on every read of the account list. Without that second one this would know
only about logins that went through this dialog, and an account signed into from a terminal would be
invisible to the switcher — half your accounts missing, silently. The switch also captures the OUTGOING
credential first, or switching away from a terminal login loses it.
.credentials.json is replaced wholesale; .claude.json is PATCHED. The second holds the CLI's entire config
and overwriting it would take out every project entry and preference in it.
Owner only, and the isolation is unchanged: getOwnerHomeDir ignores the email it is passed, so every path
here is the owner's. A member's claude reads their own home and none of this touches it. The earlier claim
in this work that the credential was "machine-wide" was wrong — the owner corrected it. What a switch
actually changes is every claude running AS THE OWNER: terminals, task runners, pipelines, the commander.
The spinner is not decoration. A switch rewrites a file and changes nothing visible, so without it the
honest reading of a click is "nothing happened" and the second click is somebody checking. A running turn
keeps the credential it was spawned with, and the response says so rather than leaving the UI to imply
otherwise.
Verified before shipping: capture records the live account with org, plan and expiry; reveal decrypts
byte-identical to what is on disk; /api/claude-auth/accounts is 401 unauthenticated and 403 for a non-owner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Fable 5
|
bd9d26199f |
the ephemeral pane is open when it exists, not when an effect says so
Refresh on /files/...?view=x.m4a came back with the query string intact and no
viewer, and then double-clicking the file did nothing at all. Two symptoms, one
cause, and the second is what made it read as a click bug.
WorkspaceView gave the pane defaultSize={0} and opened it from an effect calling
panel.resize(), so open/closed was expressed twice — the markup said closed and
the effect was meant to correct it. A correction step can be missed, and this one
was: on a deep link isEphemeralOpen is true on the first render, but
workspace.isLoaded is false until /dashboards answers and the early return means
nothing is rendered, so the effect ran against a null ref and returned. Its deps
were [isEphemeralOpen, defaultBaseSize] — one already true, the other a constant
— so it never ran again. URL open, pane at zero width.
Then the inert double-click follows for free: ?view= already held that name, so
setSearchParams changed nothing, so there was no transition for the effect to
react to. The URL being already correct is exactly why the click had nothing to
say.
Now the pane is rendered conditionally with id + order — the same pair
WorkspaceRenderer already uses — and both panels take declarative sizes. There is
no moment where markup and intent disagree, and a deep link is right on first
paint rather than corrected after it. The try/catch that guarded resizing an
unlaid-out group goes with it; nothing calls resize now.
ephemeral-pane.test.tsx asserts the SIZE the group computes, not that the element
exists — a pane at zero width satisfies any is-it-in-the-document check, which is
the failure being guarded against. Five of its six tests fail against the old
implementation, including the load-order one. Full suite: 1316 pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
58615ee5e7 |
/login can hand you the URL instead of opening it here
Opening the link opens it in THIS browser — already signed into whichever account you are trying to move away from. Copying it is how you authorise as somebody else: another browser profile, another browser, or your phone. This dialog exists for a machine with two Anthropic accounts on it, so that is the common case rather than the awkward one. Uses helpers/clipboard, which falls back to execCommand when navigator.clipboard is absent, and reports a failure rather than showing "Copied" over an empty clipboard. Corrected a claim in that helper's own comment while touching it: it said Officer is reached over the tailnet on plain http, as though that were the whole story. The owner browses over https and did when it was written. The http origins are the other ways in, and an install with no certificate has no other way in at all — which is why the fallback stays. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
31cdb93691 |
usage shows the signed-in account only, and says which one it is
Phase one of answering a question the panel could not answer: whose numbers am I looking at. This machine's owner has two Anthropic accounts, personal and work, and both had stored snapshots — so both appeared as tabs. After signing in there was no way to tell from a glance which one was now being spent. The panel was answering "here is usage for two accounts" while the question was "which am I on". So the hook filters to the account marked `current`, and the absence of one now MEANS something: no current row renders as "Not signed in" rather than as whichever tab happened to be selected first. The email also gets its own line instead of sharing one with the plan. Joined as `Team · a@b.c` in a 320px popover, the email is the half that truncates — and it is the half being read. The other accounts are said out loud rather than silently dropped: "1 other account not shown". Knowing one exists and is hidden deliberately is a different thing from wondering where it went. Temporary and a one-line revert by construction: delete `onlyCurrent` in useClaudeUsage and return `all`. The server still serves every account, the tab strip is still in the file, and nothing was deleted — the stored snapshots are a real feature, they were simply drowning the question being asked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8917f36be5 |
/login works in the chat window
Officer authenticates claude with a Claude SUBSCRIPTION over OAuth, and that is a browser round trip: open a URL, authorise, paste a code back. It was the one part of running an agent a browser-only user could not do from the browser — the answer was "open a terminal panel and drive the CLI by hand", which works, and is a strange thing to ask of somebody whose entire session is a web page. It needs no pty. `claude auth login` behaves identically through plain pipes, verified by capturing its raw bytes, so this is an ordinary subprocess with two reads and one write: spawn, read until the URL, wait for the person, write the code to stdin. The parsing is the only non-obvious part. The CLI wraps the URL in an OSC-8 hyperlink escape AND prints it again as visible text, so `https://\S+` returns two URLs concatenated with no separator between them. Stripping the escape wrappers first leaves exactly one. Written against captured bytes rather than against what the terminal appeared to show. Three decisions worth keeping: NOT under /auth. totality.ts exempts that prefix from the permission gate entirely, and correctly — it is where a caller goes to BECOME authenticated. Mounted there, an unauthenticated POST could have started a login as the owner. Verified after moving it: unauthenticated POST /api/claude-auth is 401. On the `chat` grant rather than its own. The pairing is exact: an account that may use the agent must be able to authenticate the agent, and an account that may not has nothing to authenticate. `confined` then carries the rest for free — authorize.ts drops a confined grant for an account with no osUser, which is precisely the account that cannot hold credentials of its own. Nothing Anthropic-shaped is inherited by the child. For the owner those variables point at the local proxy, whose whole job is swapping a shared secret for the owner's bearer token — handing them to a login is how you get a success that authenticates nothing. A member's login runs through setpriv --reset-env as their own Linux user, into their own home, because their turns bill their own subscription and that only holds if the credential is theirs. Pending logins are in memory on purpose: one is worthless once the process holding its PKCE verifier dies, so persisting it would store a row that can only ever be stale. Ten-minute reaper, one per account, and the dialog abandons its own on close so a dismissed dialog does not leave claude parked on a read of stdin. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
55ecbf4fb8 |
the handoff radio was still rendered nowhere, one layer above where it was fixed
"Exit and hand back to the agent, then re-arm" is the only fire behaviour a commander wants, and it is the
dialog's own default inside one. It was missing from the dialog in Command HQ.
The previous fix wired the consumer: isCommander={manager.context === 'command-hq'}, with a comment about
how the prop had never been passed by anybody. The producer was still not feeding it. EmbeddableChat builds
its manager from its OWN props — useEmbeddableChat(params) — and `context` there is a different value from
the `context` handed to useChat. Command HQ set the hook's and not the component's, so manager.context was
undefined, and the radio stayed hidden in the one place it exists for.
Two hooks named alike sitting on either side of that boundary is what hid it twice: hooks/useChat.ts and
EmbeddableChat/useEmbeddableChat.ts, one taking a `context` option, the other a `context` prop, neither
reading the other's.
Found by the owner trying to arm a deploy commander and finding only "stop when it fires", a one-shot,
where a watcher that re-arms was the whole point.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
e1ad680475 |
a commander opens in /chat, where you were already reading
Clicking one in the Live list navigated to /command-hq — out of the screen, into a different route with a different layout, having lost your place in the list you were scanning. I argued for that in the commit before this one: /chat renders the transcript without the category, cost, watcher state or the disarm control. It loses to a simpler argument. A commander IS a chat — same harness, same transcript, resumable by the same route — and being thrown out of the page you are reading costs more than metadata you did not ask for. Command HQ is where you go to MANAGE a commander, which is a separate errand from reading what it just said. Verified rather than assumed, because a commander's cwd is not one of /chat's directory groups: the default-group load misses, and GET /chat/sessions/:id falls through to the by-id scan, which returns all six messages and the real cwd with it. So the detail panel resumes it with no cwd hint at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
ebfa09e067 |
live splits into Agents and Commanders, and the payload says which is which
A commander is a chat by every mechanism it uses, so it turned up in Live beside the conversations somebody is actually having. With one deploy commander that is untidy. With a watcher armed per repo it is a list where the thing you are looking for is outnumbered. Two tabs inside Live, counts always shown. That last part differs from the badge on the Live tab above it, which hides at zero because a standing `0` there says nothing. These two say a lot at zero: `Commanders (0)` is how you find out the watcher is not running, which is usually why you looked. The flag is derived server-side from the cwd, not from a `command_hq_sessions` lookup — every commander shares one directory, so the directory IS the answer, it costs no query, and it is already right during a commander's first turn, before any row exists. It has to be in the payload rather than computed in the panel, and that is the point of the change: the iPhone app swipes between LIVE chats and has no room for tabs. Filtering there needs the server to name them. A deploy commander appearing in that swipe order is precisely what must not happen. A commander row also now opens Command HQ instead of /chat. Same transcript either way, but /chat renders it with nothing that makes it a commander legible — no category, no cost, no watcher state, and no way to disarm it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
6dae3e7a14 |
a commander's transcript was fetched, returned, and then ignored
The pane still showed "Send a message to start" over a bar reading 1 turn · $0.28. The id fix was necessary and was not the cause. useChat seeds its message list with useState(initialMessages ?? []) — read on the first render and never again. ExistingCommander fetched the transcript AND called useChat in one component body, so the hook's first render happened with resume still undefined and seeded itself empty. The messages landed a moment later and the hook had no reason to look. The early `Loading…` return does not help: hooks run above it. ChatPanelWrapper has always avoided this, and the line that does it is easy to read as a loading nicety — `if (selectedSessionId && resuming) return null` sits ABOVE the component that owns the hook, so the hook's first render is its only render, and it has real data. Split the same way here: a fetcher, and a chat mounted once there is a transcript to mount it with. Verified server-side while looking for this: loadClaudeSessionById returns the six messages for 172cdd8c, ending on the commander's answer. The data was always there and always reachable. Only the pane could not see it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
2379260ffe |
the commander pane threw its own conversation away at the end of the first turn
The messages were on screen, streaming, correct. Then the turn ended and the pane went empty under a metadata bar still reading 1 turn · $0.66. Nothing was lost — the pane discarded it. Once the transcript id was known, NewCommander navigated onto it, and CommandHqDetail answered that URL with a DIFFERENT component: ExistingCommander, keyed on the id. So React unmounted the live chat, closed its socket, and re-read the transcript from the API — a file the harness had only just finished writing. What survived was whatever that fetch returned, which was nothing. A permalink is for a refresh, not an instruction to reload. /chat has always understood that: useChat replaces the URL and remounts nothing. This pane replaced the URL and remounted everything. So the pane now keeps the session it started. CommandHqDetail remembers which id came from its own composer and keeps that component mounted while the URL names it, swapping to the resuming component only for a commander opened from the list. Clearing the memory on a real navigation means coming back later still resumes from the transcript rather than remounting an empty live chat. Worse than the empty pane, and the reason this is not cosmetic: the teardown fired at session:claude for any chat where the harness names its transcript early — the START of a turn. A commander's turns run for tens of minutes. The pane would have dropped the stream and shown a reader nothing at all while a deploy rolled across seven servers. claudeSessionId is now also set at session:claude, not only at result, matching the ref beside it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
21b893473d |
a new commander showed "Send a message to start" after answering correctly
The first deploy commander ran, cost $0.66, and reported exactly the right thing — and the pane showed an empty state, because the page was fetching an id nothing knows. Two ids for one commander. `session:init` sets `sessionId` to OFFICER's key and arrives first; `session:claude` carries Claude's transcript id and arrives later. `fileAsCommander` files the row under the transcript id, and `command_hq_sessions` is keyed on it. But NewCommander navigated on `chat.sessionId` — the first one it could see — and then set `filed`, which blocked the correction when the real id turned up. So the URL held officer's key, /api/chat/sessions/<that> 404'd twice, and the transcript was unreachable from the UI while sitting perfectly readable on disk. The transcript id was only ever in a REF, deliberately — the reconnect handshake reads it synchronously — so writing it re-rendered nothing and no caller could react to it. It is now state as well, returned alongside sessionId, with the ref kept for the handshake that needs it. setCategory had the same fault and would have silently updated no row: it was keyed on officer's key against a table keyed on the transcript id. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7a46612f41 |
the handoff watcher was built and never rendered
BackgroundJobDialog offers three fire behaviours and gates the third, `handoff` — exit, act, re-arm — on
an `isCommander` prop. Nothing ever passed it. So it defaulted to false everywhere and the option
appeared NOWHERE, including inside a Command HQ commander, where the dialog's own code makes it the
default.
Everything else was there: the fire rule, `handoffContract`, `armWatcher` reaching the server, and a note
recording that it had run for hours self-re-arming without failure. Only the radio button was missing,
which made a working mechanism look unbuilt — and it is the one a deploy watcher needs, since
`keep-going` never hands back to an agent at all.
Found while telling the owner how to start the deploy commander: the dialog in a commander showed two
options where I had said there would be three.
The fix is two lines and no new concept. `useEmbeddableChat` already receives `context` and passed it
into `useChat`; it now also returns it, and InputArea gives the dialog `isCommander={context ===
'command-hq'}`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
8d476129ea |
an answer that goes nowhere now says so, and one that lands says that too
Second half of the AskUserQuestion report: "when I answer, the agent does not react — I see the bubble for a long time and end up sending a message anyway", intermittently and not reproducible. Two different causes, both invisible from the outside. A DROPPED answer was silent at every step. user-instance discarded the boolean, sendFire does nothing when no sidecar is connected, and the lookup returns undefined for both "no such session" and "not yours". So a lost answer and a slow agent looked identical: a card that does not change. It now warns with the reason, and where a session exists it emits an error into the durable log — the same channel a successful answer uses, so a second pane sees it too, rather than confirming to the browser that clicked. A LANDED answer had the opposite problem. The card goes read-only the moment you pick, but `sent` is local and optimistic while `message.output` only arrives once the harness has produced something. In between there is a real gap, and nothing filled it — so an answered card looked exactly like one that had timed out. It now says "Answer sent — waiting for the agent", which makes the two states different without pretending to know when the agent will speak. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
4e2db3dc2f |
themes: generate all 22 from Omarchy, with contrast as a test rather than a taste
The eleven ported themes declared 34 of an 84-token contract. The missing fifty were every surface
(--panel-bg, --card-bg, --glass-bg), every state colour (--success, --warning, --busy, --info), the
header, the scrollbars and the grid — so they fell back to whatever the base stylesheet or the
previously applied theme had left behind. They also carried thirteen tokens nothing in this codebase
reads (--chart-1..5, --sidebar-*), which is the tell: they came from a shadcn template, not from the
contract in the README beside them.
So "highlights mask the content" and "text fades into the background" were not taste. They were
absence, and no amount of re-picking colours would have fixed them.
Generated now, from Omarchy 4's colors.toml, which is genuinely semantic — three background depths,
four foreground weights, accent, selection, muted, mode — and consistent: all 24 keys present in all 22
themes, checked. One mapping in scripts/themes/map.ts means one place to be wrong, one place to fix,
and an Omarchy update becomes a re-run.
Every foreground is driven through ensureContrast against the surface it actually sits on, and the
generator then re-checks sixteen pairs per theme and EXITS NONZERO on a failure. It found four real
bugs in my own mapping, which is the argument for having written it first:
- `on(fill)` picked the better of two palette extremes without checking either passed; rose-pine's
tones are all mid and came out between 2.2:1 and 4.2:1
- ensureContrast chose black or white by a luminance>0.5 test rather than by measuring. rose-pine's
rose sits at 0.25, so it drove toward white and capped at 3.5:1 where black reaches 6:1 easily
- --muted-foreground was derived against the raised surface but renders on the high one; everforest
landed at 4.44:1 and miasma at 4.00 — near-misses that look fine in a screenshot
- borders were held to 3:1, which would ring every panel in a hard line. A panel edge is decoration;
what must be discernible is a form field's boundary, so --input is checked and --border is not
35 failures at first run, 0 now.
The registry and the stylesheet imports are written from the same list, because the old port maintained
them by hand and drifted — catppuccin-mocha sat in THEMES after its stylesheet was gone. That file is
now deleted; Omarchy renamed it to catppuccin.
Eleven new themes arrive with this: ethereal, flexoki-light, hackerman, last-horizon, lumon, lupine,
miasma, retro-82, solitude, vantablack, white. Duck and Plain are Officer's own and are never generated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
fcdbf02649 |
the platform stops knowing what VNC is
Desktop is a plugin as of today, and this is the half that leaves. sidecar/vnc/, api/desktop/ and apps/Desktop/ are gone from src/, along with the vocabulary that was the real problem. sidecar/protocol.ts had a VNC section: vnc:start, vnc:ensure-password, vnc:stop, four reply variants and two types. sidecar-registry.ts had startVnc, ensureVncPassword, stopVnc, isVncConnected. Four functions and a dozen message types in the platform, describing a feature that is not the platform's — the rule CLAUDE.md states most plainly, and its clearest breach. What replaced them is generic. sendSidecarCommand(kind, cmd) and isSidecarConnected(kind) know that a command has a type and an id and that a reply carries the same id. A plugin's sidecar speaks whatever it likes through them and nothing here has to be edited when it adds a message. The desktop PERMISSION leaves too, and that is the interesting part: it was kind: 'execution', a kind a plugin permission cannot have and never will, because a permission nobody can delegate is a contradiction. The plugin expresses the same refusal as ownerOnly: ['/'] — every path under it denied to anyone but the owner. Verified: /api/desktop, /api/desktop/vnc-password and a path that does not exist all resolve owner-only. registry.test.ts records the round trip rather than just dropping the key from its list. Also gone: the app store's `vnc` entry, which would have offered an older second way to install the same thing against a process PM2 no longer has, and four commented-out mounts left from 2026-08-13. The disconnect-scope test used startVnc as its stand-in for "another sidecar's long-running request". It now uses the generic door, which is the better instrument — that file is about the blast radius of a disconnect and never had anything to do with VNC. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
16dd67a3ca |
plugins: enabling pulls first, so a plugin off for a week comes back current
A disabled plugin keeps its directory, and the directory is what the next start runs. The longer it stays off the more certainly it is stale, and enabling would quietly run whatever was current on the day it was switched off — with every step reporting success, which is exactly how the jellyfin install on alpha re-applied a two-day-old checkout. Deleting no longer has that problem, since it takes the directory with it and installing is always a fresh clone. That left disable/enable as the one remaining way to run old code without being told. The pull is best-effort and the enable is not. `updatePlugin` returns ok:false when a pull is refused, and it is refused for reasons that say nothing about whether the plugin can run: a dirty working tree — every plugin directory on this machine is one — an unreachable forge, or a directory copied in rather than cloned. Enable is the reversible half of a pair with disable, and a switch that will not turn back on because a network is down is worse than one running last week's code. So the refresh reports which of those happened and the enable proceeds regardless; a re-apply that fails falls back to the code already on disk, which was running before it was disabled. Tested by the refusal path rather than the happy one: a directory that is not a checkout comes back having reported "not refreshed", and the error that surfaces is about not being installed rather than about git — which is only possible if the refusal was stepped past instead of returned. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
287cec39d0 |
plugins: enable, disable, delete — and uninstall is gone
Three states all read as "stopped": disabled, uninstalled, and uninstalled-with-the-directory-still- there. Nothing on screen distinguished them, and the one that mattered was invisible — an uninstalled plugin kept its directory, which silently decided what the next install would run. That is how a jellyfin install on alpha re-applied a checkout from two days earlier while reporting success at every step. So uninstall stops being a verb. What it did survives as the first half of deleting: it stops the sidecar, removes the install row and the PM2 entry, unpublishes the copies, and revokes grants naming permissions that are about to stop existing. Delete is offered only on a plugin that is not running — disable is one reversible click, so a live plugin is always two deliberate steps from gone. It opens a confirmation carrying a checkbox, "also delete all its data", unticked and never inherited from last time. Unticked, the directory goes and the rows stay, and they appear in the orphan list further down the same screen. Ticked, the tables go with it, which is the only way to a machine that has never had the plugin. The checkbox picks between two ROUTES, not a body flag on one: a flag can be added to a request by anything that already knows how to call the safe verb, and the difference here is somebody's rows. Grants are revoked either way, which is load-bearing until the permissions work tomorrow: a grant naming a key the platform no longer recognises made the whole permissions screen unsaveable, because the page submits every grant it loaded. Also corrected two rationales that the change made false — the runbook's "uninstall never destroys data" verification table, and npm-deps.ts explaining directory survival in terms of uninstall. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
d6aef4cb92 |
plugins: delete is the second verb, and the list says what it is
Uninstalling a plugin left it under a heading that said "Installed", with a caption saying "not installed". It never moved, so a successful uninstall read as a failed one — and nothing on screen said the directory was still sitting there deciding what a reinstall would run. That mattered more than the wording. Install skips the clone when the directory exists (install.ts findPlugin, fetch.ts refusing an existing dir) and never pulls, so reinstalling jellyfin on alpha silently re-applied a checkout from two days earlier. The provisioning code was not on the machine, jellyfin_accounts was never created, and connecting a server did nothing at all — with no error anywhere, because every step it did run succeeded. Two changes, both UI: - The heading is "On this machine", which is what the list is: every plugin DIRECTORY, installed or not. Delete is what moves a plugin back to the marketplace, and now the screen shows why. - Delete is gated on being uninstalled and is a button rather than a small underlined link. It was previously offered in every state, so two clicks separated a running plugin from its tables being dropped. Uninstall, then delete — the order the buttons now teach. Still true and not addressed here: uninstall followed by install reuses the existing directory as it stands. The detail pane says so now; making install fast-forward a clean checkout is a separate call. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhas
|
c8686ff191 |
channels: add useAtelierRefresh, for the atelier plugin's Generate/Gallery panels
same stable-bump shape as useFilesRefresh. Generate and Gallery are independent sibling panels with no props between them (per the panel contract, components only ever receive panelId), so a finished job reaching the gallery needs a signal rather than the standalone app's onFinished callback prop. |
||
|
pastilhas
|
fe7fe49cee |
chat: stop reassigning a live session to fable
three defects, one shape: the code has two names for "which session is this", and every guard checked the one no caller uses. `fable` is the FIRST entry in the claude-code catalogue, so it is what ModelSelector picks whenever it decides a conversation needs a default. On a key without fable entitlement that lands as a 429, after a real mid-session switch — the reported header read OPUSPLAN → FABLE. 1. the settings default was applied to RESUMED chats. the guard was `!initialSessionId`, and no chat caller passes that when resuming — the id arrives as `options.resumeSessionId`, and ChatPanelWrapper goes as far as `resume ? undefined : sessionKey`. so a user's default model was written over sessions that already had one. both names are checked now. 2. `hasStarted` was `!!preloadedMessages?.length`, which is FALSE for the first frames of a resumed chat — before its messages arrive. ModelSelector reads "not started" as permission to pick a default, so a reload reassigned live sessions during that window. a session id is known on the first render and a chat that has one is by definition not new. 3. harness lock. `crossesHarness` returned false when the current harness was unknown, which reads as "nothing crosses" and is the opposite of what is known — with no current harness, everything might. so a started session offered a switch to opencode while its model was still resolving, a switch that cannot work: it hands a `ses_…` id to `claude --resume` and dispatches to the wrong sidecar. unknown is not permission; the strip locks until the answer arrives. the settings themselves were never wrong — chat.defaultModel reads claude-code/opus on the affected server. nothing was ever reading it for the sessions that got reassigned. |
||
|
pastilhasandClaude Opus 5
|
b14b1bf678 |
green that means "healthy" becomes the success token
Fifteen sites across thirteen files where a raw green stood in for a semantic state: connection dots, health lights, completed-job ticks, the copied-to-clipboard check, the installed badge, the checksum-matched line. All of them meant "on / connected / succeeded", and matched each other only because several people happened to pick the same palette number. The values do move: --success is #16a34a where green-500 was #22c55e and emerald-500 #10b981. That is the point — one token, so a theme can change its mind once, and under plain.css (the leak-detection theme, which greys --success to #404040) these now go colourless instead of staying green. Left alone, deliberately: the confetti palette and the Start button in start-confetti-button, the duck-avatar debug HUD, MetricCard's up/down delta ramp, CommandBlock's check on its hardcoded dark block, the react-email template, and the plain.css comment that names the anti-pattern. Reds are untouched — that is a separate pass, so some ternaries now read bg-success : bg-red-500 until it happens. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhas
|
a53b56bbf6 |
chat header: one green, and it is the token
the connection dot was `bg-green-500` and the bell followed it there to match. both are `success` now — #16a34a where the palette value was #22c55e. the raw palette value was the wrong thing for either to hold. tone.ts already says why: once a view can reach for any of tailwind's twenty-two palettes, green stops reading as "open" and starts reading as "the author liked green here". two elements in one header meaning the same thing should say so by sharing a token, not by two people picking the same number. |