0a9649a12bc917d292c9c9c605c6615a86857921
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  pastilhasandClaude Opus 5
|
0a9649a12b |
brand: the drawn Officer wordmark, unskewed
Replaces the old mark everywhere it is referenced — the header reads it through --logo-src and every theme points at the same file, and the auth landing page and the emailer read it directly, so one asset covers all three. The CSS skew goes with it. That is where the old logo's slant came from, and applying it to this one shears letterforms that were kerned pair by pair by hand and signed off as finished. See landing/assets/brand/WORDMARK.md for the construction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhas
|
9ca2287e50 |
bell: move it left, and let its colour say what it will do
the bell sat on the right between the connection dot and the end-session plug, which put a SETTING in among the STATUS. everything on the right reports what the chat is doing now; the bell says what it will do later. it moves to the left of the header, on its own. and it is coloured by preference, so the setting is readable without opening the menu: green for every end of turn, amber for input-needed, muted for none. green is `green-500` rather than the `text-success` token deliberately — it has to be the SAME green as the connection dot a few elements away, and a semantic token that drifted from it would leave two greens in one header meaning two different things. amber is `text-warning` (#f59e0b), which is the conditional setting: it will speak, but only sometimes. `none` keeps the struck-through bell as well as the muted colour. colour alone is not a state anyone should have to learn, and it is the one setting where being wrong is silent. |
||
|
pastilhas
|
34e21317da |
chat: the copy buttons sit on the code block, bottom right
they were sticky at the top, which put them over the first line — and on a one-line block, which is most of them in a chat, over the whole thing. absolute bottom-right inside the surface now, with `.code-surface` given the `position: relative` it never had. that omission is why a control could end up escaping to the nearest positioned ancestor and floating below the block it belongs to. `padding-bottom` on the pre to go with the existing `padding-right`: the last line is the one they overlap now, and it needs its own room the same way the first line needed it before. the trade the old comment was worried about is real but smaller than it reads: a block taller than the viewport now has its controls at the bottom rather than the top. that is where you end up after reading it anyway, and it is a worse place to be only for a block you never scroll — which is exactly the block whose first line the old position was covering. |
||
|
pastilhas
|
bf57201a11 |
bun run doctor, and provisioning checks its own work
the tenth install in a row with something new wrong, and the pattern behind them is not the individual faults. every step in provisionOsAccount is deliberately non-fatal — a member whose account provisioned fine should not be rolled back because their shell config failed. that is right, and it means "nothing reported an error" is a far weaker statement than it reads as. the acl-mask bug was the sharp version: a clean provisioning run, every named entry correct, and an account that could reach nothing. it was found by a person three days later, through a file browser message three steps removed from the cause. so provisioning now VERIFIES rather than assuming, and it verifies by making the same readdir the file browser makes. deliberately not by inspecting the acl: reading getfacl and reasoning about masks is exactly how this was missed, because the acl looked right. a check that tests something adjacent to the failure is how you get a green report and a broken server. a failed check is reported FIRST, ahead of keys and shells — an account that cannot read its own home is broken in a way that working ssh does not make up for. and `bun run doctor` for the nine servers that already exist: same check across every account, plus the one that is invisible by construction — a confined grant held by an account with no linux user, which sits in the table, shows as ticked in the UI, and resolves to nothing. read-only, so it is safe on a production box. exits 1, so it can gate the end of a setup run. same posture as assertPermissionTotality, except this reports instead of refusing to boot: one broken member must not stop the platform serving everyone else. |
||
|
pastilhas
|
069dd4b23f |
provisioning: re-assert the acl mask, last
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. |
||
|
pastilhasandClaude Opus 5
|
c982d82dde |
todo: four foreign keys churn on every push, deferred not fixed
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> |
||
|
pastilhasandClaude Opus 5
|
989c15e437 |
fix(chat): resume in the directory the transcript belongs to
--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> |
||
|
pastilhas
|
46d621c91b |
chat notifications reach the phone, on the same rule as the bell
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.
|
||
|
pastilhas
|
72d327e360 |
bell: scope the preference to a user, and make every_turn mean every turn
review of
|
||
|
pastilhasandClaude Opus 5
|
73cdc2cb77 |
bell: notify a chat's page and list row, any chat, any time
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
|
||
|
pastilhas
|
5cba1b65a6 |
notify: only "the app is gone" deletes a device row
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. |
||
|
pastilhas
|
c6ef0b34db |
caldav: a missing radicale should not crash-loop the sidecar
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.
|
||
|
pastilhas
|
5a26cdbbcb |
find my device: the design, and what it can never do
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. |
||
|
pastilhas
|
c68c734431 |
docs: what an affordance is, and the test that catches the bad ones
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. |
||
|
pastilhas
|
4cd371b55d |
chat: links open in a new tab
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. |
||
|
pastilhas
|
16369f3570 |
secret store holds foreign secrets, and notify reads from it
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. |
||
|
pastilhas
|
2cefa3d378 |
apns credentials belong in the secret store, and cannot go there yet
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. |
||
|
pastilhas
|
e598a5dcba |
notify: codes replace the type enum, and android goes data-only
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.
|
||
|
pastilhas
|
55d6eba511 |
notification catalogue: GET /api/notify/mapping
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. |
||
|
pastilhas
|
98960d2827 |
app spec: the answers from the app repo, and alpha caught up
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. |
||
|
pastilhas
|
e57d6cc1cc |
push notifications: the app-side spec
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. |
||
|
pastilhas
|
ab94a3a510 |
notify: a member could list their phones but not register one
`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. |
||
|
pastilhas
|
347e679712 |
push notifications: the hub design
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. |
||
|
pastilhas
|
fd7c9becb6 |
notify is core again
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. |
||
|
pastilhasandClaude Opus 5
|
ab636eaa42 |
page title: derive from the route path instead of a hand-maintained table
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> |
||
|
pastilhasandClaude Opus 5
|
6235662492 |
fix(chat): an answered question is not a failed tool call
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> |
||
|
pastilhasandClaude Opus 5
|
44a3d5f655 |
fix(chat): give AskUserQuestion a real answer channel
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> |
||
|
pastilhasandClaude Opus 5
|
520fad2288 |
stopping a job that is already gone is a success, not an error
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> |
||
|
pastilhasandClaude Opus 5
|
0f56aae803 |
a task the server cannot find is dismissed, not reported
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>
|
||
|
pastilhasandClaude Opus 5
|
9c6534c746 |
render markdown in your own chat bubbles, and let you copy them
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> |
||
|
pastilhasandClaude Opus 5
|
177394fb76 |
Stop becomes Kill when the job ignores it
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> |
||
|
pastilhasandClaude Opus 5
|
4b22f52c7e |
update a plugin whose local branch no longer exists on the remote
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> |
||
|
pastilhasandClaude Opus 5
|
0fd89082fe |
an uninstalled plugin's grants stop breaking the permissions screen
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> |
||
|
pastilhasandClaude Opus 5
|
b9524ee4d5 |
prefix the env with OFFICERDEV_, and keep reading the bare names
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> |
||
|
pastilhasandClaude Opus 5
|
b27410a6fc |
sign in with an email or a username
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> |
||
|
pastilhasandClaude Opus 5
|
1e03c600b8 |
stop naming a branch when pulling the capabilities repository
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> |
||
|
pastilhasandClaude Opus 5
|
5b486ed019 |
build marketplace icon URLs from HEAD, not from a branch name
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> |
||
|
pastilhasandClaude Opus 5
|
427bd1afff |
todo: close out the inputs-outside-forms sweep
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> |
||
|
pastilhasandClaude Opus 5
|
994de45296 |
wrap inputs in real forms, so enter submits instead of doing nothing
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> |
||
|
pastilhasandClaude Opus 5
|
319afe2c5d |
note that 19 panels put inputs outside a form
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> |
||
|
pastilhasandClaude Opus 5
|
79ced03bec |
put ~/.local/bin on the agent's PATH
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> |
||
|
pastilhasandClaude Opus 5
|
09f2cfa267 |
a plugin can depend on a release binary, and prove it is the right one
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>
|
||
|
pastilhasandClaude Opus 5
|
51afa40a19 |
affordances: officer/core and officerdev/<plugin> are both right
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> |
||
|
pastilhasandClaude Opus 5
|
8fe1b1824b |
a plugin can ship affordances, and installing publishes them
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> |
||
|
pastilhasandClaude Opus 5
|
d49776307d |
gitea, extracted into plugins/gitea — the platform half
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> |
||
|
pastilhasandClaude Opus 5
|
d8cccad84c |
Revert "dock: Gitea gets the teacup"
This reverts
|
||
|
pastilhasandClaude Opus 5
|
4b2c896523 |
ship the capabilities repository, and update it from the same button as plugins
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> |
||
|
pastilhasandClaude Opus 5
|
061e213780 |
dock: Gitea gets the teacup
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> |
||
|
pastilhasandClaude Opus 5
|
057bf7b183 |
load affordances and append them to every claude session
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> |
||
|
pastilhasandClaude Opus 5
|
d8c97b6814 |
affordances: the file format, where they live, and what is still open
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> |
||
|
pastilhasandClaude Opus 5
|
7a9e576ee6 |
name the thing the platform never tells an agent: affordances
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>
|
||
|
pastilhasandClaude Opus 5
|
839199bf53 |
dock: Calendar and Contacts carry their artwork, not a glyph
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> |
||
|
pastilhasandClaude Opus 5
|
3ef078210a |
update a plugin, or all of them, from the marketplace
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> |
||
|
pastilhasandClaude Opus 5
|
8f15f16d1c |
restore dav_app_passwords to the db:push barrel
Missed when calendar and contacts became core in
|
||
|
pastilhasandClaude Opus 5
|
cfbec0b757 |
plugins: a splash is part of a plugin, like its icon
assets/splash.png is discovered by presence, published by the same copy that already took the whole assets directory, and carried on DiscoveredPlugin beside icon. The platform draws no splash — a plugin has no launch. It is carried because the plugin repository is where a product's artwork lives now, and the phone app that fronts the same product needs somewhere to read it from that is not a designer's folder. The pair is the point: the icon is a reduction of the splash's world, and keeping them together is what stops them drifting. Publishing no longer gates on the icon alone, which left a plugin shipping only a splash serving nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
bbb16d6ed3 |
bitcoin-wallet, extracted into plugins/bitcoin-wallet — the platform half
Tenth extraction, and the first where the blocker was a permission rather than a path. The wallet was kind: 'admin' — owner only, never grantable — and plugin permissions are always kind: 'app'. mount.ts forces that and the manifest has no field for anything else, deliberately, so a plugin cannot ask to be restricted. Extraction therefore could not preserve admin. Raised before moving any code, because turning "the server owner's bitcoin" into a row in the grants list beside Photos and Music is the kind of change nobody notices until someone ticks it. Made anyway, and the objection inverts: every wallet query is scoped by user_id, taken from X-Officer-User which the platform injects from the session, so granting the permission gives an account its OWN wallet rather than access to anyone else's — including to the owner, whose bypass covers permission checks and not query scoping. kind: 'admin' was single-user thinking. Named bitcoin-wallet, not wallet: appName drives route, API prefix, table prefix and install key together, so the name should say what it is. Tables are bitcoin_wallet_*; the prefix guard normalises the hyphen. Verified free before committing to it — no wallet table exists on any server, and db:push would treat a rename as a drop plus a create. registry.test.ts re-anchored: `wallet` was its canonical kind: 'admin' fixture and its no-selfService fixture. Now user-admin/server-admin and terminal, with a note that a plugin's permissions are always `app` — which is exactly why this one needed a decision rather than a default. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f2c6ebaa4d |
calendar and contacts get dock tiles again
Their tiles were contributed by the app-store `caldav` catalogue entry, so
deleting that entry in
|
||
|
pastilhasandClaude Opus 5
|
d6f093532d |
install radicale and register officer-caldav on an existing server's next boot
Calendar and contacts became core in |
||
|
pastilhasandClaude Opus 5
|
9c309c5ab6 |
calendar and contacts are core again, with radicale as a plain sidecar
Reverses the 2026-08-13 decision to make caldav an app-store entry. Three reasons it does not belong there. It is not an integration. Photos-via-Immich or torrents-via-Transmission assume you already run the thing; a calendar assumes nothing, and a personal server without one is missing a baseline rather than an optional app. It needs TWO top-level routes, /calendar and /contacts, and a plugin gets one — derived from its appName, which is what makes it structurally impossible for a plugin to shadow a core route. Nobody thinks "I'll open my dav", so collapsing them under /dav was the wrong trade, and weakening the namespace guarantee to allow two was a worse one. As core routes the question does not arise. And it never actually needed Docker. Radicale is a ~2MB Python package; sidecar/caldav/radicale.ts already spawns it directly on loopback with http_x_remote_user. The container came from the app store making everything a container, not from anything Radicale requires. So: the routers are mounted again (/caldav for the UI's JSON door, /dav for app passwords, the top-level /dav sync door and the two .well-known redirects), officer-caldav joins CORE_PROCESSES, radicale joins the machine-setup package list for all four package managers, and the catalogue entry is gone. members.test.ts re-anchored a fifth time — caldav was one of two `accounts` services and memos is now the last. Noted in the test that the sixth time should be a literal fixture instead. Verified: assertPermissionTotality accepts /caldav and /dav, tsgo clean, 1085 pass. NOT yet verified against a real client — radicale is not installed on this machine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f566fda0b2 |
invoices, extracted into plugins/invoices — the platform half
Ninth extraction, third resurrection. Switched off since 2026-08-13 with the permission reduced to api: [], so assertPermissionTotality was satisfied, the server booted clean, and every panel request 404'd. Closes the same data hazard as jellyfin and soulseek: invoiceshelf/schema was commented out of the drizzle barrel. Named `invoices`, not `invoiceshelf`. The appName is THE id — API prefix, frontend route, table prefix, sidecar suffix, install key — and before extraction the API (/api/invoiceshelf) and the screen (/invoices) had drifted apart, which was harmless only while they were separate hardcoded strings. The route is the part a person sees, and the permission key and label were already `invoices`, so the API prefix was the odd one out. Cost three call sites and a table rename to invoices_accounts, which was free only because the table existed on no server — verified before deciding, not after. members.test.ts re-anchored again, this time to caldav and memos: services with no extraction planned. That assertion has now been re-pointed four times by services leaving for plugins/, which is the whole reason installer.test.ts was made literal earlier tonight. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
ee321f49fd |
refuse a plugin install whose permission key the platform still claims
Three times in one day — photos, soulseek, jellyfin — the same failure on the same machine: install reports success, the dock tile appears, the frontend rebuilds with the route in it, and every request 404s. The plugin never mounted, because setPluginPermissions refused its key as already core. That refusal was correct and useless. It happens at mount time, after the install has reported success, and its only trace is one line on stderr that nobody is reading. The cause is always the same: the key was a CORE permission until the extraction commit, so a server whose platform predates that commit still owns it. The fix is always git pull, and nothing in the product said so. installPlugin now checks the manifest's keys against the core registry before anything is written, and refuses with a message naming the colliding keys and telling the operator to pull the platform and restart. Placed with the other pre-flight checks, so it changes nothing that would need undoing. corePermissionCollisions is exported from the registry rather than reimplemented in install.ts — the core key set has one owner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
aebd6ff0c0 |
jellyfin, extracted into plugins/jellyfin — the platform half
Eighth extraction, second resurrection. Same shape as soulseek: hono.ts had the router import and its PROTECTED_MOUNTS entry commented out since 2026-08-13 and the permission reduced to api: [], so assertPermissionTotality was satisfied, the server booted clean, and every panel request 404'd. Also closes the same data hazard — jellyfin_servers was absent from the drizzle barrel, so bun db:push would have dropped it. No frontend call site needed repointing: mountPrefix derives /jellyfin from the appName, which is what the router already hardcoded. Test fixtures fixed properly rather than re-anchored again. Extracting jellyfin broke 18 tests, the FOURTH extraction in a row to break the same files — photos and transmission yesterday, slskd an hour ago, jellyfin now. installer.test.ts now builds literal CatalogueEntry fixtures and asks the catalogue nothing: it pins planSteps and runInstall, which are installer logic, and a service leaving for plugins/ says nothing about whether the installer still plans the right steps. catalogue.test.ts stays the place real entries are checked well-formed. members/catalogue/preflight re-anchored to memos, which has jellyfin's exact shape. The .prettierignore rule for the vendored hls.mjs moved into the plugin rather than being left behind naming a deleted path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
b196c9cb55 |
soulseek, extracted into plugins/soulseek — the platform half
Seventh extraction, and the first of something that was already dead. Soulseek had been switched off since 2026-08-13: hono.ts carried the router import and its PROTECTED_MOUNTS entry commented out, so createSidecarProxy never ran and registerProxiedPrefix was never called; officer-slskd was not in the ecosystem at all. Because the permission entry had been reduced to api: [], the totality check was satisfied and the server booted clean — the UI rendered and every request 404'd. Worth naming: the boot check proves every MOUNTED prefix has a permission, and is silent about a feature that mounts nothing. Also closes a live data hazard: schema.ts had the soulseek export commented out, so the three tables were absent from the drizzle barrel and bun db:push would have dropped soulseek_favorites, soulseek_browse_snapshots and soulseek_browse_dirs on any server holding them. rebuild-soulseek-tree.ts documented the workaround rather than the problem; deleted with the rest. The connection stays in core service_connections under service 'slskd' while the mount is now /api/soulseek. Those differ on purpose. Test fixtures: slskd was canonical in three app-store tests, the third extraction running to break them. installer.test.ts now builds a literal fixture instead of reaching into the catalogue — it pins planSteps, which is installer logic, and no catalogue entry is both provisioned and members:'none' any more. catalogue.test.ts and members.test.ts re-anchored to vnc/notify/gitea. Unrelated but mine: check:theme caught 5 palette classes I introduced in CommandHQ earlier tonight against a baseline of 0. Converted to bg-success / bg-warning. check:theme is not part of bun test, which is why the green suite never showed it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
c4b262dc51 |
provision-user-dirs script now sets modes, by calling the real provisioner
The script imported DATA_PATH and USER_DIRS from data-path.ts and then reimplemented the mkdir loop without the chmod that module's own provisionUserDirs applies — 711 on the account root, 700 on each subdir. A hand-provisioned account would have come out 755 at the default umask, where a UI-provisioned one is closed. Its header comment warned about exactly this drift while being an instance of it. Nothing was ever created that way here: every account on this box was made by the create-account handler and is correctly 711/700. This is a latent divergence between two paths that claim to produce identical accounts, not damage to repair. Calls provisionUserDirs(email) instead. Two consequences worth naming: re-running now re-asserts modes on existing directories, so it is also the repair; and DRY_RUN skips the call outright rather than gaining a dry-run mode in the real provisioning path to serve a script. Verified: dry run creates nothing, a fresh root comes out 711/700, and a directory chmod'd to 755 is restored on the next run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8a4b96daf8 |
fix question options rendering permanently disabled
AskUserQuestion has no answer channel: it resolves itself the moment it is called, returning "The user did not answer the questions." before the buttons have painted. QuestionActivity gated its options on `message.output === undefined`, so that self-resolve disabled every option on every question, always. Reported from real use — muted text, no-entry cursor, nothing clickable. The output means the tool call is over, which is true and irrelevant. The answer travels back as an ordinary chat message. `sent` is the only real latch. The test was the worse half: it asserted the greyed-out state was correct, using the literal self-resolve string as its fixture. Code and test were wrong in the same direction, so a green suite sat on top of a feature that had never once worked. Inverted it, and verified it fails against the old logic rather than just passing against the new. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f8028364f1 |
transmission, extracted into plugins/transmission — the platform half
Sixth extraction, straight after photos. Everything transmission now lives at gitea.officer.dev/plugins/transmission. Deleted, not commented: the sidecar, the api router, the Transmission app (28 files including detail/ and dialogs/), the screen, the App.tsx route pair, the Dashboard barrel line, the usePageTitle rule, the AppRegistry wiring, the officerdev barrel re-exports, the permission registry entry, the hono.ts import and mount comments, and the app-store catalogue entry. No database change: transmission owns no tables. Its connection lives in service_connections, a core table it now depends on from outside — a real coupling, recorded in the plugin's own PLUGIN.md rather than left to be discovered. ── Test fixtures, repointed rather than deleted ── Transmission was the canonical `members: 'none'` fixture — a single-tenant daemon with no user concept — across three app-store test files. slskd has the identical shape, so the assertions moved there. Deleting them would have quietly dropped coverage of the no-members install path along with the plugin, which is the same trap the vault extraction hit with `members: 'invite'`. ── Vocabulary swept, per the runbook ── Six screens and two App.tsx comments pointed at `/photos` or `/transmission` as the worked example of the Workspace/Panel shape. Both are plugins now, so those pointers dangled at code no longer in the tree. Repointed at /command-hq and /soulseek, which are core. bunx tsgo clean. 1080 pass / 0 fail. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a327dfc82c |
photos, extracted into plugins/photos — the platform half
Fifth extraction, and the clean case: no reverse dependency, configuration already server-side, frontend already panels. Everything photos now lives at gitea.officer.dev/plugins/photos. Deleted, not commented: the sidecar, the api router, the db directory, the Photos app (25 files), the screen, the App.tsx route pair, the Dashboard barrel line, the usePageTitle rule, the AppRegistry wiring, the officerdev barrel re-exports, the permission registry entry, both database barrels, the hono.ts import comment, and the app-store catalogue entry. The catalogue deletion is required rather than tidying — the trap the runbook records as having bitten twice. permissionAvailability() derives from sidecar_installs, which a plugin never gets a row in, so a leftover entry makes the permission permanently 'unavailable' and withholds the route and dock tile on a server where the plugin is installed and working. ── Test fixtures, repointed rather than deleted ── Photos was the canonical app-store fixture across four test files, chosen for being existing|provisioned with members: 'accounts'. Jellyfin has the identical shape, so the assertions moved there — they are about the installer, not about photos, and deleting them would have quietly dropped coverage of the provisioned install path along with the plugin. One loss worth naming: Immich's `provisioned` install mode went with the catalogue entry. Docker provisioning for plugins does not exist yet, so photos is point-at-your-own-instance until it does. bunx tsgo clean. 1080 pass / 0 fail, unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7819eff6a1 |
chat: render AskUserQuestion, instead of dropping it as raw JSON
The model has been asking questions in Officer all along. None of them ever rendered. MessageBubble dispatched the interactive question UI on `toolName === 'question'` — OpenCode's name for it. Claude Code's tool is `AskUserQuestion`, so every question from a Claude session fell through to the generic ToolActivity and printed its input as JSON in a bubble. Nothing threw, nothing logged, and the payload was arriving correctly the whole time, so it read as "the model never asks" rather than as a bug. Both harnesses send the same shape under different names; only the name was ever wrong. ── What this deliberately does NOT do ── It does not make the agent wait. Checked against the installed SDK rather than assumed: AskUserQuestion is implemented inside the bundled cli.js (with its own "No answer provided" fallback), appears nowhere in sdk.d.ts, and there is no control method or hook that can return a tool RESULT. canUseTool and PreToolUse can only allow or deny, and canUseTool is shadowed entirely under bypassPermissions, which is how Officer runs. So the tool self-resolves as unanswered the moment it is called, whatever the client does. The two ways to pretend otherwise — forging a tool result, or smuggling the choice through a denial reason — both lie to the model about what happened. Neither is here. The question is rendered, and the answer goes back as the next message, exactly what a person would have typed. The tool contract is untouched. The cost is real and stated in the file: the agent will usually have carried on and reads the answer a beat late. The day the SDK grows an answer channel, this component is the piece that already knows how to ask. ── Also fixed while in there ── State was single-valued and shared across questions, but the schema allows up to four. With more than one, the first click sent a partial answer and locked the rest. Now keyed by question index: nothing is sent until every question has an answer, and a multi-question reply is labelled by header so it cannot be ambiguous. Multi-select joins with commas, which is what the tool's own output schema documents. `multiSelect` (Claude Code) and `multiple` (OpenCode) are normalised in one place rather than at each read site. 6 tests pinning both harness shapes, the multi-question rule, the client-side "Other" escape hatch (both schemas tell the model not to offer one, because providing it is the client's job), and that an already-resolved question is read-only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
c13271a631 |
runbook: record the hand-rolled-proxy bodyParser trap
Cost an afternoon on the vault extraction and presented as far as possible from
its cause: every POST through /api/vault answered "sidecar unreachable" while
bodyless GETs worked, so it read as an intermittently dead sidecar rather than
a consumed request stream.
bodyParser runs across the protected router and reads JSON and form bodies,
disturbing the stream; a catch-all that then forwards ctx.req.raw.body forwards
something already consumed, Bun's fetch throws, and the catch reports the
sidecar as down.
createSidecarProxy registers its prefix itself, so core sidecars and any plugin
using it never meet this. Vault proxies by hand and the extraction dropped the
registration. Found by the mobile dev, who went looking on the server side
after the app kept failing where the browser extension did not — the split was
the clue, since the extension's routes are mounted above the protected router
and never see bodyParser at all.
Verified before recording: registerProxiedPrefix and isProxiedPath do what the
fix assumes, bodyParser consults them, create-proxy.ts:83 registers for core,
no vault handler reads ctx.get('body') (all three call ctx.req.json()), and the
registered prefix covers every path the mobile app uses while still not
matching /api/vaultwarden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
8367fada13 |
plugins: let a plugin claim top-level paths and divert /api by header
Restores the setup the vault extraction regressed: paste the bare Officer URL
into a Bitwarden client and log in. Nothing else.
The extraction moved the Bitwarden door to /api/vault/bw, which is correct and
unusable — a client derives /api, /identity, /icons and /notifications from ONE
url it is given, so a prefixed base turns setup into five fields copied by hand
into an advanced pane. That is not a feature anyone completes, and the owner
said so. My regression, my wrong call: I treated "a plugin cannot serve
top-level paths" as a fact about the platform when it was a fact about what had
been built.
Two additions, both manifest-declared, both narrow:
unauthenticatedRootPaths single lowercase segments (`/identity`), served
above the gate. Refused if reserved (`/api`,
`/auth`, `/plugins`, `/dav`, …), refused if another
plugin already claims it, refused if it is anything
more structural than one name.
protocolHeaders hands `/api/*` to the plugin when the request
carries one. Needed because /api is the one
namespace both servers claim — Vaultwarden has
/api/sync, Officer has /api/chat — and the path
cannot tell them apart, so the client says who it
is. ROUTING, not authentication: a forged header
reaches the plugin, which demands its own
credential, and cannot reach anything of Officer's.
The worst it does is cost that caller Officer's API.
The Bun route table gets an entry per claimed segment, built from the plugin
set — `refreshPluginMounts` runs at line ~204, long before serve() at ~378, so
the claims are known. This is the constraint I earlier asserted made the whole
thing impossible, without checking it. The real cost is smaller and stated in
the code: a plugin claiming a root path is not fully installed until
`pm2 restart officer`, because the table is fixed once serve() is called.
Every claim is logged at boot by plugin — a root path answering without a
session should not be something you read a manifest to discover.
13 more tests (30 in the file): reserved segments, malformed segments, two
plugins colliding, and segment-not-substring matching so `/identityx` never
matches `/identity`. Suite 1074 pass / 0 fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
dc190bb790 |
plugins: implement unauthenticatedPaths — the half that was never built
`unauthenticatedPaths` has been in PluginManifest since it was designed, with
validation (`publicPathProblem`), a long docstring, and a promise that
`assertPluginPublicPaths` re-checks it at boot. Nothing read the field. No
function by that name existed. Kiosk, the plugin it was written for, declares
none — so it validated, documented itself, and did nothing, and no plugin has
ever actually been served above the gate.
Vault is the first real user: a stock Bitwarden client speaks Vaultwarden's
protocol and has nowhere to put a platform JWT, so it cannot use the
authenticated /api/vault router at all.
── What was missing, and where it had to go ──
Two places, not one, and the second is the one that matters:
• the permission gate skips declared paths — but that gate only runs when a
token WAS presented (`payload && !isOwner && …`), so it is what stops a
valid non-owner reaching something ungranted.
• `protectedRouter.use(userMiddleware)` is what stops an ANONYMOUS request.
A path meant to answer without a session has to skip that too, so it is now
conditional on the same predicate. Fixing only the gate would have left
every declared path returning 401 — passing its own tests and failing in
the one case it exists for.
── Containment ──
Paths resolve against the plugin's own mount (`/api` + mountPrefix + path) and
containment is re-checked there, so a plugin cannot name `/auth` or another
plugin's routes however it edits its manifest. Refusal is per-path: one bad
entry does not take the good ones with it, and each is logged by name.
Matching is on segments rather than characters — `/api/vault/bwx` must not
match `/api/vault/bw/*`, the same class of bug `permissionForApiPath` guards
against with `/user` vs `/username`.
Every plugin with public paths is logged at boot: a route that answers without
a session should not be something you have to read a manifest to discover.
17 tests, pinning the containment rules rather than the happy path. Suite
1061 pass / 0 fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
5e4f3fe29f |
fix all seven failing tests — every one was a stale assertion, not a live bug
The suite has been carried at "1038 pass / 7 fail, same as baseline" for long
enough that the count became the thing being checked instead of the tests. All
seven turned out to pin a contract that changed on 2026-08-13, when a batch of
features were switched off pending plugin extraction. None was a defect in
running code; two were tests that could no longer detect what they were written
to detect.
── Five in registry.test.ts, one root cause ──
Switching a feature off comments out its `api:` line but keeps the permission
(the frontend route still needs gating, and existing role grants have to keep
meaning something). Eleven permissions therefore declare no API prefix now.
• `REAL_WS` still listed 'desktop', which server.tsx stopped serving. The
file's own header says it mirrors that map by hand and that this is "the
drift this file keeps catching" — it caught it, and the failure was read as
baseline for five days.
• 'refuses a claim on a router that no longer exists' withdrew /gitea, which
claims nothing any more, so nothing threw. The test could not fail for the
right reason OR pass. Re-pointed at /tasks, which is core and mounted.
• Two path→permission tests asserted /api/gitea and /api/caldav resolve.
Re-pointed at /tasks and at /user vs /users — the latter is a live overlap
AND a real privilege boundary (resolving /api/users to 'account' would hand
the ordinary-account permission the user-administration API), where the old
/dav vs /caldav pair mapped to one permission and never showed the property.
• 'every permission declares at least one api prefix' stopped being true by
design. Replaced with what it was protecting — a permission must gate
SOMETHING reachable, api or route, since one gating nothing can be granted
and revoked to no effect while reading as a control. `notify` is named as
the one genuine exception rather than silently tolerated: no API, and no
screen by design.
── plugins/music/cliamp: a real ordering fix, pushed separately ──
openPlayer checked for the cliamp binary BEFORE validating the path, so a path
escaping the owner's home answered "cliamp not found on host" on any machine
without it. Fixed there (3f4ee82): validate the request, then inspect the host.
── The pty timeout: an env var that had done nothing for five days ──
The test pinned `HOME_DIR: '/tmp'`. `HOME_DIR` was removed from the platform on
2026-08-13 when the install root became derived, and sessions.mjs resolves `~`
with node's `homedir()` — which reads `$HOME`. So the shell opened in the real
home, `pwd` never printed /tmp, and the test spent its full 15s timeout waiting
for output that could not arrive. One character class of a rename, five days
ago, costing 15s of every suite run since.
1044 pass, 0 fail, 85 files (unchanged). Suite is ~15s quicker for the obvious
reason.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
f6a1194905 |
vault, extracted into plugins/vault — the platform half
Fourth extraction, after offscale, music and email. Everything vault is now at
gitea.officer.dev/plugins/vault and installs from the marketplace; this commit
is what the platform stopped knowing.
Deleted, not commented: both routers, the sidecar, the db directory, the
hono.ts mounts/imports, server.tsx's ws import + handler entry + four
route-table entries, '/vault' from UNPROTECTED_API_PREFIXES, both entries in
totality.ts's exemption lists, both database barrels, and the app-store
catalogue entry.
The catalogue deletion is required rather than tidying — the trap the runbook
records as having bitten twice. permissionAvailability() derives from
sidecar_installs, which a plugin never gets a row in, so a leftover entry makes
the permission permanently 'unavailable' and withholds the route and dock tile
on a server where the plugin is installed and working.
── The one new piece of platform: src/servers/account-lifecycle.ts ──
Three auth handlers (signout, distress, panic) imported clearVaultTokens and
clearVaultUnlockKey directly. That is the security property behind the distress
and panic buttons — "someone got in, make the vault need a master password
again" — so it could not just be dropped, and a plugin cannot be imported by
core.
Rejected: having core DELETE from the plugin's tables by name. It removes the
import but moves the coupling somewhere worse — core would depend on a plugin's
SCHEMA, so renaming a column would silently stop the wipe. A security property
that fails silently on an unrelated change is the failure mode to design
against. (docs/email-plugin-extraction.md took that shape for READING a
plugin's data, where a stale answer is a missing feature rather than a lock
left open. The stakes decide it, not the pattern.)
Taken instead: core announces 'signout' | 'distress' | 'panic' with a user id,
and anything holding per-account state subscribes. ~30 lines, fire-and-forget,
one listener's failure cannot stop another. Core names no plugin, no table and
no column; a listener that is not there is a plugin that is not installed. The
severity mapping moved into the plugin — signout keeps the protector key,
distress and panic drop it — so the behaviour is unchanged.
── Two things deleted rather than carried, both dark since 2026-08-13 ──
The unauthenticated Bitwarden passthrough (/vaultwarden plus four root
prefixes and an /api/* header diverter). A plugin's routes mount into
protectedRouter at /api/<name>, behind the account gate; top-level
unauthenticated prefixes are not something a manifest can declare, and the Bun
route table they need entries in is built once at serve(). Keeping it meant
core naming /vaultwarden and /identity in its own route table — the vocabulary
leak the runbook forbids, for a path its own comments called TEMPORARY pending
a first-party browser extension. Owner's call: nice to have, not a requirement.
The notifications websocket, for the same reason plus a second: no plugin owns
a socket on this platform yet (server.reload({routes}) proven, never called;
handlers in server.tsx is a static map). Music parked cliamp/ for exactly this.
SignalR degrades to HTTP long-polling by itself, so clients still sync.
── Tests ──
Vault was the ONLY members: 'invite' catalogue entry, so deleting it would have
silently dropped coverage of that branch in plannedOutcome. It is now tested
against a synthetic entry instead: deleting an assertion along with the last
real user of a case is how a switch arm stops being covered without anyone
deciding it should.
bunx tsgo clean (verified it really does cover plugins/ by injecting a
deliberate error and watching it fail). Suite back at its 7 pre-existing
baseline failures — none of them this feature's, all confirmed unrelated
(the totality ones are about 'desktop'). 85 test files, unchanged, per the
runbook's trap about a moved test vanishing silently.
Needs `bun db:push` and a restart before installing, then point it at a
Vaultwarden from /vault — VAULTWARDEN_URL in .env is no longer read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
c775e8c7e3 |
re-enable vault — plugin extraction deferred, this is the same code as before
Reverses
|
||
|
pastilhasandClaude Opus 5
|
3803d42243 |
plugins: don't require a literal .git suffix on a catalogue clone URL
Found chasing a real install failure: music's marketplace row was hand- entered as https://gitea.officer.dev/plugins/music with no .git suffix, and fetchPlugin's URL check refused it outright with a message ("https URLs only, no credentials") that named neither actual reason. The suffix was never a security property — https-only, safe character set, no embedded credentials are the real checks, and Gitea/GitHub both clone identically with or without .git. Made the suffix optional rather than required, so a future hand-entered row missing it doesn't hit the same wall. Also fixed the row itself in officer_marketplace (added .git, matching every other plugin's entry) for consistency, and confirmed the gitea repo itself was never the problem — plugins/music already exists there with both commits, unaffected by this bug. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f77a41d26a |
command hq: delete a commander, from the grid card and the detail bar
DELETE /command-hq/commanders/:sessionId — deletes the transcript itself via deleteClaudeSession (the same function DELETE /chat/sessions/:id calls, so a /clear chain goes with it, every part), then the command_hq_sessions row via deleteCommandHqSession (existing, exported, never previously called from a route — its docstring said as much: "no product path to this yet"). Deliberately real deletion, not an unfile-back-to-/chat path — there still isn't one of those, and this doesn't create one. Documented next to "The /chat <-> /command-hq relationship" so it doesn't read as contradicting the "a session never moves the other direction" rule directly above it. Frontend: both the grid card and the detail bar's meta row get an inline confirm (trash icon -> check/cancel), same shape as ChatHistory's own SessionRow delete. The grid card's delete control is a sibling of the card's <Link>, not nested inside it, per docs/navigation-audit.md — the card is a stretched full-cover Link (absolute inset-0, default stacking) with the delete control in its own stacking context (z-10) on top of it, so the card stays click-anywhere except where the trash icon sits. Deleting the commander currently open in the detail panel navigates back to the bare list rather than leaving it pointed at a 404. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a335fad9a6 |
background jobs: tell the agent not to discard command output
Traced "(no output yet)" on a live commander to the actual running process on this machine rather than guessing: the tray's log-tail was working correctly (it's a general /chat feature, nothing to fix there) — the task's .output file was genuinely empty because the agent had written `timeout 8 ping -c 1 -W 5 google.com >/dev/null 2>&1`, throwing away ping's own output and only echoing on a failed ping. Correct for "let me know if it goes down," but it means a healthy watcher shows nothing at all, indistin- guishable at a glance from a stuck one. buildBackgroundJobPrompt gains an unconditional rule — every job shape, not only watchers — telling the agent not to redirect a command's own output to /dev/null or similar: whatever it would print in a terminal is what the owner wants to see live in the job's log. Landed at rule 8 for watchers (after the existing fire rule), 5 for a bare command, 4 for a bare prompt — whichever number falls after the rules already in that branch, so rule 7's existing identity (referenced by number in tests, docs and COMMS) is untouched. Also lightly reworded rule 7's "stay silent" line: it was already only about the agent's own narration, not the underlying command's output, but the distinction wasn't explicit and reads exactly like the instinct that produced the >/dev/null in the first place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
963c965056 |
command hq: auto-name a commander from its watcher's own task description
The initial title (the mechanics preamble, truncated, when a background job is
the very first message) is expected — that's just Claude Code naming the
session from its first message, same as always. But by the time the watcher's
task actually starts, the harness has already handed it a real description
("Watch google.com reachability" for a ping watcher), and that reads far
better than the preamble ever will.
Hooked into the exact moment pendingArmWatcher is consumed — the FIRST arm,
never a self-re-arm, which the watcher-loop code already had to distinguish
for its own reasons. Resolves a fresh ChatIdentity via resolveHomeDir and
calls renameClaudeSession with msg.description. Best-effort: a failure is
logged and does not touch watcherArmed.
Known gap, noted in the doc rather than fixed: the detail panel's title bar
is fetched once on mount and won't live-refresh when this fires while it's
open. The grid's cards don't have this problem since GET /commanders already
polls every 15s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
eed906f45b |
command hq: show token totals alongside cost, not just dollars
Both the grid card and the detail meta bar now read "N turns · 12.3k tok · $0.20" — tokens first, since that's what was actually asked to be primary, dollars kept alongside rather than dropped. formatTokens abbreviates past 1000 (12.3k, 1.2M) the same way a long-running watcher's cost already reads at a glance; the raw sum stops being readable well before the dollar figure does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a9be3a92c9 |
command hq: web frontend v1 — nav, grid, detail
Builds the Workspace/Panel screen the design doc's "Layout, v1" described but nothing had implemented yet: /command-hq and /command-hq/:sessionId, three always-mounted panels (officerdev/src/apps/CommandHQ/) — a flat category nav filtering the grid via ?category=, a commander grid reading GET /commanders, and a detail pane that is either an empty state, the new-commander composer, or the selected commander's resumed transcript. Follows the frontend route conventions in CLAUDE.md throughout: Workspace/Panel framework (locked, three fixed panels, no standalone screen), category and session both addressable in the URL rather than a channel, real <Link>s for every row and card, a route pair (/command-hq + /command-hq/:sessionId) the same shape as /chat's. The composer reuses the exact mechanism /chat already uses to create a commander — an ordinary turn with context: 'command-hq' via useChat/ EmbeddableChat — rather than the mobile-only POST /commanders/new HTTP route. Once the harness reports a real transcript id the URL is replaced onto it (useChat's own permalink writes /chat/<id>, which is the wrong screen here, so that's done by hand). fileAsCommander always files a new commander uncategorised — it has no way to know a category was selected in the composer — so if one was, a client-side PATCH sets it after the fact, the same race POST /commanders/new already resolves server-side for mobile, just resolved here on the client instead. The detail panel's transcript resume mirrors ChatPanelWrapper's fetch-then- mount pattern (GET /chat/sessions/:id first, then useChat with resumeSessionId + initialMessages + paginate) rather than reusing it directly — Command HQ's version is simpler (no dashboard/agent-panel concerns) and scopes rename/category/disarm through Command HQ's own PATCH route rather than /chat's, since a commander lives in a different directory than an ordinary chat session. Card status is the three-state read COMMS/command-hq/mobile-4.md proposed and the design record adopted: green running, amber armed-but-not-running (the watcherArmed && !running pair that makes a silently-dead watcher visible), grey neither. Registered in AppRegistry.tsx, re-exported from officerdev's barrel (route helpers + types, per CLAUDE.md's rule for anything an officer-web screen needs), a CORE_DOCK_ITEMS tile (not in DEFAULT_DOCK_PATHS — opt-in via the Dock settings screen, same as Jobs/Monitor/Activity), and a usePageTitle rule. bunx tsgo clean, suite at its 7 pre-existing baseline failures, none of them this feature's. NOT yet clicked through against a running server — the composer's redirect-on-real-id, the disarm button, the category-race PATCH have all typechecked and nothing more. That's the next real test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
7b7d8bbf36 |
add gen:ecosystem script to rebuild ecosystem.config.cjs from the database
bun gen:ecosystem writes the whole file from three sources: CORE_PROCESSES read directly out of scripts/setup/officer-setup/lib/services.sh (shelled out to bash, so there is exactly one list rather than a TS copy to keep in sync by hand), marketplace plugins that are installed AND enabled in Postgres and actually ship a sidecar/, and app-store services that are installed AND enabled, using each catalogue entry's `process` name against the src/servers/sidecar/<id>/index.ts convention. Extracted `pluginPm2Entry` (a pure DiscoveredPlugin -> Pm2App) out of addPluginToEcosystem so the live install/uninstall path and this from-scratch rebuild share one definition of what a plugin's entry looks like, rather than two that can drift apart. addPluginToEcosystem's own behavior is unchanged. Complements, not replaces, the existing incremental add/remove in servers/plugins/ecosystem.ts — that edits the live file at install time; this regenerates the whole thing, for a fresh clone, drift, or restoring from a backup. Found while testing against this machine's real file, worth flagging rather than silently working around: officer-marketplace (the marketplace.officer.dev process, src/servers/marketplace/server.tsx) is in this machine's ecosystem.config.cjs by hand and is modeled by neither the plugin system nor the app-store catalogue, so this script does not know about it and would drop its entry on a real run. Left alone rather than guessed at. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
9e641bc228 |
COMMS: reply to mobile-4 — cost-tracking schema change, preamble proposal deferred
Tells the mobile side what moved under fields they already reference: watcherLastFiredAt is no longer a column (command_hq_watcher_fires / command_hq_turns hold what it summarized), watcherArmedAt/watcherStoppedAt are new, and two routes (.../turns, .../fires) expose the raw series. Same argument-order bug flagged as a general caution. Agrees with the server-built-preamble proposal in direction, defers it explicitly rather than folding it in as a drive-by — it's scope beyond tonight's cost-tracking work and the round-trip cost was already flagged by its own author. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
764ba23206 |
command hq: per-turn cost ledger, watcher fires as their own table
The owner asked for individual turn token/dollar costs, a running total, cost over time, and cost per trigger — derived, not stored, following the same rule `running` already uses. Two new tables carry it: - command_hq_watcher_fires: one row per trigger (sessionRowId, taskId, firedAt). Replaces the single watcherLastFiredAt column, which lost the previous fire's timestamp every time a new one landed — fine for "when did it last fire", useless for "how many times, and what did each one cost". - command_hq_turns: one row per completed turn (sessionRowId, fireId nullable, inputTokens, outputTokens, totalUsd). Nothing pre-summed — running total, cost-over-time and cost-per-trigger are all queries over this table. Turn count needed no column either: COUNT(*) already answers it, confirmed explicitly with the owner rather than assumed. command_hq_sessions gains watcherArmedAt/watcherStoppedAt in place of any "last fired" cache — set only on the false<->true transitions, so duration (current run, or the last completed one) is computable without a full transition history table. Two new read routes, GET /commanders/:sessionId/turns and .../fires, expose the raw series behind the cost summary and watcherLastFiredAt (now computed via MAX(fired_at), not read off a column — the field survives in the JSON response under the same name). Bug found and fixed while wiring this up, recorded in docs/command-hq.md: recordCommandHqWatcherFired's signature changed from (userId, sessionId) to (sessionRowId, taskId) and one call site kept the old argument order — tsgo stayed clean because number/string still matched structurally. Caught by re-reading every call site by hand, not by any tool. Needs bun db:push before any route answers with real data. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
56911f6874 |
COMMS: the self-re-arm evidence is stronger than either write-up said
Andre's own count: at least 10-15 runs, before and after the current mechanism existed, zero failures. Both notes had it as "hours, this session". Recorded as a correction because it is a different class of claim. "It worked for hours tonight" supports a decision; "it has never failed across a dozen runs and two surrounding mechanisms" supports not revisiting it — which matters, because self-re-arm looks fragile on paper and the instinct of anyone reading it cold is to add a safety net the evidence says is unnecessary. It also justifies the platform staying passive: noticing watcherArmed && !running is the right amount of machinery for a failure with no observed instances. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
971a8bf0d4 |
COMMS: re-synced the preamble, and a proposal to stop having to
The flag was right: apps/commandhq has its own composer and ships a verbatim copy of background-job-prompt.ts, so handoffContract was still promising "the harness re-arms you". Worse than stale — a mobile-armed watcher would have waited for a re-arm that was never coming, firing once and silently stopping. Re-copied and diffed. That is the third re-sync in one session, each caught only because I happened to be reading the diff. A stale preamble typechecks, builds, and produces a job that runs, so nothing catches it. Proposes the fix: build the preamble on the server. It is a pure function of the spec, both clients already assemble that spec locally, and the create endpoint could take the spec instead of a finished prompt — one implementation, on the side that owns the mechanism the text describes. displayText and cwd both drop out as things the server can derive rather than be told. Cost stated too: it puts prompt text behind a round trip. Not asked for tonight. Also records why the mechanism changed, because it generalises: the synthetic turn lost to the fact that this session's own watcher had been self-re-arming for hours with zero failures. A measurement beat a hypothesis. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
624d67ed52 |
watcher loop: the agent re-arms itself, same turn — final mechanism, confirmed against real usage
second correction to the re-arm design tonight, and this one came from the owner, not from me. my plan (platform sends a synthetic follow-up turn once the acting turn's result lands, instructing re-arm) was technically sound — it keeps the agent inside the sdk's own Monitor tracking, which is the thing the FIRST wrong plan (silent respawn) broke — but it costs a real extra turn every cycle. pushed back on with hard evidence: the mobile dev's own watcher, on this repo, this session, had been running with THEM re-arming themselves, same turn, for hours already — zero failures. that beats a reliability concern I raised without having tested it. so: handoffContract now instructs the agent to re-arm itself, as the last action of the SAME turn that handles the notification — no synthetic turn, no platform spawn, no extra cost. exitContract's handoff branch corrected to match (was still saying "the harness re-arms a firing on its own", exactly backwards now). server side simplifies to match: createMessageHandler's task:started hook now handles both cases with one rule — pendingArmWatcher (session-object flag, not closure-captured, since arming happens turns after the closure was built) claims the FIRST task:started as the watcher; every SUBSEQUENT task:started while already armed is read as the agent's own self-re-arm and just updates watcherTaskId to match. task:notification records the fire when it matches the tracked id. the platform never drives anything — it only notices what the agent already did. pulled COMMS/command-hq/mobile-3.md, which answered the PREVIOUS (synthetic turn) version — crossed in transit. their transcript-bloat concern is moot now (no synthetic turn exists to bloat anything). their `watcherArmed && !running` detectable-failure pair stands regardless of which mechanism won and is exactly right — kept as-is, matches their own three-state dot (running/armed-but-not/neither). replied in platform.md. all four proposal items now built: prompt+dialog, stopped-vs-died, the re-arm mechanism (this commit), arming state+plumbing. bunx tsgo clean, suite unchanged (1038 pass, same 7 pre-existing baseline failures). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
cc5340b8e0 |
COMMS: on the synthetic re-arm turn, and the state pair that catches a lost one
The mechanism is right — driving the agent to reissue is the only shape that keeps the notification path intact, and finding restartBackgroundTask unusable before building on it was the better half of that commit. Two things to build in rather than discover. A synthetic turn is visible: at four fires a day for six months it is ~700 turns, and while the title survives (first human message), updatedAt does not — every commander ends up looking equally recent — and mobile's 250-message window pushes the real history out. Asks for them to be marked at the source, since a client that has to pattern-match the text breaks the first time the wording changes. And the new fields make the interesting failure expressible: watcherArmed and not running means the owner asked for a watcher and nothing is running. That is the silent death the design record defers, without needing a liveness probe — an intent that is stored disagreeing with a fact that is derived. Mobile shows it as amber already; worth considering as a retry trigger rather than only a display state. Mobile now carries watcherArmed, watcherLastFiredAt, the three-state dot, disarm via PATCH, and armWatcher threaded from the sheet and read by nobody yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f369b4ca18 |
watcher loop: arming state and end-to-end plumbing, item 3's mechanism found wrong before writing it
item 4 first (schema + plumbing), ahead of the proposal's own suggested
order, because item 3's trigger needed somewhere to write to before it could
be tested at all.
command_hq_sessions gains watcherArmed/watcherTaskId/watcherLastFiredAt.
watcherArmed is allowed to be stored unlike `running` — it's the owner's own
intent, not a live-process fact nothing external can silently falsify the
way a sidecar restart falsifies running. armCommandHqWatcher/
recordCommandHqWatcherFired/disarmCommandHqWatcher in queries.ts, exposed on
GET /commanders, GET /commanders/:sessionId, and PATCH accepts
{watcherArmed:false} to disarm (arming itself has no route — needs a live
task id only a running turn has).
armWatcher threaded the full client-to-server path: BackgroundJobDialog ->
sendWithHiddenPrefix -> QueuedPrompt -> sendPrompt's new last param -> the
chat websocket message -> ClientMessage -> startClaudeTurn's msg. typechecks
end to end, consumed NOWHERE yet — safely inert, not a shipped mechanism.
the real finding: my plan to reuse task-restart.ts's restartBackgroundTask
for the actual re-arm trigger is wrong, and I caught it before writing it
rather than after. that function respawns a process OUTSIDE the sdk's own
Monitor tracking — chat.ts's restart route emits its own task:notification
via emitToSession specifically because the harness stopped watching that
process. it updates the ui; it cannot reach back into the agent's context,
because there's no mechanism by which it could. a handoff watcher needs the
opposite — the agent must be TOLD again when it fires again, which only
happens through the sdk's own notification delivery, which only exists for
a job the sdk itself is still tracking.
so re-arming can't be a silent platform respawn. it has to drive the AGENT
to reissue its own run_in_background/Monitor call — the platform's job is
making that automatic and correct (right command via commandForTask, right
moment, no double-arm), not doing the reissuing itself. likely shape: a
synthetic follow-up turn, not from the user, once the acting turn's result
lands. not implemented — raised with the owner before building around a
wrong assumption a second time tonight.
docs/command-hq.md corrected to match — the earlier "reuse restartBackgroundTask"
claim removed and replaced with what's actually true.
bunx tsgo clean, suite unchanged at baseline (1038 pass, same 7
pre-existing failures).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
7229ce021d |
watcher loop: the prompt/dialog half, and stopped no longer reads as failed
owner's call, confirmed 2026-08-18: implement watcher-loop-proposal.md
exactly as written, before the first real tests — this governs agent
behavior generally, not just command hq. items 1-2 of the proposal's own
suggested order, done; items 3-4 (harness-owned re-arm, arming state on the
commander row) are the harder half, next.
FireBehavior replaces the stopOnFire boolean: 'stop' | 'handoff' |
'keep-going'. handoff carries the proposal's one-sentence contract verbatim
("the harness re-arms you — do not re-arm yourself, and do not build your
own polling loop on top of this one") and rewrites the closing IF IT EXITS
block so it stops contradicting rule 7 (the old universal "do not restart
it, i will start it again" directly lied about what handoff jobs actually
do).
isCommander gates the option to where the promise can be kept. the proposal
frames this entirely in terms of commanders — arming state's only home is
the commander row — so outside one there's nowhere to persist "keep
re-arming this," and offering the option there would make a promise nothing
fulfills. not wired to true anywhere yet: command hq's own composer, which
would set it, doesn't exist. every existing /chat caller is unaffected —
two options, stop default, unchanged from before tonight.
stopped-vs-died (§5): a job officer had just SIGTERM'd came back
status:'failed' (exit code 144) from the harness's own classification,
which this codebase does not control. fixed client-side — the tray already
knows the instant stop is clicked, so it now also marks that, and
useChat's task:notification handler overrides the displayed status
regardless of what the harness reported. known gap, stated in both the code
and the doc: in-memory, so it doesn't survive a refresh in the narrow window
between clicking stop and the notification landing.
docs/command-hq.md gains "the watcher loop" section: what's built, what
isn't, the proposal's own suggested order followed as given.
bunx tsgo clean. suite: 1038 pass (+9 new tests), same 7 pre-existing
baseline failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
f810bdc48e |
command hq: displayText, caught by the mobile side before either of us ran this
mobile-2.md found it: a commander created to become a background job sends buildBackgroundJobPrompt's full mechanics as `prompt` — a page of preamble, the owner's actual sentence only at the end — and command_hq_sessions has no name column, so the title comes straight from `(displayText ?? prompt).slice(0,100)`. without it every such commander titles itself with the mechanics text, and the grid becomes a column of identical unreadable cards. same precedence the websocket path already uses on both clients (sendWithHiddenPrefix on web, useSessionView.ts on mobile) — now the same on this endpoint too. fixed before either side had run this against a real server, so there's nothing to clean up on a live grid. also confirmed rather than assumed, per mobile's other note: cwd cannot be talked into a different one on this path. resolveChatCwd's command-hq branch ignores msg.cwd unconditionally and this endpoint never sets it. replied in COMMS/command-hq/platform.md. also read watcher-loop-proposal.md (exit/act/drain/re-arm as harness infrastructure, "Andre's call" to build it before first tests) — not starting it off a COMMS note alone, taking it to the owner directly since it's a real scope addition beyond what tonight's command hq build was scoped to. bunx tsgo clean, suite at baseline. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhas
|
cc121f3156 | Merge branch 'master' of gitea.officer.dev:officerdev/platform | ||
|
pastilhasandClaude Opus 5
|
7ad64445ee |
command hq: POST /commanders/new, for a client that cannot open the websocket
mobile's need, decided with the owner in COMMS/command-hq/mobile.md, now
built: { prompt (required), categoryId? } -> { sessionId, cwd }, sessionId
being claude's REAL transcript id, not a placeholder.
the owner confirmed prompt is required and described why: a commander
usually starts as an ordinary back-and-forth before a background job is ever
armed via the existing dialog, sometimes it's just "you know what to do" —
either way there's always a real first message, same as any conversation.
no empty-commander case to design around.
getting a real transcript id costs actually starting the turn, since claude
assigns one only once system.init has been reported. extracted the
turn-starting half of handleClaudeCodeChat into startClaudeTurn(ws: ... |
null, ..., onOutcome?) so both the websocket path and this endpoint drive
one spawn function instead of two that drift — handleClaudeCodeChat is now
a thin wrapper with an unchanged signature. onOutcome mirrors every
sendToClient(ws, {type:'error',...}) refusal point (member not signed in,
claude not installed, spawn failure) plus the session:claude success case,
so an http caller gets the real reason instead of a generic 30s timeout.
the category-write race: fileAsCommander (same hook the web path uses,
since context: 'command-hq' is set either way) always files with no
category. the endpoint's own createCommandHqSession is upsert-safe
regardless of which insert wins, and an unconditional setCommandHqSessionCategory
UPDATE runs after — always last, always wins, so the requested category is
what's left standing no matter the race.
said plainly in COMMS/command-hq/platform.md: this refactor of live spawn
machinery did not get the second-pair-of-eyes review i said i wanted before
touching it. bunx tsgo clean, suite at the same 7 pre-existing baseline
failures. not exercised against a running server on either side yet.
docs/command-hq.md updated throughout — API table, "how a commander is
created", "still open" now empty of blockers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
2f3e2db869 |
COMMS: exit, act, drain, re-arm — infrastructure, plus one sentence of prompt
Andre wants this implemented, prompt and code, before the first real tests. The argument is the evidence from running one: every mistake made was mechanical, not judgemental — two watchers alive at once, firing on the agent's own push, forgetting to re-baseline. Those are protocol steps that must happen every cycle, and a model is the wrong thing to hold a protocol across turns when the failure is invisible: a watcher that stopped being re-armed looks exactly like one that has not fired yet. So the harness owns the loop — re-arm from the post-action baseline (which makes draining automatic rather than remembered), one watcher per job, do not fire on the agent's own writes, and know the difference between stopped and died. The preamble stops describing a loop and promises one instead, in a sentence, so the model does not invent its own to fill the gap — which is what happened tonight. And the state belongs on the commander row: a card can say "armed, last fired 3h ago", which derived running cannot, and a row survives an agent that is in a new session or out of context. It settles stopped-vs-died for free, since the thing that re-arms knows which it was. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f652edab54 |
COMMS: answering the two questions on the create endpoint
prompt required — there is no empty-commander case on either client. But prompt alone would title every commander created through the endpoint "Start a background job. The mechanics below are load-bearing..." — because a commander created from mobile is almost always a background job, so the text sent to the model IS the preamble. The websocket already solved this: title is displayText ?? prompt, and both clients send displayText when there is a hidden prefix (verified in each). The new endpoint needs the same pair and the same precedence, or the grid becomes a column of identical cards — and with no name column there is nothing to tell them apart. Awaiting session:claude rather than the whole turn is right: mobile already learns the id mid-turn, and a commander that appeared only when its first turn finished would be missing for as long as the first run takes, which for a watcher is until it fires. Offered to review the extraction diff. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
e9b1ce5e94 |
command hq: the web creation path, and a member could not have used it
`context: 'command-hq'` on a chat websocket turn now resolves to
getCommandersDir(email) regardless of any client cwd, and the row gets
written the moment a real transcript id is known — the same
session:claude/result seed chat_session_models already waits on, a sibling
closure (fileAsCommander) hung off the same two triggers.
found while wiring it, not guessed at: a member's commander turn would have
failed to spawn at all. getCommandersDir is a sibling of home, and
confineUserTree confines every sibling of home to 700 owned by the service
user — unreachable "even by name" — which is exactly wrong for a directory a
member's own turn needs to cd into via setpriv. same shape of bug
resolveChatCwd already tells a story about (general_chat_sessions,
abandoned for the same reason). fixed by chowning commanders/ to the member
the same way confineUserTree already chowns home, and excluding it from the
loop that confines every other sibling. no ACL needed, unlike home — command
hq reads a member's transcripts through listTranscriptsAs, the same
as-the-member read /chat already uses, never as the service user directly.
the gap this leaves: an account provisioned before this commit needs one
manual reprovision (provision-linux-route.ts / manage-users.ts, already
idempotent) before its first commander turn works. documented, not silently
left.
pulled COMMS/command-hq/{mobile,watchers-what-broke}.md from the mobile
side's session — apps/commandhq already exists and typechecks against the
router. their finding: mobile cannot create a commander the way the web
composer does (a context flag two independent clients would have to carry
correctly), and decided with the owner on POST /command-hq/commanders/new
instead. not built server-side yet — the real blocker is that claude does
not assign a transcript id until a turn actually runs, so the endpoint has
to run one and wait for session:claude, which means extracting the
turn-starting half of handleClaudeChat rather than a second copy of it.
replied in COMMS/command-hq/platform.md with the two open questions before
building it (prompt omitted, and wanting a second look at that refactor).
docs/command-hq.md updated throughout to say plainly what's built vs planned
per path (web vs mobile) rather than one blended status.
bunx tsgo clean. suite at baseline (same 7 pre-existing failures).
confineUserTree has no unit tests today (sudo/uid-dependent, matching this
file's existing coverage posture) — not inventing a new harness for one
block inside it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
ff88c93b80 |
COMMS: two watchers, one event — re-arming without stopping the old one
Mine rather than the mechanism's, and recorded because the mechanism invites it: having acted on a fire, I armed a fresh watcher while the previous one was still alive. Two watchers on one branch produce two notifications for one event, and the second is indistinguishable from a real second push. It compounds the self-trigger fault above — the agent pushes, both fire, neither has anything to report. The discipline is dull: stop the watcher before you push, re-arm after. A pgrep before arming costs nothing and catches it. For Command HQ it is a hazard rather than tidiness. A commander armed twice is two processes doing the same work behind one card. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
1c1c669029 |
COMMS: what broke while actually running a background job
Written after arming, firing, draining and re-arming a real watcher rather than reading the code. Command HQ is a home for these, so anything wrong with the mechanism shows up there first and worst — a commander is meant to run for months. Six faults, the first structural: "keep going" and "tell the agent" are mutually exclusive, because a background process reaches the model only when it EXITS. A looping job can do shell work and nothing else — it cannot read a diff or judge whether a push matters. So the dialog offers a mode that silently means "the agent will never see this again", which is the wrong default for the exact case watchers exist for. Asks for a third option: exit, hand back, re-arm. Then: drain before re-arming or lose what lands in the gap; a watcher on a branch the agent also pushes to fires on its own writes, and author filtering cannot help because both sides are Claude; `timeout` does not exist on macOS so rule 6 cannot be followed as written; a job stopped on purpose is reported as failed, which would read as broken on a grid of cards; and the offered working directory is the conversation's rather than the watched thing's. Also what worked and should not be traded away — ask-before-arming earned its place in the first minute — with one caveat: the output rules leave nowhere to report that the thing asked for cannot work as specified. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
f2ae58d29a |
COMMS: notes live in the repo now, starting with command-hq
Andre: keep these in the platform repo with proper tracking rather than scp-ing them to a directory on alpha. A note on a server is invisible to whoever picks the work up next, has no history, and cannot be reviewed beside the change it argues about. In git it is diffable, it arrives with a pull, and the commit that answers a note sits next to the note. First one is the mobile side of Command HQ: what the API got right, and the single thing a client cannot do — create a commander, because no endpoint returns the commanders directory and only the web composer flags the spawn. The decision reached with Andre is recorded there, with the two rejected alternatives and why. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
eb94af87f4 |
command hq: the api, mounted and documented
full REST surface for categories, tags and commanders. core permission (personal: ['/'], no grant to hold — every query is scoped to the caller's own user_id at the sql layer regardless). registered in the permission registry and PROTECTED_MOUNTS together, so totality holds by construction. GET /commanders is the grid endpoint: everything /chat/sessions already returns per session, plus categoryId/tagIds/running. `running` is derived live off collectRunningTasks (now exported from websocket.ts) folded over chat_session_events — not a stored column, on purpose, matching the design doc's stance that a status field would go stale exactly when a sidecar restart silently kills a watcher. GET /commanders/:sessionId deliberately does NOT duplicate the transcript — that stays GET /chat/sessions/:id, unchanged. a client calls both. /chat/sessions now excludes anything filed as a commander (listCommandHqSessionIds, .catch()'d so a hiccup on this feature can't take the whole chat list down) — the other half of the one predicate this whole design turns on. there is deliberately no POST /commanders/new: creation is an ordinary chat turn in the commanders directory, which is the next commit. docs/command-hq.md gains an API reference table for the mobile dev, and a status line at the top saying plainly what is real and what is not yet: needs `bun db:push` before any route returns real data, frontend not started. bunx tsgo clean. suite at baseline (same 7 pre-existing failures, all registry/totality drift and the pty socket test — none touch this router). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
56fe3b22df |
command hq: data model and the shared commanders directory
first commit of command-hq/command-hq.md's design. two tables plus a many-to-many for tags, no server surface yet — this is data layer only. command_hq_sessions has no name column: /chat never persists a title to postgres, renameClaudeSession appends a summary entry straight into the transcript's own jsonl, and that stays the ONLY place a commander's name can live. no status column either — liveness is derived from chat_session_events the same way the background-job tray already derives it, because a stored status would go stale the moment the harness sidecar restarts without a final task:notification and nothing would ever correct it. category is a plain FK (one per commander, confirmed in spec); tags are the many-to-many case, schema only, no ui planned yet. also: getCommandersDir(email) -> DATA_PATH/<email>/commanders, one shared directory for every commander a user has. the first design was per-commander directories and was dropped same-night: creating a fresh directory timed against the harness's own spawn is a race, and a shared pre-existing directory removes it instead of handling it. deliberately DATA_PATH-rooted even for the owner, unlike ordinary /chat which runs in the owner's real home — that's what keeps commanders out of both the owner's own project transcripts and the /chat list. bunx tsgo clean. no db:push yet — next commit is the router, and the table needs to exist before anything can call it; will note the push requirement clearly when that lands. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |