on a fresh server an Admin granted files, chat and terminal reached none of
them. the grants were right, the linux account existed, the named acl entries
were on the home — and the file browser still raised EACCES.
a posix acl mask is not independent of the mode bits. chmod recomputes it from
the GROUP bits, so a directory closed to 700 gets `mask::---`, which clamps
every named entry to nothing. the platform's grant survived as
`user:pastilhas:rwx #effective:---`: present, correct-looking, and inert. it
reads as a working acl in every place anyone thought to check.
ensureOsUser already knows this and orders itself correctly — chmod, then
setfacl, with a comment saying why. verified that order is right by running
both ways on the affected host: chmod-then-setfacl gives mask::rwx,
setfacl-then-chmod gives mask::---.
what it cannot account for is the steps AFTER it, each of which creates a
directory and then closes it: .ssh at 700 from the key setup, .config and
.local from the claude installer. each inherits the default acl at creation
and clamps its own mask a moment later. the correlation on the live host was
exact — every 770 directory had mask::rwx and every 700 one had mask::---.
so the mask is re-asserted at the very end of provisionOsAccount, recursively,
and nothing else is touched: the named entries were never wrong, and
re-granting them here would hide it if they ever were.
non-fatal if it fails, like every other side effect in that function. but it
is the difference between an account that works and one that only appears to.
repaired on the affected server by hand first, and confirmed: home readable by
the service user, zero `effective:---` entries left under it.
Found while pushing chat_notification_prefs. Harmless — eight extra
statements, no prompt, no data touched — but the database CLAUDE.md told
the next person to expect only the two pk_music_now_playing lines and to
treat anything else as their own change, which is no longer true. Both
corrected; the fix itself is deliberately not done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
--resume is scoped to the working directory: Claude Code files transcripts under
~/.claude/projects/<slugged cwd>/<id>.jsonl, so resuming from anywhere else fails
with 'No conversation found with session ID' — exit 1, before any output.
Conversations created before the New Chat directory picker carry no cwd, fall
back to HOST_HOME, and could therefore never resume: every message died the same
way, the banner said only 'exited with code 1', and the exit line claimed
stderr=<silent> while the CLI had printed the reason plainly.
The transcript knows its own directory — every line carries cwd — so it is read
from the file rather than guessed, first line only, since these reach 100 MB. An
explicit cwd from the caller still wins. When the same id exists under two project
dirs (a checkout that moved: officerdev/platform and officer-dev/platform both
hold one here) the newest wins and a vanished directory is skipped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
the browser bell and phone push are now two subscribers to one signal. both
ask shouldNotify(); neither owns the rule.
deliberately a second subscriber rather than a branch inside notify-delivery.
the two channels share only the question "does this account want to hear about
this" — the browser needs an open tab and sends the chat's real title over a
loopback socket on the owner's own tailnet, the phone needs no tab and must
send NO title, because that hop goes through apple. one function doing both
means an `if (isPush)` at every step, and the first thing to go wrong is a
title leaking because the branch was missed in one place.
two codes, officer/core:chat.turn-ended and chat.input-needed. the route is
written out with its scheme rather than derived from the target: the hub has
no chat screen — chat is Butler, a sibling app — so these deep-link OUT over
officer-chat://, and two of the suite's twenty-one schemes already break the
officer-<app> pattern (officer-videos, officer-readaloud). deriving that works
until it silently does not.
`thread` interpolates now, so `chat:{id}` groups per conversation. a static
thread forces a choice between "three pings from one chat collapse" and "two
busy chats stay apart", and the wrong answer is that every chat is the same
chat.
dropped officer/core:agent: chat.turn-ended supersedes it and its route
pointed at officer://chat/{id}, a hub screen that does not exist.
the banner cannot name which conversation. a chat's title is content and
content does not travel; it says what happened, and tapping opens the chat,
which is where the name lives.
review of 73cdc2cb before building the phone half on it. three changes, and
the third is the one that matters for mobile.
1. "every end of turn" was silent when the agent asked you something.
the two kinds are disjoint at the source: turn-ended fires on
result/error/stopped, input-needed at a plan or question gate — which PARK
the turn and never emit a result. matching them one-to-one meant whoever
picked the most inclusive setting got nothing for the most urgent event.
every_turn is a superset now.
2. the preference is keyed on (user_id, session_id), not session_id alone.
the route skipped an ownership check on the reasoning that a preference for
a session you cannot reach is inert. it was not: delivery targets the
userId the sidecar reports while the preference was read globally, so any
account holding `chat` that knew a session uuid could set 'none' on someone
else's conversation and switch off their notifications, or every_turn to
make their phone buzz all night. surrogate id plus a unique INDEX rather
than a composite primary key, which drizzle-kit re-creates on every push.
3. the decision moved out of the browser socket into notify-decision.ts.
it lived inside notify-delivery.ts, which was fine while the browser was
the only listener and stops being fine the moment push subscribes to the
same signal. two copies of the rule drift, and the symptom is a bell and a
phone disagreeing about one conversation — close to undebuggable from
either end. both channels ask the same function now, and the rule is pure
so it is tested without a database.
the rest of the commit reviewed well: the ws upgrade is authenticated AND
permission-gated, there is a registry entry so totality passes, the list query
is batched rather than per-row, reads are defensively caught, and
Notification.requestPermission is requested lazily on opt-in.
alpha was missing the table entirely — reads degraded via .catch but the PATCH
would have 500'd. pushed there too.
Client half of the per-chat notification preference — DetailBar gets a bell
dropdown (every end of turn / only when input is needed / none), a global
useChatNotifications hook holds one connection to /api/chat/notify/ws for
the whole session so a background chat can still ring the bell and fire a
browser Notification, and the session list shows a badge on any row set to
notify. The server side (schema, the notify-delivery socket, the sidecar
signal at turn-end/plan-gate/question-gate) landed already in 5cba1b65,
swept in from a concurrent session sharing this working tree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
reported from the field on the first real push: it failed with BadDeviceToken
and the server deleted the registration. the build was production-signed and
the row said sandbox — a configuration mismatch, with the device and the app
both perfectly fine.
pruning there destroys the evidence. the phone re-registers on next launch,
the row comes back looking healthy, and the next send fails identically; you
can lose a day to that loop without ever seeing what is actually wrong.
so the one set becomes three. Unregistered/UNREGISTERED/NOT_FOUND prune —
apple and google are saying the app is uninstalled. BadDeviceToken,
DeviceTokenNotForTopic, TopicDisallowed, INVALID_ARGUMENT and
SENDER_ID_MISMATCH are OURS: the row is kept and the log says what to check.
everything else is transient and still counts toward three strikes.
INVALID_ARGUMENT was the sharpest one. it is how fcm reports a malformed
MESSAGE — including a non-string in `data`, which is the mistake this codebase
is most likely to make and already has a test for. deleting on it meant one
bug in the payload builder would wipe every android device from the registry
on a single send, presenting as "android push stopped working" with nothing
left to explain why.
misconfigured is also not counted as a strike. not deleting is not enough on
its own — a persistent mismatch would reach three failures and delete the row
anyway, which is the same bug with a slower fuse.
the apns log now names the mismatch rather than the reason code, since the
code alone sends people to look at the device: it prints the row's environment
and topic and says to check the SHIPPED artefact rather than the intermediate
build, which is exactly where this one hid.
reported from a fresh install: ENOENT spawning radicale, over and over.
two bugs, and the second is the worse one.
`spawn('radicale')` resolves against the PATH THIS PROCESS STARTED WITH, and
under pm2 that is a login-less minimum with no ~/.local/bin. the same trap has
now bitten `tea`, the plugin dependency probe and this, so the search path is
explicit here rather than inherited: ~/.local/bin, /usr/local/bin, /usr/bin,
/bin, then whatever pm2 supplied. /usr/bin is listed even though it is
normally present — it is where the apt package lands, and a PATH mangled by a
shell profile should not break the supported install.
falls back to `python3 -m radicale`, because radicale is a python package: a
pip install --user without ~/.local/bin on PATH, or a distro shipping the
module with no wrapper script, both leave it importable and unfindable. the
module is the thing that matters.
the second bug: startRadicale runs at module top level, so the ENOENT threw
and killed the sidecar, and pm2 restarted it forever. that is the opposite of
what the backoff inside it is for, and it took /_health down with it — so the
one endpoint that could have said what was wrong was the one thing not
answering. a missing dependency is now a value the caller handles: the sidecar
stays up, /_health returns 503 with the install command, and `installed:
false` distinguishes "never installed" from "crashed and backing off". both
are 503 but only one is fixed by waiting.
resolveRadicale takes an optional PATH so the null branch is tested rather
than reasoned about. verified the happy path live: radicale launched, sidecar
registered, zero restarts.
sketched the same day push landed, because push is the piece that makes it
possible at all — there is no other way to reach a sleeping phone.
more of it exists than expected: the wake channel, a working maplibre map with
clustering in the photos plugin, and headscale already reporting online and
lastSeen per node, which covers laptops without an app at all. what is missing
is a table, an endpoint, some app code and a panel.
what it can never do is stated up front rather than discovered later. apple's
offline finding works because a billion strangers' devices relay a lost
phone's bluetooth beacon. there is no self-hosted version of a crowd. off-grid
gets you last-known-position; powered-off gets you nothing.
two things i expect someone to get wrong, so they are called out above the
schema:
- do NOT key location on the push token. apns tokens rotate, the registration
path is already an upsert because of it, and a history keyed to one silently
forks into two devices. this needs a stable on-device uuid and a `devices`
table that is not push_devices — which is worth building anyway, since the
push registry currently has no stable device identity at all.
- store accuracy and draw the circle. ios returns 3km fixes when it is being
cheap, and rendering one as a confident pin sends someone to the wrong street.
the sharpest open question is not technical: the owner bypasses every
permission check by design, so on a family server the owner can see a member's
location structurally, unless location is given an explicit exception. that
falls out of the architecture rather than out of anyone's intent, so it should
be decided deliberately.
retention likewise. a location table is a complete movement record, apple
deliberately cannot build one, and self-hosting means choosing to. the rule
belongs in the design, not in a settings screen added afterwards.
the substance was in plugins/CLAUDE.md marked "DESIGN, NOT BUILT", which
stopped being true the same day it was written — load.ts reads them, publish.ts
copies a plugin's in on install, and claude-manager compiles them into every
session. moved to docs/affordances.md and corrected; plugins/CLAUDE.md keeps
the plugin-specific part and points here.
the new part is a third test, earned today by nearly failing it twice: CAN IT
BE FIXED INSTEAD? an affordance is for something irreducible about the
surface, and a defect is not irreducible.
both candidates drafted today failed it. "links open in the same tab" was one
missing line in MD_COMPONENTS. "AskUserQuestion never returns an answer" was
true when the code comment was written and already fixed by the time i read
it — that one would have shipped a permanent instruction to work around a bug
that no longer existed, in a file whose whole purpose is to be believed
without checking.
names the failure mode: an affordance describing a defect calcifies it. once
there is a document explaining the workaround, the defect has a rationale, and
the rationale outlives anyone's memory that it was a bug.
also records two things that are not built and read as if they were: nothing
is scoped, so every affordance is in every conversation, and affordanceBlock()
has exactly one caller — an opencode turn gets none at all.
officer is a single-page app, so a same-tab navigation to an external url
unloads it — tap a link in a message and you come back to a cold boot with the
scroll position and anything mid-flight gone.
`a` was simply absent from MD_COMPONENTS, so every link rendered as a bare
anchor. all four ReactMarkdown call sites in MessageBubble share that object,
so one override covers assistant messages, user messages, tool output and the
collapsed blocks.
noopener noreferrer with it: a bare target="_blank" hands the opened page a
live window.opener back into the app. target is set AFTER the prop spread so
raw html in a message cannot override it with _self.
putSecret/getSecret, `bun run secret:set`, and notify taking its credentials
from the store with env as the fallback. this was described two messages ago
as a later thing; it is about fifteen lines and it was blocking the honest
answer to "where does the .p8 go", so it is done.
getKey was the wrong door for anything supplied from outside — it MINTS a
random 32-byte value when the purpose is absent, which for a foreign
credential means silently authenticating to apple with a fake. getSecret
returns null instead, which is what lets the env fallback work.
putSecret retires the previous row rather than deleting it: a mistyped paste
over a working key should be recoverable, and retiredKeys already exists for
that shape. one transaction, because the partial unique index means the retire
has to land before the insert.
the CLI reads stdin and has deliberately no --value flag: a secret in argv is
in shell history, in ps output, and in any audit log that records command
lines. offering the flag would make the convenient path the leaky one. it
prints a length and the last four characters, never the value.
also `bun run notify:test`, which fires officer/core:test at a registered
device. the sidecar's port is ephemeral, so it now writes its address to
data/notify-server.url on boot and removes it on clean shutdown; the CLI
treats an unreachable address as "not running" rather than trusting the file,
because a crash leaves one behind.
the script says what actually happened, because the day-waster here is that a
send with nothing configured returns success and delivers nothing — it refuses
up front when channels is empty, and calls out sent:0/failed:0 as "no device
registered" rather than letting it read as success.
verified end to end with a p-256 key generated locally and then deleted from
the store: zero APNS vars in .env, sidecar reported channels: apns, and the
send reached the channel. store is back to jwt and offscale only.
env is the interim. the secret store's own reasoning applies almost verbatim:
bun auto-loads .env into every pm2 process, so the .p8 is readable from
/proc/<pid>/environ of twenty of them. officer-music has no business being
able to read a key that can push to the owner's apps forever and never
expires.
the obstacle is not a missing purpose string, which is what it looks like from
the outside. getKey(purpose) GENERATES a key and returns it — there is no
setter, because everything in the store so far is something the platform
minted itself. the .p8, the key id, the team id and the fcm service account
all come from outside, so this needs putSecret and a decision about who may
call it. same for DISCORD_WEBHOOK_URL and every plugin credential still in env.
recorded in TODO.md and in the design doc rather than left as an intention.
the sidecar now sends what the design describes.
producer contract: { code, userId, n?, id? }. validated on the SHAPE of the
code, never against the catalogue — a producer firing a code the mapping has
not caught up with is sending a real event, and dropping it here would trade a
degraded notification for none when the device already has a defined fallback.
the shape check still catches a typo at the producer instead of on a phone.
`ok` is gone. a failed job is its own code, officer/core:job-failed, which is
the thing the five-value enum could not express without a boolean bolted on.
apns: mutable-content: 1, alert.title fixed to the generic, and officer:{c,n,id,mv}
beside it. deliberately NOT the catalogue's title — sending the real text would
hand apple the category vocabulary in plaintext, which is what the code exists
to withhold.
fcm: data-only, no notification block. a notification block is rendered by the
system, which would put the code on the lock screen and give the app no chance
to resolve it. priority high is load-bearing — a normal-priority data message
can sit in doze indefinitely.
discord renders server-side from the catalogue, because it has no app to
resolve anything. safe: catalogue titles are templates and carry no user
content.
the catalogue is loaded ONCE per dispatch, not per channel or per device, so
every copy of one notification carries the same mv. two channels reading disk
either side of a plugin install would otherwise tell two devices different
things about the same event.
40 tests. verified live: a malformed code is refused, officer/core:test is
accepted and dispatches to zero configured channels.
the piece that makes a new notification kind a server change rather than an
app store release. a push carries a code and integers; this is what the code
means, synced to the device instead of compiled into it.
deliberately the same shape as affordances rather than a second mechanism: a
`notifications/` directory of yaml in the plugin repository, copied to
capabilities/notifications/<publisher>/<appName>/ on install, removed on
uninstall. publish.ts mirrors affordances/publish.ts closely enough to diff.
the namespace is DERIVED from where the file lands, never from what it
declares — same rule as mountPrefix. a plugin writing `officer/core:test` as a
key gets `<publisher>/<plugin>:officer/core:test` and the real core entry is
untouched. that is the security property of the whole scheme and it is pinned
by test.
version is a content hash, not a counter. a counter needs somewhere to live
and is then wrong after a restore, a rollback, or two servers built from the
same install; a hash needs no storage and is right in all three. so the client
compares mv !== version, and both docs now say so — i had written "higher".
core entries ship in code rather than on disk, because capabilities/ is
installed rather than committed and `test` has to exist on a machine that has
installed nothing — it is what first light is proved with.
read from disk per request, not memoised: installing a plugin has to change
the answer without a restart, or it presents as "the new plugin's
notifications don't work", which is the hardest kind of bug to place.
verified live: 401 through the platform, plugin catalogue appearing and
disappearing with no restart, version returning to its prior value when the
plugin is removed. 10 catalogue tests, 100% coverage of catalogue.ts.
three questions answered from monorepo-mobile, and two of my assumptions were
wrong.
bundle ids exist — dev.officer.mobile and dev.officer.mobile.dev. two of them
needs nothing special: push_devices is unique on (token, bundleId), so the
variants are separate rows on one phone, and the dev variant is exactly the
sandbox/production distinction the doc warned about. concrete now rather than
derived from build config by guesswork.
scheme is officer:// and officer-dev://, both from app.config.ts.
expo prebuild, not bare — and a config plugin that creates an ios app
extension target ALREADY EXISTS there, withVaultAutofillTarget.js for the
autofill extension. the nse follows it. that removes what i had called the
longest pole in phase 3.
corrected: expo-notifications is not in apps/mobile at all, only apps/chat.
the real blocker is narrower than the doc implied and is not code. today's
signed build has no aps-environment entitlement, and adding one fails while
xcode has no account signed in — same failure as the network extension on
2026-08-05. one manual sign-in, team RGHC4NJC77, then automatic again.
alpha: /api/notify was 404 all day because that server predated the work.
pulled, db:push, gen:ecosystem, officer-notify started, officer restarted.
verified 401 unauthenticated and push_devices with its 10 columns.
the 2026-07-31 design promised this document to `officer-suite/COMMS/`, a repo
path that has never existed. writing it where the work is instead, to be
handed to whoever builds the client.
exact contracts rather than prose: the three device routes with real request
and response shapes read off devices.ts, what is required versus defaulted,
and that the server takes the user from the session and ignores a userId in
the body.
most of it is the failure modes that cost a day each and are invisible from
the client — a send with no credentials configured returns success and
delivers nothing; a sandbox token registered as production fails at apple with
no user-visible symptom; the notification extension must not touch the network
or it will pass every test at a desk and fail on cellular with the vpn off.
leaves three questions for the owner: whether apps/mobile has a bundle id and
a provisioning profile at all, its url scheme, and expo managed versus bare —
that last one decides how the extension gets built and is probably the longest
pole in phase 3.
`personal` is matched against what remains after the permission's own prefix
is stripped, so the entries had to be the sidecar's real paths. they were
written '/devices' and '/subscriptions'; the sidecar serves '/_officer/devices'.
nothing matched, so read level permitted the GET (a safe method, allowed
anyway) and refused the POST and the DELETE — a member could see their
registered devices and neither add nor remove one.
that is the exact opposite of the comment sitting above it, which says device
registration is the caller's own. invisible so far because the owner
short-circuits every check and no member has ever been granted notify.
found while writing the app-side spec: the mobile client posts to
/api/notify/_officer/devices, which is what made the mismatch visible.
the regression test pins the real path and fails against the old value —
checked, not assumed.
second design, superseding 2026-07-31. the reversals are recorded rather than
overwritten, because the first one called its payload rule "not optional" and
this changes it.
one app on the device receives everything and renders it. the payload is a
namespaced code plus integers; the code's meaning lives in a server-owned
mapping synced to the device ahead of time, so a new notification kind is a
server change and never an app build. plugins declare their own codes on the
affordances pattern, which already does exactly this shape.
what moved: privacy relaxed but not abandoned — codes keep content off apple
and google while dropping the rigid category enum that made the doorbell
painful. appSlug inverts from "deliver to this app" to "deep-link to this
app". extensibility becomes the binding constraint.
the piece that makes it work is that the ios extension does a LOCAL lookup
against a synced mapping, not a fetch on arrival — so it does not depend on
the tailnet being up when the push lands, and it costs one build ever rather
than one per kind.
records two things it does not solve: the code vocabulary is still a
fingerprint to apple and google, and the grapheneos/fcm contradiction between
apps/mobile/PUSH_NOTIFICATIONS.md and the platform design is still unresolved.
built 2026-07-31, switched off 2026-08-13 when it was slated to become a
plugin alongside memos and photos. those two were extracted; this one never
was, so it spent six days mounted nowhere with its schema commented out and
no pm2 entry — complete code that nothing could reach.
core rather than a plugin because the producers are the platform's own: the
job queue, an agent turn ending, mail arriving. a notifier the owner can
uninstall is one those producers cannot rely on.
- hono.ts mounts /api/notify again; verified 401 unauthenticated, so the
permission gate covers it and assertPermissionTotality accepts the mount
- push_devices exported from the core schema and pushed: 10 columns,
uq_push_devices_token_bundle, idx_push_devices_user
- officer-notify added to CORE_PROCESSES, so gen:ecosystem writes it
- credentials read OFFICERDEV_X ?? X, the convention it predates
safe as core because it boots with nothing configured: every channel reports
isConfigured() false and dispatch resolves empty. verified by importing it
with the env stripped — "channels: none configured", no throw. an install
with no apns key runs it as a no-op rather than crash-looping.
APNS_ENV is dropped from the doc's credential table. it was never read: the
host comes from each device's `environment` column, so one server pushes to a
testflight build and a release build at once.
doc status corrected. the app side is not started — there is no officer-suite
repo, no PUSH_NOTIFICATIONS_APP.md, and apps/chat actively strips the ios push
entitlement. recorded there rather than here.
RULES was a hardcoded map from every route prefix to a title, which meant a
new route silently fell through to 'Officer' until somebody remembered to
add an entry — the gap that hit installed-plugin routes, which had no entry
at all. titleForPath now takes the URL's first path segment and title-cases
it, so every route gets a sane tab title for free, including ones a plugin
adds at runtime. Trade-off: a few routes lose their hand-tuned casing
(QR Transfer -> Qr Transfer, Command HQ -> Command Hq) and settings
sub-routes collapse to the one 'Settings' title instead of a distinct one
per section — both accepted as the point of removing the table.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The answer channel is a denial — the only PreToolUse decision that can carry a
result — and the harness stamps every denied tool `is_error`. So a perfectly
good answer arrived looking like a failure: red in the transcript, and read by
the agent as something that went wrong rather than as the reply to its own
question. Confirmed on the first live question through the new channel, which
came back as `<error>Show it in Officer</error>`.
The parser already sees the tool_use that opened the question, so it records the
id and clears the flag when the matching result lands. A timeout or a lost
session lands here too and is equally not an error: its output is a sentence
explaining itself, which the agent should read rather than retry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The harness answered every question itself, instantly, with "The user did not
answer the questions." — before the card had painted, let alone been read. The
agent then reasoned about a refusal that never happened: on 2026-08-19 it asked
the same question three times in a row while the answers sat on the screen.
The web UI already worked around it by rendering the card ungated and sending
the click back as an ordinary chat message. That got an answer through, but the
agent read it as a new instruction arriving from nowhere rather than as the
reply to what it asked, and nothing could distinguish a live question from one
answered last week — every replayed transcript rendered its old questions as
clickable.
A PreToolUse hook is the fix, and it has to be a hook rather than canUseTool:
under bypassPermissions — which is every session here — the SDK shadows the
callback and never calls it. Measured against 0.2.59: a bypassing session's
AskUserQuestion reached the hook and never reached canUseTool. Hooks run
regardless of permission mode.
The hook parks on a promise keyed by the harness's own tool_use_id, and returns
`deny` with the human's answer as the reason — which the harness feeds back as
the tool result verbatim. "Deny" reads wrong and is right: what it denies is the
tool's ability to answer for the user, and what replaces its output is what the
user actually said. Held open for 150s in testing with the turn completing
normally, so a person has time to think.
Keying on tool_use_id rather than an invented id means no new durable event: the
questions are already in the session log as an ordinary tool:start, and the
answer arrives as its tool:result. One source of truth, replay included — which
is what re-enables gating the card on `output`, and with it the staleness fix.
The two tests that pinned the old ungated behaviour asserted the workaround as
the contract; they now pin the reversal, including a pre-fix transcript reading
as settled, which it is.
Unanswered questions settle like plans do: 20 minutes, every session-ending path
draining them first, and wording that tells the agent the question is still on
the user's screen and must not be asked again.
Mobile (Butler) has the same workaround and is not fixed here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The chip could not be cleared by any means, and the toast could not be silenced
from the call site: useClient raises a GLOBAL onError before it throws, so
handling the failure where Stop is pressed was always going to be too late.
DELETE is idempotent. Asking for a job to stop when it is already gone has
achieved what was asked, so "no such task" and "already stopped" now answer 200
with `gone: true` instead of 400. No error, no toast, and the client clears the
chip on the flag.
A genuine refusal — a malformed id, a subagent with no fd to trace — is still
400.
The previous client-side check stays as a fallback, for a browser talking to a
server that has not been updated yet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A chip stuck on "running" could not be stopped, killed or dismissed. Stop and
Kill both answered {"stopped":false,"reason":"no such task"} — there is no
output file, so no pid, so nothing to signal — and dismiss is only offered for a
task the tray believes has finished. A chip with no way out.
The server saying it cannot find the job is authoritative rather than an error
worth reporting: the chip was the last thing claiming it existed. Pressing Stop
now clears it.
Running chips still have no dismiss button of their own, deliberately — the
tray is the only thing watching a live job and a hidden one is a job you have no
way back to. This is the escape hatch for a job that is not actually live, and
it is reached by pressing the control you would already have pressed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Your own messages were plain `whitespace-pre-wrap`, so pasting a fenced block
gave you back the backticks and none of the formatting — the one place in the
app where markdown was written and never read.
The usual reason to leave user text alone is that rendering changes what was
typed: `a_b_c` becomes italic, a leading `#` becomes a heading. That is real,
and the answer is the Copy button beside it, which copies the RAW text. The
original is one click away and nothing you wrote can be lost to a renderer.
Same remark plugins, components and sanitize schema as the assistant's,
deliberately — a code block should look identical whoever wrote it, and the
schema already strips script, iframe, object, embed and form, so pasted HTML is
inert either way.
The copy button appears on hover rather than always, unlike the assistant's: a
reply is something you copy out of, while your own message is something you
already have, so the control earns its place only when reached for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A background job that ignores SIGTERM could not be stopped from the UI at all.
Stop sends SIGTERM to every pid holding the job's output file, and the second
click sent the same signal again — task-restart.ts already said "that is what
the second click is for", and it was not. Reported after a job hung in another
chat.
The button now escalates instead of a second button appearing beside it. Press
Stop, and if the job is still running three seconds later the same control
becomes Kill in the destructive tone, and sends SIGKILL.
Escalating rather than always offering Kill, because a permanent Kill button is
a second destructive control competing with the first, and people reach for it
by default — losing the graceful shutdown that usually works. The delay is the
same argument: a clean exit takes well under a second, so offering Kill at once
teaches everyone to press it first.
`?force=1` on the existing DELETE rather than a second route: same verb on the
same thing, differing only in how hard it asks. The member path escalates too —
one `kill -KILL` run as them, since fuser and the kill must both be their own
identity.
Stated in the button's own title rather than hidden: SIGKILL gives the process
no chance to release a port or take its children with it. That is the right
trade for a hang and the reason it is not offered first.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Update button failed with "couldn't find remote ref main" on every checkout
made before the plugin repositories were standardised on `master`. It pulled
`origin <local branch name>`, and the local branch and the remote's default had
stopped agreeing — so the button could never work again on exactly the installs
that most needed it.
Now `git fetch origin HEAD` and a fast-forward: HEAD resolves to whatever the
remote's default is, so the local name stops mattering, and the merge applies it
to whichever branch the checkout happens to be on.
Fourth time today that naming a branch was the bug — the marketplace icon URLs,
the capabilities sync, the setup script, and now this. The rule that keeps
holding: fetch HEAD, never a name.
Verified by reproducing it — renamed a real checkout to `main`, pulled against a
remote that has only `master`, and it succeeded.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Uninstalling music left its grants in role_permissions. The keys stop existing
when the plugin unmounts, so the settings page — which loads every grant and
submits them all back — failed with "Unknown permission 'music'" for a row
nobody could see, edit or remove through the UI. Nothing could be saved again
without editing the database.
Two changes, because either alone leaves half the problem.
Uninstall now revokes the plugin's grants, across every role rather than one. A
deliberate exception to "uninstall deletes nothing": a grant is the PLATFORM's
record of who may reach the plugin, not anything the plugin stored. Reinstalling
means granting again, which is the honest behaviour — the alternative is access
silently returning.
And the write DROPS an unknown key instead of refusing the request, so every
server already in this state is unblocked without touching its database. That is
what the resolver already does on read, so the write now agrees with it. The
cost is that a typo in a hand-made API call is ignored rather than reported —
worth less than a settings page that cannot be used. The response returns what
was dropped, so it is not silent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PORT, PUBLIC_URL and POSTGRES_URL are names half the software in the world
uses. Bun auto-loads .env into EVERY process started in the platform directory,
so a bare PORT reaches the sidecars, the tools they spawn and anything an agent
runs from here — and a bare POSTGRES_URL reaches things with no business
holding a database credential.
Four parts.
officer-setup now writes OFFICERDEV_-prefixed names, with the reasoning in the
generated file so whoever opens it later knows why.
Every consumer reads `OFFICERDEV_X ?? X` — eleven sites across the databases,
the DAV router, officer-url.mjs, os-user-postgres and two scripts. The bare
name is the FALLBACK, never the source, which is what makes this safe to ship
before every machine has been converted.
`bun run fix:env` converts a file in place. Idempotent, preserves comments and
`export`, leaves the value untouched including an `=` inside it, and refuses to
touch names belonging to other software — prefixing PATH or NODE_ENV does not
rename a variable, it deletes it.
And it runs on every restart from the server settings screen. There rather than
at boot because a restart is the one moment the file can be rewritten and take
effect in the same breath: the process about to start is the one that reads it.
Non-fatal, since the fallback means the worst case is that nothing changed.
gen-index reads either spelling out of the file directly, because it is run by
hand as often as by the setup and a bare shell has no .env loaded.
Verified by converting this machine's own .env: PORT, PUBLIC_URL and the
database all still resolve, gen:index still finds its URL, 1152 pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Only an address worked, though usernames are already unique and already
validated as /^[a-zA-Z0-9._-]+$/ — which is what makes this safe: no `@`, so
the two namespaces cannot overlap and there is nothing to guess. An `@` decides
which lookup runs, and it decides it exactly.
The field is still called `email` on the wire, because every client sends that
name and renaming it would break them for nothing.
Fixed a latent bug while passing: the JWT took `email` from the REQUEST rather
than the row. Identical while an address was the only way in — and a username
in the `email` claim the moment it was not, leaving the DAV door, the managed
home path and everything else keyed on email looking up a user who does not
exist.
The login field is `type="text"`, not `type="email"`, or the browser refuses to
submit a username and validates someone out of an account they have.
`autoComplete="username"`, which is what password managers store beside a
password for a field that takes either.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The plugin and capabilities repositories were standardised on `master`, and
five places said `origin main` — the setup script's sync and the Update-all
path. Swapping them to `master` would be the same mistake wearing a new name.
`HEAD` resolves to whatever the remote's default is, so the question stops
being asked, exactly as it now does for the marketplace icon URLs. Only the
LOCAL branch still needs a name.
Third time today that naming a branch was the bug: the icon URLs 404'd on four
repositories created as `master`, and these would have broken the moment the
rest were renamed to match.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every available plugin drew a broken image on any server reading the remote
catalogue. The URLs said /raw/branch/main/, and four plugin repositories were
created on `master` — so those 404'd, and the others only worked by accident of
which branch somebody happened to use.
The comment above the builder already said "a repo whose default branch is
`master` gets a 404", marked [open]. It then happened. A warning in a comment
is not a guard.
Gitea resolves /raw/HEAD/ to whatever the default branch is, so the question
stops being asked. Verified against both spellings, and all 12 icons in the
live catalogue now answer 200.
It did not show on alpha because every plugin there is INSTALLED, and an
installed plugin's tile is served locally from /plugins/<name>/ rather than
from the catalogue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Replaces the "19 files, one grep" placeholder with what the full sweep
actually found, fixed and deliberately left, and why.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
24 panel and screen files had their fields sitting in a <div> instead of a
<form> — typing a value and pressing Enter did nothing, and the button was
the only way in. Fixed the sites that are a real form, a single field with
an obvious action, or a multi-field editor; left search/filter boxes and a
few genuinely ambiguous sites alone (see TODO.md for the full breakdown).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Typing a value and pressing Enter does nothing in any of them; the button is
the only way to submit. Found in gitea's connection screen and fixed there
only, because the rest are not one change: a search box has no submit and
wrapping it changes nothing, while a multi-field editor wants the useForm hook
rather than a hand-rolled onSubmit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A plugin may declare a dependency no package manager carries — tea, Gitea's
CLI, is the first — and installRelease puts it in ~/.local/bin: no root, and
nothing downloaded from the internet sitting beside what the distribution
installed.
But PM2 hands the platform a login-less PATH
(/usr/local/sbin:...:/snap/bin), so the agent it spawns inherited one too, and
the binary the platform had just installed was invisible to the agent it was
installed FOR.
Which is exactly what happened on the first real test: gitea's affordance told
the agent to use `tea`, the agent tried, and got `command not found` for
something sitting in the owner's home. The affordance worked perfectly and the
advice it gave was impossible to follow.
Appended rather than prepended, so a system binary of the same name still wins
— `identify` in os-deps is what settles which one is really wanted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
osDependencies could only say "this package, from this manager". Gitea's `tea`
is not in any distribution — it is a Go binary from dl.gitea.com — and Debian
has an UNRELATED package of that name: a graphical text editor. So the one
dependency gitea actually wants could not be expressed, and its marketplace
page showed no dependencies at all while music's showed two.
`release: { url, identify }` covers it. {os} and {arch} are filled from the
host in the spelling Go releases use, and the binary is fetched to
~/.local/bin — no root, and nothing a plugin downloaded from the internet
sitting beside what the distribution installed. Written to a temporary name and
moved into place, so a half-downloaded file is never on PATH under the real
one.
`identify` is the part that matters. Bun.which('tea') cannot tell Gitea's CLI
from the text editor, so presence was never the same question as identity —
and reporting the wrong program as satisfied is worse than reporting it
missing, because the install succeeds and every call afterwards fails
strangely. A binary that fails to identify is now `present: false, imposter:
true`.
Found while testing: Bun.which() with no options reads the PATH the PROCESS
started with, which under PM2 frequently excludes ~/.local/bin entirely. A
release binary fetched during an install would have been reported missing
seconds later by stillMissing, failing an install that had just succeeded. The
search now passes PATH explicitly, with ~/.local/bin first.
Verified against the real binaries on this machine: the genuine tea identifies,
a fake that prints text-editor output is caught as an imposter, and both
dl.gitea.com URLs (linux-amd64, darwin-arm64) answer 200.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The path takes `publisher` from the manifest verbatim, so a plugin published
by officerdev lands under officerdev/. `officer/core` is not a plugin at all —
it is the platform's own, shipped by the setup script from the capabilities
repository.
Two spellings marking two different things: platform versus publisher. Arrived
at by accident and kept on purpose. Recorded because the obvious tidy-up
removes the distinction rather than the inconsistency.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A plugin is a new SURFACE arriving at runtime, which is exactly the case
hand-written prose could never cover: install gitea and no agent learns that
`tea` is authenticated, or that plain `git` is the better tool for what git
already does. The plugin knows; nothing carried it across.
An `affordances/` directory in the plugin repository is copied to
capabilities/affordances/<publisher>/<plugin>/ on install and removed on
uninstall — the same shape as assets/ and publishAssets, deliberately, because
two mechanisms for "the plugin ships some files" would drift and that one is
already understood.
Namespaced by publisher because two plugins named `gitea` from different
publishers must not overwrite each other, and because an affordance in the tree
should say whose it is without being opened. It mirrors mountPrefix.
Uninstall removes the PLUGIN's directory, never the publisher's: every
first-party plugin publishes under one officerdev/, and taking that level out
because one was uninstalled would strip the rest silently. That is what the
tests are mostly about — a copy going wrong is obvious, this would not be.
Publishing is not fatal to an install. An affordance that failed to copy costs
an agent some knowledge; refusing the install over it costs the owner the
plugin.
Verified against the real gitea plugin: published, the loader saw
officerdev/gitea/gitea beside officer/core/image-rendering, uninstall removed
it and left core alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eleventh extraction, and the only one that deleted its UI instead of moving it.
Seventeen files under apps/Gitea/ reimplemented a fraction of an interface
Gitea already has; the plugin renders the real one in an iframe over a
same-origin proxy.
Deleting rather than moving removed a platform change nobody now has to build:
useGiteaLocation read :owner/:name/:tab/:item from five route patterns where a
plugin gets two, so an as-is extraction would have required teaching the plugin
system to declare extra route patterns. Nothing inside an iframe needs a route.
Nothing working was lost. The router had been commented out of hono.ts since
2026-08-13 with api: [], and officer-gitea was running nowhere — the screen
rendered and every request 404'd, like soulseek, jellyfin and invoices before
it.
Gitea also stops being a CORE DOCK ITEM. It was hardcoded in CORE_DOCK_ITEMS,
the only installable feature that was, on the reasoning that it fronts a remote
instance and installs nothing locally. As a plugin its tile arrives from
assets/icon.png like every other — which is also why the icon added to
public/icons/ this morning was reverted rather than kept.
'gitea' stays in the ServiceName union: the connection lives in core
service_connections, and gitea is the reason that table has its "member rows
carry only a token and inherit the owner's URL" shape at all.
registry.test.ts's grantable-permission test named gitea as "the case this was
built for"; a plugin's permissions are registered at install and are never in
that compile-time list, so it now names a core one. catalogue.test.ts
re-anchored to vnc/notify.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This reverts 061e2137.
The artwork is right, the location is not: gitea is about to become a plugin,
and a plugin carries its own icon in assets/ — published to /plugins/<name>/ on
install, and removed when it is uninstalled. Putting it in the platform's
public/icons/ makes it the one plugin whose tile the platform ships, and it
would keep being served after an uninstall.
Added here only because the plugin repository did not exist yet. It does not
yet, either — this goes back in as plugins/gitea/assets/icon.png once it does.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
capabilities/ is the file-based item store, and most of it belongs to the
owner: the six item directories are created by the platform at boot and
extensions/tool-loader is written from platform source, so neither is tracked
anywhere. What IS tracked is the small set the platform ships — today one
affordance, telling an agent that markdown images render and that the USER'S
DEVICE fetches the URL, which it cannot discover from the filesystem.
That now lives in officerdev/capabilities, public so a fresh install can clone
it without credentials.
Two ways in. The setup script syncs it during the layout step — non-fatal, and
it says what an install without it costs rather than failing: agents go back to
guessing, which is what they did before this existed. And "Update all" on the
marketplace screen carries it alongside the plugins, because it is the same
question — get me what has been published since I installed — and a second
different gesture for it is one nobody remembers.
Three states in both places, and the third is the normal one on an existing
machine: a checkout is pulled, an empty directory is cloned into, and a
directory that already holds the platform's generated items gets a repository
initialised around them. UNTRACKED files never block a pull, because the
owner's own skills and tools living here is the ordinary state — only tracked
changes do.
`cloned` and `adopted` are reported in the UI where `pulled` is not: they mean
this machine had no affordances at all until the button was pressed.
Verified against the real checkout: sync reports pulled, and the loader finds
officer/core/image-rendering afterwards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
git + tea, drawn to the icon brief: a green voxel teacup with the branch diagram
pressed into the glaze as a maker's emblem, and Officer Duck on the rim.
Core dock item with no phone app behind it, so there is an icon and no splash —
a splash belongs to something that launches.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The platform hosts the agent and never introduces itself. An agent gets a
shell, a filesystem and a prompt; everything about the CLIENT on the other end
has to be guessed. It writes , nothing renders, and
nothing says why — because an <img> carries no bearer token and it is the
user's DEVICE that fetches the URL.
servers/affordances/load.ts reads capabilities/affordances/ and compiles one
block; claude-manager passes it as systemPrompt.append with the claude_code
preset, so the harness keeps its own prompt.
Passed there rather than written to a file because it is the one place every
session goes through, owner and member alike. A generated CLAUDE.md cannot do
that — user-instance.ts deliberately refuses to write one for the owner, since
it would pollute the personal ~/.claude/CLAUDE.md they maintain themselves.
Read per session, not cached: capabilities/ is already read fresh each session,
so a plugin installed an hour ago is live on the next message. Synchronous
because createSession is not async, and making it so to read a few kilobytes
would ripple through every caller.
No filtering. Everything is loaded into every conversation, because the axis to
filter on is not one dimension — for image rendering it is what the CLIENT
renders, for gitea what TOOLING exists on the machine. Fine at two files, not
at twenty; TODO.md carries the argument.
Opencode gets nothing, and that is recorded as a gap rather than hidden: an
affordance that holds on one harness is the drift this removes. Deliberate —
opencode is paused pending v2 and the work would be thrown away.
Nine tests, aimed at the failure that matters: a file that silently does not
reach the agent looks exactly like one nobody wrote.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Design only — nothing reads any of this yet.
Markdown with YAML frontmatter, like every other item in capabilities/.
Frontmatter is for the PLATFORM, the body is for the agent: `name` becomes the
heading in the compiled block, `description` says when to reach for it and is
not sent, `version` is an INTEGER to match capabilities/agents/ rather than the
semver plugins use. A plugin-contributed affordance sits near both numbers and
they mean different things — the integer is the revision of that text, the
semver is the plugin's.
They live at capabilities/affordances/<publisher>/<plugin>/, with `core` in the
plugin slot for the platform's own. A plugin ships an affordances/ directory
and install copies it in — the same shape as assets/ and publishAssets.
No `surface` field. It was drafted and dropped: for image rendering it would
mean what the CLIENT renders, for gitea what TOOLING exists on the machine.
Two axes wearing one name. Everything loads unconditionally until that is
worked out, which is fine at two files and will not be at twenty — and this
codebase has already been bitten by a field that validated itself and was never
consumed (unauthenticatedPaths).
TODO.md carries the build list and the two deferred questions, including the
honest one: "declared where implemented" is the rule, and a hand-authored file
in a repository is not that. Accepted because prose reaches every harness and a
registry reaches one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DESIGN, NOT BUILT. No registry, no API, nothing to call. Written down now
because the name and the boundary are the parts that get expensive later, and
because a plugin author who invents a different word for this is hard to merge
with afterwards.
An affordance is what the surface on the other end offers the agent — declared
by the code that implements it, read at runtime. Not what the agent can do;
what the client will honour.
The worked example is images. Officer's chat DOES render markdown images, but
an <img> carries no bearer token, so it can only load what the browser can
fetch unauthenticated. A fresh agent knows none of that: it writes
, nothing renders, and nothing says why. That knowledge
currently lives as prose in a hand-written CLAUDE.md on one machine, phrased as
a workaround ("use a public URL") rather than as the constraint — with nothing
keeping the two in sync.
Prose is the wrong container for three reasons: it drifts from the code, it is
per-machine, and a plugin cannot contribute to it. The last one is the point —
a plugin IS a new surface arriving at runtime, and no agent learns it exists.
The rule that makes it worth building: an affordance is declared where it is
implemented, like permissions/registry.ts. A list maintained elsewhere is the
CLAUDE.md problem again with a better name.
`capability` and `skill` were both already taken here, twice in skill's case.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both were redrawn to the icon brief today, so the dock shows the same voxel mark
the phone apps do rather than a lucide CalendarDays and Contact.
tile: 'bare' for the same reason a plugin's artwork gets it — the art brings its
own frame, and a coloured square behind it reads as a mistake. color stays
because the active glow, the indicator dot and the settings tint all still use
it.
These two are core rather than plugins, so the files live in public/icons/
alongside the duck rather than arriving through publishAssets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was no update path. fetchPlugin REFUSES an existing directory — cloning
over one is how uncommitted work disappears — so install was a one-way door,
and the answer to "my plugin changed" was uninstall and reinstall, which drops
its tables on the way past.
An update is a git pull and then the ORDINARY install path. installPlugin
already skips the clone when the directory is present and re-runs everything
else: os dependencies, schema push, assets, the ecosystem entry, the sidecar,
the remount and the frontend rebuild. So there is no second implementation of
"apply a plugin" here to drift from the first.
Two refusals, both about not destroying work. A dirty working tree is refused
rather than stashed or force-pulled — every plugin directory on a developer's
machine is a live checkout, and this repository's own are edited in place.
Non-fast-forward is refused for the same reason: a diverged local commit is
somebody's work and merging it automatically is not the platform's decision.
The per-plugin button replaces one that was quietly broken: it appeared only
when `outdated` and called `install`, which cannot fetch, so it re-applied
stale code. Nothing bumps a version today either, so with everything pinned at
1.0.0 that flag never fires and the button never appeared. Now always offered,
and it pulls.
Update-all is a plain POST rather than the streaming door: twelve interleaved
step streams is not a readable log, and the useful answer is the summary. It
runs sequentially — each update pushes schema, republishes assets, rewrites the
ecosystem file and rebuilds the frontend, and two of those at once is a race
over one file each. One failure does not stop the rest, and failures are named
with their reason, because "2 failed" sends someone to the terminal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Missed when calendar and contacts became core in 9c309c5a: the routers were
uncommented but `export * from './dav/schema'` was not, so drizzle never saw
the table and bun db:push never created it. Alpha surfaced it as an unhandled
"Failed query: select ... from dav_app_passwords" on every boot.
The table holds the DAV app passwords a phone authenticates with, so the sync
door was mounted, answering 401 with a correct WWW-Authenticate header, and
incapable of ever accepting a credential — nothing could mint one.
Same shape as the hazard already recorded for the wallet, soulseek and
jellyfin: a schema commented out of the barrel is invisible to db:push, which
silently means the table is never created and, where one already exists,
that it would be dropped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhas
