The install layout a machine should have, seasoned owner or not:
~/officerdev/
platform/ the app
data/ DATA_PATH
dockers/ services the app store provisioned
capabilities/ the file-based item store
One root, everything under it. OFFICER_ROOT derives from DATA_PATH rather than being a second variable
that has to agree with the first.
Deliberately not `~/dockers`, where a seasoned user already keeps their own estate — 47 services on this
machine. That separation buys two things. Containers the app store created are distinguishable from the
user's own structurally, rather than by a naming convention we would have to enforce and they could
break. And we never reason about someone else's compose files: the store does not scan, adopt or modify
anything outside its own directory.
That also simplifies "I already have one of these" — it is answered by the user giving a URL, never by
us finding a directory and guessing whose it is. An earlier draft had the installer adopting existing
directories, which meant reading, and potentially writing over, services Officer did not create.
This development machine predates the convention and derives an ugly-but-correct path, since the project
sits inside ~/dockers/officer.dev. Still isolated, still one root. New installs get the clean shape.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
First slice, on a worktree branch so none of it touches the tree the live server runs from.
`sidecar_installs` — server-level, no userId, because a sidecar is one process serving the machine.
That is the line that keeps the model coherent for several users: installed is server-level and
owner-only, configured is per user in service_connections. A member can use Gitea without being able to
install it or point it somewhere else.
`installed` and `enabled` are separate because they answer different questions, which is what gives the
reversible middle ground: disable stops the process and keeps container, config, schema and data.
`completedSteps` makes install resumable rather than merely retryable — the failure mode being designed
against is a half-installed service that neither works nor uninstalls.
The catalogue is data, not code: no functions, no compile-time coupling, because the same shape has to
arrive as JSON from marketplace.officer.dev later. Its test pins it to the real estate — it offers
exactly the processes the light profile excludes, names processes that exist, and claims capabilities
that exist. That last check earned itself immediately: it caught `vault` (no capability at all — it is
EXEMPT because Bitwarden clients carry a Vaultwarden bearer, not a platform JWT) and `notify` (which
does have one, where I had written null).
Docker templates follow the convention already in use across 47 services in ~/dockers: a directory per
service, compose inside, relative bind mounts so data sits beside it, USER_UID/USER_GID as the owner.
An existing directory is evidence of an existing install and must be adopted, never overwritten.
Records what Phase 0 must not foreclose: a remote marketplace, sidecars moving to their own
repositories, and third-party plugins — including the note that catalogue.test.ts pins Phase 0's
invariant rather than the design's, since that relationship inverts once sidecars leave this repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
I concluded a few commits ago that the serve new /api/session pipeline accepts prompts and
never executes them, and kept turns on opencode run. Wrong. Every probe behind that passed
an explicit model claude-sonnet-4-6, and THAT model silently does not run on the new
surface — no error, no event, no assistant message. Drop the field and the same request
completes.
One broken variable in every experiment, read as a property of the system.
Measured on 1.18.16, both machines upgraded today: delivery steer injects into a running
turn (verified, output changed to order), delivery queue runs after it (verified, ONE then
TWO, zero errors), and model selection works via POST /model — just not with sonnet.
So the fork is reopened and worth taking, targeting the new surface rather than the legacy
message path, which generates fine but has neither steer nor queue. Blocked only on why
sonnet dies there while working under opencode run.
Third time this project has hit the same trap: opencode accepts input it does not honour
and says nothing — directory in the body, location.directory that never existed, now model.
A probe that changes one thing and sees nothing has not learned the feature is missing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The serve has a second, newer API surface nobody here had looked at, and it publishes
exactly what the parity doc calls impossible under stdin ignore: delivery steer and queue
on POST /prompt, an interrupt that does not tear down, and a per-session event stream with
an after cursor — the durable-replay machinery officer hand-built for claude, as a
primitive. That would have made migrating obvious.
It does not execute. A prompt is accepted with an admittedSeq, stored, emits
prompt.admitted and prompted, and then never steps. Ruled out separately: the model, the
permissions (build is *:allow, no pending requests), the per-request location (the surface
is location-scoped via header or a deepObject query, supplied everywhere, no change), and a
config gate. The legacy POST /session/id/message?directory= generates fine in 17s, so the
serve itself works — only the new pipeline is inert. session.next.* is the tell.
And not a version problem, which is the part everything here had backwards: this Mac runs
1.18.11 and alpha runs 1.17.9, measured. The dead pipeline was tested on the NEWER binary.
The original "this server runs 1.17.9" meant alpha and was copied to a machine where it was
false; corrected in runner.ts and the test.
So building against it now would produce code that looks finished and does nothing, which
is the failure mode this project keeps rediscovering. One request reopens the question
after any upgrade, and the doc names it.
Also de-flakes the lifecycle tests: they spawn real processes, and a fixed sleep(750) went
red once on a machine busy running these probes. Presence assertions poll now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B8 done, so every defect that made opencode behave wrongly is fixed. Notes what that does
not mean: bucket 1 is capability gaps, and the visible ones are downstream of the phase 2
fork, which is still unstarted and still Andre to call.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The bucket-0 table had no status anywhere; it lived in the report docs, which means the
list itself still reads as eight open defects. Says B1-B7 are done and where.
Also corrects B7 in place: the table describes the spurious cut-off only, and the same
default was mis-adopting the session into the wrong harness entirely.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Agreed in conversation, nothing implemented. Light stops being a variant and becomes the baseline —
chat, terminal, file browser — and the other fourteen sidecars arrive by the user asking for them from
an app store, eventually including sidecars the user did not write.
Mostly not a rewrite, for three reasons already true: every API route stays mounted regardless of which
sidecars run, officer already spawns nothing, and service_connections already solves the multi-user
case. What is new is provisioning, per-sidecar schema, and persisted install state.
Docker: officer is the installer, never the owner. Real compose files in the user's own directory,
started as him, found again by label. `docker compose down` works, and the containers outlive Officer.
Per-sidecar schema is right here specifically because third-party plugins are a real goal, and the
dependency graph makes it tractable: measured across 19 schema files, every sidecar depends on auth.ts
and nothing else, with no sidecar-to-sidecar edges anywhere. So the plugin contract is "you may
reference users.id" — which also makes full uninstall well-defined, since nothing else points at a
plugin's tables.
service_connections stays core and shared rather than per-service, because it already does the part
nobody would get right alone: a NULL url means "inherit the instance", so the owner's row is the
instance and members hold only their own credential, making "members never see the instance URL" a
property of the schema instead of a filter someone has to remember.
Records six open questions rather than settling them, including plugin migrations, ID namespacing for a
marketplace, and where plugin-specific config lives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The review was written as a handover; it became a fixed tree instead. Records what
landed, including the two leaks that only showed up while fixing it, and leaves the
original reasoning untouched so it still reads as the argument it was.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 1 accepted and phase 2 answered well. One real defect: the supersede path in
runOpenCodeTurn kills a stale turn without marking it, so the dead process late-fires
finish() against the turn that replaced it — committing a false "OpenCode exited" to
chat_session_events, deleting the live handle from `running`, killing the stop button
and orphaning the process.
Predates this pass; reported now because e8bd946 is what made the map load-bearing.
Reproduced with a stub binary rather than argued — the transcript is in the doc.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Investigation notes, written as they were gathered rather than after the fact. No code changes.
Covers how a sidecar comes into existence: PM2 peer, dials in to /api/sidecar/register, reports an
ephemeral port, officer proxies to it. Officer spawns nothing — the only startup problem left is
ordering, handled by waiting on a capability rather than failing the first request.
The finding worth having: `sidecar/claude/` is TWO processes, and they register as different sidecars.
`claude/index.ts` is officer-anthropic-proxy and registers capability `proxy`; `claude/user-instance.ts`
is officer-agent and registers capability `claude`. So `isConnected()` — defined as "a sidecar with
capability proxy exists" — means the Anthropic proxy is up, not the agent, which is not what the name
suggests. It has no callers today, so nothing is misreading it yet.
Marks what is unverified and what is still open rather than presenting the lot as settled: the
bind-read-release race in getFreePort, whether the `PORT ?? 5000` fallback is reachable, what a partial
boot looks like, and whether the sidecar-side boilerplate is worth factoring the way create-proxy.ts
factored officer's side.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Implementation report for whoever wrote opencode-parity.md and opencode-phase0-review.md: what landed,
the three places the specs were wrong and how the reproduce-first rule caught each, the three places I
deliberately did not follow them, and what is unverified.
Phase 2's blocking question is answered in full — the serve takes a per-request `?directory=`, so the
coupling is gone in both architectures. The migration is not started; that decision is framed in
opencode-serve-path.md and left open.
Flags `opencode:list` as the one new capability whose happy path is unproven, and B7 as newly more
masked: the B2 fix makes the client send `model` more reliably, which hides the spurious cut-off rather
than removing it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 1 item 7, done in the order the parity doc asks: read the dead design into a note, then delete it.
`docs/opencode-serve-path.md` records what `event-mapper.ts` and the SSE half of `client.ts` did, and
what a rebuild would want back from them — the delta model and tool-state transitions, which are exactly
parity Phase 3's token streaming rather than new work.
Deleted: `event-mapper.ts` entirely, and `subscribe`/the shared `GET /event` SSE loop, `createSession`,
`postMessage`, `abort` from the client, plus `isServerHealthy` from server-manager. All had no callers.
`client.ts` goes 200-odd lines to 99. What stays is the REST reads the chat list and transcript use:
listSessions, getSession, getMessages, deleteSession, renameSession.
While in there, Phase 2's blocking question turned out to be cheap to settle, so it is answered rather
than left open. The review asked whether the serve can take a per-request directory, since without one a
serve-based turn path would reintroduce the single-directory coupling that shelved this work:
POST /session?directory=/tmp/oc-phase2-probe -> directory: "/tmp/oc-phase2-probe" honoured
POST /session with directory in the BODY -> directory: "<serve cwd>" ignored
It is a query parameter on every /session* route. So the coupling is gone on both architectures and the
blocker is cleared. The note does NOT start the migration: which of the three options to take is a
product call, and it lays them out rather than presuming one.
The first probe put `directory` in the body and appeared to prove the opposite. Recorded in the note,
because it is the obvious way to test this and it gives a confident wrong answer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 0 accepted except B4, which is reopened: flipping images to false made the metadata honest but
nothing reads that capability, so the composer still accepts a drop and the image is still discarded
before the model sees it. The defect described a user-visible lie and the lie is unchanged. Gate the
composer on the flag, or plumb images through — the first is the Phase 0 one-liner.
The cwd question is answered empirically rather than argued. Against opencode 1.18.11: --dir anchors the
agent's file operations, not just the process cwd, and the anchor survives a four-step turn with a write
in the middle. So the single-server constraint that shelved this work is already gone — it went away when
turns moved off the serve to `opencode run --dir`.
Two consequences. Per-directory servers are unnecessary; don't build them. And the injected AGENTS.md
telling the agent its working directory is safe to delete — it points at a system prompt the run path
never sends, and --dir does the job it was standing in for.
Phase 2's fork also narrows: moving turns onto the serve would reintroduce the original coupling unless
the serve takes a per-request directory, so that is the question to answer, not why it was replaced.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
22bcd7d fixed both, and found the fix this document suggested was written against a field that does not
exist: opencode 1.17.9 returns `directory` at the top level, not `location.directory`, and sends no
`metadata` at all. The type declared two fields the server never returns, which is the single cause of
both defects.
Worth recording rather than quietly editing, because it generalises: the surveys behind this document
read types and call sites, not a running server, so every field name in it is a hypothesis. The
'check the installed version first' warning was the load-bearing part of the handover, not boilerplate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phases 0 and 1 only, phase 2 is a decision, and open /chat first to confirm B1 before trusting the rest.
All of it was already in the document, near the end, which is not where someone handed a file starts
reading.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phases 0 and 1 are implementable as written; phase 2 is a decision and should not be handed over as
work. More importantly: reproduce each defect before fixing it. The B-list came from read-only surveys
and only the event-path claim was re-verified at source — one of those surveys reasoned from a dead file
for part of its report, so a confident inventory here is not the same as a checked one.
B1 is the cheap provenance test: open /chat and look. Either no OpenCode session is listed, which
confirms the survey was reading the current tree, or one is, and the whole list needs re-checking.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three read-only surveys — the Claude sidecar as the reference, the OpenCode sidecar as it stands, and
every officer/frontend branch on harness. No code changed.
The headline is not a missing feature. OpenCode sessions never appear in the chat list at all: the list
filters on `metadata.officer.cwd`, and the only writer of that tag has zero callers, because sessions are
created by `opencode run --dir` rather than the API that would tag them. Resuming one is worse — the
model is dropped between the resolver and the chat hook, so a `ses_…` id reaches `claude --resume`. That
is wrong-harness dispatch, not degradation. Eight such defects are catalogued before any parity work.
Everything else hangs off one decision: OpenCode turns are a one-shot subprocess with `stdin: 'ignore'`,
while Claude turns live inside a persistent streaming session. Token streaming, mid-turn injection,
background tasks, live-session enumeration and reattach-by-id are all downstream of that, and the serve
that could support them is already running and used only for CRUD. The doc refuses to plan past that
fork until someone establishes why the serve-based turn path was replaced.
Four buckets rather than one list: broken now, Claude-has-it, neither-has-it, and what OpenCode has that
Claude does not — the last because it is what disappears in a project framed as catching up.
Thinking is out of scope for both harnesses by decision, and the selector is hidden rather than
implemented: it renders today and does nothing on either path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
IDLE_TIMEOUT_MS dropped to 30s, a background ticker started, the tab closed. Officer logged the release
thirty seconds later and the job ticked straight through it — the exact point where deleteSession used
to call _claudeKill. Constant reverted.
Also worth writing down: restarting officer does not test this. The process dies outright and
releaseSession never runs, so that only exercises adoptOrphanedSession, which already worked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer's hour-long idle timer was doing two unrelated jobs: collecting its own in-memory binding, which
is its business, and terminating the agent, which is the sidecar's. It could not do the first without
the second, because `unsub` was a closure reachable only through `kill`.
So a browser that went away killed a live agent an hour later — including one the sidecar had
deliberately protected. The sidecar already refuses to collect a session that is mid-turn or holding
background tasks: `task:started` disarms its idle GC, and `armIdle` re-checks and re-arms rather than
firing once. Officer had no view of any of that. A laptop running out of battery overnight took a
`run_in_background` job with it for no reason.
`detach` now sits beside `kill` on both streaming handles, and `_sidecarUnsub` — declared and called for
a long time, never once assigned — is populated at all three sites. `releaseSession` unsubscribes and
forgets the record without killing; the idle timer points at it. `deleteSession` is unchanged, so an
explicit disconnect still ends the session.
The third assignment site was not in the plan: `adoptOrphanedSession` sets `_claudeKill` but nothing
else, so an adopted session that later idled out would have dropped its record while the listener stayed
subscribed — a leak of one per adopt-then-leave.
No double subscription: releasing unsubscribes first, so a returning browser either adopts with a fresh
listener or starts a first turn with none behind it.
Step 1 of docs/chat-session-lifetime.md. Step 2 (a list verb, so running sessions can be found after a
restart) is still open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Investigation only, no code. The sidecar already protects sessions with background work in flight
(pendingTasks disarms its idle GC); officer's hour-long timer knows nothing about that and kills them
anyway, and does not survive its own restart. Plan is to have officer release its binding instead of
killing, and to add a list verb so running sessions can be found after a restart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The client half exists in monorepo-mobile as of f29774a, with OffChat as the
proof of concept, so this document is no longer purely forward-looking. Adds a
section covering what shipped, the two places the advice here was wrong about
the client — one key per app is not possible on mobile (shared-session puts one
credential in front of all nineteen apps), and signout was never the problem,
distress signout was — and two decisions worth a second opinion: clearing the
credential on 401 only, and leaving the traded-in JWT to expire rather than
blacklisting it, because that handler clears vault tokens keyed on the user.
docs/mobile-api-keys.md — what the server accepts, what changes in
monorepo-mobile, and the 401-vs-403 distinction, which is the one that
bites: clearing a good key on a 403 turns a member's missing capability
into a logout loop they cannot escape.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
a user can mint a long-lived key for an app or a device instead of
carrying a 30-day session, so multiple logins on the mobile apps are
per-device revocable rather than one shared token.
identity was being decided independently in userMiddleware and
originScopeMiddleware, each verifying the token itself. teaching only
one of them a new credential format is how those two stop agreeing, so
both now call resolveAuthToken and neither knows what a bearer string
is. verified: a member's key returns the same status as their jwt on
every route tried, 403s included.
a key carries its holder's full authority — not an escalation, it
equals what the password could already do. scoping wants a scopes
column, not a change here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CLAUDE.md asserted "single-user is a hard invariant, not a stage" while
users held six rows and role_capabilities held grants. Every doc that
repeated it is corrected here, in prose and in the code comments that
carried the same claim.
The accurate statement is narrower: one owner who bypasses every check,
other accounts holding only what their role is granted, and a set of
capabilities — terminal, chat, files, tasks, items, desktop, browser — that
are structurally ungrantable because they execute as the owner's OS user.
TODO.md gains a Multi-user section for what the read turned up: no way to
create a second account, dashboards.id colliding across users, authorize.ts
untested, pty/vault/opencode taking no identity, Radicale still owner_only.
claude-sidecar-isolation.md's open question is answered rather than left
open — the per-email spawn model is dead weight, because chat is an
execution capability and no second account can ever reach it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
section 9 now carries a concrete instance of its own argument: a test found a bug that
two careful readings of the file had not, in code written three days earlier to prevent
exactly that failure. also records the two bun/testing-library harness facts that cost
more than the fix did, since both present as an unrelated file breaking for no reason.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Records the pattern that came out of the refactor (path segment vs query param
vs stays-a-button), the grep that re-checks it, and the fact that BackButton —
which this section named as a standard building block — was dead and is gone.
Also folds in the two selections the audit never listed: the email folder and
the Soulseek room/peer rails. Neither was in the findings table; both were found
by sweeping for useGlobal<//useState after the listed rows were closed, which is
worth recording as the reason the table alone was not enough.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Jobs step deep-link: skipped, and measured first — selectedKey is plain
useState, not a channel, so it breaks none of this document's rules. The only
thing anchor semantics would buy is a deep link nobody asked for.
Preview slug: void, there is no Preview app.
FileBrowser widget: stays local, and M4 turned that shrug into a rule — only a
workspace guaranteed to host one browser may own the address bar.
Phases 1-4 are now closed except H4 and the New Chat button, both of which
live in the chat nucleus.
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>
Dock, Header and the mobile sheet were computing active state from
useLocation with two copies of the same startsWith helper. react-router's
NavLink already knows. end is set for Home only: without it NavLink treats
'/' as an ancestor of every route, and with it on the others a detail route
would lose its highlight.
Segment matching is stricter than the string prefix it replaces, which is
what was meant all along.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/plans/:name, no redirect guard: the bare route is 'no plan open', which is a
real state, so the auto-select-first effect is deleted rather than turned into
a Navigate. The picker stays a native select — chrome for one document, not a
master list — but it navigates instead of setting state.
Reading the server route for this turned up a path traversal: hono
percent-decodes params, so GET /api/plans/..%2F..%2Fsecret reached
join(plansDir, '../../secret.md'). basename() the param.
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.
task-logs was a clean move — the detail fetch already keyed off the id, so only
its source changed. activity needed one decision: its two row kinds stream
through different query params, so the url carries the id and the screen derives
task= or path= from the registry row. the sse effect now depends on that derived
string rather than a fresh object, so the 3s poll cannot re-open the stream. an
id that has left the registry says so instead of waiting for output forever.
/activity also had no page-title rule and read 'Officer'.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/tasks, /skills and /processes are one component, so one route pair each and the
rows become links. drops the auto-select-items[0] effect: the bare route is the
list with nothing open, which is a real state. editing and the just-created flag
move to ?edit=1 / ?new=1 — a link row cannot reset them on the way out, and
deriving them means navigating to another item clears them for free.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/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.
Five settings pages moved from a `*_SELECTED` global to `/settings/:page/:section`. The
sidebar entry is a react-router `<NavLink>` rather than a button holding the key in its
onClick closure, so a section is linkable, cmd-clickable and gets its active state from the
router; each page renders one `SettingsRoute` guard that canonicalises both the bare route
and a section that does not exist.
Integrations needed more than the shared factory. It builds its own sidebar, and it kept the
Enterprise/Personal tab in a second global — which is why a deep link to a Personal section
could never have worked: the link set the section, the tab stayed on Enterprise, and the
content pane said "Select a section" about a section that existed. The tab is derived from
the section key now.
Also removes the `/settings/resources` menu item (audit M8) and its two locale keys: there
has never been such a route, so it bounced to the catch-all and out to `/`.
pastilhasandClaude Opus 5