78896793aa467d1233e91418f8eac3bdebd4e0b3
982
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 pastilhas
|
fafc1adbfd |
anthropicViaProxy — the boundary for platform-side Claude calls
The proxy secret lives in sidecar/claude-state.json: platform-internal state whose location, format and permissions are this repo's to change. The first caller outside the sidecar read the file directly, which worked and meant the sidecar could no longer move its own state without breaking a plugin. Plugins import this module now, and only platform code touches the file. A module and not an HTTP route, deliberately: every caller is server-side code in this process, already behind its own gate. An endpoint that spends the owner's subscription would be new surface — reachable by anything with a session, needing its own registry entry — bought for no caller that exists. The day a browser-side caller appears, the route is a thin wrapper over this. The SDK is re-exported from here too, because a plugin resolving its own copy from the plugins' node_modules would have its own class identities — and an error thrown by this copy is not an instanceof the other's RateLimitError, so error mapping silently stops matching. Deliberate unfreeze for @anthropic-ai/sdk ^0.71.0; the lockfile diff is that one package and its json-schema-to-ts dependency. |
||
|
pastilhas
|
f31aeb4f6e |
a restarted process kept an environment the ecosystem file no longer had
startProcess used 'pm2 start <name>' for a process PM2 already knew, which restarts it with the environment PM2 is holding and never re-reads the file. That was harmless while an entry was a script path and a cwd. It stopped being harmless the moment entries carried env. Seen once, immediately: a plugin's allocated port was re-drawn, the installer wrote PORT_SITE=34507 into ecosystem.config.cjs, the sidecar went on serving 3011, and nothing anywhere reported the disagreement. The file and the process simply disagreed, silently, which is the exact failure the port mechanism was supposed to remove rather than introduce. Now it restarts THROUGH the file - 'restart <file> --only <name> --update-env'. The file is re-read, and --update-env replaces the stored environment rather than merging into it, so a variable removed from an entry actually goes away. |
||
|
pastilhas
|
d9110c373d |
a manifest cannot ask for a particular port
A preference sounds helpful and fails silently. When the wished-for number is taken the plugin is handed a different one, the install succeeds, and whatever was configured against the old number goes on pointing at nothing - with nobody told. This afternoon that nearly happened: 3011 was only free because fofos-dev had been stopped twenty minutes earlier, and had it still been running the site would have been given a random port behind an nginx host still aimed at 3011. So the number is always drawn fresh and always kept. Always drawn means it is never something you can assume; always kept means the proxy host is configured against it exactly once. The failure mode that remains - having to go and read the number - is one that announces itself, which the other one did not. isFree went with it; it existed only to test a wish. |
||
|
pastilhas
|
518d329c29 |
the platform can allocate a plugin a port, and remember it
A sidecar already gets a port and nothing here changes that: it binds 0, the
kernel picks, it announces the number. That is right for what it is - a private
detail between two processes, loopback, re-chosen every restart, and nothing
outside Officer needs it.
A port something ELSE connects to is a different thing. A plugin serving a
website has to be reachable from nginx, which means the number must survive a
restart and be knowable by whoever writes the proxy configuration. Ephemeral
fails both, which is why the first site plugin was going to hardcode 3011 and
hope.
So: `extraPorts: [{ name: 'site', preferred: 3011 }]` in a manifest, allocated at
install, persisted in plugin_ports, and delivered as PORT_SITE in the sidecar's
pm2 environment. Environment rather than the registration socket because a socket
answer arrives after the process has already had to decide what to bind, and pm2
is the only thing that can tell a process something before it starts.
What the platform guarantees is the part per-plugin config could never do: no two
plugins are ever handed the same number. That is a unique index rather than a
convention, because a collision is not a duplicate row - it is two services
fighting over a listener where the loser fails to bind and the winner is whoever
started first.
`preferred` is a wish, not a claim. A plugin usually arrives after the thing that
connects to it, and moving that configuration is work the platform can spare
somebody; but a preference that could fail an install would be a claim wearing a
softer word.
Allocations survive uninstall and are released only by purge. The number is
written down where this database cannot see it, so handing it to a different
plugin because this one was briefly removed points that configuration at the
wrong service.
Pm2App gained `env`, emitted as JSON rather than hand-quoted: a port is a number
today, but this is the seam where a path arrives eventually, and one apostrophe
in a value produces a file PM2 cannot parse - which takes every process on the
machine down, not just the plugin's.
Verified: stable across calls, distinct across plugins, released cleanly,
honours a preference, and a plugin declaring no ports gets no env key at all.
|
||
 pastilhasandClaude Opus 5
|
19bbbab907 |
publishing a plugin is pushing a tag
Three mechanisms where there should be one. The catalogue was filled by hand, and each host separately polled twenty-one repositories with git to work out whether a release existed — a second source of truth for a fact one place already knew. Shipping photos 2026.09.03.02 correctly and watching alpha not notice for ten minutes is what started this. The timer. scripts/marketplace-cron.sh, every minute, on the machine that publishes. Safe now only because the previous commit made the sync read tags instead of working trees; over the old one this would have published somebody's afternoon on a schedule. Nothing is written unless the release commit differs from the one already published, so a tick with nothing to do is one query, one fetch per repo and no writes — about 2.7s. One timestamped summary line per tick regardless, because a fresh timestamp is the only thing that separates "nothing to publish" from "the timer died"; a named line only for a plugin that moved. The badge. `updateable` now compares the tag at HEAD with the tag the catalogue says is newest — difference, not ordering, since parsing 2026.08.27.01 works right up until somebody tags v2 and then fails silently. refreshRemote() and its two-minute window are gone with the polling they existed to paper over. The git rule stays as the fallback for a plugin the store cannot speak for: an unregistered checkout, or an unreachable store. That case now reads whatever refs the last pull left, which is the accepted cost of not making every machine poll every repository forever. fetchCatalogue()'s cache went from five minutes to one. It only drew tiles before; now the wait for a release to appear would have been the sync's minute plus its five. Also: the Update button names its destination whenever a release is known, not only on `new-release`. An untagged checkout reports `untagged` and used to lose the tag with it, so the button said "Update" and the owner had to guess where it landed — the marketplace knows, even for a checkout that has never fetched it. Verified: forced a stale row, the timer republished it inside 60s and logged one line. Badge decisions checked against the live catalogue for seven plugins, including the two shapes that matter — at a tag the store agrees with, and untagged with a release known only to the store. 9 release tests pass, 100% of release.ts covered, four of them new and all against real repositories. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
78e89ebcec |
the marketplace publishes releases, not working trees
The sync read `platform/plugins/` — the directories this machine has installed — and imported each manifest off the working tree. So publishing meant "get officer-dev's checkout to the release, then run the script", and nothing showed when that had not happened. Live proof at the time of writing: av-club 2026.08.29.01, kanban 2026.08.29.02, openseo 0.1.0 and fofos-admin 2026.08.29.26 were all in the store, and none of the four has ever been tagged. It is also why the job could not go on a timer. A cron over it published whatever was in a working tree, on a schedule. Now every registered plugin is mirrored bare into ~/.cache/officer-marketplace/mirrors and read AT ITS NEWEST TAG — manifest, README and file list all out of `git cat-file`. No working tree in the path, so publishing something uncommitted stops being a mistake anyone can make. docs/marketplace.md proposed reading manifests over Gitea's API, which needed a sandbox or a committed manifest.json. Git gives the same guarantee with neither, and the trust model is unchanged: we import our own repositories' code. Third-party submissions still need one of those two. The list of plugins now comes from the `plugins` registry table, which the docs always called the authoritative half and which was in fact a by-product of what happened to be installed. That is what lets `finances` be published without being installed here, and it spans orgs — fofos-admin lives under fofos/, which an org listing would have missed. Adding one is `--add <clone url>`. A plugin with no tag is left alone and named in the report, not deleted. It has made no release, so there is nothing true to say about it; dropping its row would be a decision about somebody's plugin dressed up as a refresh. Also: `release_tag` on plugin_metadata, because the tag is the fact when a manifest version disagrees with it; the sync warns on a mismatch. And icon URLs pin to the tag — `/raw/HEAD/` served whatever was on the default branch, via a 303, so a plugin could show one icon and ship another. Verified: 21/25 published from a release, 4 named as untagged, all 14 tag-pinned icons answer 200. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
8d39586de5 |
two minutes, not ten
The way this gets used is: ship a plugin, open the page, look for the badge. Ten minutes of that is indistinguishable from the feature not working — a release tagged at 12:42 was invisible at 12:45 because the last fetch was at 12:37, which is correct and no comfort. Bounded by the page being open: nothing fetches when nobody is looking. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
b2349525fd |
the update badge stops going stale
releaseState compares the tag at HEAD with the newest tag on origin/<branch> — a remote-tracking ref, and nothing refreshed it. Tags arrived at clone and at the fetch pullPlugin does, so you only learned an update existed BY UPDATING. alpha had photos at 2026.08.27.01, last fetched 27 August, comparing this morning's release against a snapshot from before it existed. Truthfully at the latest, and useless. refreshRemote fetches in the background: the request answers from the refs it has and the next one is current. Rate-limited per checkout, one at a time, silent on failure — the list still has a true answer without it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
898209725a |
a plugin owns the routing under its mount
Reverts the manifest route table. Declaring a plugin's URLs to the platform put the platform in the middle of a decision that is not its own, and it was more code than what it replaced. One splat where there were two routes. A splat matches zero segments, so the bare route still works, and the plugin reads its own position off the location. The platform owns where a plugin starts and nothing after it — the same line mountPrefix already draws around its API. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
1fe767ea77 |
a plugin screen can declare its routes
Every screen got `/<route>` and `/<route>/:section` and nothing deeper, so a section had to live in the query string. A screen may now name its routes in the manifest, and give one its own arrangement of the screen's panels. Absent, the old pair is unchanged — which is every plugin but fofos-admin. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
cdbf72c7fe |
the file browser says when something is a link
An arrow beside the name, and the target in its tooltip.
`stat` follows a symlink, so the listing has always described what the link POINTS AT and never that
there was a link in the way. That is right for behaviour — a link to a folder must still say
`directory` so opening it works — and it is why `stat` cannot answer this question at all.
`readdir({ withFileTypes: true })` can, without a second syscall per entry: the kind comes off the
directory entry itself. `readlink` is asked only for the entries that are links, which in an ordinary
folder is none of them.
A BROKEN link now gets a row, and did not before. `stat` failed on it, the entry returned null, and it
disappeared from the listing — nothing said it was there, nothing could delete it, and the folder
quietly had fewer things in it than `ls` showed. It is drawn in the destructive colour with its dead
target in the tooltip.
The target is stored exactly as written rather than resolved. `../originals` moves with the folder and
`/home/…/originals` does not, and rewriting one into the other would hide that difference at the
moment somebody is looking in order to understand it.
An arrow, not a badge or a different icon: the icon says what the thing IS, and a symlink to a folder
is still a folder to whoever uses it. What the arrow adds is the indirection — which is what explains
why deleting it freed no space, or why two places show the same file.
Verified against real links: to a file, to a directory, absolute, and broken.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
ab2336516f |
dev-proxy: a stylesheet's url() is a URL
Two bugs, one line apart, both silent.
The `url(/…)` rule only matched an UNQUOTED target, so `url("/fonts/x.woff2")` — the form every
generator emits — went through untouched. And it only ran on HTML, so a linked stylesheet got the
narrow `/_bun/` rule and nothing else.
Together that meant a site's own @font-face rules kept pointing at `/fonts/…`, which inside the frame
is the platform's root. Every face 404'd and the preview rendered in a system fallback: nothing looked
broken, it just looked like a different site than the one being previewed.
JavaScript keeps the narrow rule — an absolute path in JS may not be a URL. In CSS it always is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
pastilhasandClaude Opus 5
|
160788780b |
the dev proxy did not rewrite srcset
Responsive images 404'd in every preview, and did it silently. The attribute rule matches a whole attribute value, so it could never have handled srcset — that is a comma-separated LIST of "url descriptor" pairs, and prefixing it as one value would mangle the first descriptor onto the first URL. It did not match srcset at all. Silently is the operative word. An <img> with a srcset also has a src, and the src WAS prefixed — but a browser given a valid srcset chooses from it and never looks at src. So the markup read correctly, one attribute pointed at the platform root, and the image was just missing. Found by a logo that would not load in the fofos layout preview. imagesrcset is rewritten too. That is the one on <link rel="preload" as="image">, easy to miss and expensive to miss: a preload that 404s costs a request and leaves the real image undiscovered until the body is parsed, which is the opposite of why anybody adds one. Six tests, including the case that found it — src prefixed, srcset not, image missing — and a protocol-relative candidate left alone, which is the rule everywhere else in this file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
537cc29c3e |
a package with no root entry point is not a broken install
`unresolvableDependencies` asked `Bun.resolveSync(name, pluginDir)` of every declared package. That is the right question for almost all of them and unanswerable for a few. `@tiptap/pm` declares no `main`, no `module`, and an `exports` map with no "." — it exists only as subpaths. You import `@tiptap/pm/state`, never `@tiptap/pm`. Asked to resolve the bare name Bun correctly says it cannot, and this read that as a failed install. It cost a deploy. fofos-admin declares `@tiptap/pm` because tiptap needs it present; the install was perfect — the directory, its dist and thirteen prosemirror packages all there — and the plugin was reported as failed on every host that has it. The strong check stays first, because it is the one that catches a package which installed but cannot be loaded on this machine — `sharp` resolving to a platform-specific binary is the shape it was written for. Only a package that fails it is asked the weaker question: is it there. Present-but-unimportable still fails, since it never reaches the second line. Verified on the host rather than reasoned about: of the five packages fofos-admin declares, four resolve and @tiptap/pm alone does not, and it is present. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
a6d4a18592 |
a plugin can put an action in the file browser's context menu
Tasks already reach that menu and are right for "do this to these files" — a script, run as the owner, reported through the job system, needing no frontend. They are the wrong shape for anything that continues in the interface. "Create Gallery" from a folder is not a job to watch; it is a name to type and a screen to land on, and expressing that as a script would mean a job whose only output is somewhere to go next. So a plugin exports `fileActions` from `web/file-actions.ts` and the generated module collects them. Presence on disk is the declaration, exactly as panels.ts and layout.ts already are — the manifest says nothing, because an action carries its own label and decides for itself whether it applies. They are registered by injection rather than imported by the browser. Plugins.gen.tsx is generated INTO the app, and the file browser lives in a workspace package that app depends on; importing it there would point the dependency backwards and make the package unusable outside Officer's frontend. The selection is resolved by FileGrid, which has it, and FileItem is handed ready-made items. An action receives the whole selection when the right-clicked item is part of one and just that item otherwise — what every file manager does; acting on a selection the click was not part of is the surprising alternative. An action whose `appliesTo` throws hides itself rather than breaking the menu for everything else on it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
9719e36723 |
a plugin may not bring its own React
Installing tiptap for fofos-admin took the whole plugin screen down: "Cannot read properties of null (reading 'useRef')", both panels, nothing rendering. Two Reacts. The platform has 19.2.4; `@tiptap/react` declares React as a PEER, bun installs peers, and 19.2.8 landed in plugins/node_modules where it wins resolution for everything underneath. React holds its hook dispatcher in module state, so a second instance is not a duplicated dependency — it is a broken one, and the error names nothing that would lead anybody here. Easy to reach by accident, since nobody asks for React. It arrives underneath something that does. So platform-owned packages are stripped from the merged list AND deleted after the install, and the second is the one that does the work: no plugin declares React, so there is nothing in the list to strip. Deleting afterwards is crude and deterministic, which is the right trade for a failure whose symptom is every panel on a screen refusing to render. Stripped rather than pinned. Matching the platform's version would still be two copies, and two copies is the entire problem — bun resolves up the tree, so removing them is what makes a plugin use the one already loaded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
912ecd04f7 |
a plugin can hand the agent its own MCP server
openseo is the first: it fronts something that already ships an MCP server, and the choice was to reimplement that vocabulary as Officer tools or hand the real one over. Reimplementing means a second copy that goes stale, and it fails silently — a tool exists upstream that Officer cannot see. Handing it over costs one manifest field. What a wrapper would have bought — authentication, logging, refusal — is already true of the path, because the agent reaches it through Officer's own API with Officer's own gate in front. Wrapping would buy it twice. The manifest declares a PATH and never a URL, and that is the safety property rather than a convention: mcp-host.json carries OFFICER_AUTH_TOKEN, which signs as the owner, so a manifest able to name an arbitrary host would be a manifest able to post the owner's credential anywhere. A path can only reach this machine. Installed AND enabled, since a disabled plugin's routes are not mounted and offering the agent a tool list that 404s is worse than offering nothing. A plugin that cannot be read loses its tools for the session rather than stopping the agent from starting. `generateMcpConfig` becomes async because it now asks the database. Awaited, not fire-and-forget: setMcpConfigPath is what the manager reads when it spawns, so a config arriving later is an agent running without its plugin tools and no sign of why. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
000df7fe45 |
platform events, and thumbnails warmed the moment files arrive
a closed, named list of events — `files:uploaded`, `archive:extracted`,
`files:placed` — each carrying absolute paths and an owner. NOT an event bus in the
open sense: `emit(anyString, anything)` becomes an API nobody can change, because
the moment a plugin listens for a string that string is a contract with no list
saying so. a union means adding one is a deliberate edit and removing one fails to
compile.
TWO GUARANTEES, AND THEY ARE THE WHOLE DESIGN. emit never blocks: it schedules and
returns, so an upload does not wait for a subscriber thumbnailing a HEIC. and a
subscriber cannot fail the operation that triggered it — the upload is written and
answered before anybody is told, so a plugin that is down, slow or throwing gets a
line in the log. tested both ways, sync and async, plus that one failing listener
does not stop the next.
PLUGINS SUBSCRIBE THROUGH THE MANIFEST, same shape as `fileTypes`: `hooks: {
'files:uploaded': '/v1/on-upload' }`. resolved at EMIT time rather than at boot,
because plugins are installed, updated and disabled while the server runs and a
registration made at startup describes a machine that has since changed. nothing
here names a plugin.
CORE IS THE FIRST SUBSCRIBER, and that is deliberate rather than a shortcut. the
thumbnail cache belongs to the platform — its key, its route — so a plugin doing
this work would produce files the browser never looks at. the warmer calls the same
`buildThumbnail` the request path calls, which means HEIC still warms through
av-club via the fileTypes claim, without this file knowing that plugin exists.
AND A SINGLE-FLIGHT MAP, which the warmer made necessary. two callers now want the
same thumbnail as a matter of course: the warmer starts on upload and the browser
asks a moment later. measured before the fix — four concurrent requests plus the
warmer each decoded the same 4032x3024 HEIC and took a slot from a limit of four,
which is a warmer competing with the person waiting rather than helping them. after:
all five share one build, 5.5s once, then 130ms.
verified end to end: upload returns in 56ms, four concurrent requests all 200 in a
single 5.5s build, cached 130ms. 1679 tests, docs:check green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhasandClaude Opus 5
|
21665ed024 |
HEIC opens, thumbnails retry, and both views ask for the same picture
three reports, three causes, none of them the one I would have guessed. "FAILED TO LOAD IMAGE" ON DOUBLE-CLICK. the viewer pointed `<img>` at /raw — the HEIC bytes — and no browser decodes those. `render` was declared on av-club and nothing called it. so core gains /file-browser/render, which forwards a CLAIMED type to the plugin that claimed it, and the viewer uses it for exactly the formats no browser can show. that list lives client-side and is a fact about BROWSERS, not about plugins: chrome and firefox have never decoded HEIC and safari only does on apple's own platforms. everything else keeps using /raw, which streams, supports ranges and paints progressively — all of which a rendered copy gives up. not cached on disk, unlike /thumb: a full-size render is large, looked at once, and keyed on a width the viewer picks. caching it would fill a disk to make the second look at one photograph faster. "SOMETIMES DON'T ARRIVE THE FIRST TIME". two causes and the second one made the first irreparable. the client treated any error as final, so one failure meant a file icon until the page was reloaded. it retries three times over about seven seconds now, backing off, with the attempt in the `key` so the element actually remounts — changing only the src leaves the browser's own failed-request cache in play and the retry is not one. and the SERVER remembered the failure. that is right for sharp and ffmpeg, where the file is the problem and will fail identically forever — it is what stops one bad video spawning work on every scroll. it is wrong for a PLUGIN, which fails while it restarts, while it is busy behind its own limit, and for a few seconds after an update. those pass. cached, no client retry could ever get past them, because the answer came from memory without the plugin being asked again. producer failures are no longer remembered. "THE THUMBNAIL SHOULD BE THE SAME IN LIST OR GRID". it was not, and that was mine: the list asked for 128px and the grid for 256, which are different cache keys. for a jpeg that is milliseconds. for a HEIC it is four seconds per file, so switching views showed icons where the other view had just shown photographs. one size now — the list draws at 28px and the grid at 80, so both downscale either way and 256 is sharp on a retina screen at both. verified: render 589KB webp from a 1.4MB HEIC, png correctly 415, thumb 12KB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
111618bd7f |
a plugin can claim a file type the platform cannot read
the file browser's thumbnailer read what sharp and ffmpeg read, and that list was a constant in core. HEIC forced the question: sharp's bundled libheif has no HEVC decoder, and teaching core to shell out to ImageMagick means the PLATFORM acquiring a system dependency for one format. that is a plugin's job. so a manifest may declare `fileTypes` — extensions, plus a thumbnail path and a render path on its own sidecar. `ls` unions those with core's, so a file only promises a thumbnail when something can actually produce one. `/thumb` forwards a claimed type to whoever claimed it. CORE DOES NOT KNOW av-club EXISTS. it reads a claim at runtime from whatever is installed and enabled, calls a path by name, and falls back to a file icon when nothing claims the type. no import, no name, no special case. PROVEN BY DISABLING IT: heic reports thumb=image with av-club enabled, thumb=none disabled, image again re-enabled. that is the whole requirement — the file browser is what it was without the plugin — and it is a test rather than a claim. the plugin's bytes are cached by CORE, under the same key everything else uses, so a HEIC thumbnail is produced once and then served from disk like any other. that is why `buildThumbnail` takes a producer rather than there being a second path beside it: the cache key with its mtime and size, the concurrency cap and the remembered failures all live in that one function, and a parallel path would be a second place to forget the negative caching. TWO THINGS FOUND BY WIRING IT UP. a claimed-but-not-running sidecar is skipped rather than recorded, or `ls` promises a thumbnail that cannot be fetched while a plugin restarts. and the sidecar authenticates: it accepts `x-officer-user` from anything on loopback, by its own design, so core sends the account the request is FOR — passing anything else would be lying to a plugin that scopes per user. verified: HEIC 2 MB in, 12 KB out, 5.4s cold and 101ms cached; png and mp4 unchanged; 1665 tests; docs:check green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
9cb875ca79 |
core stops claiming HEIC it cannot decode
the revert above took the ImageMagick path back out of core, where it should never have gone: decoding HEIC needs ImageMagick and libheif-plugin-libde265, and the core has no business acquiring a system dependency for one format. that is a plugin's job. this removes the other half of the same mistake. `heic` and `heif` were in core's extension list from the day the thumbnailer was written, which made `ls` promise a thumbnail sharp cannot produce — so every HEIC in a folder cost a request that 422'd before falling back to the icon, and the promise was the only reason the request happened. so without a plugin the file browser is now what it was: a file icon for a HEIC, and no wasted round trip earning it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhas
|
c5b95becd2 |
Revert "HEIC gets a thumbnail, through the decoder that can actually read it"
This reverts commit
|
||
|
pastilhasandClaude Opus 5
|
f4b9596a88 |
HEIC gets a thumbnail, through the decoder that can actually read it
sharp ships its own libvips and libheif built WITHOUT the HEVC decoder, so a HEIC parses its header, reports 4032x3024, and then fails on the pixels with "bad seek". that reads like a corrupt file and is not one — every photograph an iPhone takes is HEVC-coded HEIF, so it is most of what arrives from a phone. ImageMagick links the SYSTEM libheif, which has the codec. so a `.heic` goes through `convert` to a lossless PNG and sharp takes it from there. PNG rather than JPEG for the intermediate so the single real encode is the final one and the thumbnail is not a copy of a copy. removed in a `finally` either way — a failed decode must not leave a stray file a later run mistakes for a finished thumbnail. this is deliberately the same approach av-club has used for weeks (sidecar/sharp/decodable.ts), on these exact files. copied rather than shared, because the platform must not import from a plugin — the dependency only runs the other way, and fifteen lines of spawn is cheaper than inverting it. `convert` exits 0 having written nothing when the codec is missing, so the OUTPUT FILE is the test rather than the exit code. that is not defensive: it is precisely the failure this exists to handle. IT NEEDS `libheif-plugin-libde265`, which is not in a default Ubuntu install — libheif packages its codecs separately and ships the AV1 one, not the HEVC one. declared in av-club's manifest today, and installed on this host to prove the path. without it, `convert` fails the same way sharp does and the browser falls back to the file icon, which is the correct degradation rather than a break. the in-memory failure cache did exactly what its comment said it would: the HEIC stayed 422 after the codec was installed, until a restart. "a restart is the natural moment to give a file another chance after somebody has installed a codec" — written weeks ago, met today. verified: a real iPhone HEIC, 2 MB in, 12 KB out, 5.3s cold and 22ms cached, and the image is right. png, svg and mp4 unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
09518e1e1f |
the three files fb1cf0f6 was supposed to carry
|
||
|
pastilhasandClaude Opus 5
|
a970cb7c5f |
kanban joins the catalogue
it was on disk and discovered but not in BUNDLED, so the plugins page classified it as "a developer working on one" rather than something anybody could install. that is the file's own three-state vocabulary working correctly on an entry I forgot to write — building the plugin and creating its repository does not put it in a catalogue that is still a hand-maintained constant. the entry repeats the manifest because a remote plugin has no directory to read: everything shown BEFORE installing has to be declared here, including the two things worth seeing before consenting — the permissions it wants and the binaries it would make the machine acquire. kanban wants one permission and no binaries. `schema: true` for one table, and the entry says what is in it: a list of FOLDERS. the items are markdown on disk and this plugin keeps no copy, so an uninstall with "delete its data" ticked loses the list and never a line of anybody's work. that is the thing somebody should be able to read before they install it. `sidecar: false` — it reads and writes files with node's own fs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
fb1cf0f6f1 |
the todo board leaves the platform
`/todos` is now the `kanban` plugin. removed here: the router, the screen, the route, the TodoBoard panel, its AppRegistry entry and the `todos` permission. WHAT STAYED, and it is a seam rather than an oversight: `todo/` and `scripts/todo-index.ts`. that folder is the platform's OWN backlog, committed with the platform's own code, and the CLI regenerates TODO.md from a terminal with no Officer running. moving either would have made this repository's own documentation depend on a plugin being installed. so `todo-tree.ts` stays too, with one caller instead of two, and there are now two copies of that logic which will drift. recorded in the file itself and in the plugin's README rather than discovered in six months. the honest fix on the day it matters is to delete the CLI and let the plugin own the format. THE TOTALITY CHECK EARNED ITS KEEP. removing the router left `todos` in permissions/registry.ts and the server REFUSED TO BOOT — exactly what that guard is for. a stale permission naming a route that no longer exists is the kind of thing that otherwise sits there for months granting access to nothing. docs:check then caught two more: the generated platform skill still listed `/todos`, and AGENTS.md claimed 21 permission entries against a registry now holding 20. both fixed, and the AGENTS.md note now explains the drop the same way it already explains caldav's. verified: server boots, `bun todo:index` still regenerates TODO.md, 1665 tests pass (up from 1657 — the ported tree tests run in the plugin now), typecheck clean, docs:check green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
347acf0171 |
Command HQ shows what plugins offer, and what has not been started
the UI half. a row per plugin that ships commanders, below the owner's own
categories and separated from them — because they are not the same kind of thing.
a category is the owner's filing and they may rename it; a plugin is where
something came from and they may not. mixed into one list, "av-club" reads as a
folder somebody made, and the first thing you do with a folder you made is rename
it.
offers sit ABOVE the grid rather than in it. a commander in the grid runs, has a
transcript and has cost money; an offer is a description on disk. drawn as the same
card with a badge, the two look interchangeable, and the first consequence is
somebody hunting for the transcript of a thing that has never run.
an offer STAYS after it is used. it is a template and there is no reason to have
only one — two folders watched for two formats is two commanders from one offer,
and hiding it would make the second look impossible.
the form is drawn from the template's own `inputs`. nothing in the component knows
what av-club wants: options become buttons, boolean becomes yes/no, everything else
is a field. the button names what is missing rather than marking it red.
TWO REAL BUGS FOUND BY WIRING IT UP, both in the list route:
`?category=plugin:av-club` reached `Number('plugin:av-club')` — NaN — and the query
compared `category_id = NaN`. that matches nothing and looks exactly like "this
plugin has no commanders", which is the worst way for a filter to fail. parsed
before the numeric branch now.
and the grid DROPS every row without a transcript. that was right when the only way
to get a row was to start a conversation; it is wrong now, because a commander from
a template arrives deliberately not running — so the thing somebody just created was
invisible, under a toast saying it worked. a row with a `plugin` and no session is
now projected from the row itself, with the zeroes that are true of it, and sorted
FIRST: it is the one that needs a decision. ordinary rows keep the old behaviour,
since a hand-made row with no transcript is a conversation that failed to start and
the design refuses to draw a tombstone for it.
four locale keys, all six languages, parity test green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhasandClaude Opus 5
|
766b18b7f9 |
create a commander from a plugin's template, and refuse to arm a blank one
second half of the backend. GET /command-hq/plugin-commanders lists what the
installed plugins offer; POST /commanders takes {plugin, template, config} and
builds one from it.
the list is SEPARATE from GET /commanders, which returns what exists. merging a
thing that runs with a thing that could be made, distinguished by a flag, means
every consumer has to remember which it is holding.
`watch_dir` doubles as the reference path when a template supplies one. asking for
a reference path AND a watch directory is asking the same question twice and
inviting the two answers to disagree.
THREE FILES, EACH A COPY rather than a reference into the plugin:
state/config.env what the owner answered, in the form the watcher sources
watch.sh copied, so plugins:update cannot change the script a commander
is already running — a watcher whose code moves under it while
armed is a thing nobody could debug
AGENTS.md the template's prose, appended to the brief already written
config.env is generated with every value SINGLE-QUOTED, and that is not decoration:
WATCH_DIR is a path somebody typed, and this fleet has directories called `ABOUT US`
and `70´S`. unquoted, the first space ends the assignment and the watcher watches
the wrong folder — with `rm` downstream of that. verified by sourcing both that path
and one containing an apostrophe in a real shell.
THE ARM GUARD LIVES IN armCommandHqWatcher, not in a route. arming is not a button:
it happens when the agent starts a tracked background job and the platform notices.
a check anywhere else is one the agent routes around by simply starting its loop,
which is exactly what it does. a row with no template is unaffected.
verified end to end on the running server: the template listed, a commander created
from it, watch.sh + config.env (mode 600) + the brief on disk, config.env sourcing
cleanly, and the watcher refusing to start when config.env is absent — which is the
configure-before-running rule enforcing itself at the last line of defence.
still to come: the Command HQ section that shows the offers and draws the form.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhasandClaude Opus 5
|
e4f5e03105 |
a plugin can offer a commander, and offering is not starting
first half: the discovery and the two columns. no routes and no UI yet. PRESENCE IS THE DECLARATION. a plugin with commanders/<name>/COMMANDER.md offers one, and manifest.ts says nothing — same as tasks/ and skills/, and for the same reason: the directory already says it, and a second place to say it is a second place for the two to disagree. read in place through capabilitySources, so only an installed AND ENABLED plugin offers anything and plugins:update changes a template without republishing. A TEMPLATE IS NOT A COMMANDER. what a plugin ships is an OFFER: nothing runs, nothing is scheduled, no directory exists until an owner creates one from it. that is the shape asked for — a plugin may propose recurring work, only a person may start it. `plugin` IS A COLUMN, not a reserved category name. provenance should be structural: a category called "av-club" is a string an owner can rename, merge or delete, and the day they do, a plugin's commanders quietly become ordinary ones with nothing on disk saying otherwise. it also survives an uninstall, which is the point — the commander is still there and the UI can say where it came from. `plugin_config` holds the owner's answers because the form has to be RE-OPENABLE. somebody changing which directory is watched should see the one it is watching, not an empty form. the watcher script is generated from this, so this is the source of truth rather than the script. inputs reuse TASK.md's vocabulary exactly, so the existing form renderer draws them and the existing validation applies. "which folder, which extensions, what output" is the same question a task asks. `missingInputs` is the configure-before-running rule, and it is checked at ARM time rather than at creation. a half-configured commander that exists and is visible is useful; an ARMED one is what would run somebody's disk against a blank setting. columns verified live after db:push: plugin text, plugin_config jsonb. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
de425d9d68 |
.ts is TypeScript here, not a transport stream
caught by deploying: fofos reported `test-setup.ts` as a video. `.ts` is a real video extension — MPEG transport stream — and it was in the list for that reason, but on any machine Officer runs on it is TypeScript approximately always. every source file in every repository was drawing a play badge and spawning an ffmpeg that could only fail. the two ways of being wrong are not the same size. excluded, a genuine transport stream shows a file icon; included, browsing a source tree runs a decoder per file and negative-caches the lot. nobody keeps broadcast captures in a folder they browse from here. m2ts and mts added while in there — the container people actually have, from a camera rather than a tuner, and neither collides with anything. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
pastilhasandClaude Opus 5
|
22a4c65776 |
sharp is a declared dependency, and setup checks both it and ffmpeg
sharp does the images now; ffmpeg keeps the video. each does the job it is for — sharp is libvips in-process, no process to spawn and no pipe, which is an order of magnitude less work for the common case of a folder of photographs. a video has no frame until something decodes one, and that is ffmpeg's and nobody else's. added through the procedure bunfig.toml describes, since there is no --no-frozen-lockfile flag in bun 1.3.14: package.json edited, frozenLockfile commented out for ONE command, lockfile diff read, setting put back, and a frozen install confirmed clean afterwards. WHAT THE LOCKFILE DIFF ACTUALLY SAID, because the friction is only worth anything if somebody reads it. everything is inside sharp's tree: sharp 0.33.5 -> 0.35.4 at top level, @img/colour added, and the per-platform libvips binaries moved 1.2.4 -> 1.3.3. two SHARED packages moved with it — semver 7.7.4 -> 7.8.5 and @emnapi/runtime 1.8.1 -> 1.11.3 — both forced by sharp's own ranges, and both previous consumers (next, editorconfig) kept pinned copies of what they had. next keeps its own sharp at 0.33.5 entirely. nothing outside that moved. ^0.35.3 to match what av-club declares. 0.x caret pins the minor, so ^0.33 and ^0.35 do not overlap — the plugin intersection would have resolved two native libvips trees onto one machine for no reason. THE IMAGE LIST GREW: libvips reads HEIC and SVG and ffmpeg does not, and neither is exotic — HEIC is what every recent iPhone writes, and a folder of them drawing generic file icons was the most visible gap this had. `failOn: 'none'` and `limitInputPixels: false` are both deliberate. libvips rejects a file with any warning in it, and a truncated JPEG — an interrupted copy, a phone that died mid-write — is exactly that; refusing it would make this browser stricter than the viewer somebody opens the file with. the pixel ceiling is a DoS guard for an upload endpoint, and these are the owner's own files already on the owner's own disk: a panorama is not an attack. SETUP, both halves: ffmpeg was never in the package list at all, on any of the four package managers, despite this router shelling out to it for subtitles, audio extraction and audio tracks long before thumbnails existed. it worked because every machine set up by hand already had it. now declared. sharp gets a LOAD CHECK beside node-pty's build check, and reported separately from it. same failure shape — an install that succeeds while the native module does not — but the opposite cause: node-pty compiles and can fail to, sharp downloads a libvips binary for this exact platform and arch and can fail to resolve one. a combined "native modules" verdict would send somebody to rebuild the wrong thing. loading it is the only test worth running; a directory proves nothing, and `versions.vips` proves libvips is bound. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
0d310ab7b0 |
the file browser draws pictures, in both views
images and videos get a thumbnail in grid and list. one <Thumbnail>, two sizes — two implementations would have drifted the first time one learned something the other did not, and the fallback is the part that would have drifted. FFMPEG FOR BOTH, and no new dependency. a video needs a frame extracted, which only ffmpeg does; an image only needs resizing, which sharp does faster and with better format coverage. sharp is nevertheless not used: it sits in node_modules as somebody else's transitive dependency and is absent from package.json, so importing it is an undeclared dependency — the thing the frozen lockfile exists to prevent — and declaring it is a deliberate --no-frozen-lockfile that belongs to whoever owns the dependency list. ffmpeg is already a hard requirement of this router, so this adds nothing to what the machine must have. the cost is HEIC and a few exotics, which fall back to the icon. THE CACHE KEY CONTAINS MTIME AND SIZE. a path alone would be wrong: replace a photo under the same name and every screen keeps the old picture with nothing to clear it but somebody who knows the cache exists. keyed on content, a changed file is a different key — the old entry is orphaned rather than stale, and the response can be `immutable` honestly rather than as a bet. FAILURES ARE REMEMBERED. the browser retries a broken <img> every time it re-enters the viewport, so without this one corrupt video runs ffmpeg on every scroll, forever. in memory, so a restart gives it another chance after somebody installs a codec. `ls` DECIDES what can be thumbnailed, not the client. the browser's own NATIVE_VIDEO_EXTS is deliberately only what a <video> tag can play, which is a different question from what ffmpeg can take a frame out of — every .mkv would have gone without a picture for that reason alone. the entry has just been stat'd, so the answer is a lookup on its name. FOUND WHILE TESTING, and the reason there is a test folder: ffmpeg EXITS 0 HAVING WRITTEN A ZERO-BYTE FILE when the seek lands past the end of the input. a 0.4s clip gave exit 0 and 0 bytes with `-ss 1`, and exit 0 and a real JPEG without it. the retry keyed on the exit code and so never fired, reporting every short video as having no thumbnail. it keys on the output file now — there is one question worth asking an image encoder and it is whether there is an image. four ffmpeg at a time. the grid is virtualised so only what is on screen is asked for, but scrolling fast through a folder of video queues far more than is visible, and unbounded decoding turned a 1.9GB box into a swap storm once already. size is snapped to 64px steps so a panel resizing by a pixel cannot mint a hundred entries of one image. verified: 240 and 256 share a cache entry, 200 gets its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
3d936309a5 |
the list refreshes before the message, and the tab follows the result
reported as "the list does not update without a refresh". the counts were in fact correct, which is the more interesting half: fofos-admin was ALREADY INSTALLED on that host, so the fetch put it in Installed while the confirmation said "click it to install" and pointed at an empty Available tab. right numbers, wrong story. three fixes, and only one of them is the refresh. AWAIT THE REFETCH. `invalidateQueries` is fire-and-forget, so the confirmation appeared while the grid was still rendering the previous answer and the plugin turned up a moment later. that reads as "nothing happened" and sends somebody looking for a refresh button — which is exactly what happened. SAY WHICH THING HAPPENED. a directory and an install row are separate facts: deleting a plugin's source leaves the row, so a re-fetch can land on something the platform still considers installed. the route now reports it, and the message is either "added — click it to install" or "added — already installed". FOLLOW IT TO ITS TAB. if it came back installed, the overview switches to Installed rather than leaving somebody staring at the tab it is not in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
cac58ea044 |
the git-repo button FETCHES, and the card does the installing
it installed, and using it showed why that was wrong: the button is on the grid, the progress log is in the detail panel — so a URL install ran to completion with nothing on screen and the plugin simply appeared, already installed. no feedback, and no moment to change your mind about running somebody's code. cloning alone is enough to make a plugin real. `/api/plugins` lists what is ON DISK, so a fetched plugin shows up with `installed: false` — Available, exactly like a catalogue entry — and the existing card, its Install button and its streamed progress do the rest. one install path, and it is the one people have already used. so `install-from-url` and its streaming twin are gone, replaced by `fetch-from-url`, which clones and stops. the streaming route existed only to carry progress into a view that could not render it. the outcome is REPORTED, since that was the complaint: "fofos-admin added — click it to install", naming what the URL resolved to. the name is derived rather than typed — appName IS the directory, deciding the route, the table prefix and the process name — so being told what it became is the only way to know which card is yours. it stays on screen until the next attempt rather than being a toast that is gone before you look up. discovery is re-run after the clone: fetchPlugin checks the manifest EXISTS, discovery checks it parses. a directory failing that still renders in the grid as broken, which is honest, but saying so at fetch time reaches the person while they are still looking at the field they pasted into. verified: fetch 200 with the derived name, the plugin listed installed=false, a second fetch refused with "already on disk" rather than clobbering it, and the icon present in the clone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
5c6c5b31f8 |
"Install from Git repository", in the marketplace
a button beside the plugin count that becomes a URL field. everything after it is the machinery that was already there: same installPlugin, same step and log frames, same progress panel, same result. STREAMED, because that is what "works exactly like it already does" means here. an install writes an ecosystem entry, starts a process and rebuilds the router; answering once at the end is a spinner that stops, with no way to tell "started the sidecar" from "could not". the frame reader in usePlugins was split out rather than copied — it never cared which URL it read from, and two copies of an incomplete-frame parser is two places to get it subtly wrong. A TWIN ROUTE, not a case inside the verb map. every other verb names an INSTALLED plugin in its path; this one names something the machine has never seen, and its subject arrives in the body. folding it in would mean a route whose `:appName` is ignored for exactly one value of `:verb`. NO NAME FIELD, deliberately. appName IS the directory a plugin sits in — never declared in a manifest — so it decides the route segment, the table prefix and the pm2 process name. a box for it would invite a name that disagrees with the address. it is derived server-side and reported as the FIRST streamed step, which is the moment it can still be cancelled. collapsed until asked for: a permanent URL box at the top of a catalogue reads as the primary way in, and it is the exception — for somebody who already has an address. verified end to end against fofos/fofos-admin: 30 frames, every step from clone to mount, `assets: published to /plugins/fofos-admin/` now that it carries an icon, and the icon served at 256x256 with alpha intact. purged afterwards — officer-dev is not that website's machine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
d273dc6a14 |
install a plugin from a git URL, with no registry involved
the catalogue was the only way a remote plugin could arrive, so "build one and give it to a friend" had no route. the first real case is a plugin that must never be listed: fofos/fofos-admin is one website's admin panel, useful to exactly one person. MUCH smaller than the todo assumed. fetchPlugin already cloned, validated the URL, refused to overwrite an existing directory, checked for a manifest and removed a failed clone. exactly one line tied it to the marketplace — where the string came from. so this is a source parameter threaded through, and a route. THE NAME COMES FROM THE REPOSITORY, because appName is the DIRECTORY name and is never declared in a manifest — the id cannot disagree with where the code sits. that decision is inherited here rather than remade: the repo name becomes the directory, the route segment, the table prefix and the sidecar suffix. so it is checked against ^[a-z0-9]+(-[a-z0-9]+)*$ BEFORE anything is cloned; a half-clone under an unusable name reads as a broken plugin rather than an absent one. the URL is validated identically whether it came from the catalogue or from a person, because the catalogue is not a trust boundary — it is just where a string came from, and the same string reaches the same argv. what differs is who may ask: this route is owner-only, and the owner is choosing what code runs rather than choosing from a list somebody curated. validation is not review, and nothing here reads what it cloned. caught by testing: the source reached installPlugin and stopped there — the fetchPlugin call still had the old two arguments, so a URL install fell back to the catalogue and failed with "no catalogue entry". the guard tests are what surfaced it, because the error named the wrong cause. verified end to end against fofos-admin — cloned, schema applied, mounted, dock pinned — then purged, since officer-dev is not that website's machine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
fb0cc880ac |
sign in as a user, from user management
the support case this exists for is "it does not work for them and it does for me". reproducing that with a password reset means locking somebody out of their own account in order to look at it, which is worse than the bug. THE TOKEN SAYS WHO IS REALLY HOLDING IT. `impersonatedBy` rides on the claim and reaches every handler, because user-middleware puts the whole payload on the context. without it an impersonated action is indistinguishable from that person's own — in a log, in a transcript, in anything keyed on a user id — and a support tool that can forge activity as somebody else is a different and much worse thing than a support tool. ONE HOUR, not thirty days. a session lasts a month because a person uses their own account daily; impersonation is a task you finish. an hour is long enough to reproduce a problem and short enough that a forgotten tab stops being a live credential for somebody else's account by lunchtime. IT CANNOT CHAIN, and that is the guard that matters. `ownerGate` refuses any token carrying `impersonatedBy`, so impersonating another Super Admin does NOT hand user management back — which would have made this a way to launder owner actions through somebody else's id. stated twice, in the gate and in the handler, because one file away is too far for this one. THE WAY BACK IS A STASHED TOKEN, not a route. nothing on the server mints an owner session — a far more dangerous thing to own than this whole feature. the cost is that clearing browser storage strands you as the other person until the hour expires, and signing in again fixes that. the banner is loud and sits ABOVE the header, outside everything a fullscreen panel can hide. the failure it prevents is not a hole, it is forgetting: reading a mailbox or deleting something while believing it is yours. it asks the server who it is rather than decoding the token, so it cannot keep showing a name after the hour has run out. verified end to end against a throwaway account, since this host has one user: impersonate 200 with the target's id and impersonatedBy naming the owner, 60 minute lifetime, /auth/me answering as them; self 400, unknown user 404, chaining 403, user management while impersonating 403; one [SECURITY] line per start. the probe account was deleted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
bf8bfa6859 |
start a commander from a plugin chat, without knowing where anything lives
pointing a commander at a mailbox meant typing its path, which meant a file
browser and an account allowed to walk the disk. only the owner has that — so
"watch my email and tell me when X" was a super-user feature, in a product whose
whole point is that it should not be.
every plugin chat already mounts `ChatHeader` with a `chatContext`, and that
context IS the address: the server turns `{context:'email', contextId:'me@…'}`
into the mailbox's own directory, beside its `emails.db`. so one button on that
header reaches every plugin chat there will ever be, and a new plugin gets it by
declaring the context it already had to declare to have a chat at all. that is
what makes this common to all those chats rather than copied into each.
THE CLIENT SENDS NO PATH, because it has none. a plugin's chats live under
$DATA_PATH/<email>/plugins/<app>/chats and an email chat beside its own database;
both are built server-side and deliberately never sent to the browser. the
resolver moved out of chat.ts into `chat-context.ts` so command-hq uses the SAME
mapping — two copies would be two chances for a commander to watch a directory
its own chat has never been in.
it NAVIGATES rather than creating on the spot. a commander with no first turn has
no transcript, and the grid filters those rows out — so "create it silently"
makes something the person cannot then find. the setup screen is also where the
first turn happens, which is where the job actually gets settled. the button
carries the context there, pre-fills the name, and leaves one button to press.
the reference is shown as what it WATCHES rather than as a path, because there is
no path to show.
caught by testing rather than by reading: `resolveChatContextDir` reads the query
string, and command-hq takes its context in a JSON body — so the first version
resolved every commander to the owner's home. that failure is invisible, since a
commander watching the wrong directory just answers about the wrong thing
forever. the value-taking `chatContextDir` is what command-hq calls.
verified live: context 'email' resolves to email_accounts, plugin/proxy-manager
to its own chats directory.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhas
|
9ec60d6d75 | caldav 2026.08.27.03 — filters on calendar and contacts | ||
|
pastilhasandClaude Opus 5
|
02f20d419d |
an opencode chat you can reopen: it has a name, its messages, and its model
three complaints, one root cause and two small ones. THE TRANSCRIPT CAME BACK EMPTY because the client read `/session/<id>/message` and this build answers that with `[]` — 200, well-formed, and wrong. the same session returns 4 messages on `/api/session/<id>/message`. an empty transcript is indistinguishable from a new conversation, so reopening a chat said "send a message to start" and every message the owner had sent looked deleted. that also explains the third complaint. the model was read from the assistant turns, so no messages meant no model, so the detail reported a bare `opencode`, which the composer cannot match — and it fell back to claude code and sonnet. it now also reads the model off the session record, which is populated before any assistant turn lands. the message shape moved with the endpoint: `type` where it was `info.role`, `content` where it was `parts`, and a user message's text sits on the message rather than in a part. both shapes are accepted rather than pinned to today's build — this reader is the only thing between a working transcript and a chat that looks erased, and a host on a different opencode should lose features, never its history. AND THE ORDER WAS BACKWARDS. the endpoint returns newest first and nothing downstream re-sorted, so the answer sat above the question that produced it. sorted here, because this is the only place that still has timestamps. NAMING: opencode is meant to title a session from its contents and does not, on this surface — sessions stay at `New session - <timestamp>` through a finished turn and past it, which is why the list was a column of "(untitled)". `isPlaceholderOpenCodeTitle` exists precisely because that name leaks into the UI. so the sidecar names a NEW session from the first line of its first prompt, which is what the claude side shows. a resumed session keeps what it has, and if opencode ever does title one it writes after us and wins. verified live on the session that prompted this: 4 messages, in order, model opencode/kimi-k3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
3b1d4cea84 |
permissions off wholesale, by every documented mechanism, plus a backstop
read the documentation instead of the binary, which is what should have happened
hours ago. it says three things this code was getting wrong.
- "permission": "allow" — a BARE STRING, not the object form. that is the
documented way to say "no prompting at all".
- most permissions already default to allow. the exceptions are
`external_directory` and `doom_loop`, plus `read` on `.env`. those are what
was actually stopping turns.
- an agent's own rules take precedence over the global config, and an agent
that declares none inherits the built-in defaults — so a global allow does
not reach it.
so: `permission: "allow"` in the serve config, AND the agent moved to the
markdown FILE form with `permission: allow` in its frontmatter. the file form is
what the docs recommend "for anything non-trivial", and it is the only place an
agent's permissions are honoured — the inline definition ignores both `permission`
and `prompt`, while accepting `description` and `mode`, which is the worst kind of
partial.
WHAT I COULD NOT MAKE TRUE. with all of that applied, the serve still reports
`external_directory: ask`, `doom_loop: ask` and `read *.env: ask` on the resolved
agent. i cannot get that list to come back clean, and i am not going to guess at
it again.
which is why the event-stream approver stays and is the thing actually doing the
work: whatever opencode asks, the platform answers `always`. that is the analogue
of the claude harness's `bypassPermissions` and it does not depend on predicting
the shape of the next gate. the config above is the belt; that is the braces.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhasandClaude Opus 5
|
3082949fac |
answer opencode's permission prompts, because nothing else can
the spinner had a cause and it was none of the four things fixed before it. the
serve was holding a permission request:
{"action":"skill","resources":["calendar-and-contacts"],"source":{"type":"tool"}}
opencode asks before loading a skill. in its own terminal a person answers. here
it goes to a UI that has never heard of it, and the turn does not fail — it SITS
THERE. no error, no log line, nothing in the transcript. three models were blamed
for it, and a paid provider, and the skill itself.
replying `always` by hand released it instantly: the skill loaded and the agent
went straight to the curl the skill describes. so the whole chain was correct and
one unanswered question was holding all of it.
CONFIG IS NOT ENOUGH, and this is the part worth keeping. the serve's config
carries `permission: {skill: {"*": "allow"}}`, the agent's own ruleset reports
`skill * allow`, and it asked anyway. answering is the only approach that does not
depend on guessing the shape of the next gate correctly — and there will be a next
gate, because `external_directory` was the last one.
not a widening: the claude harness runs `bypassPermissions` deliberately, because
CLAUDE.md is explicit that an unsandboxed agent on the owner's own machine is the
point. this is the same stance for the other harness. `always` rather than `once`
so a repeated tool does not re-ask every turn.
when opencode reaches members this becomes a real decision. it is owner-only today
for larger and unrelated reasons, and it goes on the list with them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhasandClaude Opus 5
|
c226e8a46d |
copy the skills, do not link them — a link is what made it hang
the agent called `skill calendar-and-contacts` and sat there. not an error, not a refusal: a spinner, on three different models. opencode grants `external_directory` for the paths it discovered — literally `~/.config/opencode/skills/<name>/*` — and a symlink RESOLVES to the plugin directory, which is not in that list. so reading the skill body fell through to `external_directory: "*": "ask"`, and a server session has nobody to ask. the request waits forever. the permission list the serve reports says it plainly: every skill path is allowed at its LINK location and nothing allows the target. copying makes the real path the allowed path. the cost is drift — a skill edited in its plugin is not live until this sidecar restarts — which is why the copy is rewritten from scratch on every boot, and it is a good trade against a hang with no message. copies are marked so a skill somebody wrote there by hand is never clobbered and ours are replaced rather than merged, so a file deleted upstream cannot survive in the copy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
f0801808c4 |
read the documentation: four things wrong, none of them the model
an opencode agent could not look at a calendar all afternoon. i treated it as a
framing problem, then a regression, then a free-vs-paid model problem, and it was
none of those. the documentation says all four, plainly.
1. A SKILL'S `name` IS AN IDENTIFIER, not a label. it must match
^[a-z0-9]+(-[a-z0-9]+)*$ and equal its directory. every skill here carried a
human title there — "Calendar and contacts" — so every one was LISTED and none
could be LOADED. the agent found the skill, called
skill({name:"calendar-and-contacts"}), and got "Unable to load skill". `title`
is now a separate field and keeps the prose.
2. THERE IS NO `skills.paths` CONFIG KEY. it is in the binary's own config
example and not in the docs, and the difference is exactly this: skills
configured that way are offered to the agent and cannot be opened. skills load
from fixed discovery paths only, so each directory is now SYMLINKED into
~/.config/opencode/skills. links, not copies — one source of truth, and a skill
edited in its plugin is live immediately.
3. `prompt` IS A FILE REFERENCE — "{file:./path}". passing the text is parsed
without complaint and never applied. this is what made it look like a model
problem: the agent existed, the prompt was on its record, and the model had
never seen a word of it.
4. THE `skill` PERMISSION DEFAULTS TO ASKING, and a server session has nobody to
ask, so the call errors rather than waiting. {"skill":{"*":"allow"}}.
also: the platform cached opencode's model list for the lifetime of `officer`,
so signing into a provider and restarting the SIDECAR left the old catalogue in
the OTHER process — six free models, no paid ones, nothing saying why. the cache
is dropped when the sidecar reports a new port, which is the one event that
always accompanies a new serve.
verified: the prompt reaches the model — asked who it is, it answered "Officer,
running on your home server at officer-dev under your user account". 10 skills
discovered through the linked path with loadable names. NOT verified end to end:
a turn that opens the calendar skill and answers from it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhasandClaude Opus 5
|
a873690e27 |
opencode gets an identity, not just a coding agent's
three turns in a row could not look at a calendar while holding the calendar skill, and each failure had a different cause. FIRST: opencode's built-in `build` agent opens with "You are an AI coding agent. Help the user accomplish software engineering tasks." asked about a calendar it reasoned, in its own words, "this isn't a coding task, and I don't have access to any calendar" and never called the skill tool. the index was in its context the whole time. the plumbing was right and the identity was wrong, which is the harder of the two to see. so officer defines its own primary agent — mode primary, `default_agent`, and named explicitly on session create because a default is a preference and this is a requirement. only NEW sessions: a resumed one keeps the agent it was made with. SECOND: setting a custom `prompt` traded one problem for the other. with the built-in agent the index was there and the framing was wrong; with ours the framing was right and the index was gone, so the turn went looking for .ics files in the home directory. `prompt` replaces the assembled system text rather than adding to it. the index is now compiled INTO the prompt by `skillsBlock()` — the same function a claude session uses — so both halves arrive together. ours also carries the PATH to each SKILL.md, which opencode's own block does not: a path can be opened with the file tools every harness already has. WHAT IS NOT FIXED, AND IS NOT THIS FILE'S FAULT. a third attempt still failed, and a diagnostic turn reported system instructions beginning "Tool infrastructure You can call" — not ours — and named a skill (`frontend-design`) that exists nowhere in this install. the only provider this machine can reach is opencode's own hosted gateway on free models; there is no auth.json here. so either the gateway supplies its own system prompt, or a free model is confabulating about its instructions. those are different problems and neither can be told apart without a model whose credential we own. verified: the agent is registered and its prompt is 4,717 characters containing "Calendar and contacts" and the SKILL.md paths; the serve's credential works (a tool process fetched the owner's collections); 10 skills discovered. NOT verified: that any of it reaches the model on this box. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
e867fe72af |
notify one named account — and unshadow /broadcast, which never worked
"can you send a notification to George" had no answer. an agent key reaches its
own holder and nothing else, and the only route that spoke about somebody else
sent to EVERYONE. so the choice was the whole household or nobody.
POST /api/notify/user, ownerOnly, same authority and same reasoning as
/broadcast: everything else under this permission acts on the account asking, and
reaching another person's phone is administration however few phones it is. it
returns the target's email so the caller can see who was reached rather than
trusting an id they typed, and 404s an unknown account rather than letting the
sidecar's silence read as delivery.
AND THE PART THAT MATTERS MORE. /broadcast has answered 404 since the day it
landed. `createSidecarProxy` mounts `router.all('/*')` when it is CREATED, and
hono matches in registration order — so every route added to the proxy's own
router afterwards was forwarded to the sidecar, which has never heard of it.
three days, on a route whose entire purpose was to stop people POSTing to the
sidecar's ephemeral port by hand. a shadowed route does not fail like a missing
one; it fails like a sidecar that has not implemented it, so the 404 reads as
somebody else's problem.
caldav's router learned this on 2026-08-21 and wrote it down. this file now does
the same thing in the same words: the platform's own routes first, the catch-all
proxy mounted LAST.
verified: /broadcast now answers 400 to an empty body where it answered 404
before, /user delivers and reports the address, /_officer/devices still forwards.
found while trying to reach around the notify sidecar's producer secret to do
this by hand — which is exactly what that secret was added to stop, and the
comment above it says so. it stopped me. the route is the way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
|
||
|
pastilhasandClaude Opus 5
|
e6da5d8c77 |
opencode gets the skills and a credential, which it had neither of
an opencode agent could not have used the calendar skill written this morning, and would not have failed usefully either — it had no idea the skill existed and no key to call the platform with. two gaps, one file each. SKILLS: OPENCODE ALREADY HAD THE MECHANISM. it has a `skill` tool, an index compiled into its system prompt, and `skills.paths` in config taking directories of <name>/SKILL.md — the same progressive disclosure claude does over the same layout the platform already stores. so this points it at the SAME FILES rather than compiling a second index in a second format. skills/load.ts says a skill is a path because every harness can read a file; this is the better version of that bet — the harness had the feature all along. verified: `/skill?directory=…` now returns all nine platform skills, "Calendar and contacts" among them. THE CREDENTIAL, AND THE THING TO KNOW ABOUT IT. claude spawns a subprocess per session, so its key is per session and a member's resolves to their own grants. opencode cannot: ONE serve runs every session, so the only environment there is is the serve's own, minted once at sidecar start, belonging to the owner. that is sound today for exactly one reason — opencode is owner-only, enforced at every door in chat.ts because one serve runs as one user. when that lifts, this key becomes a privilege escalation. it is the same blocker as the two already there, not a new one, but it lives in a sidecar where nobody looking at chat.ts would find it, so chat.ts now names it. all three move together. verified end to end: a tool process inside an opencode session ran curl with $OFFICER_AGENT_KEY and got the owner's calendars back. OPENCODE_CONFIG_CONTENT rather than editing ~/.config/opencode/opencode.jsonc — it is inline json, it MERGES into the same chain as the config files (checked in the binary), and it dies with the process. the alternative is the platform editing a dotfile it does not own and leaving state behind that outlives the install. affordances ride the `instructions` key as one composed file, written beside the serve's state. loaded — `/config` shows it — but NOT model-verified: this box has no provider credential in auth.json, so a turn 401s before reaching a model. whoever adds one should check that first. the credential module moved out of sidecar/claude/. it was never claude-shaped; it was just there first, and it had one importer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
f00abe816e |
a sidecar proxy claims only the sub-path it forwards
registerProxiedPrefix tells bodyParser to leave a prefix's request bodies alone. that is correct for forwarded traffic and load-bearing for uploads: a parsed multipart body is re-serialised with a new boundary while the original content-type header is still forwarded, and every upload fails. but a plugin mounts its OWN routes under the same prefix, and those are not forwarded — they are served in-process and they need their bodies. claiming the whole prefix meant every field on them read as missing. caldav hit it the day it was extracted: POST /api/caldav/provision/ios answered "deviceLabel is required" for a request that carried one. its app passwords used to live at /api/dav, a second prefix that was not proxied, and one prefix per plugin ended that arrangement. so `proxiedSubPath` — caldav's sidecar answers `_officer/*` and nothing else, so it claims `/api/caldav/_officer` and the plugin's own routes are parsed normally. omitted means the whole prefix, which is right for every sidecar with no routes of its own, so nothing else changes. this affects any plugin mixing its own routes with a proxy, which is most of them. they have not hit it because their own routes are GETs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
68f3643df7 |
a pull leaves origin/master where it found it, so every checkout looked ahead
plugins:check reported "2 commit(s) NOT PUSHED" for all twenty-one installed plugins on a machine where nothing had been committed. the check was right about what it measured and the cause was here. `git fetch origin HEAD` writes FETCH_HEAD and nothing else. refs/remotes/origin/ <branch> keeps whatever it had, so after a successful pull the checkout sits at the newest commit while origin/master still points at an older one — and every `rev-list origin/master...HEAD` reports the checkout as ahead by however many commits it just pulled. so the remote-tracking ref is refreshed too, explicitly, after the fetch that cannot do it. best effort, because the local branch may not exist on the remote under that name — which is the same reason the fetch asks for HEAD rather than for a branch. fetch also asks for --tags now. tags are how releaseState decides whether there is anything to update to, so a fetch that skipped them left the Update button answering from refs older than the release it was offering. verified by staling a ref on purpose: one false positive before, none after a single pullPlugin. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
c14b686782 |
pm2 save when the process list changes, and a check that does not lie about symlinks
the owner asked whether anything runs `pm2 save` when a sidecar is added or removed. nothing did. PM2 resurrects from ~/.pm2/dump.pm2, written only by `pm2 save`, so the dump was whatever a human last happened to save. today it was FIVE DAYS old: 13 processes saved against 26 running. a reboot would have silently lost every sidecar installed since — bitcoin-wallet, desktop, gitea, invoices, iris, jellyfin, minesweeper, music, photos, soulseek, transcribe, transmission, vault. thirteen features gone, machine healthy, nothing saying why. saved after start AND after delete. removal matters as much: a dump that keeps resurrecting a deleted sidecar brings it back after a reboot as a crash loop for code no longer on the machine. a RESTART does not save — the same processes are running and the dump is already right. best effort and never fatal: a failed save leaves the estate correct and only the dump stale, which is where things already were. failing an install over bookkeeping would be the worse trade. separately, plugins:check filtered directories on the DIRENT's isDirectory(), which answers false for a symlink to a directory. platform/plugins is symlinked now, so the check would have reported "0 plugin repositories, all well-formed" — a green check over nothing, which is worse than a red one. it stats the path instead, the way discover.ts already does. dump saved once by hand as well, since five days of drift was already there: 26 saved, 26 running, no difference. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |