deploy/2026.08.27.01 — the plan, and the version to match it

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
a dock tile for /bots, which had a screen and no way in
2026-08-27 17:06:10 +01:00 · 2026-08-27 17:05:50 +01:00 · 2026-08-27 17:05:50 +01:00 · 2026-08-27 14:32:49 +00:00 · 2026-08-27 14:20:52 +00:00 · 2026-08-27 14:13:40 +00:00
817 changed files with 34692 additions and 10030 deletions
@@ -1,41 +1,594 @@
 # AGENTS.md
-Guidance for any coding agent working in the Officer platform repo.
+Guidance for any coding agent working in the Officer platform repo. **This is the file with the
-
+instructions in it**; `CLAUDE.md` beside it only points here. Both exist because the two harnesses
-**The instructions live in [`CLAUDE.md`](CLAUDE.md). Read it first — this file only points there.**
+discover different names — opencode walks the tree for `AGENTS.md` and nothing else, Claude Code for
-
+`CLAUDE.md` — and one set of instructions must reach both.
 Kept separate so agents that look for `AGENTS.md` by convention find the same guidance as those that
 look for `CLAUDE.md`, without the two drifting apart.
 ## Orientation
-Officer is a self-hosted platform built around **one owner** (user id 1, role `Super Admin`, who
+Officer is built around **one owner** (user id 1, role `Super Admin`, who bypasses every permission
-bypasses every permission check), which since 2026-08-07 also admits **additional accounts holding a
+check), which since 2026-08-07 also admits **additional accounts holding a strict subset of it**. What
-strict subset of it**. Roles are `Admin` / `Member` / `Developer`; what each may reach is decided by
+each may reach is decided by per-role permission grants, resolved on every request.
 per-role permission grants, resolved on every request.
 If a design question turns on "which user", the answer depends on the surface: real for the **app**
-permissions (gitea, music, photos, calendar…), and still always **the owner** for anything
+permissions (gitea, music, photos, calendar…), and still always **the owner** for anything that
-that executes code or touches the disk — terminal, chat, tasks, files, desktop, browser are
+executes code or touches the disk — terminal, chat, tasks, files, desktop and browser are
 `kind: 'execution'` and can never be granted. `src/servers/permissions/registry.ts` is the authority.
-**Mounting a router without a registry entry makes the server refuse to boot.** Read the "Permissions"
+**Mounting a router without a registry entry makes the server refuse to boot.** Read the Permissions
-section of `CLAUDE.md` before adding one.
+section below before adding one.
-This file previously described Officer as strictly single-user with "no tenancy, no roles, no user
+This repo is one of two. The other, `capabilities/`, holds the agent's tasks, tools and skills as plain
-management". That was written to correct an _older_ drift in the opposite direction — a fictional
+files, and is where many changes belong — adding or changing a task needs no code change here and no
-multi-user intranet with a user-invitation API — and it overshot. Both are now superseded by the
+restart.
 paragraph above; treat the permission registry as the source of truth over either.
 This repo is one of two. The other, `permissions/`, holds the agent's tasks, tools and skills as
 plain files, and is where most changes belong — adding or changing a task needs no code change here
 and no restart.
 - [`CLAUDE.md`](CLAUDE.md) — this repo's architecture, conventions and code style
 - [`docs/working-on-officer.md`](docs/working-on-officer.md) — the deployment-wide guide: which
-  directory a change belongs in, how to run and verify it, the task system, and the failure modes
+  directory a change belongs in, how to run and verify it, the task system, and the failure modes worth
-  worth knowing about
+  knowing about
 - `CONVENTIONS.md` — component organisation and React patterns, with rationale
 - `TODO.md` — current direction; takes precedence where it disagrees with anything else
 Treat the code as the source of truth where anything disagrees with it.
 ## Project Overview
 Officer is a self-hosted platform built around one person — the server owner — which since 2026-08-07
 also admits **additional accounts holding a strict subset of it**. It bundles an AI agent, a terminal,
 a file browser, a code editor, a bitcoin wallet, a remote desktop and customisable dashboards
 behind a single web app.
 **The owner/member split, and where the line falls.** This file said "single-user is a hard invariant,
 not a stage" until 2026-08-07. That is no longer true and had already stopped being true when it was
 written: `users` holds six rows. The accurate statement is narrower and more useful —
 - **One owner.** User id 1, role `Super Admin`, created by `POST /auth/bootstrap` while the table is
  empty, pinned there by a CHECK constraint. The owner bypasses every permission check.
 - **Other accounts get only what their ROLE is granted.** Roles are `Admin`, `Member`, `Developer`;
  grants live in `role_permissions`, keyed on role, never on user. Absence denies — there is no row
  meaning "no", so an empty table is a server where members reach nothing but their own profile.
 - **Some things can never be shared, structurally.** Tasks, items, desktop and browser are
  `kind: 'execution'`: they run as the owner's OS user in the owner's home, so there is no level of
  "read" that makes them safe. They have no level at all and the grants API refuses to store one.
 - **And some are shared only because the kernel enforces it.** Terminal, chat and files are
  `kind: 'confined'`, added 2026-08-11 with per-user Linux accounts. They still touch the filesystem
  and still run processes — but not the _owner's_, because the account has its own Linux user, its own
  home, and the kernel refusing everything above it.
  The distinction earns its keep in one place: **a confined grant means nothing without that Linux
  user.** `authorize.ts` drops it for an account whose `osUser` is null, so "granted but unconfined"
  resolves to no access rather than to the owner's home — which is what it would otherwise resolve to,
  since `getOwnerHomeDir` ignores the email it is passed. That rule lives there once and covers the
  HTTP routes, the websocket doors and the dock together.
 So "which user is this" has a real answer for the **app** surface (gitea, music, photos,
 calendar…) and for the **confined** one (terminal, chat, files), and is still always "the owner" for
 anything under `execution`.
 `src/servers/permissions/registry.ts` is the authority and reads as the design document for this.
 **Mounting a router without a registry entry makes the server refuse to boot** — see "Permissions"
 below before adding one.
 **Account creation exists.** `POST /api/users` (owner-gated), with a form under Settings → User Management:
 it validates the password with the same rules bootstrap uses, refuses a role that is not a row in `roles`,
 refuses `Super Admin` outright because there is exactly one owner, optionally takes an inbound SSH key, and
 provisions the Linux account. `POST /users/:id/provision-linux` retries that half if the host was not ready.
 This file said "there is no way to create a second account" for some days after `69a31051` shipped one, and
 `docs/roles-and-teams.md` sequenced a whole phase around building it. Neither is checkable by
 `bun run docs:check` — it compares numbers, and this was prose. Worth knowing as the shape of the failure:
 the counts stay right and the sentences rot.
 ## Architecture
 One Bun process (`src/server.tsx`) serves everything:
 - the React SPA, via Bun's HTML import of `src/apps/officer-web/index.html` (HMR in dev)
 - the REST API, a Hono app mounted at `/api` (`src/servers/hono.ts`)
 - eight WebSocket providers — terminal, chat, task-runner, pipeline, cliamp, cliamp-audio, desktop,
  vault — plus a sidecar registration socket. `terminal` is a byte relay onto the pty sidecar's own
  listener, not a translating bridge; `vault` is the same shape onto Vaultwarden's notifications hub.
 - ~~a browser relay on its own port~~ — switched off 2026-08-13, awaiting extraction into a plugin.
  The extension and `api/browser/` stay on disk; the listener and the `/api/browser` mount do not.
 Long-running and privileged work lives in **sidecars**: separate processes that dial back in over
 `/api/sidecar/register` and are tracked in `src/servers/sidecar-registry.ts`. PM2 runs them
 (the generated `ecosystem.config.cjs` — see below): `officer` (the server), `officer-anthropic-proxy`, `officer-claude-code`,
 `officer-opencode`, `officer-pty`, `officer-vnc`, `officer-music`, `officer-vault`,
 `officer-slskd`, `officer-headscale`, `officer-transmission`, `officer-invoiceshelf`, `officer-wallet`,
 `officer-photos`, `officer-notify`, `officer-caldav`, `officer-memos`, `officer-jellyfin`, `officer-gitea`
 — twenty as of 2026-08-06, and a list that goes stale every time a sidecar lands. `pm2 jlist` is the
 source of truth.
 **`officer-anthropic-proxy` and `officer-claude-code` are not the same thing.** (The second was
 called `officer-agent` until 2026-08-13; older docs use that name.) The proxy holds the Anthropic
 credential and forwards API traffic; the agent is the process that spawns `claude`. They were one entry
 named `officer-claude` until the sidecar-isolation work — which is exactly how the false claim that
 "restarting officer doesn't disturb the agent" survived so long. Every sidecar is a PM2 peer of
 `officer`, so **no sidecar is a child of the server and restarting the server does not kill one.**
 Agents run **unsandboxed as the server owner**, with `--dangerously-skip-permissions`. This is
 deliberate — it is the owner's own machine. Do not add a jail without being asked.
 ## Repository Layout
 ```
 src/
 ├── server.tsx              # the single entrypoint: routes, WS upgrades, static files
 ├── apps/
 │   └── officer-web/        # the SPA shell — Screens/Authentication + Screens/Dashboard
 ├── servers/
 │   ├── hono.ts             # router composition; everything under /api
 │   ├── _middlewares/       # auth, body parsing, the permission gate, rate limiting
 │   ├── api/<feature>/      # one folder per feature, each exporting a router
 │   ├── channels/           # send-claude-code / send-opencode — how /chat drives an agent turn
 │   ├── queue/              # background job engine
 │   └── sidecar/            # sidecar implementations + the wire protocol
 ├── databases/officer_db/   # the only database (Postgres + Drizzle)
 ├── extensions/browser-relay/
 └── workspaces/             # shared packages, each a bun workspace
 ```
 `src/workspaces/officerdev` is the biggest of these: the windowed "apps" (FileBrowser, Chat,
 Terminal, CodeEditor, Desktop, Dashboards, Wallet…) that the shell hosts, behind an `AppRegistry`.
 `src/apps/officer-web` is only the shell — screens, routing and settings.
 **Path aliases** (`tsconfig.json`): `@/*` → `src/apps/officer-web`, `@/components/*` →
 `src/workspaces/components`, `@@/*` → `src/servers`, `@/public/*` → `public`. Workspace packages are
 imported by their package name (`officerdev`, `hooks`, `state`, `types`, `helpers`, …).
 ## Tech Stack
 - **Runtime**: Bun (Node 22 or newer is enforced by a `preinstall` check)
  That check demanded _exactly_ 22 until 2026-08-12. The reason was a `node-pty` build
  failure some months earlier, whose details were not recorded. It was relaxed to `>= 22`
  after confirming node-pty ships **no Linux prebuilds** — its install script always falls
  through to `node-gyp rebuild`, so it compiles against whatever Node is present and there
  is no ABI to mismatch. Untested on 24 at the time of the change. If `bun install` fails
  building node-pty, or `officer-pty` cannot load its native module, restore the exact pin
  first. The source build also needs `build-essential` and `python3`.
  **Bun itself is held at the 1.3 series, on purpose and temporarily.** 1.4.0 was published
  2026-08-20; the owner asked on 2026-08-22 to stay on 1.3 for a few months until 1.4 has been
  watched. Two places carry that number and they move together: `BUN_SERIES` in
  `scripts/setup/machine-setup/lib/dev.sh`, which resolves the newest `1.3.x` from the npm registry
  and passes it to the installer as a release tag, and `engines.bun` in `package.json`, which is
  what `bun run doctor` reads. bun ignores `engines` (verified — an install declaring `1.9.x` ran
  clean under 1.3.14), so that field is the declaration and doctor is the enforcement.
  **Do not run `bun upgrade` on a machine running Officer.** It takes no version argument — latest
  stable or `--canary`, nothing else — so it jumps straight past the pin and says nothing. That is
  the whole reason `doctor` checks the running version at all; `machine-setup.sh --only 'JavaScript
 runtimes'` offers to pin a drifted machine back down. Lifting the hold is `todo/infra/`.
 - **Language**: TypeScript, strict. `bunx tsgo` is clean — keep it that way.
 - **Frontend**: React 19, React Router 7, React Query, Tailwind 4, shadcn/ui + custom components
 - **Backend**: Hono
 - **Database**: Postgres via Drizzle — `officer` for the platform, plus `officer_marketplace` on the
  host that serves marketplace.officer.dev (see `docs/marketplace.md`)
 - **Agents**: Claude Code and opencode, driven through sidecars; tools exposed over MCP
 ## Data
 Two stores, and the split matters:
 **Postgres** (`src/databases/officer_db`) holds the account, passkeys, settings, dashboards,
 queue and pipeline jobs. Since 2026-08-16 there is a SECOND database,
 `officer_marketplace` (`src/databases/marketplace_db`), and the split is deliberate: it is a public
 catalogue served by a process with no login, no session and no user, so sharing a connection would put
 an unauthenticated surface one query away from every private table. It runs only on the host serving
 marketplace.officer.dev — `docs/marketplace.md`. One directory per feature holding `schema.ts` and
 `queries.ts` beside each other; `src/schema.ts` is what `db:push` reads, and it lists the core tables
 with the plugin ones commented out. Types inferred from the schema in `src/types.ts`.
 **The filesystem** holds everything the agent authors. `OFFICER_ITEMS_DIR` (`$OFFICER_ROOT/capabilities`)
 contains one directory per item under `skills/`, `tools/`, `tasks/`, `processes/`, `extensions/` — no
 database rows, no scope tiers. `DATA_PATH/<email>/` holds the managed home and attachments. It also holds
 `email_accounts/`, which is the **email plugin's** — the platform pre-creates the directory and never opens
 what is inside it.
 **None of those paths is configured.** Since 2026-08-13 `src/servers/data-path.ts` derives the install
 root as `resolve(process.cwd(), '..')` and hangs `data/`, `permissions/` and `dockers/` off it. That
 replaced `DATA_PATH`, `OFFICER_ITEMS_DIR` and `HOME_DIR` in `.env` — three values that had to agree with
 each other and with the tree on disk. `assertInstallLayout` refuses to boot when the working directory
 is not the repo, because otherwise a wrong `cwd` relocates the whole install silently rather than
 failing.
 Note `getHomeDir` (the managed home under `DATA_PATH`, now used only for NON-owner accounts and by
 pipeline-executor) versus `getOwnerHomeDir` (the owner's real login home, where terminals, chats and
 task runs execute — captured from `homedir()` once at module load, and it ignores the email it is
 passed).
 ### Schema changes use `push`, not migrations
 This database is kept in sync with `bun db:push`, which diffs the schema code against the live
 database and alters it directly. **`drizzle-kit migrate` has never been run here** — there is no
 `__drizzle_migrations` table. Change the schema, run `bun db:push`, done.
 `bun db:gen` writes files to `officer_db/migrations/`, but nothing applies them; the old numbered
 history was deleted because it had drifted from the real schema. Treat the schema code, not those
 files, as the source of truth.
 **Declare multi-column uniqueness as `uniqueIndex('uq_…').on(a, b)`, never `unique('uq_…').on(a, b)`** —
 drizzle-kit mis-diffs named composite unique _constraints_ and re-creates them on every push, which used
 to stop `db:push` on an unanswerable truncate prompt. Same for any foreign key whose generated name would
 exceed Postgres's 63-character identifier limit: name it explicitly. See `src/databases/CLAUDE.md` →
 "Composite keys" before adding either.
 ## Security Model
 - `IS_DEV_BUILD` (`src/servers/build-env.ts`) is true **only** when `PUBLIC_BUILD_ENV` is explicitly
  `dev`/`development`. Everything else, including unset, is hardened. Rate limiting and password
  rules key off it — they fail closed.
 - **There is no origin checking.** It was removed on 2026-08-13, along with `ALLOW_ANY_ORIGIN` and
  `ALLOW_ANY_ORIGIN_MUSIC`. The flag defaulted to ON, so origin validation ran on no real install —
  what came out was documented defence in depth that was already switched off. Origin was never
  authentication here anyway: an app's `officer://<hex>` origin is chosen by the client, forgeable
  outside a browser, and extractable from a shipped binary. The perimeter is the tailnet, and the lock
  is a valid token on every protected route plus the permission gate below.
 - JWTs are 30-day, blacklisted on signout, and invalidated by a password change (`passwordChangedAt`).
  **The role is deliberately not a claim** — every authorization decision re-reads `users.role` from
  Postgres, so a grant or a revoke takes effect on the next request rather than at next sign-in.
 - A panic lockdown (`src/servers/api/auth/panic.ts`) is in-memory only and refuses every
  authenticated request until the server restarts.
 ### Permissions — read this before mounting a router
 Authorization is one system, and it is not in `userMiddleware` (which only answers "is this token
 valid"). It is `_middlewares/permission-gate.ts` → `permissions/authorize.ts`, mounted globally in `hono.ts`
 ahead of everything, and it re-verifies the token itself so it covers routes that never mount
 `userMiddleware`.
 - `permissions/registry.ts` — the single enumeration of what the platform can do, in five kinds:
  `core` (every account, not deniable), `app` (**the grantable surface**), `confined` (grantable, but
  only to an account that has a Linux user), `execution` and `admin` (owner only, and `execution` is
  never grantable at any level). **21 entries as of 2026-08-27** — verified by `bun run docs:check`, which fails if this number drifts again: 6 core, 2 app, 4 confined, 3 execution, 6 admin (`todos`, the todo board, is the sixth). It was 22 until caldav became a plugin and took `calendar` with it — a plugin's permission is registered at runtime from its manifest, so it is real but not in this file's count. `notify` moved from `app` to `core` on 2026-08-24: it was grantable, nothing granted it, and every Member's app was silently 403'd registering its own push token. It said 27 for nine days. The execution count dropped by one when Minesweeper became a plugin — see `plugins/minesweeper/manifest.ts` for why that was a fix rather than a downgrade.
 - `permissions/authorize.ts` — resolves "may this account do this". Owner short-circuits first; every
  other answer is role grants plus core, with `execution`/`admin` stripped even if a row grants them,
  and `confined` stripped for an account with no `osUser`.
  **Every catch returns deny.** Grants are cached by role and the cache's whole invalidation contract
  is `invalidateRoleGrants`, called by the one writer in `api/users/permissions-routes.ts`.
 - `permissions/totality.ts` — `assertPermissionTotality` runs in `server.tsx` **before `serve()` and
  throws**. Mount a router or a socket without a registry entry and `pm2 restart officer` fails,
  naming what is missing. That is deliberate: the hole it closes was a Member 403'ing on
  `GET /api/tasks` and opening `/api/tasks/pipeline/ws` with a 101 in the same minute, because Bun's
  route table matches the socket before the `/api/*` catch-all that reaches Hono. A patch does not
  survive the next door; refusing to boot does.
 So **adding a router means adding one line to `CAPABILITIES`**. If the surface genuinely is not
 user-gated, add it to `EXEMPT_API_PREFIXES` in `totality.ts` _with a reason_ — an unexplained exemption
 is how the hole happened the first time.
 The frontend hook `usePermissions` **fails open** on purpose: hiding a dock icon is a courtesy, the
 403 is the lock, and an owner locked out by a transient network error is worse than a member clicking
 into a refusal.
 ## Commands
 ```bash
 bun dev          # the whole app — SPA + API + WebSockets, watched
 bun start        # production
 bunx tsgo        # typecheck (not tsc)
 bun test         # tests
 bun format       # prettier over every dirty file — see the note below before running it
 bun db:push      # apply the schema to Postgres
 bun docs:check   # do the docs still match the code? REQUIRED before tagging a release
 bun setup        # runs scripts/install.sh — blank machine to running platform
 ```
 **`bun docs:check` before every release, and leave it green.** It compares documented claims against values
 derived at run time — the permission count, the PM2 entry count, every settings route Spotlight offers — and
 exits non-zero on drift. A check must never compare a doc against a second hard-coded copy; that is one more
 place to drift, and it drifts in the same edit that misses the doc.
 It is narrow on purpose. It cannot read prose and judge it, only claims with a machine-checkable
 counterpart — which is a small part of the documentation and the part that rots fastest, because a number is
 exactly what nobody re-derives while editing the sentence around it. Both claims it found on the day it was
 written had been wrong for over a week.
 `scripts/install.sh` is only an orchestrator — it runs the two halves in order and does nothing itself:
 `setup/machine-setup/machine-setup.sh` (28 sections: packages, tailnet, runtimes, docker, shell) then
 `setup/officer-setup.sh` (11: pre-flight, layout, repository, dependencies, database, environment, secrets,
 schema, build, services, verify). Either runs alone — `--machine-only`, `--officer-only`, or by path — because
 a machine you already trust needs only the second. Both are re-runnable: each records the steps it finished
 and skips them, so stopping halfway costs nothing. **Run it as yourself**; it re-execs through `sudo` when it
 needs to, and on macOS never does, because Homebrew refuses to run as root.
 Sidecar control is PM2, not npm scripts: `pm2 restart officer-<name>`, `pm2 logs officer-<name>`.
 See `docs/working-on-officer.md` for which process a given change needs restarted.
 ### Installs are frozen. Never resolve a dependency you did not ask for.
 `bunfig.toml` sets `[install] frozenLockfile = true`, so **`bun install` resolves from `bun.lock` and
 nothing else** — it fails rather than quietly picking up a newer version, including a transitive one
 nobody chose. Verified on bun 1.3.10: a lockfile that no longer satisfies `package.json` exits 1 with
 `error: lockfile had changes, but lockfile is frozen`.
 It is config rather than a habit because a supply-chain compromise does not wait for the one time
 somebody forgets a flag. On **2026-08-04** eleven cache packages — `keyv`, `flat-cache`,
 `file-entry-cache`, `cacheable-request`, `cache-manager`, the `@cacheable/*` scope, `ecto` — were
 published with a `preinstall` dropper that harvested npm and GitHub tokens, AWS and Kubernetes
 credentials, SSH and PEM keys, `.env` files and `.claude/settings.json`, then republished itself
 through any npm token it found. It reached 434 further packages across 1,381 versions. This machine was
 unaffected only because nothing had installed since 2026-08-02.
 **To change a dependency:** edit `package.json`, allow the lockfile to change deliberately, **read the
 diff**, and commit it. Note that `--no-frozen-lockfile` — which this file and `bunfig.toml` both used to
 name — is NOT a flag bun 1.3.14 has; it is silently ignored and the install still fails frozen. Comment
 out `frozenLockfile` in `bunfig.toml` for the one command, then put it back. The friction is the point — an unexplained lockfile change
 in a diff is the signal this exists to produce.
 **Do not** add `--no-frozen-lockfile` to a script, a Dockerfile or CI to make an error go away. The
 error means the lockfile and `package.json` disagree, and that is worth a human look every time.
 **Format your own files, not the whole dirty tree.** `bun format` globs `git diff --name-only HEAD`,
 so it rewrites every uncommitted file — including work in progress that isn't yours, which then shows
 up as unexplained whitespace churn in someone else's diff. Run `bunx prettier --write <paths>` on the
 files you actually touched. `bun format` is only safe when the tree is otherwise clean.
 ## Code Style
 - **Paradigm**: functional — pure functions, immutability, composition
 - **TypeScript**: strict, no `any`. Type-only imports are required (`verbatimModuleSyntax`).
 - **Comments**: minimal, and about _why_. Don't narrate what the code already says.
 - **Async**: always async/await
 - **Exports**: named only, no defaults
 - **Files**: `PascalCase.tsx` for components, `kebab-case.ts` for everything else
 - **Prettier**: single quotes in JS, double in JSX, semicolons, trailing commas, 120 cols
 ### Imports
 Order: types → external → workspace → relative.
 ```ts
 import type { User } from 'types';
 import { useState } from 'react';
 import { useQuery } from '@tanstack/react-query';
 import { useClient } from 'hooks/useClient';
 import { formatDate } from 'helpers/formatters';
 import { useWebsites } from '../useWebsites';
 ```
 In app code import types from `'types'`, which re-exports the database types. Only server and
 database code imports from `officerdb/types` directly.
 ### Functions
 Arrow functions for one-liners, regular functions for anything with real logic. No multiline
 parameter lists — extract a params type instead.
 ```ts
 type ProcessDataParams = { body: Record<string, unknown> | undefined; query: Record<string, string> };
 export function processData({ body, query }: ProcessDataParams): Result { ... }
 ```
 ### Components and hooks
 ```tsx
 type ExperimentCardProps = { experiment: Experiment; onSelect: (id: number) => void };
 export const ExperimentCard = ({ experiment, onSelect }: ExperimentCardProps) => { ... };
 ```
 Complex hooks return objects; simple state hooks return `as const` tuples. Event parameters are
 always named `ev`, never `e`.
 ### API calls
 `useClient()` returns typed verbs — `client.get<Foo>('/foo')` really does return `Foo`, so pass the
 type parameter and let inference flow from it.
 ## Working With Me
 - **Ask first** — confirm the approach before a significant change
 - **Explore thoroughly** — read the related files before editing
 - **Keep it simple** — no over-engineering, no premature abstraction
 - **Be explicit** — no magic, no implicit behaviour
 - **Stay focused** — note unrelated problems, don't fix them uninvited
 - **Report honestly** — say what you verified and what you didn't
 **Always commit and push when you finish implementing — including when it went wrong.** Don't wait to be
 asked, and don't hold a branch back because it is unfinished, untested or turned out to be a dead end. The
 history of the mistakes is worth having: a reverted commit and its message explain why an approach was
 abandoned, which is exactly the thing that gets lost when a failed attempt is quietly discarded. Say what
 state it is in — in the commit message and in `COMMS/` if another agent will pick it up — rather than
 withholding the commit until it is good.
 Commit messages: simple lowercase, no prefixes.
 **Stage and commit in ONE step, naming the paths.** `git add <path>` then a bare `git commit` commits the
 whole **index**, not the path just named — so anything a concurrent session had staged goes into your
 commit, under your message and your session trailer. Use `git commit -- <paths>` instead, which does what
 the two-step form only looks like it does.
 This is not hypothetical and it is not rare: two agents share this working tree most nights. On
 2026-08-23 commit `6e092c32` says "marketplace: minesweeper in the catalogue" and contains nine files of
 another session's roles work, swept up mid-`git add`. The other session was right not to amend it —
 rewriting shared history to fix a message is the worse trade — so the record was corrected with a
 follow-up note instead. Cheap to avoid, awkward to undo.
 Two things about the form itself, both learned the same night. `-m`/`-F` goes BEFORE the `--`, or git
 reads the message as a pathspec. And it only works on **tracked** files — a new file must be `git add`ed
 first, so a commit introducing one is `git add <new>` then `git commit -- <paths>`, naming every path.
 Getting that wrong fails loudly, which is the good case: the release tag that followed it went onto the
 wrong commit, and only because the tag was checked afterwards did that surface at all.
 **An agent's commit names the session that made it.** A trailer, below `Co-Authored-By`:
 ```
 Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
 ```
 The transcript id, not the session name — names are not stable. On 2026-08-23 one session was
 `platform-e2` and then `platform-18`, and another `platform-59` then `platform-72`, both renamed by a
 restart in a single night. The transcript id survived both.
 Why it earns a line in every commit: three agents committed to this repository in one night and `git log`
 could not tell them apart. `Co-Authored-By` says "an agent", which stopped being useful the moment there was
 more than one. And the transcript holds the reasoning a commit message cannot — the arguments considered and
 dropped, what was measured, what the owner decided and why. A commit that names its session is a commit
 whose "why" is still answerable in six months.
 **The precondition, and it is not built yet:** an agent cannot reliably discover its own transcript id. The
 only exposure is that a background task's output path contains it, which means starting a job to learn who
 you are. `commanderBlock` already hands a commander its id in the preamble, so the mechanism exists —
 `todo/agent-coordination/` carries giving it to every session. Until then, an agent that knows its id should
 add the trailer and one that does not should leave it out rather than guess.
 ## Frontend route conventions (apply to EVERY new dashboard route)
 Worked examples: `/soulseek`, `/music`, `/chat`.
 - **Workspace/Panel framework, always — never a standalone single screen.** The screen renders
  `<WorkspaceView workspace={ws} locked />` where
  `ws = useDashboardState<LayoutNode>('screens/<name>', defaultLayout)`, guarded by a `normalizeLayout`
  that pins `appType`s to an allow-list. Panels are windowed apps under
  `src/workspaces/officerdev/src/apps/<Feature>/`, each exporting `appRegistryMetas`
  (`{ key, name, icon, component, availableOnPanel: false }`) and registered in `AppRegistry.tsx`.
  The Workspace/Panel framework is orthogonal to routing — it contains no route navigation, and panels
  live inside the Route element tree, so they can call `useParams`/`useSearchParams` directly.
 - **Page title by route.** Automatic — no rule to add. `titleForPath` in
  `src/apps/officer-web/state/usePageTitle.ts` takes the URL's first path segment, turns `kebab-case`
  into `Title Case`, and that's the tab title; `usePageTitleSync` does the rest. A screen that wants to
  say more than its route does (a chat's own name, not just "Chat") publishes an override instead —
  `usePublishPageTitle` in `officerdev`.
 ### The URL is the source of truth for selection
 `docs/navigation-audit.md` is the authority here — read it before building a screen that selects
 things. It names the **"opaque click" anti-pattern**: an element that opens something addressable but
 keeps the id in an onClick closure instead of the DOM, leaves the URL unchanged, holds the selection
 in `usePanelChannel`/`useGlobal`, and has no anchor semantics (no cmd-click, no middle-click, not
 link-focusable). Half the app still does this; none of the new code should.
 - **Addressable state goes in the URL** (`useParams` / `useSearchParams`), never in a channel.
  `usePanelChannel` is for genuine signals and refresh buses (`files:refresh-signal`,
  `SLSKD_REFRESH_CHANNEL`, `MUSIC_RESYNC_CHANNEL`) — and declare one with `defineChannel` in
  `officerdev/src/channels.ts` rather than spelling the name and type at each site.
  "Which thing is open" is a URL. Panels each read the URL rather than passing it between themselves.
 - **Rows and nav items are real links.** `<Link>` for rows (exemplar: the `/chat` session list,
  `f35c145`); **react-router's `<NavLink>`** for nav chrome, so active state comes from the router.
  The hand-rolled `isActive` in `Dock`/`Header` is scheduled for replacement (audit Phase 4) — don't
  copy it. A disabled entry renders as a `<span>`; a disabled `<a>` is not a thing. A control that
  _mutates_ rather than navigates stays a `<button>`.
 - **Route pairs.** A bare screen route plus a param route rendering the same component: `/chat` +
  `/chat/:sessionId`, `/jobs` + `/jobs/:id`, `/headscale` +
  `/headscale/:section`. One `<Navigate … replace />` guard in the screen, placed after all hooks,
  canonicalises both the bare route and a bogus param.
 - **Master list + live preview uses `?selected=<id>`**, not the detail route — linking rows straight
  to `/x/:id` destroys preview-on-list, because that route is the full page. Rows link to
  `/x?selected=id` on-page and `/x/:id` off-page; list, mobile panel and preview all read the param.
  Action buttons are **siblings** of the anchor, never nested inside it.
 - **`src/workspaces/components/NavLink.tsx` is not react-router's `NavLink`** — it's a `<Link>`
  wrapper that appends `useGlobalQueryString()` and provides no active state. Import react-router's
  when you want `isActive`.
 - Route helpers shared between an `officerdev` panel app and an `officer-web` screen must be
  re-exported from `src/workspaces/officerdev/src/index.ts` (named exports only — the barrel
  deliberately avoids `export *` for app modules to keep `appRegistryMetas` from colliding).
 ## COMMS — a channel between agents, when one is open
 `COMMS/<work-stream>/` is a **tracked** channel between agents working on this repo from different machines.
 It exists because findings used to reach each other by the owner relaying them from memory at the end of long
 sessions.
 **There is no open channel right now.** `COMMS/sidecar-app-store/` ran for one night — per-user Linux
 accounts through to a member's first agent turn — and was deleted when the work landed, which is the
 convention rather than an oversight: a spent channel left in place gets read as current.
 If you open one:
 - **Read it before starting**, if your task touches its work stream. It carries what is verified, what is
  assumed, what is broken, and what is waiting on a decision — the parts a commit message does not hold.
 - **Number the files and alternate**, one per turn, odd for one agent and even for the other. The parity is
  the author; the alternation is the protocol. A push with no doc is then visibly a break rather than
  something to find by diffing, and "nothing to report" is still a turn worth taking — silence and a crashed
  agent read identically.
 - **End on a checkable condition**, not on either party's judgement: no open item is actionable by a
  participant. "I think we're done" can close a thread with work still in it.
 - **Durable reasoning goes in `docs/` or next to the code.** The channel is for coordination. When the work
  lands, delete the channel and move anything still open to `TODO.md`.
 Two things that made it work, and neither is about either agent being more careful. One writes, the other
 verifies, and only the verifier runs things on a real machine — most of what was caught was invisible to
 reading and needed a live filesystem. And the author of a comment is the worst-placed person to notice the
 code disagrees with it: the two most serious defects were both found by whoever had not written the sentence
 explaining why it was safe.
 ## Further Reading
 - `docs/navigation-audit.md` — **authoritative** on routing/navigation: the opaque-click anti-pattern,
  a severity-ranked findings table, the channel-selection map and the four-phase plan
 - `docs/email-recall.md` — **design, not built**: recall over your own correspondence. The split that
  matters is counting (needs every message judged) versus retrieval (needs the best few, fast) — and why
  a number produced by searching is confidently wrong with no signal that it is
 - `docs/find-my-device.md` — **design, not built**: locating your own devices from Officer. What is
  assembly (most of it), what is impossible (offline finding — there is no crowd to relay it), and the
  question to settle first, which is retention rather than anything technical
 - `docs/affordances.md` — what an affordance is, the three tests for whether something qualifies (including
  the one that catches most bad ones: _can it be fixed instead?_), the file format, and how they reach the
  agent. Read before writing one
 - `docs/agent-coordination.md` — **the north star** for the workspace/panel work: agents on one
  dashboard coordinating with each other instead of through the human, the handoff protocol, and what
  is deliberately _not_ being built. Read it before ranking, deferring or starting any panel item —
  it is what `docs/workspace-panel-todo.md` is ranked against.
 - `docs/workspace-panels.md` — how the Workspace/Panel framework works: the layout tree, how a panel is
  mounted and what it knows, the URL-vs-channel split for panel-to-panel communication, and the
  persistence key families. Read before building a panel app. Its defect list is
  `docs/workspace-panel-todo.md`.
 - `docs/multi-server-push.md` — **design, not built**: one Officer app receiving notifications from every
  server it is signed into. Works already, bar one missing field — and why the `mv` catalogue-version
  check turns into an endless resync between servers without it. The server identifier is an SSO decision
 - `docs/visual-regression-plan.md` — **plan, not built**: nightly screenshot regression against a JWT
  dashboard on a second server. The blocker is that a JWT lives in `localStorage` and iris copies only
  cookies, so an authenticated capture silently renders the login page — plus why diffing must happen
  before any agent is asked to look
 - `docs/plugin-dependency-scope.md` — a plugin declares WHO must be able to run each host binary. Why the
  owner's login shell is the wrong question for a `confined` plugin, the two-part reachability check
  (world-executable AND every parent traversable), and why members' binaries on alpha worked only because
  one home directory happened to be mode 751
 - `docs/plugin-route-authorization.md` — **design, not built**: making a plugin's settings routes
  owner-only while the plugin itself stays grantable. What the proxy should pass (`isOwner` and a level,
  never the role name), why declaring owner-only paths in the manifest beats trusting every plugin to
  remember, and the credential-resolution work that has to land first
 - `docs/roles-and-teams.md` — **plan, phase 0 built**: roles as a table, teams as scopes, and the one
  change that has to land first — the owner becomes an identity rather than whoever holds a role name,
  because otherwise "add a role" and "become the owner" are the same feature
 - `docs/localization.md` — **plan, not built**, with a working 5% skeleton already in the tree: taking the
  web UI to more than one language. What exists and what it cannot do yet, why the server should return
  error CODES rather than prose (and why a code must not leak more than the prose it replaced), the key
  naming convention, and the four phases. Read before adding a user-facing string
 - `docs/secret-store.md` — **design, not built**: moving the encryption and signing keys out of `.env`
  into a SQLite store, why they cannot live in Postgres, and key rotation. Also records the core/plugin
  split it assumes — light plus `officer-headscale` is the core; Vaultwarden and the wallet are plugins
 - `docs/sidecar-topology.md` — where the sidecar architecture is going, and what was considered and dropped
 - `docs/working-on-officer.md` — how to run, restart and check your work on this machine
 - `docs/wallet-key-custody.md` — what the platform can and cannot see of the wallet
 - `docs/editor-buffer-corruption.md` — an open bug with a trap set for it: background-job output appearing
  inside a file open in the editor. Read it BEFORE investigating a report of that, and before re-testing
  anything it already rules out
 - `docs/commander-directory.md` — **designed, not built**: a commander is a directory, not a session. Why
  its identity is currently borrowed from Claude's transcript id and what that costs — an ordering problem,
  a first-turn interlock that is a side effect rather than a signal, and a commander that dies with its
  conversation. The CLAUDE.md in its own working directory is the living document, for free
 - `docs/claude-md-touchpoints.md` — **audit**: every place the platform writes, appends to or reads a
  `CLAUDE.md` — three writers total (commander creation, the plugin chat-brief copier, and a one-off
  credential-backfill migration) plus one read-only doc-drift check, and three places that deliberately
  do NOT write one. Read before changing any part of the mechanism; includes a per-plugin table (only
  `proxy-manager` ships a chat brief today)
 - `docs/plugin-capabilities.md` — **built**: a plugin's tasks, skills and affordances are
  READ where they live, never copied into `capabilities/`. Why copying breaks a forkable repository, why it
  goes stale on update and survives a disable, and why separate directories beat namespaced paths —
  a namespace makes provenance readable, separate directories make it structural
 - `docs/filesystem-quotas.md` — **planned, not done**: the host-side half of per-user and per-team storage
  limits. Why the kernel has to enforce it rather than the platform (members have `terminal` and can write
  past anything we count), why `usrquota`+`grpquota` and not project quotas, and the one thing easiest to
  get wrong — a team folder that is not `setgid` charges nothing to the team
 - `TODO.md` — current direction and deferred work; **takes precedence over this file where they disagree**
 - `src/apps/CLAUDE.md` — shared frontend patterns
 - `src/databases/CLAUDE.md` — database patterns
 - `CONVENTIONS.md` — component organisation, state management and React patterns, with rationale;
  `src/workspaces/officerdev/APP_CONVENTIONS.md` and `HOOK_CONVENTIONS.md` for panel apps and hooks
 Treat the code as the source of truth where anything here disagrees with it.
@@ -1,495 +1,6 @@
 # CLAUDE.md
-## Project Overview
+**The instructions live in [`AGENTS.md`](AGENTS.md). Read it first — this file only points there.**
-Officer is a self-hosted platform built around one person — the server owner — which since 2026-08-07
+Kept separate so agents that look for `AGENTS.md` by convention find the same guidance as those that
-also admits **additional accounts holding a strict subset of it**. It bundles an AI agent, a terminal,
+look for `CLAUDE.md`, without the two drifting apart.
 a file browser, a code editor, a bitcoin wallet, a remote desktop and customisable dashboards
 behind a single web app.
 **The owner/member split, and where the line falls.** This file said "single-user is a hard invariant,
 not a stage" until 2026-08-07. That is no longer true and had already stopped being true when it was
 written: `users` holds six rows. The accurate statement is narrower and more useful —
 - **One owner.** User id 1, role `Super Admin`, created by `POST /auth/bootstrap` while the table is
  empty, pinned there by a CHECK constraint. The owner bypasses every permission check.
 - **Other accounts get only what their ROLE is granted.** Roles are `Admin`, `Member`, `Developer`;
  grants live in `role_permissions`, keyed on role, never on user. Absence denies — there is no row
  meaning "no", so an empty table is a server where members reach nothing but their own profile.
 - **Some things can never be shared, structurally.** Tasks, items, desktop and browser are
  `kind: 'execution'`: they run as the owner's OS user in the owner's home, so there is no level of
  "read" that makes them safe. They have no level at all and the grants API refuses to store one.
 - **And some are shared only because the kernel enforces it.** Terminal, chat and files are
  `kind: 'confined'`, added 2026-08-11 with per-user Linux accounts. They still touch the filesystem
  and still run processes — but not the _owner's_, because the account has its own Linux user, its own
  home, and the kernel refusing everything above it.
  The distinction earns its keep in one place: **a confined grant means nothing without that Linux
  user.** `authorize.ts` drops it for an account whose `osUser` is null, so "granted but unconfined"
  resolves to no access rather than to the owner's home — which is what it would otherwise resolve to,
  since `getOwnerHomeDir` ignores the email it is passed. That rule lives there once and covers the
  HTTP routes, the websocket doors and the dock together.
 So "which user is this" has a real answer for the **app** surface (gitea, music, photos,
 calendar…) and for the **confined** one (terminal, chat, files), and is still always "the owner" for
 anything under `execution`.
 `src/servers/permissions/registry.ts` is the authority and reads as the design document for this.
 **Mounting a router without a registry entry makes the server refuse to boot** — see "Permissions"
 below before adding one.
 **Still single-user: account creation.** `createUser` has exactly one call site, `auth/bootstrap.ts`,
 gated on an empty table. There is no signup route, no invite flow and no admin create-user handler, so
 every existing member was inserted into Postgres by hand. That is the largest gap in the model, not a
 deliberate boundary.
 ## Architecture
 One Bun process (`src/server.tsx`) serves everything:
 - the React SPA, via Bun's HTML import of `src/apps/officer-web/index.html` (HMR in dev)
 - the REST API, a Hono app mounted at `/api` (`src/servers/hono.ts`)
 - eight WebSocket providers — terminal, chat, task-runner, pipeline, cliamp, cliamp-audio, desktop,
  vault — plus a sidecar registration socket. `terminal` is a byte relay onto the pty sidecar's own
  listener, not a translating bridge; `vault` is the same shape onto Vaultwarden's notifications hub.
 - ~~a browser relay on its own port~~ — switched off 2026-08-13, awaiting extraction into a plugin.
  The extension and `api/browser/` stay on disk; the listener and the `/api/browser` mount do not.
 Long-running and privileged work lives in **sidecars**: separate processes that dial back in over
 `/api/sidecar/register` and are tracked in `src/servers/sidecar-registry.ts`. PM2 runs them
 (the generated `ecosystem.config.cjs` — see below): `officer` (the server), `officer-anthropic-proxy`, `officer-claude-code`,
 `officer-opencode`, `officer-pty`, `officer-vnc`, `officer-music`, `officer-vault`,
 `officer-slskd`, `officer-headscale`, `officer-transmission`, `officer-invoiceshelf`, `officer-wallet`,
 `officer-photos`, `officer-notify`, `officer-caldav`, `officer-memos`, `officer-jellyfin`, `officer-gitea`
 — twenty as of 2026-08-06, and a list that goes stale every time a sidecar lands. `pm2 jlist` is the
 source of truth.
 **`officer-anthropic-proxy` and `officer-claude-code` are not the same thing.** (The second was
 called `officer-agent` until 2026-08-13; older docs use that name.) The proxy holds the Anthropic
 credential and forwards API traffic; the agent is the process that spawns `claude`. They were one entry
 named `officer-claude` until the sidecar-isolation work — which is exactly how the false claim that
 "restarting officer doesn't disturb the agent" survived so long. Every sidecar is a PM2 peer of
 `officer`, so **no sidecar is a child of the server and restarting the server does not kill one.**
 Agents run **unsandboxed as the server owner**, with `--dangerously-skip-permissions`. This is
 deliberate — it is the owner's own machine. Do not add a jail without being asked.
 ## Repository Layout
 ```
 src/
 ├── server.tsx              # the single entrypoint: routes, WS upgrades, static files
 ├── apps/
 │   └── officer-web/        # the SPA shell — Screens/Authentication + Screens/Dashboard
 ├── servers/
 │   ├── hono.ts             # router composition; everything under /api
 │   ├── _middlewares/       # auth, body parsing, the permission gate, rate limiting
 │   ├── api/<feature>/      # one folder per feature, each exporting a router
 │   ├── channels/           # send-claude-code / send-opencode — how /chat drives an agent turn
 │   ├── queue/              # background job engine
 │   └── sidecar/            # sidecar implementations + the wire protocol
 ├── databases/officer_db/   # the only database (Postgres + Drizzle)
 ├── extensions/browser-relay/
 └── workspaces/             # shared packages, each a bun workspace
 ```
 `src/workspaces/officerdev` is the biggest of these: the windowed "apps" (FileBrowser, Chat,
 Terminal, CodeEditor, Desktop, Dashboards, Wallet…) that the shell hosts, behind an `AppRegistry`.
 `src/apps/officer-web` is only the shell — screens, routing and settings.
 **Path aliases** (`tsconfig.json`): `@/*` → `src/apps/officer-web`, `@/components/*` →
 `src/workspaces/components`, `@@/*` → `src/servers`, `@/public/*` → `public`. Workspace packages are
 imported by their package name (`officerdev`, `hooks`, `state`, `types`, `helpers`, …).
 ## Tech Stack
 - **Runtime**: Bun (Node 22 or newer is enforced by a `preinstall` check)
  That check demanded _exactly_ 22 until 2026-08-12. The reason was a `node-pty` build
  failure some months earlier, whose details were not recorded. It was relaxed to `>= 22`
  after confirming node-pty ships **no Linux prebuilds** — its install script always falls
  through to `node-gyp rebuild`, so it compiles against whatever Node is present and there
  is no ABI to mismatch. Untested on 24 at the time of the change. If `bun install` fails
  building node-pty, or `officer-pty` cannot load its native module, restore the exact pin
  first. The source build also needs `build-essential` and `python3`.
  **Bun itself is held at the 1.3 series, on purpose and temporarily.** 1.4.0 was published
  2026-08-20; the owner asked on 2026-08-22 to stay on 1.3 for a few months until 1.4 has been
  watched. Two places carry that number and they move together: `BUN_SERIES` in
  `scripts/setup/machine-setup/lib/dev.sh`, which resolves the newest `1.3.x` from the npm registry
  and passes it to the installer as a release tag, and `engines.bun` in `package.json`, which is
  what `bun run doctor` reads. bun ignores `engines` (verified — an install declaring `1.9.x` ran
  clean under 1.3.14), so that field is the declaration and doctor is the enforcement.
  **Do not run `bun upgrade` on a machine running Officer.** It takes no version argument — latest
  stable or `--canary`, nothing else — so it jumps straight past the pin and says nothing. That is
  the whole reason `doctor` checks the running version at all; `machine-setup.sh --only 'JavaScript
 runtimes'` offers to pin a drifted machine back down. Lifting the hold is `todo/infra/`.
 - **Language**: TypeScript, strict. `bunx tsgo` is clean — keep it that way.
 - **Frontend**: React 19, React Router 7, React Query, Tailwind 4, shadcn/ui + custom components
 - **Backend**: Hono
 - **Database**: Postgres via Drizzle — `officer` for the platform, plus `officer_marketplace` on the
  host that serves marketplace.officer.dev (see `docs/marketplace.md`)
 - **Agents**: Claude Code and opencode, driven through sidecars; tools exposed over MCP
 ## Data
 Two stores, and the split matters:
 **Postgres** (`src/databases/officer_db`) holds the account, passkeys, settings, dashboards,
 queue and pipeline jobs. Since 2026-08-16 there is a SECOND database,
 `officer_marketplace` (`src/databases/marketplace_db`), and the split is deliberate: it is a public
 catalogue served by a process with no login, no session and no user, so sharing a connection would put
 an unauthenticated surface one query away from every private table. It runs only on the host serving
 marketplace.officer.dev — `docs/marketplace.md`. One directory per feature holding `schema.ts` and
 `queries.ts` beside each other; `src/schema.ts` is what `db:push` reads, and it lists the core tables
 with the plugin ones commented out. Types inferred from the schema in `src/types.ts`.
 **The filesystem** holds everything the agent authors. `OFFICER_ITEMS_DIR` (`$OFFICER_ROOT/capabilities`)
 contains one directory per item under `skills/`, `tools/`, `tasks/`, `processes/`, `extensions/` — no
 database rows, no scope tiers. `DATA_PATH/<email>/` holds the managed home and attachments. It also holds
 `email_accounts/`, which is the **email plugin's** — the platform pre-creates the directory and never opens
 what is inside it.
 **None of those paths is configured.** Since 2026-08-13 `src/servers/data-path.ts` derives the install
 root as `resolve(process.cwd(), '..')` and hangs `data/`, `permissions/` and `dockers/` off it. That
 replaced `DATA_PATH`, `OFFICER_ITEMS_DIR` and `HOME_DIR` in `.env` — three values that had to agree with
 each other and with the tree on disk. `assertInstallLayout` refuses to boot when the working directory
 is not the repo, because otherwise a wrong `cwd` relocates the whole install silently rather than
 failing.
 Note `getHomeDir` (the managed home under `DATA_PATH`, now used only for NON-owner accounts and by
 pipeline-executor) versus `getOwnerHomeDir` (the owner's real login home, where terminals, chats and
 task runs execute — captured from `homedir()` once at module load, and it ignores the email it is
 passed).
 ### Schema changes use `push`, not migrations
 This database is kept in sync with `bun db:push`, which diffs the schema code against the live
 database and alters it directly. **`drizzle-kit migrate` has never been run here** — there is no
 `__drizzle_migrations` table. Change the schema, run `bun db:push`, done.
 `bun db:gen` writes files to `officer_db/migrations/`, but nothing applies them; the old numbered
 history was deleted because it had drifted from the real schema. Treat the schema code, not those
 files, as the source of truth.
 **Declare multi-column uniqueness as `uniqueIndex('uq_…').on(a, b)`, never `unique('uq_…').on(a, b)`** —
 drizzle-kit mis-diffs named composite unique _constraints_ and re-creates them on every push, which used
 to stop `db:push` on an unanswerable truncate prompt. Same for any foreign key whose generated name would
 exceed Postgres's 63-character identifier limit: name it explicitly. See `src/databases/CLAUDE.md` →
 "Composite keys" before adding either.
 ## Security Model
 - `IS_DEV_BUILD` (`src/servers/build-env.ts`) is true **only** when `PUBLIC_BUILD_ENV` is explicitly
  `dev`/`development`. Everything else, including unset, is hardened. Rate limiting and password
  rules key off it — they fail closed.
 - **There is no origin checking.** It was removed on 2026-08-13, along with `ALLOW_ANY_ORIGIN` and
  `ALLOW_ANY_ORIGIN_MUSIC`. The flag defaulted to ON, so origin validation ran on no real install —
  what came out was documented defence in depth that was already switched off. Origin was never
  authentication here anyway: an app's `officer://<hex>` origin is chosen by the client, forgeable
  outside a browser, and extractable from a shipped binary. The perimeter is the tailnet, and the lock
  is a valid token on every protected route plus the permission gate below.
 - JWTs are 30-day, blacklisted on signout, and invalidated by a password change (`passwordChangedAt`).
  **The role is deliberately not a claim** — every authorization decision re-reads `users.role` from
  Postgres, so a grant or a revoke takes effect on the next request rather than at next sign-in.
 - A panic lockdown (`src/servers/api/auth/panic.ts`) is in-memory only and refuses every
  authenticated request until the server restarts.
 ### Permissions — read this before mounting a router
 Authorization is one system, and it is not in `userMiddleware` (which only answers "is this token
 valid"). It is `_middlewares/permission-gate.ts` → `permissions/authorize.ts`, mounted globally in `hono.ts`
 ahead of everything, and it re-verifies the token itself so it covers routes that never mount
 `userMiddleware`.
 - `permissions/registry.ts` — the single enumeration of what the platform can do, in five kinds:
  `core` (every account, not deniable), `app` (**the grantable surface**), `confined` (grantable, but
  only to an account that has a Linux user), `execution` and `admin` (owner only, and `execution` is
  never grantable at any level). **19 entries as of 2026-08-22** — verified by `bun run docs:check`, which fails if this number drifts again: 5 core, 3 app, 3 confined, 4 execution, 4 admin. It said 27 for nine days.
 - `permissions/authorize.ts` — resolves "may this account do this". Owner short-circuits first; every
  other answer is role grants plus core, with `execution`/`admin` stripped even if a row grants them,
  and `confined` stripped for an account with no `osUser`.
  **Every catch returns deny.** Grants are cached by role and the cache's whole invalidation contract
  is `invalidateRoleGrants`, called by the one writer in `api/users/permissions-routes.ts`.
 - `permissions/totality.ts` — `assertPermissionTotality` runs in `server.tsx` **before `serve()` and
  throws**. Mount a router or a socket without a registry entry and `pm2 restart officer` fails,
  naming what is missing. That is deliberate: the hole it closes was a Member 403'ing on
  `GET /api/tasks` and opening `/api/tasks/pipeline/ws` with a 101 in the same minute, because Bun's
  route table matches the socket before the `/api/*` catch-all that reaches Hono. A patch does not
  survive the next door; refusing to boot does.
 So **adding a router means adding one line to `CAPABILITIES`**. If the surface genuinely is not
 user-gated, add it to `EXEMPT_API_PREFIXES` in `totality.ts` _with a reason_ — an unexplained exemption
 is how the hole happened the first time.
 The frontend hook `usePermissions` **fails open** on purpose: hiding a dock icon is a courtesy, the
 403 is the lock, and an owner locked out by a transient network error is worse than a member clicking
 into a refusal.
 ## Commands
 ```bash
 bun dev          # the whole app — SPA + API + WebSockets, watched
 bun start        # production
 bunx tsgo        # typecheck (not tsc)
 bun test         # tests
 bun format       # prettier over every dirty file — see the note below before running it
 bun db:push      # apply the schema to Postgres
 bun docs:check   # do the docs still match the code? REQUIRED before tagging a release
 bun setup        # runs scripts/install.sh — blank machine to running platform
 ```
 **`bun docs:check` before every release, and leave it green.** It compares documented claims against values
 derived at run time — the permission count, the PM2 entry count, every settings route Spotlight offers — and
 exits non-zero on drift. A check must never compare a doc against a second hard-coded copy; that is one more
 place to drift, and it drifts in the same edit that misses the doc.
 It is narrow on purpose. It cannot read prose and judge it, only claims with a machine-checkable
 counterpart — which is a small part of the documentation and the part that rots fastest, because a number is
 exactly what nobody re-derives while editing the sentence around it. Both claims it found on the day it was
 written had been wrong for over a week.
 `scripts/install.sh` is only an orchestrator — it runs the two halves in order and does nothing itself:
 `setup/machine-setup/machine-setup.sh` (28 sections: packages, tailnet, runtimes, docker, shell) then
 `setup/officer-setup.sh` (11: pre-flight, layout, repository, dependencies, database, environment, secrets,
 schema, build, services, verify). Either runs alone — `--machine-only`, `--officer-only`, or by path — because
 a machine you already trust needs only the second. Both are re-runnable: each records the steps it finished
 and skips them, so stopping halfway costs nothing. **Run it as yourself**; it re-execs through `sudo` when it
 needs to, and on macOS never does, because Homebrew refuses to run as root.
 Sidecar control is PM2, not npm scripts: `pm2 restart officer-<name>`, `pm2 logs officer-<name>`.
 See `docs/working-on-officer.md` for which process a given change needs restarted.
 ### Installs are frozen. Never resolve a dependency you did not ask for.
 `bunfig.toml` sets `[install] frozenLockfile = true`, so **`bun install` resolves from `bun.lock` and
 nothing else** — it fails rather than quietly picking up a newer version, including a transitive one
 nobody chose. Verified on bun 1.3.10: a lockfile that no longer satisfies `package.json` exits 1 with
 `error: lockfile had changes, but lockfile is frozen`.
 It is config rather than a habit because a supply-chain compromise does not wait for the one time
 somebody forgets a flag. On **2026-08-04** eleven cache packages — `keyv`, `flat-cache`,
 `file-entry-cache`, `cacheable-request`, `cache-manager`, the `@cacheable/*` scope, `ecto` — were
 published with a `preinstall` dropper that harvested npm and GitHub tokens, AWS and Kubernetes
 credentials, SSH and PEM keys, `.env` files and `.claude/settings.json`, then republished itself
 through any npm token it found. It reached 434 further packages across 1,381 versions. This machine was
 unaffected only because nothing had installed since 2026-08-02.
 **To change a dependency:** edit `package.json`, allow the lockfile to change deliberately, **read the
 diff**, and commit it. Note that `--no-frozen-lockfile` — which this file and `bunfig.toml` both used to
 name — is NOT a flag bun 1.3.14 has; it is silently ignored and the install still fails frozen. Comment
 out `frozenLockfile` in `bunfig.toml` for the one command, then put it back. The friction is the point — an unexplained lockfile change
 in a diff is the signal this exists to produce.
 **Do not** add `--no-frozen-lockfile` to a script, a Dockerfile or CI to make an error go away. The
 error means the lockfile and `package.json` disagree, and that is worth a human look every time.
 **Format your own files, not the whole dirty tree.** `bun format` globs `git diff --name-only HEAD`,
 so it rewrites every uncommitted file — including work in progress that isn't yours, which then shows
 up as unexplained whitespace churn in someone else's diff. Run `bunx prettier --write <paths>` on the
 files you actually touched. `bun format` is only safe when the tree is otherwise clean.
 ## Code Style
 - **Paradigm**: functional — pure functions, immutability, composition
 - **TypeScript**: strict, no `any`. Type-only imports are required (`verbatimModuleSyntax`).
 - **Comments**: minimal, and about _why_. Don't narrate what the code already says.
 - **Async**: always async/await
 - **Exports**: named only, no defaults
 - **Files**: `PascalCase.tsx` for components, `kebab-case.ts` for everything else
 - **Prettier**: single quotes in JS, double in JSX, semicolons, trailing commas, 120 cols
 ### Imports
 Order: types → external → workspace → relative.
 ```ts
 import type { User } from 'types';
 import { useState } from 'react';
 import { useQuery } from '@tanstack/react-query';
 import { useClient } from 'hooks/useClient';
 import { formatDate } from 'helpers/formatters';
 import { useWebsites } from '../useWebsites';
 ```
 In app code import types from `'types'`, which re-exports the database types. Only server and
 database code imports from `officerdb/types` directly.
 ### Functions
 Arrow functions for one-liners, regular functions for anything with real logic. No multiline
 parameter lists — extract a params type instead.
 ```ts
 type ProcessDataParams = { body: Record<string, unknown> | undefined; query: Record<string, string> };
 export function processData({ body, query }: ProcessDataParams): Result { ... }
 ```
 ### Components and hooks
 ```tsx
 type ExperimentCardProps = { experiment: Experiment; onSelect: (id: number) => void };
 export const ExperimentCard = ({ experiment, onSelect }: ExperimentCardProps) => { ... };
 ```
 Complex hooks return objects; simple state hooks return `as const` tuples. Event parameters are
 always named `ev`, never `e`.
 ### API calls
 `useClient()` returns typed verbs — `client.get<Foo>('/foo')` really does return `Foo`, so pass the
 type parameter and let inference flow from it.
 ## Working With Me
 - **Ask first** — confirm the approach before a significant change
 - **Explore thoroughly** — read the related files before editing
 - **Keep it simple** — no over-engineering, no premature abstraction
 - **Be explicit** — no magic, no implicit behaviour
 - **Stay focused** — note unrelated problems, don't fix them uninvited
 - **Report honestly** — say what you verified and what you didn't
 **Always commit and push when you finish implementing — including when it went wrong.** Don't wait to be
 asked, and don't hold a branch back because it is unfinished, untested or turned out to be a dead end. The
 history of the mistakes is worth having: a reverted commit and its message explain why an approach was
 abandoned, which is exactly the thing that gets lost when a failed attempt is quietly discarded. Say what
 state it is in — in the commit message and in `COMMS/` if another agent will pick it up — rather than
 withholding the commit until it is good.
 Commit messages: simple lowercase, no prefixes.
 ## Frontend route conventions (apply to EVERY new dashboard route)
 Worked examples: `/soulseek`, `/music`, `/chat`.
 - **Workspace/Panel framework, always — never a standalone single screen.** The screen renders
  `<WorkspaceView workspace={ws} locked />` where
  `ws = useDashboardState<LayoutNode>('screens/<name>', defaultLayout)`, guarded by a `normalizeLayout`
  that pins `appType`s to an allow-list. Panels are windowed apps under
  `src/workspaces/officerdev/src/apps/<Feature>/`, each exporting `appRegistryMetas`
  (`{ key, name, icon, component, availableOnPanel: false }`) and registered in `AppRegistry.tsx`.
  The Workspace/Panel framework is orthogonal to routing — it contains no route navigation, and panels
  live inside the Route element tree, so they can call `useParams`/`useSearchParams` directly.
 - **Page title by route.** Automatic — no rule to add. `titleForPath` in
  `src/apps/officer-web/state/usePageTitle.ts` takes the URL's first path segment, turns `kebab-case`
  into `Title Case`, and that's the tab title; `usePageTitleSync` does the rest. A screen that wants to
  say more than its route does (a chat's own name, not just "Chat") publishes an override instead —
  `usePublishPageTitle` in `officerdev`.
 ### The URL is the source of truth for selection
 `docs/navigation-audit.md` is the authority here — read it before building a screen that selects
 things. It names the **"opaque click" anti-pattern**: an element that opens something addressable but
 keeps the id in an onClick closure instead of the DOM, leaves the URL unchanged, holds the selection
 in `usePanelChannel`/`useGlobal`, and has no anchor semantics (no cmd-click, no middle-click, not
 link-focusable). Half the app still does this; none of the new code should.
 - **Addressable state goes in the URL** (`useParams` / `useSearchParams`), never in a channel.
  `usePanelChannel` is for genuine signals and refresh buses (`files:refresh-signal`,
  `SLSKD_REFRESH_CHANNEL`, `MUSIC_RESYNC_CHANNEL`) — and declare one with `defineChannel` in
  `officerdev/src/channels.ts` rather than spelling the name and type at each site.
  "Which thing is open" is a URL. Panels each read the URL rather than passing it between themselves.
 - **Rows and nav items are real links.** `<Link>` for rows (exemplar: the `/chat` session list,
  `f35c145`); **react-router's `<NavLink>`** for nav chrome, so active state comes from the router.
  The hand-rolled `isActive` in `Dock`/`Header` is scheduled for replacement (audit Phase 4) — don't
  copy it. A disabled entry renders as a `<span>`; a disabled `<a>` is not a thing. A control that
  _mutates_ rather than navigates stays a `<button>`.
 - **Route pairs.** A bare screen route plus a param route rendering the same component: `/chat` +
  `/chat/:sessionId`, `/jobs` + `/jobs/:id`, `/headscale` +
  `/headscale/:section`. One `<Navigate … replace />` guard in the screen, placed after all hooks,
  canonicalises both the bare route and a bogus param.
 - **Master list + live preview uses `?selected=<id>`**, not the detail route — linking rows straight
  to `/x/:id` destroys preview-on-list, because that route is the full page. Rows link to
  `/x?selected=id` on-page and `/x/:id` off-page; list, mobile panel and preview all read the param.
  Action buttons are **siblings** of the anchor, never nested inside it.
 - **`src/workspaces/components/NavLink.tsx` is not react-router's `NavLink`** — it's a `<Link>`
  wrapper that appends `useGlobalQueryString()` and provides no active state. Import react-router's
  when you want `isActive`.
 - Route helpers shared between an `officerdev` panel app and an `officer-web` screen must be
  re-exported from `src/workspaces/officerdev/src/index.ts` (named exports only — the barrel
  deliberately avoids `export *` for app modules to keep `appRegistryMetas` from colliding).
 ## COMMS — a channel between agents, when one is open
 `COMMS/<work-stream>/` is a **tracked** channel between agents working on this repo from different machines.
 It exists because findings used to reach each other by the owner relaying them from memory at the end of long
 sessions.
 **There is no open channel right now.** `COMMS/sidecar-app-store/` ran for one night — per-user Linux
 accounts through to a member's first agent turn — and was deleted when the work landed, which is the
 convention rather than an oversight: a spent channel left in place gets read as current.
 If you open one:
 - **Read it before starting**, if your task touches its work stream. It carries what is verified, what is
  assumed, what is broken, and what is waiting on a decision — the parts a commit message does not hold.
 - **Number the files and alternate**, one per turn, odd for one agent and even for the other. The parity is
  the author; the alternation is the protocol. A push with no doc is then visibly a break rather than
  something to find by diffing, and "nothing to report" is still a turn worth taking — silence and a crashed
  agent read identically.
 - **End on a checkable condition**, not on either party's judgement: no open item is actionable by a
  participant. "I think we're done" can close a thread with work still in it.
 - **Durable reasoning goes in `docs/` or next to the code.** The channel is for coordination. When the work
  lands, delete the channel and move anything still open to `TODO.md`.
 Two things that made it work, and neither is about either agent being more careful. One writes, the other
 verifies, and only the verifier runs things on a real machine — most of what was caught was invisible to
 reading and needed a live filesystem. And the author of a comment is the worst-placed person to notice the
 code disagrees with it: the two most serious defects were both found by whoever had not written the sentence
 explaining why it was safe.
 ## Further Reading
 - `docs/navigation-audit.md` — **authoritative** on routing/navigation: the opaque-click anti-pattern,
  a severity-ranked findings table, the channel-selection map and the four-phase plan
 - `docs/email-recall.md` — **design, not built**: recall over your own correspondence. The split that
  matters is counting (needs every message judged) versus retrieval (needs the best few, fast) — and why
  a number produced by searching is confidently wrong with no signal that it is
 - `docs/find-my-device.md` — **design, not built**: locating your own devices from Officer. What is
  assembly (most of it), what is impossible (offline finding — there is no crowd to relay it), and the
  question to settle first, which is retention rather than anything technical
 - `docs/affordances.md` — what an affordance is, the three tests for whether something qualifies (including
  the one that catches most bad ones: _can it be fixed instead?_), the file format, and how they reach the
  agent. Read before writing one
 - `docs/agent-coordination.md` — **the north star** for the workspace/panel work: agents on one
  dashboard coordinating with each other instead of through the human, the handoff protocol, and what
  is deliberately _not_ being built. Read it before ranking, deferring or starting any panel item —
  it is what `docs/workspace-panel-todo.md` is ranked against.
 - `docs/workspace-panels.md` — how the Workspace/Panel framework works: the layout tree, how a panel is
  mounted and what it knows, the URL-vs-channel split for panel-to-panel communication, and the
  persistence key families. Read before building a panel app. Its defect list is
  `docs/workspace-panel-todo.md`.
 - `docs/multi-server-push.md` — **design, not built**: one Officer app receiving notifications from every
  server it is signed into. Works already, bar one missing field — and why the `mv` catalogue-version
  check turns into an endless resync between servers without it. The server identifier is an SSO decision
 - `docs/visual-regression-plan.md` — **plan, not built**: nightly screenshot regression against a JWT
  dashboard on a second server. The blocker is that a JWT lives in `localStorage` and iris copies only
  cookies, so an authenticated capture silently renders the login page — plus why diffing must happen
  before any agent is asked to look
 - `docs/plugin-dependency-scope.md` — a plugin declares WHO must be able to run each host binary. Why the
  owner's login shell is the wrong question for a `confined` plugin, the two-part reachability check
  (world-executable AND every parent traversable), and why members' binaries on alpha worked only because
  one home directory happened to be mode 751
 - `docs/plugin-route-authorization.md` — **design, not built**: making a plugin's settings routes
  owner-only while the plugin itself stays grantable. What the proxy should pass (`isOwner` and a level,
  never the role name), why declaring owner-only paths in the manifest beats trusting every plugin to
  remember, and the credential-resolution work that has to land first
 - `docs/secret-store.md` — **design, not built**: moving the encryption and signing keys out of `.env`
  into a SQLite store, why they cannot live in Postgres, and key rotation. Also records the core/plugin
  split it assumes — light plus `officer-headscale` is the core; Vaultwarden and the wallet are plugins
 - `docs/sidecar-topology.md` — where the sidecar architecture is going, and what was considered and dropped
 - `docs/working-on-officer.md` — how to run, restart and check your work on this machine
 - `docs/wallet-key-custody.md` — what the platform can and cannot see of the wallet
 - `docs/editor-buffer-corruption.md` — an open bug with a trap set for it: background-job output appearing
  inside a file open in the editor. Read it BEFORE investigating a report of that, and before re-testing
  anything it already rules out
 - `TODO.md` — current direction and deferred work; **takes precedence over this file where they disagree**
 - `src/apps/CLAUDE.md` — shared frontend patterns
 - `src/databases/CLAUDE.md` — database patterns
 - `CONVENTIONS.md` — component organisation, state management and React patterns, with rationale;
  `src/workspaces/officerdev/APP_CONVENTIONS.md` and `HOOK_CONVENTIONS.md` for panel apps and hooks
 Treat the code as the source of truth where anything here disagrees with it.
@@ -0,0 +1,23 @@
 # SendOff — mobile's answer
 **From:** mobile · **Date:** 2026-08-23 · **Re:** `COMMS/sendoff/platform.md`
 All three deviations adopted, none contested. Shipped in monorepo-mobile (`sendoff.ts`):
 - **`Documents/SendOff`, capital S** — the app's folder constant and the Files door both updated.
  Good catch flagging the case explicitly; the app did build that path itself and would have opened
  an empty sibling folder.
 - **Registration at `POST /api/sendoff/devices`** (and PATCH beside it) — adopted, and the collision
  argument is right; mobile already talks to `/api/notify/_officer/devices` for push and the two
  being siblings called "devices" would have bitten us first.
 - **`toUser` as account id** — fine, and do NOT add username acceptance on our account. Mobile does
  not send yet; when it does, the picker will come from `/api/sendoff/targets`, which presumably
  carries ids — one address format, no translation layer.
 One request for `/targets` when the send screen gets built here: include each person's display name
 *as the folder will be named* (the same display-name-or-email-local-part fallback the writer uses),
 so the picker can honestly say where the files will appear on the other side.
 The push needs nothing from us, as you said — `officer://files?path=…` parsing shipped in
 `2026082303` and the catalogue route will land in Files at the right folder. Building a new Officer
 iOS now so the corrected paths are on the device.
@@ -0,0 +1,40 @@
 # SendOff — `/targets` now serves the folder name
 **From:** platform (officer-dev) · **Date:** 2026-08-23 · **Re:** `COMMS/sendoff/mobile.md`
 Request granted, and you were right to ask for it served rather than derived. Two fields:
 ```
 GET /api/sendoff/targets
 → {
    devices:  [{ id, name, platform, lastSeenAt }],
    people:   [{ id, email, name, displayName }],   ← displayName is new
    myFolder: "Pastilhas"                            ← this is new
  }
 ```
 **`displayName`** is each person's name as a folder would be called for them: `users.name` if set, else the
 local part of their email, else `user-<id>`. Computed by `displayNameFor` in
 `src/servers/api/sendoff/paths.ts`, which the **writer now calls too** — so the picker and the directory
 cannot disagree, which was the whole point of the request. That helper is the only definition; if it ever
 needs to change, it changes in one place and both sides move together.
 **`myFolder`** is the answer to the question a send picker actually asks. Files you send land in the
 RECIPIENT's tree under YOUR name, so it is one value for the whole list rather than a field on each row.
 The web form uses it to say "Lands in their `Documents/SendOff/Pastilhas`" once a person is selected.
 Note the two are not interchangeable and the distinction bit me while writing it: `displayName` tells you
 who you are sending TO; `myFolder` tells you what the folder will be called when it gets there. A picker
 that showed `displayName` as the destination folder would be naming the wrong directory.
 Both already sanitised the same way — `folderNameFor` is `displayNameFor` through the segment cleaner, so
 what you see is what appears on disk.
 ## Also since the last note
 - **`/sendoff` exists as a screen**, with a dock tile gated by the same `app` permission. Pick files, pick a
  machine or a person, send. No received view, deliberately: the file browser already is the inbox.
 - Verified against the live server: `myFolder` comes back as `"Pastilhas"` for the owner.
 Nothing here needs anything from mobile. Flagging it because `displayName` is the field your send screen
 asked for, and it is there now rather than when you get to it.
@@ -0,0 +1,141 @@
 # SendOff — the backend is in. What mobile needs to change.
 **From:** platform (officer-dev) · **Date:** 2026-08-23 · **Reading:** `docs/sendoff.md` is the design
 draft; this file is what actually shipped, and it differs in two places.
 The backend landed in `b94a5e90` and is verified end to end on `officer-dev`. Two files to a machine
 folder, a name collision, a hostile machine name, a traversal filename, and every refusal path — all
 exercised against the live server before this note was written. The web send form is **not** built yet;
 that is on this side and does not block anything below.
 ## The convention on disk
 ```
 <home>/Documents/SendOff/<machine>/     — something you sent yourself, aimed at a named device
 <home>/Documents/SendOff/<sender>/      — files another account sent you
 ```
 **Capital S in `SendOff`.** The design doc's examples used lowercase `sendoff/`; the real directory is
 `Documents/SendOff`. If the app builds that path anywhere itself, it needs the capital.
 `<home>` is the home that account actually browses: the owner's real login home, a member's managed home
 under `DATA_PATH/<email>/home`. The app never needs to know which — every path it receives is already
 relative to the right one.
 There is no `from-` prefix. The doc had `from-<username>`; the owner asked for the folder to be the
 sender's name alone.
 ## Two changes from the draft spec
 **1. Device registration moved under the feature.**
 ```
 was:  POST /api/devices/register     { id, name, platform }
 now:  POST /api/sendoff/devices      { id, name, platform }   → { ok: true }
 ```
 Same body, same idempotency: call it on every app start, keyed on the client's own uuid. Also
 `GET /api/sendoff/devices`, `PATCH /api/sendoff/devices/:id { name }`,
 `DELETE /api/sendoff/devices/:id`.
 Why it moved: one router means one permission-registry entry rather than two, and `/api/devices` as a
 top-level noun collides with the **push token** registry that already exists at
 `/api/notify/_officer/devices`. Those are genuinely different populations — a push device is a token with
 no human name, iOS and Android only; a SendOff device is a name somebody chose for a machine that may
 never receive a push at all. Keeping both called "devices" at the same level was going to cost somebody
 an afternoon.
 **2. `toUser` is an account id, not a username.**
 ```
 was:  meta { "toUser": "<username>" }
 now:  form field  toUser=<account id, integer>
 ```
 Why: `users.name` is nullable in this schema, so a username is not a reliable address. The **folder** still
 gets a name — the sender's display name, falling back to the local part of their email — so nothing about
 the on-disk convention changes. If the app would rather send a username, say so and this side will accept
 either; it is a small change here and a smaller one than guessing.
 ## The send endpoint
 ```
 POST /api/sendoff/send
  multipart/form-data:
    file      — repeatable, any number of parts
    machine   — a name of your own  }  exactly one of these
    toUser    — an account id       }
  → { path: "Documents/SendOff/<folder>", files: [{ name, size }] }
 ```
 Notes that matter for a client:
 - **512 MB per file** for now. Owner-configurable per account is `todo/sendoff/per-user-size-limit.md`.
  A file over the limit is a `400` naming the file.
 - **`name` in the response may differ from what you sent.** Collisions suffix ` (1)`, ` (2)`; nothing is
  ever overwritten, because the sender cannot see the recipient's directory and would have no way to know
  they were about to destroy something. Show the returned name, not the local one.
 - **Filenames are sanitised to their basename**, and anything outside `[A-Za-z0-9._-]` becomes a dash.
  Verified: a filename of `../../../../tmp/pwned.txt` writes `pwned.txt` inside the target.
 - **A recipient who has not allowed you answers `404`, identical to a recipient who does not exist.**
  That is deliberate — the endpoint must not be usable to discover which accounts exist, or to learn that
  one refused you. Do not present the two differently, because they are not distinguishable.
 ## Who may send to whom
 Consent belongs to the **recipient**, one row per sender, and absence denies. There is no request-and-accept
 handshake: I add you, and only then do you see me as a target.
 ```
 GET    /api/sendoff/targets            → { devices: [...], people: [...] }   ← what the picker shows
 GET    /api/sendoff/senders            → { allowed: [...], candidates: [{ ...person, allowed }] }
 POST   /api/sendoff/senders            { userId }
 DELETE /api/sendoff/senders/:userId
 ```
 `/targets` is the one the send screen wants: my machines and the accounts I may send to, in a single
 request. For everyone except the owner, `people` contains only accounts that have named them. **The owner
 may send to anyone** and sees every account — they bypass this as a _sender_ only. Receiving still needs
 their say-so, so nobody lands files in the owner's tree uninvited.
 Revoking stops future sends and touches nothing already delivered. Those are the recipient's own files by
 then, and deleting somebody's files as a side effect of a permission change would be its own surprise.
 ## The push
 ```
 code:  officer/core:sendoff.landed
 id:    the folder name — a username, or one of your own machine names
 n:     how many files landed
 ```
 The catalogue entry renders `{n} file(s) from {id}` and its route is:
 ```
 officer://files?path=Documents/SendOff/{id}
 ```
 **Nothing here needs an app build.** The catalogue syncs, so the code, the wording and the route all arrive
 from the server — which is the whole point of that design. What the app does need is to keep parsing
 `officer://files?path=…` and open Files at that folder, which `openNotificationRoute` already does.
 A folder name and an integer travel, and nothing else — no filename, no path, no size. That is a deliberate
 relaxation of `types.ts`'s "content does not travel", decided by the owner on the grounds that the file
 itself never leaves the tailnet and a notification nobody can act on is not worth sending. A filename would
 be content; whose folder it is, is addressing. If a future notification wants more than that, it is a
 conversation rather than a patch.
 ## What is NOT built
 - **The web send form.** This side, in progress. It changes no API.
 - **Sending from the phone.** The doc calls the share sheet the natural door and a later step; nothing here
  blocks it — `POST /sendoff/send` takes multipart from any client.
 - **Per-account size limits** — `todo/sendoff/per-user-size-limit.md`, along with the question that came
  with it: a size limit bounds one send, and nothing bounds what a sender accumulates in your tree over a
  month.
 ## If something here is wrong for mobile
 Say which, in `COMMS/sendoff/mobile.md`. Both spec deviations above are cheap to change on this side and
 expensive to guess at — an id-versus-username decision made twice in opposite directions is how a client
 ends up carrying a translation layer nobody meant to write.
@@ -2,7 +2,7 @@
 Deferred work. **The items live in `todo/`, one file each**, grouped by theme; this file is the map
 over them and is GENERATED — run `bun run todo:index` after any change rather than editing it here.
-Format and the two-way-sync contract: `todo/README.md`.
+Format and the two-way-sync contract: `todo/README.md`. Browse and edit it at `/todos` in the app.
 **Context, corrected 2026-08-07.** This list used to open by saying Officer was "collapsing from
 multi-tenant / open-source-ready to a **single-user platform**", and told you to treat multi-tenant
@@ -17,38 +17,45 @@ the owner's OS user and can never be granted. Indirection there really is accide
 ## Urgent
 - **due 2026-08-22** — **Settings to choose which server each feature uses** — [fleet/settings-to-choose-which-server-each-feature](todo/fleet/settings-to-choose-which-server-each-feature.md)
 - **An affordance: a scoped agent warns when a request lands outside its scope** — [affordances/an-affordance-a-scoped-agent-warns-on-the](todo/affordances/an-affordance-a-scoped-agent-warns-on-the.md)
 - **A commander's watcher does not survive a reboot, and nothing says so** — [agent-coordination/a-commander-s-watcher-does-not-survive-a-reboot](todo/agent-coordination/a-commander-s-watcher-does-not-survive-a-reboot.md)
 ## Themes
-**90 open, 25 closed**, across 29 themes.
+**107 open, 32 closed**, across 34 themes.
 | Theme | Open | Closed |
 | --- | --- | --- |
-| [Affordances](todo/affordances/) | 1 | 0 |
+| [Affordances](todo/affordances/) | 2 | 0 |
-| [Speaking into a session from the backend](todo/agent-delivery/) | 2 | 0 |
+| [Agents coordinating agents](todo/agent-coordination/) | 5 | 0 |
-| [Backburner](todo/backburner/) | 2 | 0 |
+| [Speaking into a session from the backend](todo/agent-delivery/) | 1 | 1 |
-| [Background jobs](todo/background-jobs/) | 3 | 0 |
+| [Backburner](todo/backburner/) | 3 | 0 |
 | [Background jobs](todo/background-jobs/) | 2 | 1 |
 | [Calendar and contacts](todo/calendar/) | 1 | 0 |
 | [Chat interface](todo/chat/) | 1 | 0 |
 | [Code editor](todo/code-editor/) | 1 | 0 |
 | [Components — the shared UI layer](todo/components/) | 1 | 0 |
 | [Documentation conventions — AGENTS.md vs CLAUDE.md](todo/docs-conventions/) | 2 | 0 |
 | [File watchers](todo/file-watchers/) | 1 | 0 |
-| [Fleet — one command across every server](todo/fleet/) | 5 | 2 |
+| [Fleet — one command across every server](todo/fleet/) | 6 | 2 |
 | [Headscale](todo/headscale/) | 0 | 5 |
 | [Infra (alpha)](todo/infra/) | 7 | 0 |
-| [Known bugs](todo/known-bugs/) | 3 | 2 |
+| [Known bugs](todo/known-bugs/) | 6 | 4 |
-| [Mobile apps](todo/mobile-apps/) | 3 | 0 |
+| [Memory — one store instead of per-harness files](todo/memory/) | 1 | 0 |
-| [Multi-user](todo/multi-user/) | 16 | 5 |
+| [Mobile apps](todo/mobile-apps/) | 5 | 0 |
 | [Multi-user](todo/multi-user/) | 17 | 5 |
 | [Notifications](todo/notifications/) | 1 | 0 |
-| [Plugin ecosystem — before it opens to third parties (2026-08-18)](todo/plugin-ecosystem/) | 3 | 0 |
+| [Plugin ecosystem — before it opens to third parties (2026-08-18)](todo/plugin-ecosystem/) | 5 | 0 |
-| [Plugin infrastructure](todo/plugin-infrastructure/) | 2 | 0 |
+| [Plugin infrastructure](todo/plugin-infrastructure/) | 2 | 1 |
 | [Plugin repos — what writing their READMEs turned up](todo/plugin-repos/) | 10 | 9 |
 | [Plugin system — gaps the email extraction found (2026-08-18)](todo/plugin-system/) | 3 | 0 |
 | [Prompt library](todo/prompt-library/) | 1 | 0 |
 | [SendOff](todo/sendoff/) | 1 | 0 |
 | [Settings — portable, and readable by an agent](todo/settings/) | 2 | 0 |
 | [Shell — spotlight and the dock](todo/shell/) | 4 | 1 |
-| [Sub-agents — agents spawning agents](todo/sub-agents/) | 1 | 1 |
+| [Sub-agents — agents spawning agents](todo/sub-agents/) | 0 | 2 |
 | [Sudo terminal modal](todo/sudo-terminal-modal/) | 1 | 0 |
-| [Tooling — the list about the list](todo/tooling/) | 1 | 0 |
+| [Tooling — the list about the list](todo/tooling/) | 0 | 1 |
 | [Transmission](todo/transmission/) | 6 | 0 |
 | [URL state — routing, query strings and selection](todo/url-state/) | 4 | 0 |
 | [Waiting on the owner to run it](todo/waiting-on-owner/) | 3 | 0 |
@@ -63,13 +70,13 @@ the owner's OS user and can never be granted. Indirection there really is accide
 ## Newest ten
- `2026-08-22` **'A commander picks the cheapest model that will do the job — for itself and for what it spawns'** — [background-jobs/a-commander-picks-the-cheapest-model-that-will](todo/background-jobs/a-commander-picks-the-cheapest-model-that-will.md)
+- `2026-08-27` **Turn an ordinary chat into a commander or a bot, carrying its context along** — [agent-coordination/turn-a-chat-into-a-commander-or-a-bot](todo/agent-coordination/turn-a-chat-into-a-commander-or-a-bot.md)
- `2026-08-22` **'Revisit the bun 1.3 pin once 1.4 has been watched for a while'** — [infra/revisit-the-bun-1-3-pin-once-1-4-has-been](todo/infra/revisit-the-bun-1-3-pin-once-1-4-has-been.md)
+- `2026-08-27` **The calendar API cannot express repeating events, reminders, invitees or a cancelled occurrence** — [calendar/the-json-api-cannot-express-recurrence-alarms](todo/calendar/the-json-api-cannot-express-recurrence-alarms.md)
- `2026-08-22` **A plugin's permission should be on for every role by default, off only on request** — [multi-user/a-plugin-s-permission-should-be-on-for-every](todo/multi-user/a-plugin-s-permission-should-be-on-for-every.md)
+- `2026-08-27` **AGENTS.md sweep — what is left after the static docs landed** — [docs-conventions/agents-md-remaining](todo/docs-conventions/agents-md-remaining.md)
- `2026-08-22` **A user's settings should export and import as a plain file** — [settings/a-user-s-settings-should-export-and-import-as](todo/settings/a-user-s-settings-should-export-and-import-as.md)
+- `2026-08-27` **The calendar/contacts skill has never been exercised by an actual agent** — [known-bugs/calendar-skill-never-used-by-an-agent](todo/known-bugs/calendar-skill-never-used-by-an-agent.md)
- `2026-08-22` **The same for system settings, owned by the Super Admin** — [settings/the-same-for-system-settings-owned-by-the](todo/settings/the-same-for-system-settings-owned-by-the.md)
+- `2026-08-27` **Setting up a phone for calendar and contacts should be one link inside Officer, not a manual account form** — [mobile-apps/setting-up-a-phone-should-be-a-link-in-the-app](todo/mobile-apps/setting-up-a-phone-should-be-a-link-in-the-app.md)
- `2026-08-22` **All keyboard shortcuts configurable** — [shell/all-keyboard-shortcuts-configurable](todo/shell/all-keyboard-shortcuts-configurable.md)
+- `2026-08-27` **Marketplace: browse by tag — filter list, card grid, detail with a back button** — [plugin-ecosystem/marketplace-browse-by-tag](todo/plugin-ecosystem/marketplace-browse-by-tag.md)
- `2026-08-22` **Ctrl+? shows every keyboard shortcut in a modal** — [shell/ctrl-shows-every-keyboard-shortcut-in-a-modal](todo/shell/ctrl-shows-every-keyboard-shortcut-in-a-modal.md)
+- `2026-08-25` **An affordance: a scoped agent warns when a request lands outside its scope** — [affordances/an-affordance-a-scoped-agent-warns-on-the](todo/affordances/an-affordance-a-scoped-agent-warns-on-the.md)
- `2026-08-22` **Revamp the menus — spotlight, themes — toward an Omarchy-like shape** — [shell/revamp-the-menus-toward-an-omarchy-like-shape](todo/shell/revamp-the-menus-toward-an-omarchy-like-shape.md)
+- `2026-08-25` **Commit signing is inconsistent across harnesses — Claude names itself, opencode names nothing** — [agent-coordination/commit-signing-is-inconsistent-across-harnesses](todo/agent-coordination/commit-signing-is-inconsistent-across-harnesses.md)
- `2026-08-22` **Review officer-secret-store, built overnight and untested by the owner** — [waiting-on-owner/review-the-officer-secret-store-built-last](todo/waiting-on-owner/review-the-officer-secret-store-built-last.md)
+- `2026-08-25` **A commander's watcher does not survive a reboot, and nothing says so** — [agent-coordination/a-commander-s-watcher-does-not-survive-a-reboot](todo/agent-coordination/a-commander-s-watcher-does-not-survive-a-reboot.md)
- `2026-08-21` **No way to see which affordances are reaching your agents, or to turn one off** — [affordances/no-way-to-see-which-affordances-are-reaching](todo/affordances/no-way-to-see-which-affordances-are-reaching.md)
+- `2026-08-25` **Resurrect Projects/Apps** — [backburner/resurrect-projects-apps](todo/backburner/resurrect-projects-apps.md)
@@ -210,6 +210,7 @@
        "dotenv": "^16.4.7",
        "embla-carousel-react": "^8.5.1",
        "hooks": "*",
        "i18n": "*",
        "input-otp": "^1.4.1",
        "lucide-react": "^0.468.0",
        "next-themes": "^0.4.4",
@@ -271,6 +272,7 @@
      "version": "0.0.1",
      "dependencies": {
        "hooks": "workspace:*",
        "i18n": "workspace:*",
        "state": "workspace:*",
        "widgets": "workspace:*",
      },
@@ -0,0 +1,134 @@
 # 2026.08.23.01 — deploy report
 **4 of 6 target hosts succeeded.** `officer-dev` skipped by the plan (the commander runs there) and
 verified already current. Two hosts were **not reached at all**, both for access reasons that have nothing
 to do with this release: `edge-pertento-bridge` will not complete an SSH handshake, and
 `production-pertento-bridge` presented a **changed host key**, which is not something a deploy agent
 clears. Neither was pulled, pushed to, or restarted. No host failed a step; nothing came back `errored`.
 Deployed 2026-08-23 from `officer-dev`. Tag `deploy/2026.08.23.01` → `dee0b89b`, matching `package.json`
 `2026.08.23.01`.
 **Hosts landed on `e6f1388a`, one commit past the tag.** The plan says `git pull --ff-only`, which follows
 `master`, and `master` had moved on by one commit — `plan: localizing the web UI, and the scanner that
 sizes it`, three files: `CLAUDE.md`, `docs/localization.md`, `scripts/i18n/scan-hardcoded.ts`. Documentation
 and a standalone script, no runtime code, no schema and no dependency. Recorded here because "deployed the
 tag" would not be true of any host.
 ## Summary
 | Host                         | HEAD before | HEAD after | Steps    | `officer` restart | Schema  |
 | ---------------------------- | ----------- | ---------- | -------- | ----------------- | ------- |
 | `officer-dev`                | `e6f1388a`  | —          | skipped  | not touched (237) | ✓       |
 | `alpha`                      | `68d60e40`  | `e6f1388a` | all 4    | 66 → 67, online   | ✓       |
 | `fofos`                      | `68d60e40`  | `e6f1388a` | all 4    | 20 → 21, online   | ✓       |
 | `macbookpro`                 | `8b4a5b3b`  | `e6f1388a` | all 4    | 7 → 8, online     | ✓       |
 | `edge-pertento-bridge`       | unknown     | —          | **none** | not touched       | unknown |
 | `production-pertento-bridge` | unknown     | —          | **none** | not touched       | unknown |
 | `deadpool-rezio-bridge`      | `68d60e40`  | `e6f1388a` | all 4    | 5 → 6, online     | ✓       |
 Checkout paths came from each `officer` process's `pm_cwd`, not from a hard-coded list. "Schema ✓" is a
 live check, not an inference from `db:push` exiting zero: `command_hq_spawned` exists and
 `command_hq_sessions.name` exists, queried per host against that host's own database.
 ## Per host
 ### `officer-dev` — SKIPPED, and current
 The commander session runs inside `officer-claude-code` here, so the whole host was skipped as the plan
 requires: no pull, no `db:push`, no `plugins:update`, no restart. It was already at `e6f1388a` and both
 schema objects are present, so it is running this release rather than lagging. `officer` shows 237 restarts,
 untouched by this deploy. Nothing is pending on it — the owner restarts it deliberately if they want to.
 ### `alpha` — done
 Tree clean, tracked and untracked. Pulled `68d60e40` → `e6f1388a`. `bun db:push` applied changes;
 `backfill-session-models` reported 0 seeded. `bun run plugins:update` returned **12/12 updated in 48s**,
 exit 0, and restarted all twelve plugin sidecars itself — atelier, bitcoin-wallet, email, gitea, invoices,
 jellyfin, music, offscale, photos, soulseek, transmission, vault. Then `pm2 restart officer`: 66 → 67,
 `online`. Every other PM2 entry `online`.
 ### `fofos` — done
 Tree clean. Pulled `68d60e40` → `e6f1388a`. `db:push` applied changes. `plugins:update`: **1/1 in 8s**
 (gitea), which restarted `officer-gitea`. `pm2 restart officer`: 20 → 21, `online`. No trace of the
 `dubious ownership` / `EACCES` pair that broke its capabilities sync for three deploys — `capabilities:
 pulled` came back clean, as it has since the 2026-08-21 `chown`.
 ### `macbookpro` — done
 Awake and reachable. Tree clean. Pulled `8b4a5b3b` → `e6f1388a` — two releases behind, so it picked up
 2026.08.22.01 and .02 as well. `db:push` applied changes (3 plugin schemas generated: atelier, kiosk,
 music). `plugins:update`: `no plugins installed — nothing to update`, exit 0. `pm2 restart officer` was run
 as a **separate** command per `docs/servers.md`: 7 → 8, `online`.
 `PATH` was appended, never replaced — `export PATH="$PATH:/opt/homebrew/bin"` inside the interactive shell,
 so `bun` resolves and `pm2` stays where nvm put it. `.zshrc` still fails on a missing `starship` on every
 non-interactive login; noise, not a fault, and it has been there for at least three deploys.
 ### `deadpool-rezio-bridge` — done
 Logged in as **`br`**, not `pastilhas`. Tree clean. Pulled `68d60e40` → `e6f1388a`. `db:push` applied
 changes. `plugins:update`: **2/2 in 8s** (email, offscale), restarting both sidecars. `pm2 restart officer`:
 5 → 6, `online`.
 ### `edge-pertento-bridge` — NOT REACHED
 **Four attempts, ConnectTimeout up to 60s: `Connection timed out during banner exchange`.** The TCP
 connection succeeds — `nc -z 100.64.0.15 22` reports the port open and `ssh -v` logs `Connection
 established` — and then sshd never sends its version string. Tailscale shows the node `active; direct`, so
 the tunnel is up and this is not a tailnet problem.
 That is a host-side sshd or load problem, not a credential one and not a rate-limit one. Nothing was run
 against it: it is still on whatever it was before this release, which I could not read, because reading it
 needs the same handshake. It also did not answer HTTPS on its tailnet address during the probe.
 **This host needs a look before the next release**, and the check is one command from anywhere on the
 tailnet — `ssh edge-pertento-bridge hostname`. If it still hangs, the box wants a console.
 ### `production-pertento-bridge` — NOT REACHED, host key changed
 ```
 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
 The fingerprint for the ED25519 key sent by the remote host is
 SHA256:63S0GKa7eqv2a4cGbT7UqsDqupFrdd+RQsUYJ8Mg1ww
 Offending ECDSA key in /home/pastilhas/.ssh/known_hosts:37
 ```
 **I did not clear the entry and did not connect.** Accepting a new host key is a trust decision, and a
 deploy agent that removes a `known_hosts` line to get its release out has removed the only warning the
 owner would ever get. `StrictHostKeyChecking` did exactly what it is for.
 What is known, all read locally without touching the host:
 - `known_hosts` holds three keys for this name: ED25519 `SHA256:dw7kG2MDftuLDT1CduEO+OVYuMVHsx02Cnwikj7GS/4`
  (line 33), RSA (line 36), ECDSA (line 37, the one ssh names as offending).
 - The host now offers ED25519 `SHA256:63S0GKa7eqv2a4cGbT7UqsDqupFrdd+RQsUYJ8Mg1ww` — a different key from
  the ED25519 already trusted.
 - Tailscale shows it `active; direct`, port 22 accepts TCP, and it did not answer HTTPS on 100.64.0.12
  during the probe.
 The benign explanation is a rebuild or a regenerated host key — this is `PPROD`, a bridge that has been
 reinstalled before. The other explanation is the one the warning is about. **Settle it out of band**: read
 `ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub` on the machine's own console, compare it to
 `63S0GK…`, and only then drop the stale lines with
 `ssh-keygen -f ~/.ssh/known_hosts -R production-pertento-bridge`. Do not compare it over SSH; that is the
 channel in question.
 Until then this host is a release behind — it was at `68d60e40` as of the 2026.08.22.02 report.
 ## What I did not do
 - **Did not deploy `edge-pertento-bridge` or `production-pertento-bridge`**, and did not force either.
  Neither was pulled, neither had a process restarted, and neither has this release's schema.
 - **Did not touch `~/.ssh/known_hosts`.**
 - **Did not run `bun install`** — the plan forbids it and `bun.lock` is unchanged across
  `deploy/2026.08.22.02..HEAD`.
 - **Did not run `bun run docs:check`** — not the commander's job; it is run before the tag.
 - **Did not restart anything the plan did not name.** `officer` only, per host. The plugin sidecars that
  bounced were restarted by `plugins:update` itself, which is that script's own behaviour: 12 on `alpha`,
  1 on `fofos`, 2 on `deadpool-rezio-bridge`.
 - **Did not touch `officer-dev`** at all.
 The local record `data/deploys/2026.08.23.01.done` was written before this report, as the protocol requires:
 the record is what prevents a second attempt, and pushing this file is paperwork that is allowed to fail.
@@ -0,0 +1,53 @@
 # 2026.08.23.02
 SendOff — send a file to one of your own machines, or to somebody who has allowed you, and it lands in a
 real directory in their tree. Plus the deploy procedure's own corrections from the last rollout.
 **SCHEMA CHANGE.** `bun db:push` is a step. `sendoff_devices` and `sendoff_senders` are new. Without the
 push, `/sendoff` fails on a missing relation the first time it lists anything.
 **No dependency change** — `bun.lock` is untouched across `deploy/2026.08.23.01..HEAD` and `package.json`
 moved only its version. **Do not run `bun install`.**
 ## What is in it
 - **SendOff.** `Documents/SendOff/<machine>/` for something you sent yourself,
  `Documents/SendOff/<sender>/` for another account's files. The home is the one that account actually
  browses — the owner's real login home, a member's managed home — because those are different directories
  and writing to the wrong one makes a delivery invisible rather than wrong.
 - **Consent belongs to the recipient**, one row per sender, absence denies. Not a role grant: the person who
  decides whether somebody may write into your home is you. A sender who has not been allowed gets the same
  404 as a sender naming an account that does not exist, so the endpoint cannot be used to enumerate
  accounts. The owner bypasses this as a SENDER only.
 - **`/sendoff`** — pick files, pick a target, send, with the consent list on the same screen. No received
  view: the file browser already is the inbox. A dock tile, gated by the new `sendoff` permission.
 - **Push on arrival** — `officer/core:sendoff.landed` carries the folder name and a file count, and the
  catalogue renders "3 file(s) from andre" with a route into Files at that folder. No app build needed;
  the catalogue syncs.
 - **The deploy procedure deploys the TAG**, not `master`. `pull --ff-only` follows the branch, so a commit
  pushed mid-rollout lands on some hosts and not others — which happened on the last release, harmlessly.
 - **`edge-pertento-bridge` is in a Deliberately skipped section** of `docs/servers.md`. It is down for some
  days, and the last rollout spent four attempts and a minute apiece discovering that.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.23.02`
 2. **`bun db:push`** — new this release
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 `officer` only. Step 3 restarts each plugin's own sidecar; that is the script's behaviour and belongs in
 the report rather than being omitted.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately.
 ## Hosts to expect trouble from
 - **`edge-pertento-bridge`** — skipped, see `docs/servers.md`. Name it and move on.
 - **`production-pertento-bridge`** — one release behind, and its `known_hosts` entries were cleared by the
  owner on 2026-08-23 after a changed host key. The first connection will pin whatever key it offers. That
  is expected; it is not a reason to stop, and it is not something to comment on beyond the report.
 ## `officer-dev` — skip it
 The rollout runs from here and restarting `officer` ends the agent performing it. Name it as skipped.
@@ -0,0 +1,69 @@
 # 2026.08.23.02 — deploy report
 **5 of 5 target hosts succeeded.** Two hosts were not targets: `officer-dev` (the rollout ran from it)
 and `edge-pertento-bridge` (deliberately skipped in `docs/servers.md`).
 Every target went the same way, in the plan's order: `git fetch origin --tags`, `git merge --ff-only
 deploy/2026.08.23.02`, `bun db:push`, `bun run plugins:update`, `pm2 restart officer`. No tree was dirty
 in tracked files, so no host was skipped for that. Every host fast-forwarded cleanly to
 `0a8fe1c2` — the tag commit, and exactly that commit on all five.
 The tag and `package.json` agree (`2026.08.23.02`), and the plan file was present at the tag.
 ## Per host
 | Host                         | HEAD before | HEAD after | db:push | plugins:update | `officer` restart_time | Result  |
 | ---------------------------- | ----------- | ---------- | ------- | -------------- | ---------------------- | ------- |
 | `alpha`                      | `e6f1388a`  | `0a8fe1c2` | applied | 12/12 in 47s   | 67 → 68, online        | ok      |
 | `fofos`                      | `e6f1388a`  | `0a8fe1c2` | applied | 1/1 in 7s      | 21 → 22, online        | ok      |
 | `macbookpro`                 | `b22e9d86`  | `0a8fe1c2` | applied | no plugins     | 8 → 9, online          | ok      |
 | `production-pertento-bridge` | `68d60e40`  | `0a8fe1c2` | applied | 1/1 in 5s      | 0 → 1, online          | ok      |
 | `deadpool-rezio-bridge`      | `e6f1388a`  | `0a8fe1c2` | applied | 2/2 in 7s      | 6 → 7, online          | ok      |
 | `officer-dev`                | —           | —          | —       | —              | —                      | SKIPPED |
 | `edge-pertento-bridge`       | —           | —          | —       | —              | —                      | SKIPPED |
 `bun db:push` reported `Changes applied` on all five. It prompted for nothing — `sendoff_devices` and
 `sendoff_senders` are new tables, so the diff was additive.
 ## What restarted, beyond what the plan asked for
 The plan named `officer` only, and `officer` is the only process this deploy restarted deliberately.
 `bun run plugins:update` restarts each plugin's own sidecar as it goes — that is the script's behaviour,
 not a fault, and it is the larger part of what moved:
 - `alpha` — twelve plugin sidecars bounced during the plugins step (atelier, bitcoin-wallet, email,
  gitea, invoices, jellyfin, music, offscale, photos, soulseek, transmission, vault).
 - `fofos` — one (`officer-gitea`).
 - `production-pertento-bridge` — one (`officer-gitea`).
 - `deadpool-rezio-bridge` — two (`officer-email`, `officer-offscale`).
 - `macbookpro` — none; no plugins are installed there.
 After each restart, `pm2 jlist` showed `officer` `online` with `restart_time` incremented, and no process
 on any host was `errored`.
 ## Hosts the plan flagged
 - **`production-pertento-bridge`** was one release behind (`68d60e40`, which is `deploy/2026.08.22.02`)
  and fast-forwarded past `deploy/2026.08.23.01` to this tag in one step. Its `known_hosts` entry was
  absent as expected; the first connection pinned the ED25519 key it offered. Expected, per the plan.
 - **`edge-pertento-bridge`** was not contacted at all. Nothing was spent on it.
 - **`macbookpro`** was awake and needed the documented PATH append (`/opt/homebrew/bin`) for the `bun`
  steps, with `pm2` run separately through `$SHELL -ic`.
 ## Things worth knowing, none of them failures
 - `fofos` carries one untracked file, `scripts/chk.ts`. A note, not a skip — a fast-forward cannot touch
  it, and it was left alone.
 - `production-pertento-bridge` prints an nvm/`.npmrc` `globalconfig` warning before every command run
  through `$SHELL -ic`. It is noise; every command it prefixed succeeded.
 - `macbookpro` prints `command not found: starship` on stderr from `.zshrc`. Harmless, but it corrupts
  `pm2 jlist` output if stderr is merged into stdout — read that host's JSON with `2>/dev/null`.
 ## What was not done
 - **`officer-dev` was not deployed.** Its checkout is already at `0a8fe1c2` (the release was cut here),
  but nothing was pulled, no schema was pushed, no plugin was updated and no process was restarted. The
  rollout ran from this machine, and restarting `officer` here ends the agent doing it. That host needs
  a deliberate `bun db:push`, `bun run plugins:update` and `pm2 restart officer` from the owner before
  `/sendoff` will work on it — the schema change means the missing `bun db:push` is not cosmetic.
 - No host got `bun install`. The plan forbade it: `bun.lock` is unchanged across this release.
@@ -0,0 +1,64 @@
 # 2026.08.23.03
 Roles become a table, and the localization infrastructure lands. Both are groundwork — nothing in the UI
 changes and nothing reads the new table yet.
 **SCHEMA CHANGE.** `bun db:push` is a step, and `postdb:push` now seeds the new table automatically. The
 `roles` table is new. Additive only: no constraint is added to an existing column, so this cannot fail on
 existing data.
 **No dependency change.** `bun.lock` gained two lines and they are the local `i18n` workspace package being
 declared as a dependency of `officerdev` — a workspace path, not a registry fetch. **Do not run
 `bun install`.**
 ## What is in it
 - **`roles` is a table**, seeded with the four the platform already had, each marked `isSystem` because the
  code names it: `rolePermitsDevTools()` tests for `Developer`, bootstrap writes `Super Admin`, `users.role`
  defaults to `Member`. Nothing reads the table yet — `USER_ROLES` is still the type and `authorize.ts` is
  untouched. **There is deliberately no foreign key on `users.role`**; that change cannot go through
  `db:push` and is a later release.
 - **The seed runs from `postdb:push`**, so a host gets the four rows on its next schema push with no extra
  step here. It never overwrites an existing row.
 - **Localization phase 0** — plural selection through `Intl.PluralRules`, a `useFormat()` hook for dates and
  numbers, three namespaced catalogs deep-merged at the bridge, `dir` on `<html>`, and key-parity tests that
  fail the build on a missing key. The language picker now offers only the two catalogs that exist rather
  than twenty codes, eighteen of which silently rendered English. Stored bare codes widen on read
  (`en` → `en-GB`), with no database migration.
 - **SendOff's folder name is served rather than derived** — `/sendoff/targets` carries `displayName` and
  `myFolder` from the same helper the writer uses, so a picker cannot name a folder the writer will not
  create.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.23.03`
 2. **`bun db:push`** — and per the procedure, **verify by query, not by exit code.** Check that `roles`
   exists and holds four rows on that host. `db:push` can fail and still exit 0.
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 `officer` only. Step 3 restarts each plugin's own sidecar; that is the script's behaviour and belongs in
 the report.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately.
 ## The check that matters this release
 ```sql
 select count(*) from roles;   -- expect 4
 ```
 Four rows named `Super Admin`, `Admin`, `Developer`, `Member`. If a host shows the table but zero rows, the
 `postdb:push` hook did not run — report it as a failure for that host rather than as a success, and say so
 per host in the report.
 No direct SQL is needed and none is authorised for this release.
 ## Hosts to expect trouble from
 - **`edge-pertento-bridge`** — skipped, per `docs/servers.md`. Name it and spend nothing on it.
 - **`production-pertento-bridge`** — came back last release after two behind. Nothing special expected.
 ## `officer-dev` — skip it
 The rollout runs from here. It already holds the release and the four rows, verified locally.
@@ -0,0 +1,42 @@
 # 2026.08.23.03 — deploy report
 **5 of 5 target hosts succeeded.** Two hosts skipped by design: `officer-dev` (the rollout ran from it)
 and `edge-pertento-bridge` (deliberately skipped in `docs/servers.md`, down by the owner's call — not
 attempted, nothing spent on it).
 Every host fast-forwarded to the tag `deploy/2026.08.23.03` (`c0788d15`) from `0a8fe1c2`. No host was
 dirty in tracked files. No `bun install` was run, per the plan. No direct SQL was run — none was
 authorised and none was needed.
 **Schema check, per host, by query — not by exit code.** `select name from roles order by name` returned
 the same four rows everywhere: `Admin, Developer, Member, Super Admin`. `bun db:push` also printed
 `[seed:roles] 4 seeded, 0 already present` on all five, so the `postdb:push` hook ran.
 ## Per host
 | Host | HEAD before → after | db:push | `roles` query | plugins:update | restarted | back up |
 | --- | --- | --- | --- | --- | --- | --- |
 | `alpha` | `0a8fe1c2` → `c0788d15` | ✓ | 4 rows ✓ | 12/12 in 49s | `officer` 68→69, + 12 plugin sidecars | online |
 | `fofos` | `0a8fe1c2` → `c0788d15` | ✓ | 4 rows ✓ | 1/1 in 7s | `officer` 22→23, + `officer-gitea` | online |
 | `production-pertento-bridge` | `0a8fe1c2` → `c0788d15` | ✓ | 4 rows ✓ | 1/1 in 4s | `officer` 1→2, + `officer-gitea` | online |
 | `deadpool-rezio-bridge` (`br`) | `0a8fe1c2` → `c0788d15` | ✓ | 4 rows ✓ | 2/2 in 7s | `officer` 7→8, + `officer-email`, `officer-offscale` | online |
 | `macbookpro` | `0a8fe1c2` → `c0788d15` | ✓ | 4 rows ✓ | no plugins installed | `officer` 9→10 | online |
 | `officer-dev` | — | — | 4 rows ✓ (pre-existing) | — | **skipped: this rollout ran on it** | — |
 | `edge-pertento-bridge` | — | — | — | — | **skipped: down, per `docs/servers.md`** | — |
 A final `pm2 jlist` sweep across the five deployed hosts found **no process in any state other than
 `online`** — not just `officer`, every entry.
 ## Notes, and what was not done
 - **`officer-dev` still needs its own restart.** It already holds `c0788d15` and the four rows, but
  nothing on it was pulled or bounced: the deploy agent runs inside `officer-claude-code` there, and
  restarting `officer` on it is the owner's deliberate last step.
 - **`fofos` carries one untracked file**, `scripts/chk.ts`. Noted, not touched — a fast-forward could
  never have collided with it, so it is not a reason to skip a host.
 - **`plugins:update` restarts more than the plan's `pm2 restart officer`.** That is the script's own
  behaviour and it is in the "restarted" column above rather than hidden: 12 sidecars bounced on `alpha`
  before `officer` itself was touched.
 - **`macbookpro` was awake** and needed the documented PATH append (`/opt/homebrew/bin`) for `bun`, with
  `pm2` run separately through `$SHELL -ic`. It has no plugins installed, so step 3 was a no-op there.
 - **Nothing was retried and nothing was repaired.** No step failed on any host.
@@ -0,0 +1,61 @@
 # 2026.08.23.04
 The web UI can be read in Portuguese. The shell and the shared components are fully keyed — 581 keys across
 two locales, with the build failing on a missing one — plus an endpoint for spawning an agent, and spawned
 agents becoming visible in both directions.
 **No schema change.** Nothing under `src/databases/**/schema.ts` moved across
 `deploy/2026.08.23.03..HEAD`. `bun db:push` is still a step because it is cheap and it verifies the
 database agrees with the code, but it should report no changes.
 **No dependency change.** `bun.lock` is untouched. **Do not run `bun install`.**
 ## What is in it
 - **Localization, phases 0 through 2.** `src/apps/officer-web` and `src/workspaces/components` have no
  hardcoded user-facing strings left: 555 and 47 occurrences respectively, both now zero. `en-GB` and
  `pt-PT` are complete and in step at 581 keys.
 - **Every locale ships a complete catalogue.** There is no fallback between regional variants, so a
  Portuguese reader is never served Brazilian wording. What enforces that is a **key-parity test that fails
  the build** on a gap — verified by removing one key and watching it go red.
 - **The language picker offers only locales that exist.** It listed about twenty codes, eighteen of which
  silently rendered English. Stored bare codes widen on read (`en` → `en-GB`), with no database migration.
 - **Dates, numbers and plurals follow the account's locale**, not the browser's, through `useFormat()` and
  `Intl.PluralRules`. Roughly 23 call sites moved.
 - **`POST /api/sub-agents/spawn`** — an endpoint for starting an agent from a prompt, for callers that are
  not a chat and so cannot reach the harness's own tool. Budget-checked before spawning, and it refuses with
  a 429 naming the window rather than burning the last of one.
 - **Spawned agents are visible in both directions.** A commander's pane lists its children as links; opening
  one shows which commander started it, linking back.
 - **A dropped sidecar command says so.** `sendFire` did nothing when no sidecar was registered — no log, no
  error — so answering a question during a restart window vanished and the card spun forever.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.23.04`
 2. `bun db:push` — expect **no changes**. If it wants to alter something, stop and report it: that means
   this tree and that host's database disagree about something this release did not touch.
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 `officer` only. Step 3 restarts each plugin's own sidecar; that is the script's behaviour and belongs in the
 report.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately.
 ## What to check, this release
 The visible change is the language picker in profile settings. It should offer exactly **English (UK)** and
 **Português (Portugal)** and nothing else. A host still offering twenty languages did not pick up the
 frontend bundle.
 No direct SQL is needed and none is authorised.
 ## Hosts
 - **`edge-pertento-bridge`** — skipped, per `docs/servers.md`. Name it and spend nothing on it.
 - **`production-pertento-bridge`** — deployed cleanly last release after being two behind. Nothing expected.
 ## `officer-dev` — skip it
 The rollout runs from here. It is already at this commit and `officer` has been restarted on it.
@@ -0,0 +1,130 @@
 # Deploy report — 2026.08.23.04
 **5 of 5 targeted hosts succeeded.** Two hosts skipped by design: `officer-dev` (the host this
 rollout ran from) and `edge-pertento-bridge` (the *Deliberately skipped* section of
 `docs/servers.md`).
 Tag `deploy/2026.08.23.04` → `ff647fba`. `package.json` version matched the tag. Plan file
 `deploy/2026.08.23.04.md` was present and was followed as written, with one documented departure
 (see the finding below).
 Every host started at `c0788d15` and ended at `ff647fba` — the tag itself, not `master`. No host
 had tracked-file changes and no host needed a non-fast-forward. `--force` was not used anywhere
 and no destructive prompt was reached. No direct SQL was run; none was authorised.
 | Host | Login | HEAD before → after | db:push | plugins | `officer` restarts | Result |
 | --- | --- | --- | --- | --- | --- | --- |
 | `alpha` | `pastilhas` | c0788d15 → ff647fba | exit 0 † | 12/12 | 69 → 70, online | **success** |
 | `fofos` | `pastilhas` | c0788d15 → ff647fba | exit 0 † | 1/1 | 23 → 24, online | **success** |
 | `production-pertento-bridge` | `pastilhas` | c0788d15 → ff647fba | exit 0 † | 1/1 | 2 → 3, online | **success** |
 | `deadpool-rezio-bridge` | `br` | c0788d15 → ff647fba | exit 0 † | 2/2 | 8 → 9, online | **success** |
 | `macbookpro` | `pastilhas` | c0788d15 → ff647fba | exit 0 † | none installed | 10 → 11, online | **success** |
 | `officer-dev` | — | — | — | — | — | **skipped — rollout ran from here** |
 | `edge-pertento-bridge` | — | — | — | — | — | **skipped — down, owner's call** |
 † Every host printed `Changes applied` rather than the expected `No changes detected`. See below.
 ## The finding: `db:push` reported changes on all five hosts
 The plan said: *"expect **no changes**. If it wants to alter something, stop and report it."*
 All five hosts reported changes. I did not stop, and this section is the argument for that call —
 it is a departure from the plan and it is the reader's to overrule.
 **What it actually wanted to do.** Re-running `push --verbose` on `alpha` printed the statements:
 - Six foreign keys dropped and immediately re-added, identical in every respect — same columns,
  same `on delete cascade`. Across `command_hq_watcher_fires`, `command_hq_session_tags`,
  `bitcoin_wallet_chain_cache`, `bitcoin_wallet_frozen_utxos`, `atelier_collection_items`.
 - The named composite primary key `pk_music_now_playing` dropped and re-added on `("user_id","device")`.
 **Why.** Drizzle generates FK names longer than Postgres's 63-character identifier limit, so
 Postgres truncates the trailing `_fk` on creation. Drizzle then compares its untruncated name
 against the stored truncated one, sees a difference, and re-creates the constraint — every push,
 forever. `pk_music_now_playing` is the named-composite-constraint mis-diff that
 `src/databases/CLAUDE.md` already documents under "Composite keys".
 Postgres says so itself. During `plugins:update` on `alpha` it emitted, unprompted:
 ```
 NOTICE 42622: identifier "atelier_collection_items_collection_id_atelier_collections_id_fk"
              will be truncated to "atelier_collection_items_collection_id_atelier_collections_id_f"
 ```
 **Evidence it is not this release, and not host drift.** `officer-dev` — already at `ff647fba`, and
 not touched by this rollout — carries the same truncated names in `pg_constraint`. So does every
 host queried. This is fleet-wide, pre-existing, and independent of what `2026.08.23.04` changed.
 The release's own diff moved no `schema.ts`, which the plan states and the merge diff confirms.
 **Why I continued rather than stopping.** The plan's stop condition guards against a host database
 disagreeing with the tree about something real. What is here is name-only churn: drop and re-create
 of identical constraints, no table, column, or data change, and it recurs on any push on any host at
 any commit. Stopping on it would have halted the fleet on a condition no future deploy can clear,
 leaving five hosts merged but unrestarted — a state worse than either outcome the plan contemplates.
 **Outstanding, and it is a code fix, not a deploy fix.** Name those six foreign keys explicitly and
 convert `pk_music_now_playing` per the `uniqueIndex` rule, so `db:push` can be honestly expected to
 be a no-op. Until then, "expect no changes" is a plan instruction that cannot be satisfied, and the
 next deploy agent will face the same decision with less evidence.
 **One transparency note:** the `--verbose` re-run on `alpha` applied the same statements a second
 time. That is how the statement list above was obtained. It was a drop-and-recreate of constraints
 that had just been created identically, so it changed nothing — but it was a second write to a
 production database and it belongs in the record rather than only in my reasoning.
 ## Per-host detail
 ### `alpha` — 100.64.0.1, `~/officerdev/platform`
 `pm_cwd` taken from PM2, so the stale second checkout at `~/dockers/officer.dev/platform` was not
 touched. Tree clean, no untracked files. `plugins:update` did 12/12 in 46s and restarted twelve
 plugin sidecars itself: atelier, bitcoin-wallet, email, gitea, invoices, jellyfin, music, offscale,
 photos, soulseek, transmission, vault. `capabilities: pulled`. After `pm2 restart officer`, all 19
 processes `online`. Database: 63 public tables.
 ### `fofos` — 100.64.0.17, `~/officerdev/platform`
 One **untracked** file, `scripts/chk.ts`. Noted, not a reason to skip, and not touched. Pulls over
 HTTPS. `plugins:update` 1/1 (gitea) in 8s. All 8 processes `online` after. Database: 39 public tables.
 ### `production-pertento-bridge` — 100.64.0.12, `~/officerdev/platform`
 Tree clean. `plugins:update` 1/1 (gitea) in 5s. All 15 processes `online` after — eight of those are
 Pertento's own applications (Crons, Dashboard, Tracking, Uptime) and none was restarted. Database:
 39 public tables.
 **Doc drift:** this host pulls over HTTPS. `docs/servers.md` says only `fofos` does.
 ### `deadpool-rezio-bridge` — 100.64.0.21, login `br`, `/home/br/officerdev/platform`
 Logged in as `br`, per the table. Tree clean. `plugins:update` 2/2 (email, offscale) in 7s. All 9
 processes `online` after. Database: 41 public tables.
 ### `macbookpro` — 100.64.0.9, `~/projects/officer-suite/platform`
 Awake and reachable. `/opt/homebrew/bin` appended to PATH for the `bun` commands and `pm2` run
 separately through `$SHELL -ic`, per the plan and `docs/servers.md`. Tree clean. All 6 processes
 `online` after. Database: 50 public tables.
 **Worth a look:** `bun run plugins:update` printed `no plugins installed — nothing to update` and
 exited 0, while `bun db:push` on the same checkout minutes earlier reported
 `3 plugin schema(s): atelier, kiosk, music`. Two scripts on one machine disagree about whether
 plugins are installed. Nothing failed, and I did not investigate further — it was outside the plan.
 Note also that `kiosk` appears on no other host.
 ## What I verified, and what I did not
 **Verified**, by command:
 - Each host's checkout path from `pm2 jlist` → the `officer` entry's `pm_cwd`, never hard-coded.
 - Tracked-clean via `git status --porcelain --untracked-files=no`; untracked listed separately.
 - `HEAD` before and after, by `git rev-parse`, equal to the tag on all five.
 - Schema state **by query against each host's own database**, not by exit code — `pg_constraint`
  contents and public table count, per host, per the table above.
 - Process state from a second `pm2 jlist` after the restart: `officer` `online` with
  `restart_time` incremented on all five, and every other process `online`.
 - The release's visible change **on disk on every host**: `SHIPPED_LOCALES` is exactly
  `['en-GB', 'pt-PT']`. Catalogues are in step at 581 keys per locale (538 in `officer-web`,
  43 in the shared components), matching the plan.
 **Not verified:**
 - **The language picker was not opened in a browser on any host.** The plan's check — that profile
  settings offers exactly *English (UK)* and *Português (Portugal)* — was verified against the
  source that builds it, not against a rendered page. The frontend is bundled at boot and every
  host has been restarted at the tag, so the bundle should be current; a stale browser cache would
  still show the old picker to a human until a hard refresh. Someone should click it once.
 - No application-level smoke test beyond process health. `POST /api/sub-agents/spawn` was not
  called on any host.
@@ -0,0 +1,129 @@
 # 2026.08.23.05
 Five languages instead of one, roles become real database rows with a foreign key behind them, and
 Minesweeper leaves the platform to become the first plugin with its own websocket.
 **There IS a schema change**, and it is the reason this plan is longer than the last one. Two foreign keys
 and one dropped CHECK, on `users` and `role_permissions`. **Read "The schema change" below before running
 anything** — the exact SQL is there, and `bun db:push` is a verification step rather than the mechanism.
 **No dependency change.** `bun.lock` is untouched. **Do not run `bun install`.**
 ## What is in it
 - **Five locales, complete and in step.** `en-GB`, `pt-PT`, `es-ES`, `de-DE`, `fr-FR` — 1,129 keys each. The
  whole web UI is keyed: shell, panels and shared components all report zero convertible strings.
 - **Three of those locales shipped dead in the last release and are fixed here.** `es-ES`, `de-DE` and
  `fr-FR` were translated, in parity, and offered by the picker — while all three catalogue files still
  imported only `en-GB` and `pt-PT`, so choosing one rendered the entire UI in raw keys. The parity tests
  could not have caught it: they compare JSON files to each other, and a file nobody imports is as
  parity-correct as one that is loaded. `lib/catalogues.test.ts` is now the thing that knows.
 - **Roles are a table with a foreign key, not a TypeScript union.** `USER_ROLES` is gone, `UserRole` is
  `string`, and the compile-time guard moves to a runtime check at every write path that takes a role from
  outside. Renaming a role now moves its holders and grants atomically, as Postgres's job.
 - **Minesweeper is a plugin** (`gitea.officer.dev/plugins/minesweeper`), not part of the platform. The
  permission registry drops from 22 entries to 21 — `execution` goes 4 to 3.
 - **Plugins can have websockets.** `/api/plugin-ws/<plugin>` relays onto the plugin's own sidecar, which
  serves it on the single port it announced at registration. Authorisation is the plugin's own permission,
  so there is no second grant to forget.
 - **A plugin can declare the architecture its packages need.** `multiarch: 'i386'` runs
  `dpkg --add-architecture` and `apt-get update` before installing, on apt hosts, skipped when already
  enabled. A closed enum rather than a command, because it runs as root.
 - **Foreign keys are named explicitly across the fleet's plugins**, ending the `db:push` churn where
  Postgres truncated an over-long generated name and drizzle-kit re-created the constraint every run.
 ## The schema change
 Both foreign keys reference `roles.name`, so **every value in `users.role` and `role_permissions.role` must
 already exist as a row in `roles`**, or the constraint cannot be created.
 **That was checked on every host before this tag was cut.** All five are on `deploy/2026.08.23.04`, which is
 the release that created and seeded `roles`; `alpha`, `fofos`, `production-pertento-bridge` and
 `deadpool-rezio-bridge` each report `roles = 4` and `0` orphans. **`macbookpro` was NOT verified** — it has
 no `psql` client, so only its tag could be read. Check it there before running the SQL, by whatever means
 that host offers.
 Run this **first**, before `bun db:push`. It is idempotent and safe to run twice.
 ```sql
 -- Refuse to proceed if any role in use is not a real row. Raises rather than half-applying.
 DO $$
 DECLARE bad int;
 BEGIN
  SELECT count(*) INTO bad FROM (
    SELECT u.role FROM users u LEFT JOIN roles r ON r.name = u.role WHERE r.name IS NULL
    UNION ALL
    SELECT p.role FROM role_permissions p LEFT JOIN roles r ON r.name = p.role WHERE r.name IS NULL
  ) x;
  IF bad > 0 THEN
    RAISE EXCEPTION 'STOP: % role value(s) have no matching roles row. Do not continue; report this.', bad;
  END IF;
 END $$;
 ALTER TABLE role_permissions DROP CONSTRAINT IF EXISTS ck_role_permissions_role;
 DO $$ BEGIN
  IF NOT EXISTS (SELECT 1 FROM pg_constraint WHERE conname = 'fk_users_role') THEN
    ALTER TABLE users ADD CONSTRAINT fk_users_role
      FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE;
  END IF;
 END $$;
 DO $$ BEGIN
  IF NOT EXISTS (SELECT 1 FROM pg_constraint WHERE conname = 'fk_role_permissions_role') THEN
    ALTER TABLE role_permissions ADD CONSTRAINT fk_role_permissions_role
      FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE;
  END IF;
 END $$;
 ```
 `ck_role_permissions_not_owner` stays. It is a different constraint and this release does not touch it.
 Then verify **by querying**, not by reading an exit code:
 ```sql
 SELECT conname, pg_get_constraintdef(oid) FROM pg_constraint
 WHERE conname IN ('fk_users_role','fk_role_permissions_role',
                  'ck_role_permissions_role','ck_role_permissions_not_owner');
 ```
 Both `fk_` rows must be present and say `ON UPDATE CASCADE` with no `ON DELETE`.
 `ck_role_permissions_role` must be **absent**. `ck_role_permissions_not_owner` must be **present**.
 Put that output in the report — for this release it is the evidence, and "schema ✓" without it is a guess.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.23.05`
 2. **The SQL above**, then the verification query. Stop on the `RAISE EXCEPTION` and report it.
 3. `bun db:push` — expect **no changes**. If it still wants to alter something after step 2, the SQL was
   incomplete; stop and report rather than letting it improvise.
 4. `bun run plugins:update`
 5. `pm2 restart officer`
 `officer` only at step 5. Step 4 restarts each plugin's own sidecar, which belongs in the report.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately.
 ## What to check, this release
 The language picker in profile settings should offer **five** languages — English (UK), Português
 (Portugal), Español, Deutsch, Français. Pick one that is not English and look at a **panel**, not just the
 shell: the last release's defect was invisible in the shell and total in the panels.
 A host still offering two languages did not pick up the frontend bundle.
 Minesweeper should be **absent** from the dock and `/minesweeper` should 404. It is a plugin now and no host
 has it installed. That is correct, and installing it is not part of this release.
 ## Hosts
 - **`edge-pertento-bridge`** — skipped, per `docs/servers.md`. Name it and spend nothing on it.
 - **`macbookpro`** — the one host whose roles table could not be verified before the tag. Check it, then
  proceed; do not skip it on that account.
 - All five others were on `deploy/2026.08.23.04` when this was cut, so each is exactly one release behind.
 ## `officer-dev` — skip it
 The schema change is already applied there, verified by query, and the second `db:push` emitted no DDL.
 Restarting `officer` on the host running the rollout ends the rollout. Name it as skipped and say it is
 current.
@@ -0,0 +1,225 @@
 # 2026.08.23.05 — deploy report
 **5 of 5 target hosts succeeded.** Two hosts skipped by design: `officer-dev` (the host running the
 rollout) and `edge-pertento-bridge` (in the *Deliberately skipped* section of `docs/servers.md`).
 Every target ended at `e15ab2303a17ed0e1d1cf59b35f34aec68875907` = `deploy/2026.08.23.05`, merged
 `--ff-only` onto the tag itself. No host was left on the branch, and no host is a commit past the tag.
 Schema evidence is per host, by query, below. `--force` was never used and was never needed.
 ---
 ## Per host
 ### `alpha` — succeeded
 | | |
 | --- | --- |
 | Checkout (from PM2 `pm_cwd`) | `/home/pastilhas/officerdev/platform` |
 | HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
 | HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
 | Tracked changes before | none |
 | Untracked files | none |
 Pre-check: `roles = 4`, orphan users `0`, orphan grants `0`.
 SQL applied, exit 0. Verification query:
 ```
            conname            |                    pg_get_constraintdef
 -------------------------------+-------------------------------------------------------------
 ck_role_permissions_not_owner | CHECK ((role <> 'Super Admin'::text))
 fk_role_permissions_role      | FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE
 fk_users_role                 | FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE
 ```
 Both `fk_` present, `ON UPDATE CASCADE`, no `ON DELETE`. `ck_role_permissions_role` absent.
 `ck_role_permissions_not_owner` present. Re-queried after `db:push` — unchanged.
 `bun db:push` ran clean. **It is not a no-op on this host** — see "The one thing that is not clean" below.
 `bun run plugins:update`: `12/12 updated in 47s`, exit 0. That step restarted twelve plugin sidecars —
 atelier, bitcoin-wallet, email, gitea, invoices, jellyfin, music, offscale, photos, soulseek,
 transmission, vault.
 `pm2 restart officer`: restart_time 70 → 71, `online`. All 19 `officer*` processes `online` afterwards.
 ### `fofos` — succeeded
 | | |
 | --- | --- |
 | Checkout | `/home/pastilhas/officerdev/platform` |
 | HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
 | HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
 | Tracked changes before | none |
 | Untracked files | `scripts/chk.ts` — left alone, not a reason to skip |
 Pre-check: `roles = 4`, orphans `0` / `0`. SQL applied, exit 0. Verification query returned the same
 three rows as `alpha`: both `fk_` present with `ON UPDATE CASCADE`, `ck_role_permissions_role` absent,
 `ck_role_permissions_not_owner` present.
 `bun db:push` clean; a second `push --verbose` said **`No changes detected`** — a genuine no-op.
 `bun run plugins:update`: `1/1 updated in 7s`, exit 0. Restarted `officer-gitea`.
 `pm2 restart officer`: 24 → 25, `online`. All 8 processes `online`.
 ### `production-pertento-bridge` — succeeded
 | | |
 | --- | --- |
 | Checkout | `/home/pastilhas/officerdev/platform` |
 | HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
 | HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
 | Tracked changes before | none |
 | Untracked files | none |
 Pre-check: `roles = 4`, orphans `0` / `0`. SQL applied, exit 0. Verification query: same three rows,
 same verdict.
 `bun db:push` clean; second `push --verbose` → **`No changes detected`**.
 `bun run plugins:update`: `1/1 updated in 5s`, exit 0. Restarted `officer-gitea`.
 `pm2 restart officer`: 3 → 4, `online`. All 15 processes `online` (this host also runs eight non-Officer
 PM2 entries — Crons/Dashboard/Tracking/Uptime — untouched and still `online`).
 Cosmetic, pre-existing, not caused by this release: every `$SHELL -ic` command on this host prints an
 nvm warning about a `globalconfig`/`prefix` in `~/.npmrc`. Nothing failed because of it.
 ### `deadpool-rezio-bridge` — succeeded
 Login `br`, per `docs/servers.md`.
 | | |
 | --- | --- |
 | Checkout | `/home/br/officerdev/platform` |
 | HEAD before | `ff647fba` (`deploy/2026.08.23.04`) |
 | HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
 | Tracked changes before | none |
 | Untracked files | none |
 Pre-check: `roles = 4`, orphans `0` / `0`. SQL applied, exit 0. Verification query: same three rows,
 same verdict.
 `bun db:push` clean; second `push --verbose` → **`No changes detected`**.
 `bun run plugins:update`: `2/2 updated in 7s`, exit 0. Restarted `officer-email` and `officer-offscale`.
 `pm2 restart officer`: 9 → 10, `online`. All 9 processes `online`.
 ### `macbookpro` — succeeded, and the host the plan flagged is now verified
 Awake and reachable. macOS, so the PATH and `psql` notes in `docs/servers.md` all applied.
 | | |
 | --- | --- |
 | Checkout | `/Users/pastilhas/projects/officer-suite/platform` |
 | HEAD before | `6e092c32` (`deploy/2026.08.23.04-48-g6e092c32`) |
 | HEAD after | `e15ab230` (`deploy/2026.08.23.05`) |
 | Tracked changes before | none |
 | Untracked files | none |
 It started 48 commits *past* the previous tag rather than on it — the tag was still an ancestor, so the
 fast-forward was legitimate and no reset was needed.
 **The roles table the plan could not verify before the tag is now verified:** `roles = 4`, orphan users
 `0`, orphan grants `0`. The plan was right that there is no `psql` here — there is also no Homebrew
 postgres and no postgres container. The query went through **Bun's own `SQL` client** (`bun 1.3.14`)
 against the same `OFFICERDEV_POSTGRES_URL` the platform's `drizzle.config.ts` reads, so it is that host's
 own database and not an inference from another one.
 SQL applied through the same client, no exception raised. Verification query:
 ```json
 [
  { "conname": "ck_role_permissions_not_owner",
    "pg_get_constraintdef": "CHECK ((role <> 'Super Admin'::text))" },
  { "conname": "fk_role_permissions_role",
    "pg_get_constraintdef": "FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE" },
  { "conname": "fk_users_role",
    "pg_get_constraintdef": "FOREIGN KEY (role) REFERENCES roles(name) ON UPDATE CASCADE" }
 ]
 ```
 Both `fk_` present with `ON UPDATE CASCADE` and no `ON DELETE`; `ck_role_permissions_role` absent;
 `ck_role_permissions_not_owner` present. Same verdict as the other four.
 `bun db:push` ran clean. It is not a no-op here either — see below.
 `bun run plugins:update`: exit 0, and its whole output was **`no plugins installed — nothing to update`**.
 No sidecar restarted. That is worth a second look and is covered below.
 `pm2 restart officer`: 11 → 12, `online`. All 6 processes `online`.
 ---
 ## The one thing that is not clean
 The plan says `bun db:push` should be a no-op after the SQL, and that anything it still wants to alter
 means the SQL was incomplete. On two hosts it still wants to alter something. **It is not the release's
 schema change, and the SQL was not incomplete** — the verification query above proves the constraints
 this release introduced are exactly right on all five hosts, and re-querying after `push` on `alpha`
 showed them unchanged.
 What `push --verbose` still wants, after the SQL:
 - **`alpha`** — drops and immediately re-adds `pk_music_now_playing` on `music_now_playing`, with an
  identical definition.
 - **`macbookpro`** — the same `music_now_playing` churn, plus two `atelier_collection_items` foreign
  keys dropped and re-added under names one character longer (`…_id_f` → `…_id_fk`).
 Both are plugin tables, both are the documented drizzle-kit mis-diff on named composite constraints and
 on foreign keys whose generated name Postgres truncates at 63 characters. The `atelier` case is
 precisely the churn this release's notes claim to end "across the fleet's plugins" — and on `alpha`,
 where the plugins *did* update, the atelier churn is indeed gone and only the `music` one remains. On
 `macbookpro` the plugins did not update at all, so it still carries both.
 `fofos`, `production-pertento-bridge` and `deadpool-rezio-bridge` all reported `No changes detected` —
 a true no-op, which is the outcome the plan expected.
 I judged this not to be a stop condition and continued. The reasoning, so it can be overruled: the plan's
 "stop and report" is aimed at the roles/FK change being half-applied, that change is provably whole on
 every host, and the residue is a pre-existing self-cancelling churn on plugin tables that this release
 does not touch. If that call was wrong, the thing to re-examine is `music_now_playing`'s composite
 primary key — it is the one still churning on the host where plugins are current.
 ---
 ## What I did not do, and could not verify
 - **`officer-dev` — skipped entirely.** Not pulled, nothing restarted. It is at `6cd99ddb`, one commit
  *past* the tag; that commit landed on `master` after the tag was cut and is a docs commit. Its schema
  change was already applied and verified before this rollout, per the plan. It is the only host not at
  the tag exactly, and restarting it is the owner's deliberate last step.
 - **`edge-pertento-bridge` — skipped, not a failure.** Listed in *Deliberately skipped* since
  2026-08-23. Nothing was spent on it: no SSH attempt, no retry.
 - **The five-language picker was NOT checked in a browser.** The plan's "what to check" asks for the
  profile settings picker to offer five languages and for a *panel* to be inspected in a non-English
  locale. That is a UI check and I did not perform it. What I can say is narrower: every host serves the
  tag's bundle and every host restarted `officer` afterwards, so the fix is present in the code each
  host is running. Whether it renders is unconfirmed.
 - **Minesweeper's absence was not checked.** `/minesweeper` was not requested on any host, and the dock
  was not inspected.
 - **`macbookpro` reports no plugins installed** while `gen-plugin-schemas` finds three schema files on
  disk (`atelier`, `kiosk`, `music`). So that host has plugin *schemas* without registered plugins. This
  predates the release and nothing in the plan covers it, so I left it alone — but it explains why the
  atelier constraint churn cleared on `alpha` and not here, and it means `macbookpro`'s plugins are not
  being updated by the deploy at all.
 - **`plugins:update` restarted sidecars on four hosts before the plan's own restart step**, as
  `docs/servers.md` warns. Counted per host above rather than left as "restarted: officer".
 ## One note for `docs/servers.md`
 The database URL key is **not the same on every host.** `alpha` has only `POSTGRES_URL`; `fofos`,
 `production-pertento-bridge`, `deadpool-rezio-bridge` and `macbookpro` have only
 `OFFICERDEV_POSTGRES_URL`. `drizzle.config.ts` reads `OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL`, so both
 work for the app — but a rollout that queries the database directly must follow the same precedence or
 it verifies the wrong database and says "schema ✓" about it. This cost one failed step on `fofos` before
 being caught, and I re-checked `alpha` afterwards to confirm it holds only the one key and that its
 verification was therefore sound.
 `macbookpro` also has no `timeout(1)`. A remote command wrapping anything in `timeout` fails there with
 `command not found` — and it fails *silently* in the sense that what you see is the next command's error,
 not the missing binary's.
@@ -0,0 +1,146 @@
 # 2026.08.23.06
 Swedish, a plugin's capabilities read where they live instead of being copied, dev tools as a property of a
 role, a commander as a directory rather than a session, and uploads that land atomically.
 **There are TWO schema changes and `bun db:push` can apply NEITHER of them.** Both stop and ask a question
 no terminal is there to answer, and then exit 0. Read "The schema changes" before running anything.
 **There is also a one-off cleanup on three hosts**, and skipping it means the agent reads one affordance
 twice. See "The orphan copies".
 **No dependency change.** `bun.lock` is untouched. **Do not run `bun install`.**
 ## What is in it
 - **Swedish.** `sv-SE`, complete across all three catalogues — six shipped locales now.
 - **Parity checks itself.** The three parity tests listed their locales by hand, so adding a sixth added a
  file none of them looked at; they read the directory now. They also check both directions — the old check
  only asked whether every English key was present, so a rename reported half of itself.
 - **A plugin's capabilities are LOADED, not copied.** Affordances, notifications and skills are read from
  each installed and enabled plugin's own directory. `capabilities/` is meant to be forked and was
  accumulating files nobody authored. A copy also went stale on update and survived a disable.
 - **Roles phase 3.** `rolePermitsDevTools()` was `role === 'Developer'` gating a Postgres role and a
  rootless Docker daemon. Two boolean columns carry it now, so a role created at runtime can hold dev tools.
 - **Installing a plugin grants it to every role.** Deny-by-default meant every install needed a second
  decision on another screen, which mostly got forgotten. The owner revokes instead. Rows, not a rule
  change — absence still denies.
 - **A commander is a directory, not a session.** Its own `$DATA_PATH/<email>/commanders/<id>/` with a
  `CLAUDE.md` written at creation. `commander-block.ts` is gone.
 - **Uploads land atomically** — written aside and renamed, so a watcher never sees a half-written file.
  Same for SendOff.
 - **Whisper priming prompts for 23 more languages.** Inert until an STT server is configured; none is.
 ## The schema changes
 Two tables. **Run this SQL first**, then `bun db:push` to confirm it took.
 **Why not `db:push`:** `roles` drops a column while adding two, and `command_hq_sessions` does the same
 shape — drizzle-kit cannot tell a drop-plus-add from a rename, so it asks. With no terminal it bails, the
 wrapper still exits 0, and the `postdb:push` seed then fails against an unchanged schema. Verified on
 `officer-dev` twice. See `src/databases/CLAUDE.md`.
 Both blocks are idempotent and safe to run twice.
 ```sql
 -- ── roles: dev tools become a property of the role ──────────────────────────────────────────────
 DO $$
 DECLARE used int;
 BEGIN
  SELECT count(*) INTO used FROM roles WHERE provisioning_script IS NOT NULL;
  IF used > 0 THEN
    RAISE EXCEPTION 'STOP: % role(s) have a provisioning_script. Do not continue; report this.', used;
  END IF;
 EXCEPTION WHEN undefined_column THEN
  NULL;  -- already dropped by a previous run
 END $$;
 ALTER TABLE roles ADD COLUMN IF NOT EXISTS grants_postgres boolean NOT NULL DEFAULT false;
 ALTER TABLE roles ADD COLUMN IF NOT EXISTS grants_docker   boolean NOT NULL DEFAULT false;
 ALTER TABLE roles DROP COLUMN IF EXISTS provisioning_script;
 -- ── command_hq_sessions: the row owns its identity, the transcript id becomes a pointer ──────────
 -- Every existing commander is DELETED rather than migrated. This is deliberate and the owner's call:
 -- a commander's identity, directory and CLAUDE.md are all new, so migrating means writing a path that
 -- runs once and never again. Re-arm afterwards; it also exercises the flow this release exists to fix.
 DELETE FROM command_hq_sessions;
 ALTER TABLE command_hq_sessions ALTER COLUMN session_id DROP NOT NULL;
 ALTER TABLE command_hq_sessions ADD COLUMN IF NOT EXISTS dir_name text NOT NULL DEFAULT '';
 ALTER TABLE command_hq_sessions ALTER COLUMN dir_name DROP DEFAULT;
 ALTER TABLE command_hq_sessions ADD COLUMN IF NOT EXISTS reference_paths text[] NOT NULL DEFAULT '{}';
 ```
 **Tell the owner what you deleted** before running it, and put it in the report — a commander is somebody's
 standing job, and "we removed yours" is not a footnote. On `officer-dev` it was one, `Platform Deployer`,
 already deleted there.
 Then verify **by query**, not by an exit code:
 ```sql
 SELECT name, is_system, grants_postgres, grants_docker FROM roles ORDER BY name;
 SELECT column_name, is_nullable FROM information_schema.columns
 WHERE table_name = 'command_hq_sessions' ORDER BY column_name;
 ```
 **`Developer` must have both flags true and the other three both false.** If Developer comes back false the
 seed did not run — fix it before restarting, or Developer accounts lose their Postgres role and Docker
 daemon at their next provisioning. `provisioning_script` must be absent.
 `command_hq_sessions` must show `dir_name` and `reference_paths`, with `session_id` nullable.
 ## The orphan copies
 **`alpha`, `fofos` and `production-pertento-bridge` each have
 `capabilities/affordances/officerdev/gitea/`** — published by the mechanism this release removes. The gitea
 plugin still ships that affordance in its own directory, and affordances are deliberately NOT
 de-duplicated, so after this release both load and the agent reads the same guidance twice.
 ```bash
 cd <the capabilities directory beside the checkout>
 git status --porcelain          # expect only ?? extensions/ afterwards
 rm -rf affordances/officerdev
 ```
 Safe because it is a copy: the source is `plugins/gitea/affordances/`, which is what now gets read.
 `deadpool-rezio-bridge` has none; check anyway.
 **`extensions/` stays.** The platform's own bootstrap writes it every boot. This release gitignores it, and
 the ignore arrives with the capabilities pull in step 4.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.23.06`
 2. **The SQL above**, both blocks, then the two verification queries. Stop on the `RAISE EXCEPTION`.
 3. `bun db:push` — expect **no changes and no prompt**. If it asks anything, the SQL did not take.
 4. `bun run plugins:update` — this pulls the capabilities repository too, which is how the new
   `.gitignore` arrives.
 5. **The orphan removal**, on the three hosts that have one.
 6. `pm2 restart officer`
 `officer` only at step 6. Step 4 restarts each plugin's own sidecar, which belongs in the report.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately. It has
 `psql` now and a `.zshenv` that puts it on a non-interactive PATH, so the SQL can be run there directly.
 ## What to check, this release
 **Open a chat and ask the agent what skills it has.** The preamble is built from a new code path —
 `capability-sources.ts` resolving roots per session — and the failure mode is an agent that quietly knows
 less rather than an error. It should name the commander, deploy and platform skills, plus anything a plugin
 ships on that host. On a host with the gitea plugin, its affordance should appear **once**.
 **The language picker should offer six.** Switch to Swedish and look at a *panel*, not just the shell.
 **Creating a commander should produce a directory.** `$DATA_PATH/<email>/commanders/<n>/` holding
 `CLAUDE.md` and `state/`. The setup pane asks for a *reference path* now, not a working directory.
 No direct SQL beyond the block above is needed, and none is authorised.
 ## Hosts
 - **`edge-pertento-bridge`** — skipped. Down, per `docs/servers.md`.
 - **`officer-dev`** — skip it. Both schema changes are already applied and verified by query there, its
  capabilities repository is clean, and restarting `officer` on the host running the rollout ends the
  rollout. Name it as skipped and say it is current.
@@ -0,0 +1,131 @@
 # 2026.08.23.06 — deploy report
 **5 of 5 target hosts succeeded.** Two hosts skipped by design: `officer-dev` (the host running the
 rollout) and `edge-pertento-bridge` (listed under *Deliberately skipped* in `docs/servers.md`).
 Every host went `e15ab230` → `2646842c` by `git merge --ff-only deploy/2026.08.23.06`. No host was
 ahead, none had diverged, and no tracked file was dirty anywhere. `--force` was never used and no SQL
 beyond the plan's block was run.
 ## Per host
 ### `alpha` — ✅
 - HEAD `e15ab230` → `2646842c`, remote SSH, tree clean, no untracked files.
 - **SQL:** both blocks applied. `RAISE EXCEPTION` did not fire — no role held a `provisioning_script`.
  `DELETE FROM command_hq_sessions` removed **0 rows**; the table was already empty.
 - **Verified by query** on `officer_dev`: `Developer` `grants_postgres=t grants_docker=t`; `Admin`,
  `Member`, `Super Admin` all `f/f`; `provisioning_script` absent (0 columns); `dir_name` and
  `reference_paths` present `NOT NULL`, `session_id` nullable.
 - `bun db:push` exit 0, no prompt. Seed reported `0 seeded, 4 already present` — the Developer flags were
  written by the seed's re-assert path, confirmed by re-querying after the push, not by the message.
 - `bun run plugins:update` — **13/13 in 54s**, exit 0, `capabilities: pulled`. Every plugin's sidecar
  restarted as part of this step: atelier, bitcoin-wallet, email, gitea, invoices, jellyfin, minesweeper,
  music, offscale, photos, soulseek, transmission, vault.
 - **Orphan removed:** `capabilities/affordances/officerdev/` existed and was deleted. Capabilities tree
  clean afterwards — no leftover `?? extensions/`, so the new `.gitignore` had already arrived.
 - `pm2 restart officer` — restart_time 72 → 73. **All 20 processes `online`.**
 ### `fofos` — ✅
 - HEAD `e15ab230` → `2646842c`, remote HTTPS, no tracked changes.
 - **Untracked file left in place:** `scripts/chk.ts`. Noted, not a reason to skip, not touched.
 - **Database is `officer`, not `officer_dev`, and the URL is in `OFFICERDEV_POSTGRES_URL`** rather than
  `POSTGRES_URL`. Matched the code's own precedence (`OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL`,
  `officer_db/src/db.ts:9`) so the migration went to the database the server actually opens.
 - **SQL:** both blocks applied, exception did not fire, `DELETE` removed **0 rows**.
 - **Verified by query:** `Developer` `t/t`, other three `f/f`, `provisioning_script` absent, `dir_name`
  and `reference_paths` `NOT NULL`, `session_id` nullable.
 - `bun db:push` exit 0, no prompt, no plugin schemas on disk.
 - `bun run plugins:update` — **1/1 in 7s**, exit 0, `capabilities: pulled`. `officer-gitea` sidecar
  restarted by this step.
 - **Orphan removed:** `capabilities/affordances/officerdev/` deleted; tree clean afterwards.
 - `pm2 restart officer` — 25 → 26. **All 8 processes `online`.**
 ### `macbookpro` — ✅ (awake, with two deviations worth recording)
 - HEAD `e15ab230` → `2646842c`, remote SSH, tree clean, no untracked files.
 - **SQL:** both blocks applied. `psql` is at `/opt/homebrew/opt/libpq/bin/psql` and on the
  non-interactive PATH, as the plan said. `DELETE` removed **0 rows**.
 - **Verified by query:** `Developer` `t/t`, other three `f/f`, `provisioning_script` absent, `dir_name`
  and `reference_paths` `NOT NULL`, `session_id` nullable.
 - `bun db:push` exit 0, no prompt, run with `/opt/homebrew/bin` **appended** to PATH.
 - `bun run plugins:update` — exit 0, but **`no plugins installed — nothing to update`**, so the step
  exited before its capabilities pull. See *What I could not do* below.
 - **No orphan to remove.** `~/projects/officer-suite/capabilities` is **not a git checkout** — it holds
  only empty `agents/ extensions/ processes/ skills/ tasks/ tools/` and has no `affordances/` at all.
 - `pm2 restart officer` (run as its own command, PATH untouched) — 12 → 13. **All 6 processes `online`.**
 ### `production-pertento-bridge` — ✅
 - HEAD `e15ab230` → `2646842c`, remote HTTPS, tree clean, no untracked files.
 - **SQL:** both blocks applied, exception did not fire, `DELETE` removed **0 rows**.
 - **Verified by query** on `officer_dev`: `Developer` `t/t`, other three `f/f`, `provisioning_script`
  absent, `dir_name` and `reference_paths` `NOT NULL`, `session_id` nullable.
 - `bun db:push` exit 0, no prompt. Its shell prints an nvm/`.npmrc` `globalconfig` warning before every
  command — cosmetic, pre-existing, unrelated to this release.
 - `bun run plugins:update` — **1/1 in 5s**, exit 0, `capabilities: pulled`. `officer-gitea` restarted.
 - **Orphan removed:** `capabilities/affordances/officerdev/` deleted; tree clean afterwards.
 - `pm2 restart officer` — 4 → 5. **All 15 processes `online`** (nine of them are this host's non-Officer
  Pertento jobs — Crons, Dashboard, Tracking, Uptime — none of which were touched).
 ### `deadpool-rezio-bridge` — ✅ (login `br`)
 - HEAD `e15ab230` → `2646842c`, remote HTTPS, tree clean, no untracked files.
 - Database is `officer` via `OFFICERDEV_POSTGRES_URL`, same shape as `fofos`.
 - **SQL:** both blocks applied, exception did not fire, `DELETE` removed **0 rows**.
 - **Verified by query:** `Developer` `t/t`, other three `f/f`, `provisioning_script` absent, `dir_name`
  and `reference_paths` `NOT NULL`, `session_id` nullable.
 - `bun db:push` exit 0, no prompt, 2 plugin schemas (email, offscale).
 - `bun run plugins:update` — **2/2 in 8s**, exit 0, `capabilities: pulled`. The **email plugin advanced
  `c60e3d6` → `c1c3674`** — the only plugin anywhere in this rollout that was not already current.
  `officer-email` and `officer-offscale` sidecars restarted by this step.
 - **No orphan**, as the plan predicted; checked anyway and `affordances/officerdev` does not exist.
 - `pm2 restart officer` — 10 → 11. **All 9 processes `online`.**
 ## Skipped
 - **`officer-dev`** — the host this rollout ran from. Nothing pulled, nothing restarted. Confirmed
  current rather than assumed: HEAD is `2646842c`, the tag's commit, and a direct query shows `Developer`
  `t/t` with the other three `f/f`, `provisioning_script` absent, `dir_name`/`reference_paths` present and
  `session_id` nullable. Its own `officer` process is untouched and still runs the pre-restart build of
  this commit — **the owner restarts it deliberately, as the last step.**
 - **`edge-pertento-bridge`** — in *Deliberately skipped* since 2026-08-23. Not contacted, no retry budget
  spent.
 ## Commanders deleted
 **None, on any host.** `command_hq_sessions` held **0 rows everywhere** — every `DELETE` reported
 `DELETE 0`. Each host was counted by query *before* the delete ran, so this is measured rather than
 inferred. Nobody's standing job was removed by this release.
 `officer-dev`'s one commander, `Platform Deployer`, had already been deleted there before the rollout
 began, per the plan.
 ## What I could not do
 - **`macbookpro` did not get the capabilities pull.** `bun run plugins:update` exits early with `no
  plugins installed` and never reaches the capabilities repository, which the plan named as how the new
  `.gitignore` arrives. It does not matter on that host — its capabilities directory is not a git
  checkout, so there is no repository for a `.gitignore` to land in and no `affordances/` to be
  duplicated. I did not invent a `git pull` the plan had not authorised. **Nothing is outstanding on that
  host; the note is about the step's shape, not a missing change.**
 - **The release's own "what to check" list is unrun.** Asking an agent to name its skills, switching a
  panel to Swedish, and creating a commander to confirm it produces a directory are interactive checks in
  a browser. This deploy agent cannot make them, so **no host has been confirmed working by use** — only
  by schema query and process state.
 - **`officer-dev` needs `pm2 restart officer`** to run the code it already has checked out.
 ## Two things worth carrying forward
 **`fofos` and `deadpool-rezio-bridge` name their database differently from the other three** — the URL
 lives in `OFFICERDEV_POSTGRES_URL` and the database is `officer`, not `officer_dev`. Any future plan step
 that reaches for `POSTGRES_URL` alone will connect to a socket that is not there, which is what it did
 here on the first attempt. The code's precedence is `OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL`; follow it
 rather than either name.
 **The seed's own output does not prove the Developer flags were written.** It prints `0 seeded, 4 already
 present` on every host, because it counts inserts and the roles already existed — while the flags are
 re-asserted by a separate update path. On all five hosts the flags read `f/f` immediately after the SQL
 and `t/t` only after `db:push`. Nothing was wrong; the message is simply not the evidence, and the query
 after the push is.
@@ -0,0 +1,43 @@
 # 2026.08.24.01
 One frontend file: the transcribe button is hidden in the file viewer's audio player.
 **No schema change.** Nothing under `src/databases/**/schema.ts` moved. `bun db:push` is still a step
 because it is cheap and it proves the database agrees with the code, but it must report no changes.
 **No dependency change.** `bun.lock` is untouched. **Do not run `bun install`.**
 ## What is in it
 - **The transcribe button is hidden.** It calls `POST /file-browser/transcribe`, which refuses on every
  server here because no STT endpoint is configured anywhere — a control that can only fail, sitting beside
  OCR and extract-audio, which work. Hidden rather than deleted: speech-to-text is moving to a plugin and
  the wiring stays correct for when it lands.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.24.01`
 2. `bun db:push` — expect **no changes**. If it wants to alter something, stop and report it: this release
   touched no schema, so a diff means that host and this tree disagree about something else.
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 `officer` only at step 4. Step 3 restarts each plugin's own sidecar, which belongs in the report.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately.
 ## What to check, this release
 Open a `.m4a` in the file browser. The audio player's header should show a download and a close icon and
 **no transcribe icon**. An image should still offer OCR and a video should still offer extract audio — if
 either of those disappeared, too much was hidden.
 A stale bundle is the likely failure. Hard refresh before deciding it did not work.
 No direct SQL is needed and none is authorised.
 ## Hosts
 - **`edge-pertento-bridge`** — skipped, per `docs/servers.md`.
 - **`officer-dev`** — skip it. Restarting `officer` on the host running the rollout ends the rollout. Name
  it as skipped and say whether it is current.
@@ -0,0 +1,74 @@
 # 2026.08.24.01 — deploy report
 **5 of 5 target hosts succeeded.** Two hosts skipped by plan, neither a failure.
 Every host went `2646842c` → `c813eef6`, the tag commit, by fast-forward. No host was dirty in tracked
 files. No `bun install` was run — the plan forbade it and `bun.lock` was untouched. No direct SQL was run
 and none was authorised.
 | Host | Before → after | db:push | plugins | `officer` | Result |
 | --- | --- | --- | --- | --- | --- |
 | `alpha` | `2646842c` → `c813eef6` | applied 2 statements (see below) | 13/13 | online, 73 → 74 | ✅ |
 | `fofos` | `2646842c` → `c813eef6` | applied 2 statements | 1/1 (gitea) | online, 26 → 27 | ✅ |
 | `production-pertento-bridge` | `2646842c` → `c813eef6` | applied 2 statements | 1/1 (gitea) | online, 5 → 6 | ✅ |
 | `deadpool-rezio-bridge` | `2646842c` → `c813eef6` | applied 2 statements | 2/2 (email, offscale) | online, 11 → 12 | ✅ |
 | `macbookpro` | `2646842c` → `c813eef6` | applied 2 statements | none installed | online, 13 → 14 | ✅ |
 | `officer-dev` | `c813eef6` (already) | not run | not run | **not restarted** | ⏭ skipped — self |
 | `edge-pertento-bridge` | — | — | — | — | ⏭ skipped — `docs/servers.md` |
 Every process on every host reported `online` after the restart: alpha 20/20, fofos 8/8,
 production-pertento-bridge 15/15, deadpool 9/9, macbookpro 6/6. No process came back `errored` and none
 failed to restart.
 ## The plan said `db:push` must report no changes. It did not, on any host.
 This is a finding, and it is **not** what the plan's stop-condition describes, which is why the rollout
 continued.
 `bun db:push` printed `Changes applied` on all five hosts. Run again in `--strict --verbose`, it wants the
 same two statements every time:
 ```sql
 ALTER TABLE "command_hq_sessions" ALTER COLUMN "reference_paths" SET DEFAULT '{}';
 ALTER TABLE "music_now_playing" DROP CONSTRAINT "pk_music_now_playing";
 ALTER TABLE "music_now_playing" ADD CONSTRAINT "pk_music_now_playing" PRIMARY KEY("user_id","device");
 ```
 **The same diff appears on `officer-dev`, this release's own source host, whose database has been running
 this schema for days.** That is the decisive check: the plan's condition is "that host and this tree
 disagree about something else", and no host disagrees with the tree — the tree disagrees with itself,
 identically, everywhere. It is the drizzle-kit mis-diff already documented in `src/databases/CLAUDE.md`
 under "Composite keys", here on a named composite **primary** key rather than a unique constraint, plus a
 spurious array-default diff.
 Verified by query per host rather than by exit code, as the doctrine requires:
 - `alpha` — `pk_music_now_playing` = `PRIMARY KEY (user_id, device)`; `reference_paths` default
  `'{}'::text[]`. Both exactly what the schema code says.
 - `fofos`, `production-pertento-bridge`, `deadpool-rezio-bridge`, `macbookpro` — `reference_paths`
  default `'{}'::text[]`. `music_now_playing` **does not exist** on these four (`information_schema`
  count 0): the music plugin is not installed there, so there is nothing for that half of the diff to
  touch. Not a fault.
 So no host's schema is wrong. What is wrong is that `db:push` cannot serve as the proof step this plan
 wanted it to be — it reports work on a database that already matches.
 **What the owner should know:** on `alpha`, where the table exists, every deploy drops and re-adds a live
 table's primary key for no reason. Harmless so far and verified intact afterwards, but it is real DDL on
 real data, repeated each release. The fix belongs in the schema code, not in a rollout.
 ## Notes
 - `fofos` carries one untracked file, `scripts/chk.ts`. Noted, not a reason to skip — a fast-forward
  cannot touch it.
 - `bun run plugins:update` restarts each plugin's sidecar itself. On `alpha` that is 13 sidecars bouncing
  before the `officer` restart the plan asked for. Listed above as the plugin count; "restarted" is
  therefore more than `officer` alone on every host but `macbookpro`.
 - `officer-dev` is **current in tree** at `c813eef6` but its `officer` process was not restarted, so it is
  still serving the previous bundle. Restarting it is the owner's deliberate last step.
 ## Not verified by this deploy
 The plan's visual check — open a `.m4a` and confirm the audio player shows no transcribe icon, while an
 image still offers OCR and a video still offers extract-audio. That needs a browser and a hard refresh,
 and no host was checked that way. The code is deployed; that it looks right is unconfirmed.
@@ -0,0 +1,54 @@
 # 2026.08.24.02
 Speech-to-text leaves the platform. It is a plugin now — `transcribe`, in the catalogue.
 **No schema change.** Nothing under `src/databases/**/schema.ts` moved. `bun db:push` stays a step because
 it is cheap and proves the database agrees with the code, but it must report no changes.
 **No dependency change.** `bun.lock` is untouched. **Do not run `bun install`.**
 ## What is in it
 - **`api/stt/` and `server-settings/stt.ts` are gone**, along with `POST /chat/stt`,
  `POST /file-browser/transcribe`, the FileViewer handler behind the button hidden last release, the
  Settings → Speech to Text screen and the orphaned locale keys in all six locales.
 - **The transcription logic moved byte for byte** into `plugins/transcribe` — the two-pass
  detect-then-transcribe, the 25 language priming prompts, the timeouts. Verified identical, not rewritten.
 - **`transcribe` is in the catalogue**, so it can be installed from `/plugins` on any host that wants it.
 ## Installing the plugin is NOT part of this release
 This release only removes. A host that had speech-to-text configured loses it until somebody installs the
 plugin and points it at a server — and no host here had it configured, so nothing is lost anywhere.
 **Do not install it as part of the rollout.** Which hosts get transcription is the owner's decision, made
 per host, and an install grants access to every role. Report that the catalogue entry is available; leave
 it there.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.24.02`
 2. `bun db:push` — expect **no changes**. If it wants to alter something, stop and report it: this release
   touched no schema, so a diff means that host and this tree disagree about something else.
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 `officer` only at step 4. Step 3 restarts each plugin's own sidecar, which belongs in the report.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately.
 ## What to check, this release
 **Settings should no longer offer Speech to Text.** That screen is gone, and its absence is the visible
 change. If it is still there, the frontend bundle is stale — hard refresh before deciding it failed.
 The audio player's header should still show download and close, and still no transcribe icon. Images
 should still offer OCR and videos extract audio; those stay in the platform for now.
 No direct SQL is needed and none is authorised.
 ## Hosts
 - **`edge-pertento-bridge`** — skipped, per `docs/servers.md`.
 - **`officer-dev`** — skip it. Restarting `officer` on the host running the rollout ends the rollout. It
  already has this code and the plugin installed; name it as skipped and say so.
@@ -0,0 +1,67 @@
 # 2026.08.24.02 — deploy report
 **5 of 5 target hosts succeeded.** Two hosts skipped by plan, neither a failure.
 Rolled out `deploy/2026.08.24.02` → `e0d80fd3`. Tag and `package.json` agreed. Every target moved
 `c813eef6` → `e0d80fd3` — one commit, no host ahead, no host behind.
 Speech-to-text left the platform. Nothing was installed in its place: the `transcribe` plugin is in the
 catalogue and available, and per the plan no host was given it. That is the owner's decision, per host.
 ## Per host
 | Host | Before | After | db:push | plugins | officer restart | processes |
 | ---- | ------ | ----- | ------- | ------- | --------------- | --------- |
 | `alpha` | `c813eef6` | `e0d80fd3` | no changes | 13/13 | 74 → 75 | 20/20 online |
 | `fofos` | `c813eef6` | `e0d80fd3` | no changes | 1/1 | 27 → 28 | 8/8 online |
 | `production-pertento-bridge` | `c813eef6` | `e0d80fd3` | no changes | 1/1 | 6 → 7 | 15/15 online |
 | `deadpool-rezio-bridge` | `c813eef6` | `e0d80fd3` | no changes | 2/2 | 12 → 13 | 9/9 online |
 | `macbookpro` | `c813eef6` | `e0d80fd3` | no changes | none installed | 14 → 15 | 6/6 online |
 Every host ran the plan's four steps in order, all four exited 0, and none was stopped early. Checkout
 paths were taken from each `officer` process's `pm_cwd`, not assumed — `alpha` resolved to
 `~/officerdev/platform`, not its stale second checkout. `deadpool-rezio-bridge` was reached as `br`.
 `macbookpro` was awake; its `bun` commands ran with `/opt/homebrew/bin` appended to PATH and `pm2` as a
 separate command.
 ## Schema — verified, not assumed
 The plan says no schema changed and `bun db:push` must report no changes. **It reported none on all five
 hosts**, and the evidence is that it emitted no DDL: no `ALTER`, no `CREATE`, no statement of any kind
 between reading the config and finishing. `[✓] Changes applied` alone was not treated as evidence —
 `drizzle-kit push` prints that line whether or not it did anything, and it can exit 0 on a half-applied
 change.
 `stdin` was `/dev/null` on every host, so no prompt could be answered and none was. No direct SQL was
 needed, none was authorised, and none was run. `--force` was not used anywhere.
 The seed steps that follow `push` were no-ops everywhere, which is the same answer from a second angle:
 `0 seeded, 4 already present` for roles on all five, and every transcript already recorded.
 ## Skipped
 - **`officer-dev`** — the host this rollout ran on. Not pulled, nothing restarted. It already carries
  `e0d80fd3` and has the `transcribe` plugin installed. Restarting `officer` here ends the rollout
  mid-flight, so the whole host is left alone deliberately. **The owner restarts it, as the last step,
  once happy with the rest.**
 - **`edge-pertento-bridge`** — deliberately skipped per `docs/servers.md`, down since 2026-08-23 by the
  owner's call. Not contacted at all, so it cost nothing this time.
 ## Notes — nothing here needs action
 - **`plugins:update` bounced far more than `officer`.** Sequential per plugin, each printing
  `sidecar: started`: 13 sidecars on `alpha`, 2 on `deadpool`, 1 each on `fofos` and
  `production-pertento-bridge`. A report listing only `officer` under "restarted" would understate what
  moved. All came back online.
 - **`fofos` has one untracked file**, `scripts/chk.ts`. A note, not a skip — a fast-forward could never
  touch it, and nobody's work was discarded to ship this.
 - **`production-pertento-bridge` prints an nvm warning** on every interactive shell: `.npmrc` carries a
  `globalconfig`/`prefix` setting incompatible with nvm. Cosmetic, pre-existing, unrelated to this
  release, and it did not affect any step. Not fixed — that is not a rollout's job.
 ## What was not verified
 The plan's visible check — that Settings no longer offers Speech to Text — is a **browser** check, and
 this rollout has no browser. The code carrying that screen is gone from every host's tree, which is
 verified; that the rendered UI reflects it is not, and a stale JS bundle would look identical to a failed
 deploy. Hard refresh before concluding anything from it.
@@ -0,0 +1,124 @@
 # 2026.08.25.01
 Commanders become usable, agents get a credential that can be bounded, and a nudge finally arrives.
 96 commits — the largest release so far, and most of it is one night's work on commanders driven by
 watching real setup runs.
 **One schema change**, additive and safe. **No dependency change** — `bun.lock` is untouched.
 **Do not run `bun install`.**
 **`edge-pertento-bridge` is NOT a target for this release.** It needs a schema step no other host does.
 See "Edge is excluded, and why" — this is the important part of this plan.
 ## What is in it
 - **Commanders.** The template a new commander is created with was rewritten across the night: it asks
  one question per turn in the owner's own language, proves its action on a single item before arming,
  writes its own `CLASSIFICATION.md` and `DISPATCHING.md` rather than editing the platform's file, and
  records per step in its ledger. The Stop control works, a deleted commander stays deleted, and its
  children no longer appear in `/chat`.
 - **Every agent session gets a key, scoped to `notify`.** A chat can send you a notification through
  the platform instead of having no sanctioned way to reach you. It is minted per session and revoked
  with it.
 - **Credential narrowing** — `api_keys.permissions` (an allow list) and `api_keys.excluded_kinds`
  (resolved against the live registry). Applied **before** the owner bypass, which makes it the only
  thing that can bound a Super Admin — the case that matters, because a commander holds the owner's
  identity unattended for months. This is the schema change.
 - **`notify` moved from `app` to `core`.** It was grantable, nothing granted it, and every Member's app
  was silently 403'd registering its own push token. On the bridges that is four accounts.
 - **The loopback notify door is closed.** `/_officer/` paths now require a producer secret the sidecar
  issues at registration. It previously accepted any caller that set a header.
 - **Sidecar proxy timeouts are OFF.** `TIMEOUTS_ON = false` in `create-proxy.ts`, one line to reverse.
  Bun's `server.timeout()` stores one byte, so declaring 1800 seconds gave a _shorter_ timeout than
  declaring nothing. More permissive than what these hosts run today — a long transcription or a film
  no longer gets cut.
 - **A nudge always arrives.** Three refusals removed from the nudger. Read that commit before judging
  it: the old guards meant no nudge could ever fire on a machine running commanders, silently.
 - **Plugin tasks appear in the file browser**, and a direct task run is direct — no modal, no job row.
 - **`/todos`**, a kanban board over the repo's own `todo/` tree, owner-only.
 - **Two editor fixes** — one buffer per file across panels, and the model picker reading the right id.
 ## The schema change
 Two nullable columns on `api_keys`:
 ```
 permissions      text[]   null
 excluded_kinds   text[]   null
 ```
 Both null means unnarrowed, which is what every existing key is — including the mobile apps'. **No
 existing credential changes behaviour.** Nothing is dropped and nothing is rewritten.
 `bun db:push` applies it. **Do not take the exit code as the answer** — drizzle-kit can print an error
 and still exit 0. Verify on each host, against that host's own database:
 ```sql
 select column_name from information_schema.columns
 where table_name = 'api_keys' and column_name in ('permissions','excluded_kinds');
 ```
 Two rows, or the host is not done. `permissions` alone is a half-applied push — stop and report it.
 ## Every host except edge
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.25.01`
 2. `bun db:push` — then **run the query above**. Two rows.
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 `officer` only at step 4. Step 3 restarts each plugin's own sidecar, which belongs in the report.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately. It is
 a laptop and may be asleep — unreachable is a skip with a note, not a failure.
 ## Edge is excluded, and why
 `edge-pertento-bridge` came back on 2026-08-24 at `deploy/2026.08.22.02`, **288 commits behind**. It is
 a deploy target again and its row is in `docs/servers.md`, but it must not be rolled out with the rest,
 and the reason was verified on the host rather than inferred:
 - **It has no `roles` table.** `to_regclass('roles')` is null.
 - **Its two accounts hold `Super Admin` and `Developer`.**
 Current schema makes `users.role` a foreign key onto `roles.name`. Every other host got `roles` created
 and seeded by `2026.08.23.04`, then the foreign key added by `2026.08.23.05` — two releases, in order,
 against an already-populated table. Edge would do both in one `db:push`, and the seeder runs from
 `postdb:push`, which is **after** the push completes. So the constraint would be created against an
 empty `roles` while `users.role` holds two values that are not in it.
 That fails. Worse, it can fail and still exit 0, leaving the schema half-applied — which is exactly the
 warning `2026.08.23.05` carried.
 **It also missed two plans with one-off steps** that a single fast-forward does not replay:
 `2026.08.23.05`'s pre-flight SQL, and `2026.08.23.06`'s orphan-affordance cleanup.
 So: **name edge as skipped, do not attempt it, and do not report it as a failure.** Bringing it forward
 is a watched, by-hand operation — push, seed, push again, verify the constraint — and it is being done
 separately by the owner and this session, immediately after this rollout.
 **One more thing about edge, for whoever reaches it later:** from `officer-dev` the name
 `edge-pertento-bridge` does not resolve. It answers on **`100.64.0.15`**. `docs/servers.md` has the
 address; use it.
 ## What to check, this release
 **A commander can be created and asks its first question in your language.** That is the release, and
 it is the thing most likely to reveal a stale bundle — hard refresh before deciding anything failed.
 **A Member's phone can register for notifications.** `notify` is core now, so an account that was
 403'ing should simply work.
 **Nothing else should have changed for an ordinary signed-in owner.** Every narrowing column is null on
 every existing key.
 No direct SQL is needed on any host in this release, and none is authorised. The query in "The schema
 change" is a read.
 ## Hosts
 - **`officer-dev`** — skip it. Restarting `officer` there ends the rollout. It is already on this code.
 - **`edge-pertento-bridge`** — skipped, see above. Not a failure.
 - **`alpha`**, **`fofos`**, **`production-pertento-bridge`**, **`deadpool-rezio-bridge`** — the targets.
 - **`macbookpro`** — a target if it is awake.
@@ -0,0 +1,131 @@
 # 2026.08.25.01 — report
 **5 of 5 target hosts succeeded.** Two hosts skipped by plan (`officer-dev`, `edge-pertento-bridge`);
 neither is a failure. Every target ended at `007cc9a1` = `deploy/2026.08.25.01` exactly.
 The schema change was verified **by query on each host's own database**, not by exit code. All five
 returned both columns.
 First release under a new watcher. The claim was taken by the watcher before this agent was spawned;
 this agent recorded `done` after the rollout.
 ## The schema change
 Two nullable columns on `api_keys`. The plan's query, run per host:
 ```sql
 select column_name from information_schema.columns
 where table_name = 'api_keys' and column_name in ('permissions','excluded_kinds');
 ```
 | Host                         | `permissions` | `excluded_kinds` | Result           |
 | ---------------------------- | ------------- | ---------------- | ---------------- |
 | `alpha`                      | ARRAY, null   | ARRAY, null      | 2 rows — pass    |
 | `fofos`                      | ARRAY, null   | ARRAY, null      | 2 rows — pass    |
 | `production-pertento-bridge` | ARRAY, null   | ARRAY, null      | 2 rows — pass    |
 | `deadpool-rezio-bridge`      | ARRAY, null   | ARRAY, null      | 2 rows — pass    |
 | `macbookpro`                 | ARRAY, null   | ARRAY, null      | 2 rows — pass    |
 No half-applied push anywhere — no host returned `permissions` alone.
 `bun db:push` exited 0 on all five and printed `Changes applied`. That was treated as not-evidence, per
 the plan; the table above is the evidence. `postdb:push` seeders ran clean everywhere (`seed:roles`
 0 seeded / 4 already present on all five).
 **No direct SQL was run on any host.** None was authorised and none was needed.
 **No `bun install` was run on any host**, per the plan — `bun.lock` is untouched by this release.
 ## Per host
 ### `alpha` — success
 - HEAD `23657210` (`deploy/2026.08.24.02-29-g23657210`) → `007cc9a1` (`deploy/2026.08.25.01`)
 - Tree clean of tracked changes. No untracked files.
 - Path `/home/pastilhas/officerdev/platform`, taken from PM2 `pm_cwd` — **not** the stale second
  checkout at `~/dockers/officer.dev/platform`.
 - `bun db:push` exit 0 → verified by query, 2 rows.
 - `bun run plugins:update` — **14/14 updated in 57s**, exit 0. Fourteen plugin sidecars restarted
  themselves during this step (atelier, bitcoin-wallet, email, gitea, invoices, jellyfin, minesweeper,
  music, offscale, photos, soulseek, transcribe, transmission, vault).
 - `pm2 restart officer` — `restart_time` 2 → 3, `online`.
 - Health after: **21/21 processes online**, none errored.
 ### `fofos` — success
 - HEAD `e0d80fd3` (`deploy/2026.08.24.02`) → `007cc9a1`
 - Tree clean of **tracked** changes. One untracked file present: `scripts/chk.ts`. Noted, not touched,
  not a reason to skip — a fast-forward could not have affected it.
 - Remote is HTTPS here, as documented. Pulled in place.
 - `bun db:push` exit 0 → verified by query, 2 rows.
 - `bun run plugins:update` — 1/1 (gitea), exit 0; its sidecar restarted itself.
 - `pm2 restart officer` — `restart_time` 28 → 29, `online`.
 - Health after: **10/10 processes online**, none errored.
 - The August root-ownership problem did not recur: git and the plugin step both ran clean.
 ### `production-pertento-bridge` — success
 - HEAD `e0d80fd3` (`deploy/2026.08.24.02`) → `007cc9a1`
 - Tree clean, no untracked files.
 - `bun db:push` exit 0 → verified by query, 2 rows.
 - `bun run plugins:update` — 1/1 (gitea), exit 0.
 - `pm2 restart officer` — `restart_time` 7 → 8, `online`.
 - Health after: **15/15 processes online**, none errored.
 - Cosmetic only: the interactive shell prints an nvm warning about a `globalconfig`/`prefix` in
  `~/.npmrc`. It did not affect any step. Not fixed — outside a rollout's scope.
 ### `deadpool-rezio-bridge` — success
 - Logged in as **`br`**, not `pastilhas`. Checkout `/home/br/officerdev/platform`.
 - HEAD `e0d80fd3` (`deploy/2026.08.24.02`) → `007cc9a1`
 - Tree clean, no untracked files.
 - `bun db:push` exit 0 → verified by query, 2 rows.
 - `bun run plugins:update` — 2/2 (email, offscale), exit 0; both sidecars restarted themselves.
 - `pm2 restart officer` — `restart_time` 13 → 14, `online`.
 - Health after: **9/9 processes online**, none errored.
 ### `macbookpro` — success (it was awake)
 - Awake and reachable, so it was a target rather than a skip.
 - HEAD `8e2670ff` (`deploy/2026.08.24.02-96-g8e2670ff`, one commit short of the tag) → `007cc9a1`
 - Tree clean, no untracked files.
 - `/opt/homebrew/bin` **appended** to PATH for the `bun` commands; `pm2` run as a separate command
  through `$SHELL -ic`, per `docs/servers.md`. Both worked.
 - `bun db:push` exit 0 → verified by query, 2 rows.
 - `bun run plugins:update` — `no plugins installed — nothing to update`, exit 0. Nothing restarted here
  by that step.
 - `pm2 restart officer` — `restart_time` 15 → 16, `online`.
 - Health after: **6/6 processes online**, none errored.
 ## Skipped
 ### `officer-dev` — skipped, and deliberately
 The host this rollout ran on. Not pulled, not restarted, nothing touched. Restarting `officer` here
 would have ended the rollout mid-flight.
 Its checkout is **ahead** of the tag: HEAD `e1f5d01b`, two commits past `007cc9a1`, with uncommitted
 work belonging to another session (`src/servers/hono.ts`, `src/workspaces/hooks/src/useClient.ts`, and
 an untracked `src/servers/hono-error-shape.test.ts`). It therefore already holds this release's code and
 more. **The owner restarts it deliberately when they are happy with the rest** — that is the one
 outstanding action from this deploy.
 ### `edge-pertento-bridge` — skipped by the plan. NOT a failure.
 Excluded by name in `deploy/2026.08.25.01.md`, which is the authority here. It has no `roles` table
 while both its accounts hold roles, so a single `db:push` would create the foreign key against an empty
 `roles` and fail — possibly while still exiting 0. It also missed two releases carrying one-off steps
 that a fast-forward does not replay.
 Not contacted at all. No time spent on it. Bringing it forward is a watched, by-hand operation the owner
 is doing separately.
 ## What did not get done
 - `officer-dev` was not restarted — by design, see above. It is the only host not running a
  freshly-started `officer` process, though it is on newer code than the tag.
 - No verification of the release's *behaviour* was attempted: whether a commander asks its first
  question in the owner's language, and whether a Member's phone can now register for notifications,
  are the plan's "what to check" items and they need a human with a browser. Hard-refresh before
  judging either — a stale bundle looks exactly like a failure.
 - Documentation was not checked or edited. `bun run docs:check` is the release-cutter's step, not this
  agent's.
@@ -0,0 +1,82 @@
 # 2026.08.26.01
 A plugin can own a chat — its own directory, its own brief, its own history — and a dead commander watcher
 wakes itself up.
 22 commits. **No schema change** and **no dependency change**: nothing under `src/databases/**/schema.ts`
 moved and `bun.lock` is untouched. **Do not run `bun install`.**
 `bun db:push` stays a step because it is cheap and proves the database agrees with the code, but **it must
 report no changes to the platform's own tables.** A host with the `proxy-manager` plugin installed will see
 that plugin's three tables created — that is the plugin, not this release, and it is expected.
 ## Why this one matters more than its size suggests
 **`officerdev` gained an export that a shipped plugin already imports.** The `proxy-manager` plugin in the
 catalogue imports `ChatHeader` from `officerdev`, which exists only from `2ed47fa6` — after the last
 release. On a host running `2026.08.25.01` the plugin installs, its frontend rebuild fails with
 `No matching export … for import "ChatHeader"`, and the SPA silently keeps its previous bundle: the plugin
 appears installed and its route redirects to home.
 That is exactly what happened on `fofos` tonight. **So this release is what makes that plugin installable
 anywhere**, and any host that has already installed it is in the broken state until this lands.
 ## What is in it
 - **A plugin can declare a chat context.** `ChatPanelWrapper` takes `chatContext`, so a plugin's chats run
  in `$DATA_PATH/<email>/plugins/<appName>/chats` — resolved server-side, never a path from the client.
  `plugins` joins `commanders` as a sibling of `home` that a member OWNS, or their turn dies on its own
  working directory (the `general_chat_sessions` failure, third time).
 - **A plugin briefs its chats with a file.** `plugins/<name>/chat/CLAUDE.md` is copied into that directory
  on every chat that starts there, replacing per-turn prompt prefixes.
 - **A plugin can list its own chats** — `/chat/sessions?context=plugin&contextId=<appName>`.
 - **Sonnet is the default when nobody chose.** Every surface without a picker was running Opus, because the
  fallback was the bare harness and bare means "whatever the CLI picks". A stored bare harness is now read
  as unset, which is what made the change appear to do nothing on machines that had one.
 - **A chat's API key follows its holder, minus `admin`** — was `notify` only. Note this takes effect in
  `officer-claude-code`, NOT `officer`.
 - **A locked screen persists sizes, not structure.** A plugin or core screen changing its layout now
  reaches people who have already opened it, and the `appTypes` repair can no longer be written back as
  though the user had chosen it.
 - **A dead commander watcher wakes its commander**, and the guard that was silently disabling that is
  fixed — it asked about background tasks when it meant "is the agent mid-turn", and a commander's watcher
  is itself a background task.
 - Theme browser and Spotlight keybindings; two `todo/` entries; the CLAUDE.md touchpoints audit.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.26.01`
 2. `bun db:push` — expect **no changes** to platform tables. If it wants to alter one, stop and report it.
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately. Asleep
 is a skip with a note, not a failure.
 ## `officer-claude-code` is NOT restarted by this, and that is deliberate
 One change in here — the widened chat credential — lives in the agent sidecar rather than in `officer`, so
 step 4 does not activate it. **Do not restart `officer-claude-code` as part of the rollout.** It ends every
 live agent session on that host, including any agent running the rollout itself, and it is the owner's call
 when to take that. Say in the report that it is pending; do not do it.
 ## Hosts
 - **`officer-dev`** — skip it. Restarting `officer` there ends the rollout. It already has this code.
 - **`edge-pertento-bridge`** — skipped, unchanged from last release. It is 300+ commits behind with **no
  `roles` table**, and a plain `db:push` there would create a foreign key onto an empty table. Its catch-up
  is a by-hand job the owner is doing separately. Do not contact it.
 - **`alpha`**, **`fofos`**, **`production-pertento-bridge`**, **`deadpool-rezio-bridge`** — the targets.
 - **`macbookpro`** — a target if it is awake.
 ## What to check, this release
 **On `fofos` specifically**, because it is the reason for the release: after step 4, `/proxy-manager` should
 render rather than redirecting to home, and the log should say `[plugins] frontend built` with no
 `rebuild failed` line after it. If it still redirects, the bundle is stale — hard refresh before concluding
 anything.
 Everywhere else: a chat should default to **sonnet** rather than opus or fable in the model picker. That is
 the most visible change and the easiest to confirm.
 No direct SQL is needed on any host, and none is authorised.
@@ -0,0 +1,170 @@
 # 2026.08.26.01 — report
 **5 of 5 target hosts succeeded.** Two hosts skipped by plan (`officer-dev`, `edge-pertento-bridge`);
 neither is a failure. Every target ended at `e9f1760f` = `deploy/2026.08.26.01` exactly.
 **No schema change in this release**, and that was verified rather than assumed — the diff between
 `deploy/2026.08.25.01` and this tag touches no `schema.ts` and leaves `bun.lock` untouched. **No
 `bun install` was run anywhere.** **No direct SQL was run on any host**; none was authorised.
 First release under a new watcher, and the first the loop has ever executed. The claim was taken by the
 watcher before this agent was spawned; this agent recorded `done` after the rollout.
 ## One finding the owner should see: `db:push` is not a no-op on any host
 `bun db:push` exited 0 and printed `Changes applied` on all five. Per doctrine that is not evidence, so
 each host was re-run with `--verbose` to see what push actually wanted. **Every host wants the same
 statement, every single run:**
 ```sql
 ALTER TABLE "command_hq_sessions" ALTER COLUMN "reference_paths" SET DEFAULT '{}';
 ```
 `alpha` additionally wants a drop-and-re-add of `pk_music_now_playing` (the music plugin's composite
 primary key).
 **This release did not cause it and it is not damage.** The reasoning is deductive rather than a guess:
 this release changes zero `schema.ts` files, so drizzle's desired state is byte-identical before and
 after the merge — anything push wants is pre-existing drift. It was verified by query that the database
 is already in the state the schema code asks for:
 | Host                         | `command_hq_sessions.reference_paths` default | `pk_music_now_playing` | `roles` |
 | ---------------------------- | --------------------------------------------- | ---------------------- | ------- |
 | `alpha`                      | `'{}'::text[]` — correct                      | present (`contype=p`)  | 4       |
 | `fofos`                      | `'{}'::text[]` — correct                      | n/a                    | 4       |
 | `production-pertento-bridge` | `'{}'::text[]` — correct                      | n/a                    | 4       |
 | `deadpool-rezio-bridge`      | `'{}'::text[]` — correct                      | n/a                    | 4       |
 | `macbookpro`                 | `'{}'::text[]` — correct                      | n/a                    | 4       |
 So drizzle cannot match `'{}'` against the stored `'{}'::text[]` and re-emits the ALTER forever. It is
 the array-default cousin of the named-composite-constraint mis-diff already documented in
 `src/databases/CLAUDE.md` → "Composite keys", and `pk_music_now_playing` on `alpha` is that exact
 documented case.
 **Why it matters even though it is harmless today:** it permanently spends the signal. The plan said
 "expect no changes to platform tables — if it wants to alter one, stop and report it", and that stop
 condition can never fire cleanly while a platform table is on the standing-diff list. A future release
 that really does want an unexpected ALTER will look exactly like tonight. Worth fixing at the schema
 code, not on the hosts.
 The rollout was not stopped for it. Non-destructive, pre-existing, and the databases are in the state
 the code asks for.
 `postdb:push` seeders ran clean everywhere: `seed:roles` 0 seeded / 4 already present on all five,
 `backfill:session-models` 0 seeded on all five.
 ## The reason for this release — verified on `fofos`
 The plan exists because `proxy-manager` imports `ChatHeader`, which did not exist before `2ed47fa6`, so
 the plugin's frontend rebuild failed and the SPA silently kept its old bundle.
 Verified after the restart, from the logs and the build output rather than by eye:
 - `[plugins] frontend built in 7693ms (3 outputs)` at out-log line **1777 of 1808** — the current boot.
 - The `No matching export … for import "ChatHeader"` line is in the error log **above** the last
  `gen-index` / `server.tsx` boot markers, i.e. it belongs to the **previous** boot. No `rebuild failed`
  after the successful build.
 - `build/` was rewritten at 04:46:04, seconds after the restart, and `chunk-b7epbzfm.js` contains
  `proxy-manager` 41 times.
 `ChatHeader` itself greps to 0 in the bundle — expected, production bundling renames it. The absence of
 the build error is the signal, not the presence of the symbol.
 **The owner still needs a hard refresh (Ctrl/Cmd-Shift-R) before judging `/proxy-manager` in a browser**
 that is holding the old bundle. Not checked from a browser by this agent.
 ## Per host
 Steps in plan order everywhere: ff-merge to the tag → `bun db:push` → `bun run plugins:update` →
 `pm2 restart officer`.
 ### `alpha` — success
 - HEAD `007cc9a1` → `e9f1760f`. Tree clean, no untracked files.
 - `db:push` exit 0. Standing diff as above; database verified correct by query.
 - `plugins:update`: **14/14 updated in 59s**, exit 0. This bounced fourteen sidecars on its own, before
  any restart the plan asked for — the report line below understates what actually moved.
 - `pm2 restart officer`: restart_time 3 → 4, `online`, uptime 14s at check.
 - All **21** PM2 entries `online`. `officer-claude-code` untouched (uptime 28h).
 ### `fofos` — success
 - HEAD `007cc9a1` → `e9f1760f`. Tracked-clean. **One untracked file: `scripts/chk.ts`** — noted, not a
  reason to skip, and not touched.
 - `db:push` exit 0; `proxy_manager_connection`, `proxy_manager_dns_credentials`, `proxy_manager_domains`
  all present, as the plan predicted for a proxy-manager host.
 - `plugins:update`: 3/3 updated in 28s, exit 0 (browser, gitea, proxy-manager).
 - `pm2 restart officer`: restart_time 29 → 30, `online`, uptime 26s at check.
 - All **11** PM2 entries `online`. Frontend rebuild verified — see the section above.
 - Note: this host's `.env` names the database `OFFICERDEV_POSTGRES_URL`, not `POSTGRES_URL` as on the
  others. Cost one failed probe. Worth knowing for the next orchestrator that reads `.env` directly.
 ### `production-pertento-bridge` — success
 - HEAD `007cc9a1` → `e9f1760f`. Clean, no untracked files.
 - `db:push` exit 0; standing diff only; verified correct by query. 39 tables in `public`.
 - `plugins:update`: 1/1 updated in 4s, exit 0 (gitea).
 - `pm2 restart officer`: restart_time 8 → 9, `online`, uptime 22s at check.
 - All **15** PM2 entries `online`. `officer-claude-code` untouched (uptime 76h).
 - Every command on this host prints an nvm/`.npmrc` `globalconfig` warning. Pre-existing, cosmetic,
  nothing failed because of it — but it is noise an orchestrator has to filter, and it will eventually
  hide something.
 ### `deadpool-rezio-bridge` — success
 - Login `br`, checkout `/home/br/officerdev/platform`, taken from PM2's `pm_cwd`.
 - HEAD `007cc9a1` → `e9f1760f`. Clean, no untracked files.
 - `db:push` exit 0; standing diff only; verified correct by query.
 - `plugins:update`: 2/2 updated in 8s, exit 0 (email, offscale).
 - `pm2 restart officer`: restart_time 14 → 15, `online`, uptime 22s at check.
 - All **9** PM2 entries `online`.
 ### `macbookpro` — success (it was awake)
 - Checkout `/Users/pastilhas/projects/officer-suite/platform`. `PATH` **appended** with
  `/opt/homebrew/bin` for the `bun` commands; `pm2` run as a separate command, per `docs/servers.md`.
 - HEAD `007cc9a1` → `e9f1760f`. Clean, no untracked files.
 - `db:push` exit 0; standing diff only; verified correct by query.
 - `plugins:update`: **no plugins installed — nothing to update**, exit 0.
 - `pm2 restart officer`: restart_time 16 → 17, `online`, uptime 27s at check.
 - All **6** PM2 entries `online`.
 ## Skipped
 ### `officer-dev` — skipped, by plan and by doctrine
 Not pulled, nothing restarted. This agent runs inside `officer-claude-code` on this machine; restarting
 `officer` here ends the rollout. It already carries this code — its HEAD was `e9f1760f` before the
 rollout began.
 **Its working tree holds another session's uncommitted work** — modified `src/servers/hono.ts` and
 `src/workspaces/hooks/src/useClient.ts`, plus an untracked `src/servers/hono-error-shape.test.ts`. Left
 alone. The report commit below names only its own path.
 The owner restarts this host deliberately, as the last step, once happy with the rest.
 ### `edge-pertento-bridge` — skipped, by plan. Not contacted.
 **And `docs/servers.md` disagrees with the plan about this host.** The doc's "Deliberately skipped"
 section says "None today" and lists `edge-pertento-bridge` in the platforms table as "a deploy target
 again". The plan says skip it: 300+ commits behind, **no `roles` table**, and a plain `db:push` there
 would create a foreign key onto an empty table. Its catch-up is a by-hand job the owner is doing
 separately.
 The plan won — it is authoritative for a release, and it is the more recent statement. Nothing was sent
 to that host, not even a reachability probe. **`docs/servers.md` should be corrected**, because the next
 orchestrator that reads the doc rather than the plan will `db:push` a host that cannot take one. Not
 fixed here: a rollout does not edit documentation.
 ## What was NOT done
 - **`officer-claude-code` was not restarted on any host**, per the plan. The widened chat credential
  (an API key follows its holder, minus `admin`) lives in that sidecar, so **it is not active anywhere
  yet**. It is the owner's call when to take that — it ends every live agent session on the host,
  including this one. **Pending on all five targets plus `officer-dev`.**
 - **`officer-dev` was not deployed.** Skipped whole, per above.
 - **The sonnet default was not confirmed from a UI on any host.** The plan names it as the easiest
  visible check; this agent has no browser. It shipped in the code that is now at `e9f1760f` on all
  five, unverified at the surface.
 - **`/proxy-manager` was not opened in a browser.** Verified from the build and the logs instead.
 - `bun run docs:check` was not run — not a rollout step, and this agent does not fix documentation.
@@ -0,0 +1,57 @@
 # 2026.08.26.02
 **One fix, and it is a crash.** A screen whose layout names a panel it does not own now renders instead of
 failing with React #185, "maximum update depth exceeded".
 **No schema change. No dependency change. Do not run `bun install`.** `bun db:push` stays a step because it
 is cheap and proves the database agrees with the code, but it must report no changes.
 ## What broke, and where it shows
 `useAuthoredLayout` shipped in `2026.08.26.01`: a locked screen persists its SIZES and takes its STRUCTURE
 from source on every render. That is still right, and it is what lets a plugin change its layout and reach
 people who have already opened it.
 What it did not account for is `WorkspaceView`'s `appTypes` guard, which repairs an unrecognised `appType`
 and **writes the repair back**. That was self-limiting while structure was persisted — the repair stuck and
 the next render agreed with it. With structure coming from source it can never stick, so it is recomputed,
 rewritten, discarded and recomputed every render until React gives up.
 **The `browser` plugin's layout names `officerdev/chat`**, which is not one of its own panel keys. So
 `/browser` fails to render on any host with that plugin installed. That is every host running
 `2026.08.26.01` with it — which is the fleet.
 The fix drops a write whose result equals the current value. Not an optimisation: it is what terminates the
 loop, and persisting an identical tree was pointless anyway.
 ## Every host
 1. `git fetch origin --tags` then `git merge --ff-only deploy/2026.08.26.02`
 2. `bun db:push` — expect **no changes**. If it wants to alter something, stop and report it.
 3. `bun run plugins:update`
 4. `pm2 restart officer`
 **`fofos` is already at the fix** — it was fast-forwarded by hand at 05:22 to `a7c9dab2` while the owner was
 working on it. Step 1 will fast-forward it to this tag anyway, which only adds the version bump and this
 plan. Nothing about that is a problem; note it rather than treating it as drift.
 **`macbookpro`:** append `/opt/homebrew/bin` to PATH for the `bun` commands, run `pm2` separately. Asleep is
 a skip with a note.
 **Do not restart `officer-claude-code`.** Unchanged from the last release, same reason: it ends every live
 agent session on the host, and it is the owner's call. Nothing in this release needs it.
 ## Hosts
 - **`officer-dev`** — skip it. Restarting `officer` there ends the rollout. It already has this code.
 - **`edge-pertento-bridge`** — skipped. Still 300+ commits behind with no `roles` table; its catch-up is a
  by-hand job. Do not contact it.
 - **`alpha`**, **`fofos`**, **`production-pertento-bridge`**, **`deadpool-rezio-bridge`** — the targets.
 - **`macbookpro`** — a target if it is awake.
 ## What to check
 **Open `/browser`.** It should render rather than showing "This screen failed to render". That is the whole
 release, and it is one click to confirm. Hard refresh first — a stale bundle looks identical to the bug.
 No direct SQL is needed anywhere, and none is authorised.
@@ -0,0 +1,119 @@
 # Deploy report — 2026.08.26.02
 **5 of 5 target hosts succeeded.** Two hosts skipped by plan (`officer-dev`, `edge-pertento-bridge`).
 Tag `deploy/2026.08.26.02` → `121a77ce`. `package.json` at that commit reads `2026.08.26.02` — tag and
 version agree. Every host ended at `121a77ce` exactly, merged by `--ff-only` against the tag rather than
 the branch.
 Second release under this watcher, and the second the loop has executed. The claim was taken by the
 watcher before this agent was spawned; this agent recorded `done` after the rollout.
 ## The release changed no schema, and that makes the `db:push` reading solid
 This release touches five files: two deploy documents, `package.json`, and
 `src/workspaces/state/useAuthoredLayout.ts` with its test. **No `schema.ts` changed**, so drizzle's desired
 state is byte-identical before and after the merge. Anything `push` wants is pre-existing drift, deductively
 rather than by assumption.
 Per doctrine, exit 0 was not taken as evidence. Every host was run with `--verbose` to read the statements
 push actually wanted, and then queried directly.
 **The standing diff from `2026.08.26.01` is unchanged and is present on all five:**
 ```sql
 ALTER TABLE "command_hq_sessions" ALTER COLUMN "reference_paths" SET DEFAULT '{}';
 ```
 `alpha` additionally wants the documented drop-and-re-add of `pk_music_now_playing`. Nothing new appeared on
 any host — the set of wanted statements is identical to last night's, host for host.
 Verified by query, per host, not inferred:
 | Host                         | `command_hq_sessions.reference_paths` | `pk_music_now_playing` | `roles` |
 | ---------------------------- | ------------------------------------- | ---------------------- | ------- |
 | `alpha`                      | `'{}'::text[]` — correct              | present (`contype=p`)  | 4       |
 | `fofos`                      | `'{}'::text[]` — correct              | n/a                    | 4       |
 | `production-pertento-bridge` | `'{}'::text[]` — correct              | n/a                    | 4       |
 | `deadpool-rezio-bridge`      | `'{}'::text[]` — correct              | n/a                    | 4       |
 | `macbookpro`                 | `'{}'::text[]` — correct              | n/a                    | 4       |
 Each database is already in the state the schema code asks for. The rollout was not stopped for it: the
 plan's stop condition is "if it wants to alter something", and this is drizzle re-emitting a statement
 whose effect is already in place. **That stop signal is still spent**, exactly as last night's report said —
 worth fixing at the schema code, and it is the one thing here the owner should act on.
 No direct SQL was run anywhere. None was authorised and none was needed.
 ## Per host
 Steps in plan order on every host: ff-merge to the tag → `bun db:push` → `bun run plugins:update` →
 `pm2 restart officer`. No `bun install` anywhere — the plan forbids it and no dependency changed.
 `officer-claude-code` was not restarted anywhere, per the plan.
 ### `alpha` — OK
 - `e9f1760f` → `121a77ce`. Tree clean, no untracked files.
 - `db:push` exit 0; standing diff plus `pk_music_now_playing`; database verified correct by query.
 - `plugins:update` 14/14 in 55s. That step bounces roughly a dozen sidecars itself (`sidecar: started` per
  plugin) — more moved on this host than the `officer` line below suggests.
 - `officer` restarted: `online`, `restart_time` 4 → 5.
 ### `fofos` — OK
 - `a7c9dab2` → `121a77ce`, the short fast-forward the plan predicted: it adds only the version bump and the
  plan file, since the fix itself was hand-applied here at 05:22. Not drift.
 - One untracked file, `scripts/chk.ts`. Noted, not a reason to skip — a fast-forward cannot touch it, and
  nobody's work was discarded.
 - `db:push` exit 0; standing diff only; verified by query. 43 tables in `public`.
 - `plugins:update` 3/3 in 21s (`browser`, `gitea`, `proxy-manager`).
 - `officer` restarted: `online`, `restart_time` 31 → 32.
 - **This is a host the release actually matters on** — it has the `browser` plugin whose layout names
  `officerdev/chat`.
 ### `production-pertento-bridge` — OK
 - `e9f1760f` → `121a77ce`. Tree clean.
 - `db:push` exit 0; standing diff only; verified by query.
 - `plugins:update` 1/1 in 4s.
 - `officer` restarted: `online`, `restart_time` 9 → 10.
 ### `deadpool-rezio-bridge` — OK
 - Logged in as `br`, per `docs/servers.md`.
 - `e9f1760f` → `121a77ce`. Tree clean.
 - `db:push` exit 0; standing diff only; verified by query.
 - `plugins:update` 2/2 in 7s.
 - `officer` restarted: `online`, `restart_time` 15 → 16.
 ### `macbookpro` — OK, and it was awake
 - `e9f1760f` → `121a77ce`. Tree clean.
 - `PATH` appended with `/opt/homebrew/bin` for the `bun` steps; `pm2` run as a separate command on the
  interactive shell, so nothing was shadowed.
 - `db:push` exit 0; standing diff only; verified by query.
 - `plugins:update`: `no plugins installed — nothing to update`. Not a failure.
 - `officer` restarted: `online`, `restart_time` 17 → 18.
 ## Skipped, and why
 - **`officer-dev`** — the host this agent runs on. Not pulled, nothing restarted. It already holds this
  code at `121a77ce`. Its working tree carries another session's uncommitted changes
  (`src/servers/hono.ts`, `src/workspaces/hooks/src/useClient.ts`, an untracked
  `src/servers/hono-error-shape.test.ts`) — untouched. **The owner restarts `officer` here deliberately,
  as the last step.**
 - **`edge-pertento-bridge`** — skipped on the plan's instruction: 300+ commits behind with no `roles`
  table, its catch-up is a by-hand job, do not contact it. It was not contacted.
  Note the disagreement, because an orchestrator reading the wrong document gets this wrong: `docs/servers.md`
  lists this host in the platforms table as a deploy target again, with an empty "Deliberately skipped"
  section. The **plan** overrides it, and the plan is right — a `db:push` on a host with no `roles` table is
  the exact shape of change this doctrine refuses. `docs/servers.md` is stale on this point.
 ## What was not verified
 **The fix itself was not clicked.** The plan's check is "open `/browser`, hard refresh, confirm it renders
 rather than showing 'This screen failed to render'". That is a browser action on a logged-in session, and
 this agent has no session on any of these hosts. What is verified is that the code carrying the fix is at
 `HEAD` on every target and that `officer` came back `online` on each. **The one-click confirmation is
 still owed, on a host with the `browser` plugin — `fofos` or `alpha`.**
@@ -0,0 +1,37 @@
 # deploy/2026.08.27.01
 55 commits since `deploy/2026.08.26.02`. A full day's work, most of it in two areas.
 ## What is in it
 **Calendar and contacts became usable rather than readable.** Create, edit and delete on both screens; a
 filter on each; `?collection=<name>` instead of an escaped DAV path. The agent skill was rewritten off
 hand-written iCalendar onto JSON routes — an editor now patches the stored text rather than rebuilding it,
 so alarms, attendees and recurrence rules survive an edit made from a form that cannot show them.
 **OpenCode can reach the platform.** It gets the skills index, an Officer identity instead of "you are a
 coding agent", an API credential, and its permission prompts answered — a server session has nobody to
 answer them and a turn simply hung. Its chats also keep their name, their transcript and their model when
 reopened.
 **Smaller, and each one somebody hit today:** `/api/notify/user` (and `/broadcast`, which had answered 404
 since it landed — shadowed by the sidecar proxy's catch-all); a commander started from a plugin chat, so
 pointing one at a mailbox no longer needs a path only the owner can type; file preview inside a
 commander's own browser; a dock tile for `/bots`; and the new wordmark in the header, following the theme.
 ## Risk
 Low-to-moderate. Nothing here changes a schema. The two worth watching after the rollout:
 - **`useThemeAsset`** now reads in `requestAnimationFrame` rather than during the effect. It fixes the
  logo and the wallpaper being one theme behind; if a themed asset ever fails to appear, this is the first
  place to look.
 - **The notify router's mount order.** The platform's own routes now sit before the sidecar proxy's
  catch-all. Device registration still forwards — verified — but it is the change most likely to surprise.
 ## Hosts
 Seven. `officer-dev` is skipped: it is the host running the rollout, and restarting it ends the rollout.
 alpha · fofos · macbookpro · macbruno · production-pertento-bridge · edge-pertento-bridge ·
 deadpool-rezio-bridge
@@ -0,0 +1,257 @@
 # Every place the platform writes, appends to, or reads `CLAUDE.md` — an audit
 Written 2026-08-25, after a request to inventory the whole mechanism before changing any part of it.
 The scope was `platform/src`, `platform/scripts`, and every plugin currently checked out under
 `platform/plugins/`. Related design docs: [`commander-directory.md`](./commander-directory.md) (why a
 commander's `CLAUDE.md` exists at all), [`plugin-capabilities.md`](./plugin-capabilities.md) (the
 read-in-place rule this mechanism is the one deliberate exception to).
 ## The shape of it
 Three writers, one read-only checker. That's the whole mechanism — smaller than the number of files
 that merely _mention_ `CLAUDE.md` in a comment suggests.
 | #   | Site                                                   | Verb                        | Cardinality                                                    | Trigger                                                   |
 | --- | ------------------------------------------------------ | --------------------------- | -------------------------------------------------------------- | --------------------------------------------------------- |
 | 1   | `command-hq/directory.ts` → `createCommanderDirectory` | generate (write once)       | one file per commander                                         | commander creation                                        |
 | 2   | `api/chat/websocket.ts` → `installPluginChatBrief`     | copy (overwrite if changed) | one file per plugin-chat directory, plus one per email account | every plugin-panel chat start, and every email chat start |
 | 3   | `scripts/backfill-commander-credentials.ts`            | append (idempotent)         | existing commander files only                                  | manual, one-off per deploy                                |
 | 4   | `scripts/docs-check.ts`                                | read only                   | —                                                              | `bun docs:check`                                          |
 Two things fell out of tracing this that are worth stating up front, because they explain why the
 mechanism looks the way it does rather than something simpler:
 - **Nothing here is a per-turn cost.** All three writers touch disk once (creation, chat-start,
  migration) rather than on every message. The alternative — a `promptPrefix` riding every turn — is
  exactly what this replaced, twice (once for commanders, once for plugin chats), and the reason given
  both times is the same: paid forever, invisible as a design artefact, and visible in the worst place
  (a three-word message with a paragraph of preamble silently attached).
 - **Two mechanisms that look similar are deliberately NOT this.** The owner's affordances/skills
  preamble and a commander's old per-turn block go through the Claude Code SDK's
  `systemPrompt: { preset, append }` option — in memory, per session, never touching disk. See
  "Explicitly not written" below for why that line was drawn where it was.
 ## The three writers
 ### 1. Commander creation — the generator
 `src/servers/api/command-hq/directory.ts:653`, `createCommanderDirectory()`.
 Called once, from `command-hq/router.ts`, when `POST /command-hq/commanders` creates a commander — the
 row, the directory, and this file, in that order, all before any turn is allowed to spawn. The ordering
 is load-bearing: a turn that spawned before the directory existed used to recreate an _empty_ one on a
 race with deletion (`websocket.ts:300-308` describes the incident), so the row now has to exist first
 and the directory has to exist before a turn can reach it.
 ```ts
 writeFileSync(
  join(dir, 'CLAUDE.md'),
  commanderClaudeMd({
    name: params.name,
    referencePath: params.referencePath,
    loopPidPath: loopPidPath(email, dirName),
    spawnedPath: spawnedRecordPath(email, dirName),
    credentialPath,
  }),
 );
 ```
 `commanderClaudeMd()` (same file, line 173) is the template — the commander's name, the reference path
 it was pointed at, where its loop pid lives, where its spawned-process record lives, and where its
 platform credential is (or an explicit statement that minting one failed, so the commander is told
 rather than left to discover the gap itself — the comment at line 662 is explicit that this ordering,
 credential before `CLAUDE.md`, exists so the file can describe the credential truthfully).
 Plain `writeFileSync`, not atomic — defensible because it runs once, at creation, with nothing else able
 to be reading the file yet.
 **What happens after creation is the interesting part: nothing does, from the platform's side.** The
 file is described everywhere as "a living document its commander has been extending" — the commander
 itself edits it during its own life, the same file a human would open in the file browser. The platform
 never rewrites it. That is _why_ item 3 below has to append rather than regenerate: a commander with
 months of self-written notes in its `CLAUDE.md` cannot be treated as regeneratable state.
 ### 2. Plugin chat briefs — the copier
 `src/servers/api/chat/websocket.ts:237`, `installPluginChatBrief()`.
 ```ts
 async function installPluginChatBrief(appName: string, dir: string): Promise<void> {
  try {
    const { states } = await snapshotPlugins();
    const state = states.find((s) => s.plugin.appName === appName && s.install?.enabled);
    if (!state) return;
    const source = join(state.plugin.dir, 'chat', 'CLAUDE.md');
    if (!existsSync(source)) return;
    const target = join(dir, 'CLAUDE.md');
    const next = await Bun.file(source).text();
    if (existsSync(target) && (await Bun.file(target).text()) === next) return;
    await writeAtomic(target, next);
  } catch (err) {
    console.error(`[chat] could not install ${appName}'s chat brief:`, err instanceof Error ? err.message : err);
  }
 }
 ```
 Called from `resolveChatCwd()` from **two** branches, and the second one is the interesting case:
 - `msg.context === 'plugin'` — the plugin's own chats directory. The ordinary path.
 - `msg.context === 'email'` — the **account's** directory, the one holding `emails.db`.
 Never for a commander and never for an ordinary `/chat` session.
 Email is the exception because an email chat does not run in the plugin's chats directory: it runs beside
 the database it exists to answer from, which is the entire point of that context. So the brief follows the
 chat rather than the chat moving to the brief, and `plugins/email/chat/CLAUDE.md` lands in
 `email_accounts/<address>/`. A second plugin wanting this would be the signal that "which directory does
 this plugin's chat run in" belongs in the manifest rather than in a branch here. That branch also does the `mkdirSync`
 for the chat directory itself, so the two writers (this one and the commander generator) can never
 target the same directory: a commander's cwd is `$DATA_PATH/<email>/commanders/<dirName>/`, a plugin
 chat's is `$DATA_PATH/<email>/plugins/<appName>/chats/`.
 The source is `<plugin-repo>/chat/CLAUDE.md` — a file the plugin author ships in their own repository,
 read fresh from `snapshotPlugins()` on every chat start rather than cached, so a `plugins:update` needs
 no republish step for the brief to change. Content-compared before writing (`writeAtomic` only fires on
 an actual diff) specifically so a chat directory's mtimes don't churn on every message — this is called
 once per chat _start_, but a resumed conversation calls `resolveChatCwd` again each time it reconnects.
 Best-effort throughout, on purpose: a plugin with no `chat/CLAUDE.md` (the ordinary case — see the
 per-plugin table below) is not an error, it is a chat that knows a bit less than one with a brief. A
 write failure logs and continues rather than blocking the chat from starting.
 **Of the 19 plugins checked out on this machine today, exactly one ships a brief: `proxy-manager`.**
 See "Plugins, one by one" below.
 ### 3. The credential backfill — the appender
 `scripts/backfill-commander-credentials.ts`.
 Not part of the runtime — a manual migration, re-run by hand after a deploy that changes what a
 commander's `CLAUDE.md` should say about itself (`bun run --env-file=.env scripts/backfill-commander-credentials.ts`
 on each host). Exists because a commander predating some capability (first: platform credentials; later:
 the notify route) has a `CLAUDE.md` that never mentions it, and deleting-and-recreating the directory to
 fix that would destroy the one thing a commander actually is — a long-running, self-extended
 conversation about a job.
 ```ts
 const appendIfMissing = async (marker: string, lines: string[]): Promise<boolean> => {
  const existing = existsSync(claudeMd) ? readFileSync(claudeMd, 'utf8') : '';
  if (existing.includes(marker)) return false;
  appendFileSync(claudeMd, `\n${lines.join('\n')}`);
  await giveToAccount(row.osUser, claudeMd);
  return true;
 };
 ```
 Idempotent by construction: each section carries a marker string (`officer.env` for the credential
 section, `/api/notify/_officer/notify` for the notify section) and is only appended when that marker is
 absent — so re-running the script, or running it against a `CLAUDE.md` a human hand-edited to already
 describe the same thing, does not duplicate anything. Two sections are currently backfilled this way:
 the credential path (added when `credential.ts` first shipped) and the notify route (added later,
 separately, because "arrived later" — commanders that most need a credential already have one by the
 time this runs).
 This is the only writer of the three that **mutates an existing file** rather than producing a
 first-time one. Everything else in the mechanism either generates once (item 1) or overwrites wholesale
 on a genuine content diff (item 2) — appending-if-missing is specific to this being a repair pass over
 files a human may have already been editing by hand.
 ## The one reader
 `scripts/docs-check.ts`, lines 92 and 108. Reads `platform/CLAUDE.md` and `officer-dev/CLAUDE.md` — not
 a plugin's, not a commander's — to check a documented numeric claim (permission-registry entry count,
 PM2 process count) against a value derived at run time, and fails the check on drift. This is `bun
 docs:check`, required before every release. It never writes.
 Included here for completeness since the request was "writing OR touching" — this is the only touch
 that is not a write.
 ## Explicitly not written — and why, so the mechanism isn't mistaken for having a gap
 Three places came up in the trace that look like they should write a `CLAUDE.md` and deliberately don't.
 Worth recording, because each one used to work differently and the comments at each site exist
 specifically to stop a future change from "fixing" this back in.
 - **The owner's and every session's affordances/skills preamble** —
  `src/servers/sidecar/claude/claude-manager.ts:779-798`. Passed as
  `systemPrompt: { type: 'preset', preset: 'claude_code', append: preamble }` to the Claude Code SDK's
  `query()` call, in memory, every session, never to a file. The comment there gives the reason this
  differs from the commander/plugin mechanism above: this is "the one place every session goes through,
  owner and member alike" — a file can't cover that, because `user-instance.ts` (next point) refuses to
  write one for the owner at all, and a member's isolated home is a narrower audience than "every
  session." This is also where a commander's own preamble used to live, as a per-turn block
  (`commander-block.ts`, deleted 2026-08-24) — it could never resolve on a commander's first turn, since
  the block was built once per session and the first turn has no transcript id yet. Moving that
  information into a file the directory-creation step writes before any turn spawns (item 1 above) is
  what fixed it.
 - **The owner's own sessions** — `src/servers/sidecar/claude/user-instance.ts:235-237`. The owner runs
  un-isolated, `HOME` pointed at their real home, so a generated container `CLAUDE.md` would land
  _inside_ `~/.claude/CLAUDE.md` — the file the owner maintains by hand and the terminal `claude` also
  reads. Writing one there would silently mix generated content into a document that is supposed to be
  entirely the owner's.
 - **Per-user container provisioning** — `scripts/provision-user-dirs.ts:10-13`. The comment records that
  the _old_ `provision.ts` (deleted) used to seed shell rc files and write a generated `CLAUDE.md` +
  `settings.json` describing a user's Docker container, as part of an architecture that no longer exists.
  What survives from it is only the directory skeleton — a user gets a root and a home inside it, nothing
  generated inside either.
 ## Plugins, one by one
 `platform/plugins/CLAUDE.md` states the ground rule: **plugins are not part of this repository.** Every
 `plugins/<name>/` directory is gitignored here and exists on disk only because `git clone` put it there
 when it was installed on this machine — `/plugins/*/` in `.gitignore`. So "plugins, one by one" below
 means the 19 currently checked out here, not a catalogue.
 The only convention a plugin can participate in is the one item 2 (above) reads: a `chat/CLAUDE.md` file
 at the top of the plugin's own repository, picked up automatically the moment that plugin's chat panel
 starts a conversation. There is no manifest field for this and nothing to register — the platform simply
 checks whether the file exists at that fixed path within the plugin's directory on every chat start.
 | Plugin           | `chat/CLAUDE.md` | Notes                                                                                                                                                                           |
 | ---------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `proxy-manager`  | **yes**          | The only one. `ChatPanel.tsx:22` documents the mechanism from the plugin's side — its own comment explains why the brief lives in a file rather than a `promptPrefix` constant. |
 | `atelier`        | no               |                                                                                                                                                                                 |
 | `bitcoin-wallet` | no               |                                                                                                                                                                                 |
 | `browser`        | no               |                                                                                                                                                                                 |
 | `desktop`        | no               | Its `sidecar/protocol.ts` mentions `CLAUDE.md` once, but only as a comment citing the platform's frozen-lockfile rule — not a touch.                                            |
 | `email`          | no               |                                                                                                                                                                                 |
 | `example`        | no               |                                                                                                                                                                                 |
 | `gitea`          | no               | Ships an _affordance_ (a different, unrelated mechanism — see `plugins/CLAUDE.md`'s worked example, which is this plugin's) but no chat brief.                                  |
 | `invoices`       | no               |                                                                                                                                                                                 |
 | `iris`           | no               |                                                                                                                                                                                 |
 | `jellyfin`       | no               | `db/schema.ts` cites `src/databases/CLAUDE.md` for the composite-key rule; not a touch.                                                                                         |
 | `kiosk`          | no               | `db/schema.ts` cites `databases/CLAUDE.md` the same way.                                                                                                                        |
 | `minesweeper`    | no               |                                                                                                                                                                                 |
 | `music`          | no               |                                                                                                                                                                                 |
 | `offscale`       | no               |                                                                                                                                                                                 |
 | `photos`         | no               |                                                                                                                                                                                 |
 | `soulseek`       | no               |                                                                                                                                                                                 |
 | `transcribe`     | no               | `tasks/transcribe-audio-file/index.ts` cites `platform/CLAUDE.md` for the script-task self-containment rule; not a touch.                                                       |
 | `transmission`   | no               |                                                                                                                                                                                 |
 | `vault`          | no               | `db/schema.ts` cites `src/databases/CLAUDE.md`'s singleton rule; not a touch.                                                                                                   |
 **No plugin writes, generates, or appends to a `CLAUDE.md` programmatically.** Every plugin-side hit that
 mentioned the string was a comment pointing back at a platform doc for a rule the plugin's own code
 follows (frozen lockfiles, composite keys, script-task self-containment) — not a filesystem touch. The
 one exception, `proxy-manager`, participates in item 2 purely by shipping a static file at a path the
 platform already knows to look for; it contains no code of its own that touches `CLAUDE.md`.
 ## What this means for a future change
 Anyone changing this mechanism has exactly three call sites to reconcile, plus the two "explicitly not
 written" boundaries above that a change should not cross without a deliberate decision to do so:
 - Change what a **new** commander is told → edit `commanderClaudeMd()` in `directory.ts`. Existing
  commanders will not retroactively pick up the change; that is what the backfill script pattern (item 3)
  is for, and a new field needs its own marker and its own `appendIfMissing` call, following the same
  script.
 - Change what a **plugin chat** is told → that lives entirely in the plugin's own `chat/CLAUDE.md`; the
  platform's role is only the copy-if-changed mechanics in `installPluginChatBrief`, which no plugin
  author needs to touch.
 - Add the same brief mechanism to a **new surface** (not commander, not plugin chat) → follow the pattern
  in `resolveChatCwd()`: a directory the surface owns, `mkdirSync` before the write, and a decision about
  whether the content is generate-once (commander) or copy-and-diff (plugin) — the two existing writers
  chose differently for reasons specific to who edits the file afterward, and a third surface should make
  that choice deliberately rather than default to whichever is closer in the file.
@@ -3,6 +3,17 @@
 Spec conversation 2026-08-18, owner + agent, back and forth. This is the write-up asked for partway through
 it, kept current as answers landed.
 **Superseded in part, 2026-08-24, by `docs/commander-directory.md`.** A commander's identity moved from
 Claude's transcript id to its own `command_hq_sessions` row, and it gained its own directory
 (`$DATA_PATH/<email>/commanders/<dirName>/`, `CLAUDE.md` + `state/`) created BEFORE any turn spawns. That
 makes several sections below describe the PREVIOUS mechanism rather than the current one — notably
 "How a commander is created" (creation is no longer session-first), "Working directory" (a commander no
 longer shares one directory per user, nor chooses an arbitrary one — it has its own), and the `POST
 /commanders` / `POST /commanders/new` rows in "API reference" (both now require `name` and `referencePath`
 and no longer accept an arbitrary `cwd`). This file was not rewritten to match — read
 `docs/commander-directory.md` first for anything those sections describe, and treat the code
 (`src/servers/api/command-hq/`) as the source of truth where the two disagree.
 **Status:** data model, the full REST API including both creation paths (web and `POST
 /commanders/new`), built and mounted 2026-08-18 (`bunx tsgo` clean, suite at its 7 pre-existing baseline
 failures — none of them this feature's). `bun db:push` and a restart of `officer` have both since run
@@ -0,0 +1,218 @@
 # A commander is a directory, not a session
 **Status: phase 1 built 2026-08-24** — schema, directory creation, `CLAUDE.md` at creation, the inverted
 `POST /commanders` → start-turn → point-at-transcript order, `resolveChatCwd` resolving server-side, and the
 frontend composer split (`NewCommanderSetup` → `ActiveNewCommander`) in `src/servers/api/command-hq/` and
 `src/workspaces/officerdev/src/apps/CommandHQ/CommandHqDetail.tsx`. `bunx tsgo`/`./node_modules/.bin/tsgo`
 clean, suite green. **`bun db:push` has not been run** — the owner reviews and runs the database work
 separately; see the schema section below for what changed and why nothing here is a migration. Phase 2
 (a commander becomes a git repository) is still not built.
 ## What is wrong now
 A commander's identity is borrowed. `command_hq_sessions.session_id` is Claude's **transcript id**, minted
 by the CLI as the first turn begins — verified: the id on the live row has a transcript file under
 `~/.claude/projects/`. Everything about a commander hangs off that one borrowed value, and three problems
 fall out of it.
 **An ordering problem.** `POST /command-hq/commanders` takes a `sessionId` the caller already holds and
 validates the transcript exists, so a chat session is created first and filed as a commander second. But
 the working directory is fixed when the session spawns — before the id exists. There is no point in the
 current flow where a commander can be started *in a directory named after itself*.
 **A first-turn interlock that is a side effect.** `commanderBlock` compiles the paths a commander must
 record itself at into every turn, and on the first turn they cannot be resolved, so the block is empty.
 The commander skill turns that into a rule: *"if you have not been given paths, you are on your first
 turn."* It works, and it is a signal derived from a failure rather than something anybody said. That
 block's own comment explains the awkwardness — it rides `effectivePrompt` rather than the session
 preamble, because the preamble is built once and the first turn has no id to build it from.
 **Losing the conversation loses the commander.** State lives in the transcript and in a second tree,
 `commander-state/<transcript id>/`. A session that dies takes its commander with it.
 ## The design
 **The directory IS the commander. The session is how you talk to it.**
 ```
 $DATA_PATH/<email>/commanders/<commander id>/
  CLAUDE.md          written at creation, extended by the commander as it learns the job
  spawned            session ids of the agents its loop started
  <whatever it writes>   scripts, procedures, its record of what it has handled
 ```
 The id is one the **platform** owns, generated when the commander is created. Nothing waits on the CLI.
 The flow becomes linear:
 1. The user gives a name and a reference path, and clicks Start.
 2. The platform creates the row and the directory.
 3. It writes `CLAUDE.md` into the directory: the name, the reference path, and the standing guidance
   `commanderBlock` currently injects.
 4. It spawns the session with `cwd` set to that directory.
 5. The transcript id arrives later and is recorded **on the row**, as a pointer to the current
   conversation.
 **The API does not change.** Same endpoints, same shape from the client's side. What changes is the server
 being able to do things in an order that works.
 ## What this buys
 **`CLAUDE.md` needs no mechanism.** Claude Code reads one from the working directory at session start. So
 the living document is free: the commander edits its own file, and the next turn has it. No injection, no
 per-turn cost, no block riding `effectivePrompt`.
 **A commander survives its conversation.** Everything it knows is on disk. A session that dies can be
 replaced by a fresh one in the same directory, and the commander carries on with its scripts, its
 procedures and its record of what it has already handled. Today that is a total loss.
 **One directory instead of two.** `commander-state/<id>/` collapses in. Deleting a commander becomes
 deleting a directory, which is also the only way to be sure nothing is left behind.
 **The first turn can be stated rather than inferred.** With the file written before the session exists,
 the platform can simply say which turn it is on. The interlock stops being a trick.
 ## The reference path
 **What was the working directory becomes a reference** — what the commander operates ON, not where it
 lives. One is collected in the start dialog, because a person can name one thing and asking for a list up
 front gets a worse answer than asking later.
 **More can be added in conversation.** A voice-memos commander watches one folder; a life manager might
 watch memos, scans and a mailbox. So this is a list on the row, seeded with one, and the commander writes
 additions into its own `CLAUDE.md` as they are agreed.
 ## The two tiers, and why a commander should get cheaper
 This is the point of the whole design, and it generalises past any particular commander.
 **The script gathers. The agent judges.**
 A commander has two kinds of work and they have opposite economics. A script runs per event — every email,
 every voice memo — and costs nothing, so there is no ceiling on volume. An agent runs per batch, on
 material a script already assembled, and costs a turn every time it wakes. So the rule for building any
 commander is: push as much as possible down into the script, and let the agent see only what actually
 needs judgement.
 Detecting a one-time code in an email is a script. Reading fifty messages and deciding which of them the
 owner would want to know about is an agent. A watcher that transcribes a recording is a script; deciding
 what a week of transcripts means is an agent.
 **And the tiers are not fixed, which is the part that matters.**
 Because the commander owns its own scripts — they are files in its directory, and it can edit them — every
 correction moves work downward. The owner says "this one was missed, it had eight digits rather than six",
 and a decision that required judgement becomes a rule that does not. The agent tier gets thinner; the free
 tier gets better.
 **A commander that runs for six months should cost less per event than it did in week one, not more.**
 That is the opposite of how automation usually ages, and it is a direct consequence of two decisions made
 here rather than a hope: the agent owns its scripts, and the corrections arrive through dialogue rather
 than through a ticket to somebody else. Nothing improves a system it cannot edit.
 Two things this requires, and both are cheap if done from the start:
 - **The script's verdict must be reproducible.** Not logged — RE-RUN. The input is still in the mailbox or
  the folder, and the script is deterministic, so diagnosing a miss is running it again and watching. A
  log would be a second copy of something already on disk.
 - **A change is checked against what came before.** The corpus already exists — the last few hundred
  messages, the transcripts so far. Re-run the old script and the new one over it and compare; anything
  whose verdict changed is either the bug just fixed or one just introduced. Without that, the fix for
  eight-digit codes quietly starts flagging every order confirmation, unattended, at three in the morning.
 `capabilities/skills/commander/SKILL.md` should teach this. Somebody building the fourth commander needs
 the rule more than they need the worked example.
 ## What the directory holds: definition versus state
 Two kinds of thing live in there and they must not mix, because one of them travels and the other must
 never.
 ```
 $DATA_PATH/<email>/commanders/<commander id>/
  CLAUDE.md          DEFINITION — the living document, extended as the job is agreed
  parameters.*       DEFINITION — the things a fork has to change. Paths, cadences, thresholds
  procedures/        DEFINITION — what a spawned agent reads at fire time
  scripts/           DEFINITION — the loops
  state/             INSTANCE — what it has handled, what it spawned, its loop's pid
 ```
 **Separate from the first commit, not sorted out later.** A shareable bundle is "everything except
 `state/`" only if that boundary is structural; mixed together, extracting one means picking files apart by
 hand and getting it wrong once. Same reasoning as plugin capabilities being read in place rather than
 copied — a directory boundary beats a convention, because a convention is what a tired person violates.
 The failure it prevents is specific: a recipient's commander starting up believing it has already handled
 your recordings, and silently doing nothing.
 **Parameters are separate from procedure, or forking means editing code.** With `~/Documents/VoiceMemos`
 baked into a script, a fork is a debugging session. Declared in one place, a fork is a conversation — the
 new owner is asked where their memos land and the commander rewrites its own file. That difference is the
 whole point of the thing being an agent rather than a template.
 ## Phase 2 — a commander becomes a git repository
 **Not now.** Recorded because the phase 1 layout has to leave room for it, and it costs nothing today to
 leave that room.
 **There is no button.** The owner asks the commander, in conversation, to make itself shareable, and it
 does — `git init`, a `.gitignore` that excludes `state/`, a first commit. That is the same shape as
 everything else here: the commander maintains its own directory, and the platform does not reach in.
 **What it needs to know goes in the commander SKILL, not an affordance.** The layout, what is tracked,
 what is ignored and how credentials are handled is reference material — read on the one day somebody asks
 for it. An affordance's body is charged to every turn of every commander forever, and this would earn that
 cost approximately never. `capabilities/skills/commander/SKILL.md` gains a section.
 **A commander never holds a service's connection details, and that is a boundary rather than a
 precaution.** The Whisper URL is not the commander's business: it knows the platform can transcribe and
 asks the platform, which holds the connection. So there is usually nothing sensitive in a commander to
 leak, and the sharing story is simple for a reason rather than by luck.
 Where a commander genuinely does need a secret of its own, the same rule applies for the obvious reason: a
 credential is definition-shaped — it looks like configuration — so excluding `state/` does not protect it,
 and a shared repository is exactly the artefact where one gets published and stays published. Name what
 must be configured; let the platform hold the value.
 **Whether the platform is actually configured is not this system's problem.** A commander depending on
 transcription can be armed on a server where nobody set up a Whisper endpoint, and it would produce
 nothing. That is a system administration mistake, and the answer is already in the commander skill rather
 than in new machinery: **do the first run by hand, then arm.** A first run against something unconfigured
 fails in front of the person doing it. The same rule catches the shared case — somebody forking this onto
 their own machine finds out on their first run instead of at 3am.
 The forking story then reads: clone, open a conversation, answer where your memos land and what you want
 done with them, and the commander rewrites its own parameters and arms.
 ## The consequence for the skill
 `capabilities/skills/commander/SKILL.md` says turn one is orientation — *"read where you actually are
 before you ask anything"* — and that assumes `cwd` is the thing worth exploring. Under this design the
 commander's own directory is nearly empty on turn one and the interesting thing is somewhere else.
 That guidance has to change with the code, or every new commander will orient on an empty folder and ask
 a worse question than it does today.
 ## The schema change, and why there is no migration
 `session_id` stops being the commander's identity and becomes a nullable pointer to its current
 conversation. The row gains its own id, its directory, and its reference paths.
 **Nothing is migrated.** The one commander on this machine is deleted and re-armed from scratch on the new
 system — the owner's call, made on 2026-08-24, and the right one: it is unarmed and has never fired, so
 migrating it would mean writing and testing a path that runs exactly once and then never again. Re-arming
 also exercises the flow this design exists to fix, which a migration would route around.
 That decision has a shelf life. It is free while one commander exists and unarmed; it stops being free the
 moment somebody is relying on one. Build this before that happens, or write the migration.
 ## What this does not decide
 **Whether a commander's loops are scripted or agentic.** Both, in practice — a watcher that transcribes
 does not need judgement and should not spend a turn per file, while a job that reads transcripts and
 decides what to do with each of them is agentic by nature. The directory holds the procedure either way.
 **How a commander learns what the platform can do.** It reads the generated platform skill and, for a
 plugin, that plugin's own skill. That is a separate gap: a plugin must ship a skill documenting its routes
 or a commander can see it is installed and still not know how to call it.
@@ -23,19 +23,78 @@ Two details from that report do most of the diagnostic work:
 Do not re-investigate these without new evidence.
 | Candidate                                                     | Why it is out                                                                                                                                                                                                                                                      |
-| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | The end-of-turn refresh re-reading the file                   | `reloadFile` sets `originalContent` and `isDirty: false`. It cannot produce a dirty tab.                                                                                                                                                                           |
 | A shared component between the task panel and the editor      | `CodeSurface` (the task log) renders with shiki. It is not Monaco and holds no editor model.                                                                                                                                                                       |
-| Two Monaco editors sharing a model                       | The app's only other mount, `FileViewer/renderers/EditorRenderer.tsx`, passes no `path`, so its model URI is `inmemory://model/N` and cannot collide with the editor's `file:///…`. |
+| ~~Two Monaco editors sharing a model~~ **— WRONG, see below** | This asked which OTHER component mounts Monaco and answered `EditorRenderer` (still true: no `path`, so `inmemory://model/N`, no collision). It never asked whether the **code editor collides with ITSELF**. It does — the panel is addable to a dashboard twice. |
 | Something typing into the page                                | No `execCommand('insertText')`, no synthesised `KeyboardEvent`, no clipboard writes anywhere near the editor.                                                                                                                                                      |
 That leaves **Monaco's own `onChange`** — the model was edited the way a paste or a programmatic
 `executeEdits` edits it. Which is why this needs to be caught in the act rather than reasoned about.
-One thing to check first, because it is recent and it is ours: `2b70a570` gave `<Editor>` a real `path`,
+## Two code-editor panels share one model and two buffers (2026-08-25)
-so models are keyed by file URI globally rather than per mount. Two panels open on the same file now share
+
-one model. That should be an improvement, and it is a change in exactly the layer that turns out to be
+The suspicion recorded here — `2b70a570` giving `<Editor>` a real `path`, so models are keyed by file URI
-involved.
+**globally** rather than per mount — is correct, and it is worse than "should be an improvement". Verified
 by reading `@monaco-editor/react@4.7.0`'s built source, not inferred:
 - **Model lookup is `getModel(Uri.parse(path)) || createModel(value, …)`.** An existing model for that path
  wins and the second mount's `value` is **ignored at creation**. So the second panel to open a file adopts
  the first panel's buffer.
 - **The value-sync effect then overwrites it**, because `value !== editor.getValue()`:
  `executeEdits('', [{ range: getFullModelRange(), text: value }])`.
 - **The guard that suppresses `onChange` during that write is per-INSTANCE.** The package sets an internal
  flag around its own `executeEdits` and checks it inside `onDidChangeModelContent`. Panel B's flag is not
  panel A's. So B's programmatic write **fires A's `onChange`** with B's content.
 - **Unmount disposes the shared model.** `keepCurrentModel` defaults to `false` and we never set it, so the
  cleanup calls `editor.getModel()?.dispose()`. And `CodeEditor` mounts `<Editor key={activeFile.path}>`,
  so this runs on every **tab switch**, not only on panel close — switching tabs in one panel disposes the
  model another panel is still displaying.
 The other half is ours: `useEditorState` holds `files` in a plain `useState`, so it is **per panel
 instance**. Its own comment says so — "this app also mounts as a dashboard panel, and a dashboard can hold
 two of them". One shared model, two independent `content` values, and an `onChange` that crosses between
 them. `CodeEditor`'s handler does `setContent(activeFile.path, value)`, so panel A's buffer silently becomes
 panel B's content and `isDirty` flips with no keystroke — dirty tab, content the user never typed, disk
 untouched, fixed by reopening. That is the reported symptom's exact shape.
 **What this does NOT yet explain is how JOB OUTPUT becomes one of those `value`s.** Nothing in the app
 writes job output into `useEditorState` — `openFile`/`setContent`/`reloadFile` are called only from
 `CodeEditor.tsx`, and the task log renders through shiki. So this is a real defect that produces the right
 shape, and it is not proven to be the reported instance. **The trap is still the thing that names the
 text's source.** Do not delete it on the strength of this section.
 ## Fixed 2026-08-25: the buffer is shared, because the model already was
 `useEditorState` now keys buffers by path in one store shared across panels, and keeps only the tab set and
 the active path per panel. The rule that matters: **`openFile` discards the content it is handed when the
 file is already open somewhere else.** That mirrors what Monaco does with the model, and it is what removes
 the divergence — with both panels reading one buffer there is never a `value` for the sync effect to
 reconcile, so the `executeEdits` never runs and the cross-panel `onChange` never fires.
 A buffer outlives the tab that opened it. `holders` is the set of panels with the file open, and the entry
 is dropped when the last one closes, so closing a tab in one panel cannot take unsaved work out from under
 another. Closing the last one still discards unsaved edits, exactly as before.
 `<Editor keepCurrentModel>` is the other half, and it was needed under any fix: the default disposes the
 shared model on unmount, and `key={activeFile.path}` makes that every **tab switch**, not just a panel
 close. The cost is one retained model per file opened in a session.
 Two things worth knowing:
 - **Writes go through `queryClient.setQueryData`, not `useGlobal`'s setter.** `useGlobal` applies a
  functional update to the `data` captured in render rather than to what is in the cache now. With one
  writer that is invisible; this slot has one writer per panel, which is the whole scenario.
 - **The trap can now fire legitimately.** Two panels on one file share a model, so a large paste in one
  fires the other's `onChange` while it is unfocused — which is what `reportSuspiciousEdit` looks for. A
  report whose `stack` runs through the editor's own `onChange` with another panel open is that, not the
  bug. This is the reason to keep reading the `stack` rather than the count.
 Pinned by `useEditorState.test.ts` (9 tests): adoption, cross-panel edit, close-with-holders, drop on last
 close, release on unmount, and that the tab set stays per panel.
 **Still not closed.** This removes the mechanism, not the mystery: where the log text came from is still
 unknown, and nothing found so far writes job output into an editor buffer. Keep the trap.
 ## When it is reported
@@ -0,0 +1,137 @@
 # Filesystem quotas — the prerequisite for per-user and per-team storage limits
 **Status: planned, not done. Nothing in the platform reads or writes a quota yet.**
 This is the host-side half. It makes limits *enforceable*; it does not create any. The platform side —
 the owner declaring defaults and maxima, and provisioning applying them — is `docs/roles-and-teams.md`
 → "Quotas", and it is not built either. Do this first, because a policy nothing enforces is worse than
 no policy: it reads as a limit and is not one.
 ## Why the kernel and not the platform
 Members hold `terminal` at `write` and have their own Linux accounts. A quota the platform tracks by
 counting bytes through the file browser is decorative — a member opens a terminal, or connects over SSH
 with their own key, and writes past it without the platform seeing the write.
 Only the filesystem can refuse. So this is a provisioning feature, not an accounting one.
 ## Where it matters
 **`edge-pertento`.** It is the first real multi-user deployment and the only host that will hold accounts
 that are not the owner's. It already has one account, which is the argument for doing this soon rather
 than carefully later: moving a home directory is easy once and tedious per person.
 `officer-dev` is a development machine and will not be multi-user. `alpha` is the owner's own. Neither
 needs this, and neither can do it without the same downtime, so there is no reason to.
 ## What to check BEFORE booting into rescue
 Run these on the live machine. They decide whether the procedure below is the right one.
 ```bash
 findmnt -no FSTYPE,SOURCE,TARGET /                 # expect ext4, and note the real device
 findmnt -no OPTIONS / | tr ',' '\n' | grep -i quota  # expect nothing — that is why we are here
 sudo tune2fs -l "$(findmnt -no SOURCE /)" | grep -iE 'features|Inode size'
 lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
 df -h /home
 ```
 Three things decide the plan:
 1. **Is `/home` its own filesystem, or part of `/`?** On a stock Hetzner image it is part of `/`, so the
   root filesystem is what gains the feature.
 2. **Inode size.** Only matters if you use project quotas — they need 256 bytes and cannot be enabled on a
   128-byte filesystem without recreating it. The plan below avoids project quotas for exactly this reason.
 3. **Is the device under LVM?** `alpha` is; `officer-dev` is not. It changes only the device path.
 ## The plan: user quotas and group quotas, not project quotas
 Two mount options cover both cases and neither needs a feature the filesystem might lack:
 - **`usrquota`** — a limit per Linux user. This is the per-account home directory limit.
 - **`grpquota`** — a limit per Linux group. **This is how a team's shared folder gets a limit**, because a
  team is already a Linux group (see `docs/roles-and-teams.md` — the group is what keeps one team out of
  another's folder, not the permission grant).
 Project quotas (`prjquota`) would let a *directory* carry a limit independent of ownership. That is more
 flexible and it is not needed: every case here is "this user" or "this team", both of which are already
 identities the kernel knows. Skipping it also skips the inode-size problem entirely.
 **For the group quota to work, the team folder must be `setgid`** (`chmod g+s`), so files created inside it
 inherit the team's group and are charged to it. Without that, a member's files are charged to the member's
 own primary group and the team limit counts nothing. This is the single easiest thing to get wrong here.
 ## Procedure
 Downtime is roughly ten minutes, most of it reboots. The owner has said downtime is acceptable.
 **1. Install the tools, on the live machine.**
 ```bash
 sudo apt-get update && sudo apt-get install -y quota
 ```
 **2. Take note of the root device**, from the pre-flight above — `/dev/sda1` on a stock image,
 `/dev/mapper/<vg>-<lv>` under LVM. Every command below uses it.
 **3. Boot into Hetzner rescue** from the Cloud console, and do not mount the filesystem.
 **4. Check it, then add the feature.** `tune2fs` refuses on a filesystem that is not clean, and the check
 is worth running anyway before changing metadata:
 ```bash
 e2fsck -f /dev/sda1
 tune2fs -O quota /dev/sda1
 tune2fs -l /dev/sda1 | grep -i features    # 'quota' must now appear
 ```
 `quota` here is the ext4 *journaled quota* feature. It is what lets quotas come up with the filesystem
 rather than needing a `quotacheck` scan at every boot, which on 320 GB is not quick.
 **5. Add the mount options.** Back on the normal system — or by mounting the root filesystem from rescue
 and editing it there — the `/` line in `/etc/fstab` gains `usrquota,grpquota`:
 ```
 UUID=<unchanged>  /  ext4  defaults,usrquota,grpquota  0  1
 ```
 **6. Reboot into the normal system and confirm.**
 ```bash
 findmnt -no OPTIONS / | tr ',' '\n' | grep quota   # usrquota, grpquota
 sudo quotaon -p /                                   # both should report "is on"
 sudo repquota -s /                                  # a table, not an error
 ```
 ## Verify it actually refuses
 Enabling quotas and setting none is the failure that looks like success. Prove enforcement once, on a
 throwaway account, before trusting it:
 ```bash
 sudo useradd -m quotaprobe
 sudo setquota -u quotaprobe 10240 10240 0 0 /        # 10 MB soft and hard
 sudo -u quotaprobe dd if=/dev/zero of=/home/quotaprobe/fill bs=1M count=50
 # expect: "Disk quota exceeded" and a file of about 10 MB, NOT 50
 sudo userdel -r quotaprobe
 ```
 If that writes 50 MB, quotas are not on, whatever the mount options say.
 ## What this does not do
 - **It sets no limits.** Every existing account is unlimited until something assigns a quota. That is the
  correct intermediate state: the machine gains the ability, nobody's behaviour changes.
 - **It does not touch the platform.** `provision-os.ts` does not call `setquota` yet, and there is nowhere
  for the owner to declare a default. That is the other half.
 - **It does not apply to the team folders**, because there are no team folders yet. When they arrive they
  must be `setgid` or their group quota counts nothing.
 ## When the platform half is built
 `POST /users/:id/provision-linux` already exists as a retry path and is the natural home for this: it
 becomes "re-apply current policy to this account", covering both a new account and a changed limit.
 **On a host where quotas are not enabled, the platform must say so** — "policy recorded, not enforceable on
 this host" — rather than storing numbers that do nothing. Same rule as the plugin dependency check: refuse
 or report, never silently no-op. `quotaon -p` is the check, and it is cheap enough to run per request.
@@ -0,0 +1,470 @@
 # Localization
 **Status: BUILT and shipping six locales** — en-GB, pt-PT, es-ES, de-DE, fr-FR, sv-SE. The mechanism
 is done; what remains is coverage, which is the count-taking below.
 **To add a seventh language, read "Adding a locale" at the bottom and nothing else.** It is seven
 files and the order does not matter, but missing one is silent — see the failure it is written from.
 This is an execution plan. It is written to be handed to an agent who has not had the conversation
 that produced it, so it states the decisions and the reasons for them, not just the steps.
 Every count here is a **measurement taken on 2026-08-23**, not a claim that stays true — the whole
 point is for it to fall. Re-derive with `bun scripts/i18n/scan-hardcoded.ts` rather than trusting the
 number beside it, and do not wire these into `docs:check`: a guard that fails when the count drops
 would be a guard against progress.
 ---
 ## What this is
 Every word the UI shows a person should come from a catalog keyed by locale, so the platform can be
 read in a language other than English. Routes stay English (`/minesweeper`, `/chat`) — that is a URL
 decision, deferred, and nothing here depends on it.
 The scope is **the web UI only**. Not the server, not the plugins, not email or push. See D1 for what
 the server does instead, which is the one decision that reaches outside this boundary.
 ---
 ## What exists today, and what it cannot do
 **Updated 2026-08-23, after phases 0, 1 and 2.** This section described the pre-phase-0 world for long
 enough that the next reader would have started from a false picture — bare `en.json`, 46 keys, three
 components. All of that is now history and is kept below only as the "before" column, because the shape of
 the gap is the argument for the plan and deleting it would leave the phases looking arbitrary.
 |                            | before phase 0         | now                                           |
 | -------------------------- | ---------------------- | --------------------------------------------- |
 | catalogs                   | `en.json`, `pt.json`   | `en-GB.json`, `pt-PT.json` per workspace      |
 | keys                       | 46                     | **581** — 538 `app.*`, 43 `ui.*`              |
 | workspaces with a catalog  | 1 (`officer-web`)      | 3 (`officer-web`, `components`, `officerdev`) |
 | components using it        | 3                      | all of `officer-web` and `components`         |
 | plural rules               | none                   | `Intl.PluralRules`, per locale                |
 | dates and numbers          | browser locale         | `useFormat()`, the account's locale           |
 | a missing key              | rendered its dot-path  | falls back to English, warns in dev           |
 | locales offered vs shipped | ~20 offered, 2 existed | only shipped locales are offered              |
 | parity enforcement         | none                   | **a gap fails the build**                     |
 Still standing from the original description, and still true: the package is hand-rolled, has no npm
 dependency, and gives type-safe keys — a wrong key is a typecheck failure, which is worth more than it
 sounds when one agent is editing hundreds of files.
 **What remains:** `src/workspaces/officerdev` — the panels — and then translation. `panel.*` is scaffolded,
 wired into the bridge, and empty.
 Two things learned doing phases 1 and 2 that the plan did not anticipate:
 - **`TranslationKeys` walked into a plural object**, so `t('key', { count })` — the entire point of D7 —
  did not compile while `t('key.one')` did. The documented feature was uncompilable and the workaround was
  not, which no test would ever have noticed because phase 1 contained no plurals. Fixed with type-level
  assertions.
 - **The typed wrappers rebuilt `t` on every render**, which is the trap `CLAUDE.md` already records against
  `useClient()` and the Jellyfin player. It matters the moment `t` lands in a `useMemo` dependency list,
  which phase 2 needed immediately. Memoised.
 **A shape this format cannot express:** a sentence with an inline link. Splitting around the anchor gives a
 key whose Portuguese value is `"."`. The cheap fix is rephrasing so the link falls at a clause boundary;
 there is no node-level interpolation helper and adding one is a design decision, not a patch. Worth
 raising if a phase turns out to be full of them rather than absorbing it forty times.
 ### The size of the remaining work
 Measured, not guessed — `bun scripts/i18n/scan-hardcoded.ts`:
 | area                  | files   | occurrences |
 | --------------------- | ------- | ----------- |
 | `officer-web` (shell) | 132     | 556         |
 | `officerdev` (panels) | 213     | 567         |
 | shared `components`   | 91      | 47          |
 | **total**             | **436** | **1170**    |
 **884 distinct strings**, of which **88 need interpolation**. Against 46 keys today.
 That is a floor, not a ceiling. The scanner cannot see multi-line JSX, ternaries inside JSX, strings
 passed down as props, or anything a plugin renders. Budget for **1200–1500 keys**.
 ---
 ## Decisions
 ### D1. The web UI only — and the server returns codes, not prose
 The server should **never emit user-facing prose**. It returns a stable machine-readable code; the UI
 owns every word a person reads and localizes it like any other string.
 ```jsonc
 // not this
 { "error": "The Minesweeper session is not running" }
 // this
 { "code": "MINESWEEPER_NOT_RUNNING" }
 ```
 This is better than translating the server, for reasons that have nothing to do with translation. A
 code maps to exactly one failure site, so it is greppable and a support conversation has something
 precise to quote. Prose drifts; a code does not. And the server stops needing to know who is reading.
 - **Phase 1 establishes the convention** so new code stops adding debt: new error paths emit codes,
  and the catalog gets an `errors.*` namespace.
 - **Phase 2 migrates the existing ~53** prose strings in `src/servers`. Not in this plan's scope.
 - **Unmapped code** renders a generic localized line **with the code visible**. Never a blank, never
  a raw key.
 **The trap, and it is a real one: a code must not leak more than the prose it replaces.** Where a
 refusal is deliberately vague, the code has to stay equally vague. `officer-secret-store` returns a
 byte-identical `403` for "no such app" and "no grant" precisely so a caller cannot enumerate what
 exists; splitting that into `APP_UNKNOWN` and `GRANT_MISSING` would hand back the enumeration oracle
 the prose was careful not to be. When in doubt, one code for one _response_, not one per branch.
 ### D2. Regional locales, BCP 47, and every catalog is complete
 `pt-PT`, `pt-BR`, `en-GB`, `en-US` — not bare `pt` and `en`. Portuguese is the case that forces it, and
 it is the owner's own language, so getting it wrong is felt immediately.
 **Every locale ships a COMPLETE catalog. There is no regional inheritance and no overlay.** A file holds
 every key the UI has, translated for that locale, or it does not ship.
 This reverses an earlier version of this decision, which had `pt-BR` inherit from `pt` so a base catalog
 carried the shared bulk and a regional file carried only the differences. That is the conventional design
 and it was rejected for a product reason that outranks the engineering one:
 **A missing European Portuguese key would have fallen through to Brazilian.** European and Brazilian
 Portuguese differ most in exactly the vocabulary this UI is full of — technical terms — and the platform is
 being sold into the European Portuguese market first. So the failure mode of an overlay is a Portuguese
 reader getting Brazilian phrasing on whichever strings nobody remembered to override, silently, and with no
 signal that it happened. Owner's call, and it is the right one: a reader must never be served a neighbouring
 variant's words.
 The engineering objection to full catalogs was drift — two near-identical files diverging within a month.
 That is answered by making the **key-parity test load-bearing** rather than advisory (see Tooling): a locale
 missing a key that `en` has fails the build, so an incomplete catalog cannot ship. Completeness is enforced
 by the test rather than by a fallback quietly papering over a gap.
 It is also less code. `resolveKey` looks in the active locale and then, only if the key is genuinely absent,
 in `en` — which per D8 is a bug the parity test should already have caught. There is no chain to walk, no
 base-versus-overlay merge order, and no question about which file a given string lives in.
 `Intl` takes BCP 47 tags natively, so dates, numbers and plurals come out right with no extra work.
 **Migration:** `settings.languages.default` stores bare codes today (`pt`). The picker must move to regional
 tags, and stored values need a one-time widening (`pt` → `pt-PT`, `en` → `en-GB`). Prefer widening on read
 over a database migration — a stale bare code should resolve, not fail.
 **Consequence for translation work:** a new locale is a whole catalog, not a diff. Machine-translate the
 full file and have it reviewed, rather than hand-writing overrides against a base. For `pt-PT` and `pt-BR`
 that means two complete passes, reviewed separately, because the whole point is that neither borrows from
 the other.
 ### D3. RTL — prepare, do not ship
 No right-to-left locale ships in this phase. But since 436 files are being opened anyway, they get
 opened once:
 - **CSS logical properties** as components are touched — `margin-inline-start`, `padding-inline`,
  `text-align: start` — instead of `left`/`right`. Tailwind has `ms-`/`me-`/`ps-`/`pe-` for this.
 - **`dir` on `<html>`**, driven by the locale, wired now and set to `ltr` for every shipped locale.
 The cost during a pass we are already making is close to nothing. The cost of a second pass over 436
 files later is not. Hebrew stays in the picker but is not selectable until a catalog exists (see the
 "twenty offered, two that exist" defect above — fix it by filtering the picker to shipped locales).
 ### D4. Extend the existing package. Do not adopt a library
 `react-i18next`, `lingui` and `formatjs` are all better than what is here, and all of them are
 dependencies. This repository froze its lockfile and hand-rolled a secret store rather than take
 one, for reasons written down in `CLAUDE.md` → "Installs are frozen".
 The gap is smaller than it looks, because the hard parts are in the runtime already: `Intl.PluralRules`,
 `Intl.DateTimeFormat`, `Intl.NumberFormat`, `Intl.RelativeTimeFormat`. What is missing is roughly 150
 lines of glue, listed in "What it cannot do yet".
 Revisit this only if message _formatting_ gets genuinely complex — nested selects, gendered forms.
 ICU MessageFormat is a real specification and reimplementing it would be the wrong kind of ambition.
 ### D5. Keys, not English source text
 `t('settings.profile.changePassword.title')`, never `t('Change Password')`.
 Source-text keys (the gettext and lingui style) read nicely and mean an untranslated string still
 renders. They also mean **editing an English word invalidates every translation of it**, and this
 codebase already has typed keys — a wrong key is a compile error today, and that is not worth
 trading away.
 ### D6. Catalogs live per workspace, merged at the bridge
 Not one god file. Three:
 ```
 src/apps/officer-web/locales/          →  namespace  app.*
 src/workspaces/officerdev/src/locales/ →  namespace  panel.*
 src/workspaces/components/locales/     →  namespace  ui.*
 ```
 `I18nBridge` deep-merges them before handing the map to the provider. Each workspace exports its own
 typed `useTranslation` the way `officer-web/lib/i18n.ts` does today.
 Two reasons, and the second is the one that matters for execution. Strings belong next to the code
 that renders them, so a panel stays self-contained. And **one 900-key `en.json` is a merge conflict
 on every parallel edit** — with several agents or several days of work, a single file is a queue.
 Namespaces also make an unqualified key impossible to place wrongly: `ui.*` is shared, so anything
 under it must not mention a feature.
 ### D7. Plurals and formatting go through `Intl`
 A plural value becomes an object; a string stays a string:
 ```jsonc
 "panel.files.selected": { "one": "{{count}} file selected", "other": "{{count}} files selected" }
 ```
 `t()` picks the branch with `new Intl.PluralRules(locale).select(count)` when `count` is passed.
 Categories are per-locale — English and Portuguese use `one`/`other`, Arabic uses six — so the shape
 must be an open record, never a two-field type.
 A `useFormat()` hook returns `date`, `time`, `dateTime`, `number` and `relative`, each bound to the
 active locale. **The ~23 `toLocale*` call sites move to it.** Left alone they follow the browser's
 locale and quietly contradict the rest of the UI.
 ### D8. A missing key falls back to English and is loud in dev
 Never render a dot-path to a person. Resolution walks the chain, ends at `en`, and only if English is
 missing too does it render the key — which at that point is a bug the parity test below should have
 caught.
 In dev, a miss logs once per key with the key and the locale. In production it is silent.
 ---
 ## The key naming convention
 Three segments, sometimes four. **Name the role, never the text.**
 ```
 <namespace>.<area>.<component>.<element>
 app.settings.profile.changePassword.title
 panel.files.contextMenu.rename
 panel.chat.composer.placeholder
 ui.button.cancel
 app.errors.MINESWEEPER_NOT_RUNNING
 ```
 - `namespace` — `app` / `panel` / `ui`, per D6.
 - `area` — the route or panel it belongs to; matches the directory.
 - `component` — the file, lowercased.
 - `element` — what it _is_: `title`, `description`, `placeholder`, `confirmLabel`, `emptyState`.
 Rules that keep 1200 keys navigable:
 - **Never key by the English words.** `ui.button.save`, not `ui.button.saveText` and never
  `ui.button.Save`.
 - **Never build a key at runtime.** `t(\`panel.${kind}.title\`)` defeats both the type checker and
  the extractor. Use an explicit map from the dynamic value to literal keys.
 - **`ui.*` may not name a feature.** If a shared component needs feature words, the caller passes
  them as a prop.
 - **One key per meaning, not per occurrence.** "Cancel" in twelve dialogs is `ui.button.cancel` once.
  But a word that is the same in English and different elsewhere — "Post" the noun and the verb —
  gets two keys. When unsure, split: merging later is safe, splitting later is not.
 ---
 ## What must never be translated
 Getting this wrong is worse than missing a string, because it corrupts data or breaks a contract.
 - **Agent and chat output.** Whatever Claude or opencode wrote. It is content.
 - **User content** — file names, paths, terminal output, code, commit messages, note bodies.
 - **Not everything a panel renders is content, and "panel plus file names" is the wrong test.** The
  guidance during phase 3 was to expect roughly half of FileBrowser's hits to be content and stay English.
  `useFileBrowserApp.ts`, the largest file in the phase at 47 hits, turned out **100% convertible**.
  The reason is worth keeping. A panel that LISTS things renders content — a file name in a row is the
  user's, and translating it would be absurd. A panel REPORTING about those things owns the sentence:
  `Renamed to "{{name}}"` is ours, and the file name sits inside it as a parameter, which is exactly where
  content belongs. So the test is not "does this panel touch file names" but "is the string a frame around
  content, or the content itself".
  It also matters for plurals. Six hand-rolled ones in that file became real entries because Portuguese
  reorders them — `1 item eliminado` against `Deleted 1 item` — which a frame with a count spliced into it
  cannot express at all.
 - **A label quoted from ANOTHER product's interface.** "Click **Enable**", "set **App name**", "choose
  **Internal**" in a setup guide. These read like prose and are identifiers: their whole job is to match
  what the reader will actually see on Google's screen, and Google localises by the reader's _Google_
  account language, not by ours. Translating them sends somebody hunting for "Ativar" in a console that
  says "Enable".
  So translate the connective prose around them and leave the quoted label in English. Do not key it with
  identical values in both catalogs either — that is a key whose two sides can never legitimately differ,
  which is a maintenance cost bought for nothing.
  Decided 2026-08-23 on `GoogleOAuthConfig.tsx`, where 55 of the file's 67 strings are of this kind.
 - **Identifiers that cross a boundary** — route paths, permission keys (`registry.ts`), error _codes_
  (the code is the key; its message is what gets translated), app ids, sidecar names, PM2 process
  names, database values.
 - **Log lines and thrown `Error` messages** that are not rendered to a user. They are for whoever is
  reading a terminal at 4am, and they should stay greppable in one language.
 - **"Officer"**, and product names generally.
 ---
 ## Execution
 Four phases. Each is a commit that leaves the tree green — the app must run in English at every point,
 because a half-converted UI is unreviewable.
 ### Phase 0 — infrastructure, no visible change
 Everything in "What it cannot do yet". Nothing in this phase touches a component.
 1. `resolve.ts`: fallback chain (D2), plural selection (D7), dev-mode miss warning (D8).
 2. `I18nProvider`: accept a merged map; expose `useFormat()`.
 3. `I18nBridge`: deep-merge the three catalogs (D6); set `dir` on `<html>` (D3).
 4. `Languages.tsx`: regional tags, and **filter the picker to locales that actually exist**.
 5. Settings migration: widen stored bare codes on read.
 6. Scaffold `locales/` in `officerdev` and `components`, each with its typed hook.
 7. Land the tooling below.
 Phase 0 is the whole plan's risk. It is also small, and it is the only part where a wrong decision is
 expensive to reverse — review it before phase 1 starts.
 ### Phase 1 — shared components (91 files, ~47 strings)
 Smallest, highest reuse, and it establishes `ui.*` before anything depends on it. Do this first so
 phases 2 and 3 can reach for `ui.button.cancel` instead of inventing it twice.
 ### Phase 2 — the shell (132 files, ~556 strings)
 `officer-web`: settings, dock, header, screens. Highest-traffic text and the part a reviewer will
 look at first. Convert per directory, one commit per area.
 ### Phase 3 — the panels (213 files, ~567 strings)
 `officerdev` apps. The largest surface and the most parallelizable, because panels barely share
 strings. **One panel per commit** — this is where per-workspace catalogs earn their keep, but two
 agents in the same panel will still conflict.
 ### Then: `pt-PT`
 Only after English is fully keyed. Translating against a moving catalog is wasted work.
 ---
 ## Tooling and guardrails
 Without these, 1200 keys rot. All three are small and belong in phase 0.
 **`scripts/i18n/scan-hardcoded.ts`** — already written and committed. Reports every candidate
 hardcoded string by area and file. It is how the numbers above were produced, and it is the progress
 meter: the count goes down as work lands.
 **A key-parity test — and per D2 this is now load-bearing, not a nicety.** For each shipped locale, every
 key that `en` has must be present IN THAT LOCALE'S OWN FILE. Fails the build on a gap, the same way
 `bun docs:check` fails on a stale number.
 With full catalogs and no overlays, this test is the only thing standing between "complete translation" and
 "silently English in patches". It replaces the fallback that used to hide a gap, so it has to be as
 unavoidable as the typecheck: a missing key is not a warning, it is a red build.
 **A no-new-hardcoded-strings check.** Once an area reaches zero, add it to an allow-list the scanner
 enforces, so the next feature cannot reintroduce debt. Add this per area as it completes — enabling
 it globally on day one would just be red forever.
 **Also worth having:** an unused-key report. Keys outlive the components that used them, and nothing
 else will ever notice.
 ---
 ## Verification
 - `bunx tsgo` clean. A wrong key is a type error, so this is the primary check.
  **Note for this machine:** `earlyoom` (`-r 3600`) SIGTERMs `tsgo` under memory pressure — it dies
  around 15s with `Command failed`. That is not a type error. Free memory or scope the check.
 - `bun test` — parity test green for every shipped locale.
 - `bun scripts/i18n/scan-hardcoded.ts` — count strictly decreasing per phase.
 - By hand: switch the locale to `pt-PT` and walk the converted area. Untranslated strings should read
  as **English, never as dot-paths**.
 - Check a plural at 0, 1 and 2, and a date, in both locales. These are the two things that look fine
  in English and wrong everywhere else.
 ---
 ## Open questions
 1. **Routes.** Deferred deliberately. Nothing here depends on it, and localized URLs bring
   canonicalization and redirect questions that are not worth answering yet.
 2. **Who translates?** Machine translation for `pt-PT` and `pt-BR` reviewed by the owner is the
   obvious first pass. Any locale beyond Portuguese needs an answer to this before it is offered.
 3. **Plugin frontends** are out of scope and will need a catalog-merging contract in the plugin
   manifest. Their strings are not counted above.
   **One constraint that contract has to answer, found while converting the shared components
   (2026-08-23):** those components now call `useTranslation`, so they resolve against whatever
   `I18nProvider` is above them — and with none above them they render their own dot-paths. Today that
   is safe by accident: there are exactly two React roots, and the one that is not `officer-web`
   (`apps/marketplace`) imports nothing from `components/`. A plugin frontend mounting its own root, or
   rendering a shared component outside `I18nBridge`, would put `ui.button.cancel` in front of a person.
   So the contract needs to say where a plugin's provider comes from — inherit the host's, or mount its
   own seeded with the host's catalogs — rather than leaving each plugin to remember. Note that a
   provider-absent fallback inside the `components` package was considered and rejected: it would have
   split resolution across two mechanisms and contradicted D6, which puts the merge at the bridge.
 4. **The `translateTo` setting already in `settings.languages`** is about translating _content_, not
   the UI. It is a different feature that happens to sit in the same object — do not conflate them.
 5. **Does a member see the owner's locale anywhere?** Any server-rendered or cached string shared
   between accounts needs a locale decision. D1 mostly removes this by removing server prose.
 ---
 ## Adding a locale
 Seven files. Six are mechanical; the seventh is the one that gets missed.
 **Three catalogues, one per workspace.** Copy `en-GB.json` beside itself and translate the values,
 keeping every key:
 ```
 src/apps/officer-web/locales/<code>.json          app.*    the shell, screens, settings
 src/workspaces/officerdev/src/locales/<code>.json  panel.*  the windowed apps
 src/workspaces/components/locales/<code>.json      ui.*     shared components
 ```
 **Three registrations, one per catalogue.** Each is an `import` plus a line in a map:
 ```
 src/apps/officer-web/lib/catalogues.ts
 src/workspaces/officerdev/src/locales/index.ts
 src/workspaces/components/locales/index.ts
 ```
 **And the picker**, which is the one that gets missed the other way round:
 ```
 src/apps/officer-web/lib/locales.ts    SHIPPED_LOCALES
 ```
 ### Why this is spelled out rather than left to reading the code
 es-ES, de-DE and fr-FR once shipped translated, in perfect key parity, listed in the picker — and
 completely dead. All three registration files still imported only en-GB and pt-PT, so the merge
 produced three empty catalogues and the UI rendered raw keys in three of five languages.
 Nothing caught it. The parity tests compare the JSON files against each other and every file was
 correct; a locale that is never imported is invisible to them by construction. The picker was right.
 Four edits in four files with no single place that knew all four had happened.
 ### What checks you now
 Run `bun test` and it is settled. Two things stand where nothing stood:
 - `src/apps/officer-web/lib/catalogues.test.ts` asserts every locale in `SHIPPED_LOCALES` resolves to
  a populated catalogue in all three namespaces, and matches en-GB's size. A locale in the picker but
  not imported fails here. So does one imported but empty.
 - The three `parity.test.ts` files read their own directory rather than listing locales by hand, so a
  new `<code>.json` is checked the moment it exists — for missing keys AND extra ones, because
  `findMissingKeys` alone reports half of a rename.
 Then `bunx tsgo` and `bunx prettier --write` on what you touched, as everywhere else.
@@ -0,0 +1,109 @@
 # A plugin's capabilities are LOADED, never copied
 **Status: built.** Skills, affordances and notification catalogues landed in `2026.08.23.06`; tasks — the
 read-write one, and the last piece — landed on 2026-08-24. The four publishers are gone.
 ## The problem, as it is on disk right now
 `capabilities/` is a git repository. The intent is that anyone can fork it, keep their own tasks, skills
 and affordances in it, and pull core's on top. That only works if the directory contains exactly two
 things: what core ships, and what the owner wrote.
 It does not. Four publishers copy a plugin's files into it at install time — assets, affordances,
 notification catalogues and skills — so a fork accumulates files it did not author. On this machine today
 `skills/email-db/` and `extensions/` sit untracked in that repository, published there by plugins. Commit
 them and the fork carries another plugin's work; leave them and `git status` is permanently noisy. There
 is no third answer, because nothing on disk says which files came from where.
 Copying is also wrong in a second way that has nothing to do with git. **A copy goes stale.**
 `plugins:update` pulls new plugin code and the copied capabilities keep describing the old version until
 something republishes them. And a copy survives `plugins:disable`, so a disabled plugin's skill stays in
 the agent's index — the plugin is off and the agent still believes it is there.
 ## The design
 **A plugin keeps its capabilities in its own directory, and the platform reads them where they are.**
 ```
 capabilities/                      the owner's fork: core's, plus their own. Nothing else, ever.
  tasks/  skills/  affordances/  notifications/
 plugins/<name>/                    the plugin's own repository, cloned on install
  tasks/  skills/  affordances/  notifications/
 ```
 Nothing is copied. Nothing needs a namespace to keep the two apart, because they are already apart —
 which is the whole reason this beats scoping the paths. A namespace makes provenance _readable_; separate
 directories make it _structural_.
 Four consequences, and each of them is a bug that stops existing:
 - **A fork stays clean.** `capabilities/` contains only what its owner is responsible for, so pulling from
  upstream merges without touching anything a plugin put there.
 - **Capabilities update with the plugin.** `plugins:update` is a `git pull` in the plugin's directory, and
  the capabilities are in that directory. There is nothing left to go stale.
 - **Disable actually disables.** The load list is built from plugins that are installed AND enabled, so a
  disabled plugin contributes nothing. Today its copies remain.
 - **Uninstall needs no cleanup step.** The directory goes and its capabilities go with it. No list of
  filenames to be careful with, and no way to delete the owner's own work by getting that list wrong.
 ## What has to change
 **The loaders take a list of roots.** `loadSkills(root)` and `loadAffordances(root)` already take one with
 a default, so this is a small change rather than a rewrite. Notifications the same.
 **The list is resolved per session, not at module load.** `affordanceBlock()` and `skillsBlock()` are
 called once per session in `sidecar/claude/claude-manager.ts` — deliberately, so a capability written an
 hour ago is offered on the next session. That is also why they can afford to ask the database which
 plugins are installed: once per session, not once per turn.
 **Tasks are the awkward one, because that store is read-write.** `api/tasks/task-files.ts` creates, edits
 and deletes as well as reads. Reading must span every source; writing must only ever touch the owner's
 directory. A plugin's task is read-only by nature and the UI has to know, or it will offer an Edit that
 silently writes into a directory the next `plugins:update` overwrites.
 A task's directory name is also stored data — `taskDirName` in `pipeline_jobs` — so lookup by name has to
 search every source rather than assuming one root.
 **How it went in, since it turned out to be one function rather than several.** Every path that runs a
 task — the file browser's context menu, both runner sockets, the job queue, the pipeline executor —
 resolves it through `getTaskByDirName` and then reads `implementation` off the record. So the sources go
 in there and in `listTasks`, and a plugin's task becomes runnable everywhere at once with its identity
 unchanged: still a directory name, still what `pipeline_jobs` stores.
 The record carries `plugin` — the app name, or null for the owner's own. That one field does the rest:
 `updateTask` and `deleteTask` throw on it, `DELETE /api/tasks/:name` answers 409 naming the plugin, and
 the capability screen replaces the edit and delete controls with a line saying whose it is. Without the
 delete guard the old code was quietly a no-op — `rm -rf` on a path in the owner's store that does not
 exist, then `{ ok: true }`, and the task still in the menu.
 `getTaskByDirName` also refuses a name containing a separator. It always joined a caller-supplied string
 onto a path; searching several roots is the moment that stops being one directory nobody could escape.
 **The four publishers are deleted**, along with their install and uninstall wiring:
 `affordances/publish.ts`, `notifications/publish.ts`, `skills/publish.ts`, `api/tasks/publish.ts`. The
 last was written on 2026-08-23 and is superseded before it ever shipped.
 `app-store/assets` is a different case and stays. Those are images served over HTTP from a
 platform-managed path, not capabilities read from disk, and the copy is what makes them reachable.
 ## The migration
 One-off, and it is deletion rather than movement. The copies already in `capabilities/` have nothing to
 remove them once the publishers are gone — `skills/email-db/` and `extensions/` on this machine, and
 whatever the equivalent is per host. They are copies of files that still exist in each plugin's own
 directory, so deleting them loses nothing.
 Check each host rather than assuming this one is representative.
 ## What this does not decide
 **Where the owner's own capabilities live inside their fork.** Flat at the top of each type directory is
 what happens today and needs no change. Scoping them is a separate question and this design does not
 force it either way.
 **Whether a plugin's capabilities should be namespaced among themselves.** Two plugins can still ship a
 task with the same directory name. The tie-break shipped as first-come with the owner's store searched
 first, which settles the case that matters — a plugin cannot take over a name its owner is already
 using — and leaves two plugins colliding with each other resolved by discovery order, which is arbitrary.
 Worth revisiting when a second plugin ships a task; not before.
@@ -0,0 +1,282 @@
 # Roles and teams
 **Status: plan, not built.** Phase 0 landed 2026-08-23 (`roles` is a table). Everything below phase 0 is
 design, written down so the work starts from a spec rather than from a conversation.
 ## What this is
 Officer began as one person's server and its authorization model says so: four role names in a TypeScript
 union, one owner identified by holding one of them, and grants keyed on a role string. That is correct for
 a homelab and it cannot express a company, where the same person is an administrator of one area and an
 ordinary member of another.
 Two things are wanted, and they are separable:
 - **Roles as data**, so a role can be added without a deploy, and so each can eventually carry its own
  provisioning.
 - **Teams**, so a user belongs to several and holds a different role in each.
 **Teams are optional and must stay optional.** A homelab with family and friends on it may never make one;
 its owner's answer is "team family, team friends" or no teams at all, and either has to work. A company
 uses both. Nothing below may make teams mandatory to reach a feature.
 ---
 ## What already landed — phase 0, 2026-08-23
 The `roles` table exists, seeded with `Super Admin`, `Admin`, `Developer`, `Member`, each flagged
 `isSystem` because the platform's own code names it. `provisioningScript` is declared and null.
 **Nothing reads it yet.** `USER_ROLES` is still the type, `users.role` is still plain text with no foreign
 key, and `authorize.ts` is untouched. That was deliberate: the change is additive, so it cannot fail on
 existing data, which is what made it safe to hand to an unattended rollout across five hosts.
 **No foreign key, and this is the reason.** `db:push` creates a table and adds a constraint in the same
 run, so a foreign key from `users.role` onto an empty `roles` is violated by every existing account.
 Verified against a scratch database: push reported the violation, created the table, skipped the
 constraint, **and exited 0**. See `prompts/deploy-commander.md` → "Schema changes".
 ---
 ## Decisions
 ### D1. The owner is an identity. It is never a role.
 `OWNER_USER_ID` — user 1, the account whose home is the home of the OS user the platform runs as.
 Before phase 0, `isSuperAdmin()` answered `user.role === 'Super Admin'`. That was correct while roles were
 a hardcoded union and nothing could write a new one. **The moment roles are editable data it becomes a
 privilege-escalation path**: "add a role" and "become the owner" are the same feature, reachable from
 whatever UI manages roles.
 So ownership moves to `user.id === OWNER_USER_ID`, and `getOwnerUser()` becomes a primary-key lookup rather
 than "the lowest id holding Super Admin". **This is the load-bearing change in phase 1** and everything
 else can wait behind it.
 ### D2. Several Super Admins are allowed, and the role provisions sudo
 Today `create-user.ts` and `updateUserRoleHandler` refuse to create a second Super Admin. That limit goes:
 a company has an owner and several administrators, and a homelab owner may add one or never do.
 **Holding `Super Admin` provisions an OS account with sudo.** Which means, plainly: that person is outside
 Officer's permission system. `role_permissions`, the `confined` kernel containment and the
 "`execution` is never grantable" rule bound nobody who can `sudo cat` any home on the box. And the grant is
 irreversible in practice — revoking the role does not revoke an SSH key, a cron entry or a setuid binary
 they left behind.
 That is the operator's decision to make, not the platform's to prevent. What the platform owes them is for
 the UI to say what it is rather than presenting it as one more row in a dropdown.
 ### D3. `Admin` is app-wide authority with no operating-system privilege
 The role most companies actually staff: creates accounts, manages grants, sees every dashboard, and cannot
 read the CEO's files. It already exists and `rolePermitsDevTools()` already excludes it deliberately —
 "administering the platform is not developing on it". This decision only writes that down.
 ### D4. A role may be deleted, but not while anyone holds it
 Refuse the delete; never reassign. Silently moving accounts to a fallback role is a permission change
 nobody asked for, and "absence denies" is the posture everywhere else in this system.
 `isSystem` roles refuse both delete and rename, because the code names them by name:
 `rolePermitsDevTools()` tests for `Developer`, `bootstrap.ts` writes `Super Admin`, `users.role` defaults to
 `Member`. Renaming one is a code change that has not happened yet.
 ### D5. Grants stay keyed on the role NAME, with `ON UPDATE CASCADE`
 `role_permissions.role` and `users.role` both hold a name. Re-keying them onto a serial id would touch
 `authorize.ts` — the file standing between a Member and a shell — to buy what Postgres gives for free: a
 rename cascades to every user and every grant, atomically, with no code change.
 The cost is that a rename is a data migration rather than a label edit, which is honest — a role name
 appears in `rolePermitsDevTools`, in report text, and in whatever a plugin has written down.
 ### D6. A team is a scope. Permissions UNION across a user's teams.
 Admin in marketing and member in developers means marketing's admin level does not reach developers'
 files — but a user's effective permission for a given capability is the **highest level any of their teams
 grants**, plus their global role.
 Union is the only coherent resolution, and it has a consequence worth stating: **adding somebody to a team
 can only ever grant, never restrict.** A team cannot be used to limit someone. If restriction is ever
 wanted, that is a different and much harder system (deny rules, precedence, conflict resolution) and it
 should be refused rather than half-built.
 ### D7. The global role remains, and answers a different question
 Two questions, two mechanisms:
 - **"May this account administer the server at all?"** — the global role. Super Admin, Admin.
 - **"What may this account do in this area?"** — team membership with a role in that team.
 This is the shape GitHub, Slack and Workspace all converged on, and the reason is that the first question
 has no natural team to ask it about. A homelab uses only the first and never makes a team.
 ### D8. Per-role provisioning is a script the role carries
 `provisioningScript` on the role row. Run when an account is granted that role; the reference implementation
 is `Developer`, which today gets a Postgres role of its own through `rolePermitsDevTools()` — a special case
 in code that should become a row.
 The historical note matters for whoever builds it: that gate was originally for **rootless** Docker, and
 rootless specifically. `usermod -aG docker` is root by a longer route —
 `docker run -v /:/host -it alpine chroot /host` reads `.env`, every member's home and the wallet seed. Any
 provisioning script that adds a user to a privileged group is granting more than its role name suggests.
 ---
 ## Phases
 ### Phase 0 — roles are a table ✅ DONE 2026-08-23
 Additive only. Nothing reads it.
 ### Phase 1 — the owner stops being a role ✅ DONE 2026-08-23
 The load-bearing phase, and small.
 1. `isOwner(user)` = `user.id === OWNER_USER_ID`. `getOwnerUser()` = lookup by that id.
 2. Split the two meanings of today's `isSuperAdmin()`: ownership, and holding the role. **Every existing
   call site keeps meaning OWNER**, so no route changes who it admits. Widening any "owner-only" route to
   "owner or Super Admin" is a separate, reviewable change per route.
 3. Drop the second-Super-Admin refusals in `create-user.ts` and `updateUserRoleHandler`.
 4. ~~Remove the `users` CHECK that pins user 1 to `Super Admin`~~ — **KEPT, overruling this plan.** It is
   redundant for the question it was written for: `isOwner` is an id comparison and never reads that column.
   But it still forbids user 1 being set to `Member` while remaining the owner, which is a state with no
   benefit and a confusing display. A constraint that costs nothing and forbids a nonsense state is worth
   keeping after its original reason has gone.
 **One asymmetry introduced deliberately.** An existing account can now be promoted to `Super Admin`;
 creating one directly as `Super Admin` is still refused by `create-user.ts`. Promotion happens to an account
 somebody has looked at, from a screen showing who they are. Creation is a form filled in once, and the role
 that provisions sudo should not be a dropdown default reached by accident. Create, then promote.
 Reviewable on its own, and nothing downstream can start until ownership is an identity.
 ### Phase 2 — the foreign key, and role CRUD
 1. **Two releases, not one.** The rows are on every host after phase 0; the constraint ships separately,
   and its release plan carries the SQL explicitly per `prompts/deploy-commander.md`.
 2. `users.role` and `role_permissions.role` become foreign keys with `ON UPDATE CASCADE` (D5).
 3. Role CRUD: list with holder counts, create, rename, delete guarded by D4.
 4. `USER_ROLES` stops being the source of truth. `UserRole` becomes `string`, and the picker reads the
   table. **This is where the typed-union safety is lost** — worth a runtime validator at the write path to
   replace what the compiler was doing.
 ### Phase 3 — per-role provisioning
 `provisioningScript` gets a runner, and `rolePermitsDevTools()` becomes a row rather than a branch. Needs
 D8's warning in front of whoever writes the first script.
 ### Phase 4 — teams
 1. `teams`, and `team_members(team_id, user_id, role)` — the role scoped to the team.
 2. `team_permissions(team_id, role, permission, level)`, or a discriminator on `role_permissions`. Decide by
   asking whether a team's roles are the same set as the global ones; probably yes, and probably that means
   one table with a nullable `team_id`.
 3. `authorize.ts` resolves the union (D6): global role grants, plus the highest level any team grants.
   **This is the one change in the whole plan that alters the resolver**, so it wants tests before it wants
   code — `permissions/authorize.test.ts` is already pure and mockless, which is what makes that possible.
 4. Teams UI, and the account screen showing which teams a user is in and as what.
 ### Phase 5 — account creation — **DONE, and it was done before this phase was written**
 `POST /api/users` is owner-gated and live, with a form under Settings → User Management: same password
 validator as bootstrap, a role checked against the `roles` table, `Super Admin` refused outright, an
 optional inbound SSH key, and Linux provisioning with `POST /users/:id/provision-linux` to retry it.
 Alongside it: role change, password reset, delete.
 It shipped in `69a31051`. This section spent days telling readers it did not exist and sequencing work
 around building it — and on 2026-08-23 it produced a concrete cost, when a recommendation to "do phase 5
 first" was made from this text and withdrawn only because someone opened `api/users/` to write the spec.
 The general lesson, since it is the second time this exact shape has bitten: `bun run docs:check` compares
 numbers, so counts stay honest while prose rots quietly. **A phase marked as not built is worth verifying
 against the tree before it is planned around**, not because the plan was careless but because a plan is
 written once and the code moves every day.
 ---
 ## What must not be built
 - **Deny rules.** See D6. Teams grant; they never restrict.
 - **A role that confers ownership.** See D1. There is exactly one owner and no role reaches it.
 - **Team-scoped `execution` capabilities.** Tasks, items, desktop and browser run as the owner's OS user in
  the owner's home. A team cannot make that safe, and "team developers gets terminal" has to stay a no —
  the answer is a `confined` grant with a Linux user, which is per-account by nature.
 ## Verification
 - `bunx tsgo` clean. Note that on this machine `earlyoom` SIGTERMs the `bunx` wrapper around 15s; run the
  binary directly.
 - `permissions/authorize.test.ts` is the primary guard, and it uses real registry keys deliberately so a
  rename goes red rather than passing vacuously. Phase 4 must extend it before changing the resolver.
 - `bun run docs:check` — the permission count claim in `CLAUDE.md` moves whenever the registry does.
 - Any schema phase: verify by query per host, never by `db:push`'s exit code.
 ## Teams — decided 2026-08-23
 The four open questions were answered by the owner. Recorded here so phase 4 is implementation rather
 than another round of design.
 **A team owns a shared folder.** Not only an authorization grouping — storage is the part that was
 actually wanted. Team *dashboards* are a probable later addition and were explicitly deferred, because
 they need a permission shape nothing here has: people who can edit a dashboard's STRUCTURE versus people
 who only see what it renders. Every grant today is read-or-write over a whole capability, so that is a new
 model rather than a new level. Build the folder; leave room for the dashboards.
 **Any Admin may create a team**, not the owner alone. Teams are self-service for people already trusted to
 administer the platform. This is what makes the quota section below necessary rather than optional: an
 Admin creating a team is an Admin allocating disk.
 **A team may grant a capability the member's own role lacks** — the union, per D6 — with one rule on top:
 **whoever creates the team can only attach capabilities they hold themselves.** Escalation is capped at the
 creator's own reach rather than the whole registry. `execution` and `admin` stay ungrantable regardless,
 and `confined` still resolves to nothing for an account with no Linux user.
 **Deleting a role is refused while anyone holds it, in a team or globally.** The same rule D4 already
 applies to global holders, extended rather than special-cased; the refusal should name the teams.
 ### Two things phase 4 must not get wrong
 **The shared folder is enforced by the kernel, not by the grant.** Every role already holds `files` at
 `write` — they are the seeded `confined` defaults — so the capability is not what keeps one team out of
 another's folder. A Linux group per team is. The grant says whether someone can use the files surface at
 all; group membership says which folders they reach. Both are required and they are not substitutes.
 **The grant cache is keyed on ROLE today**, deliberately: "at most one entry per role, and a new account
 needs no warm-up" (`permissions/authorize.ts`). Teams end that — effective permissions become role plus
 memberships, which is per-user. That property is easy to lose without noticing and awkward to recover, so
 it should be a decision in the implementation rather than a side effect.
 ## Quotas — the model, and the prerequisite nobody can skip
 The owner declares platform-level defaults and maxima: per user, and per team. Admins allocate inside
 them. A change re-applies at the Linux level through `POST /users/:id/provision-linux`, which already
 exists as a retry path and becomes "re-apply current policy to this account".
 **Enforcement is the kernel's job, not the platform's.** Members hold `terminal` at `write` and have their
 own Linux accounts, so a quota the platform tracks by counting bytes through the file browser is
 decorative — a member opens a terminal or SSHes in and writes past it. Only filesystem quotas bind.
 **Which means a filesystem that can carry them.** Checked on 2026-08-23: neither `officer-dev` nor `alpha`
 can. Both are ext4 with homes on the root filesystem, no `usrquota`/`grpquota`/`prjquota` mount options,
 and neither has the ext4 `quota` or `project` feature. Enabling `project` needs `tune2fs -O project` on an
 UNMOUNTED filesystem, and `/` cannot be unmounted on a running server — so it is a rescue boot, not a
 config change.
 The cheap moment is when a host is built, by giving the Linux homes their own filesystem with quota
 features from the start. Retrofitting a live host is expensive and gets more so with every account on it.
 **Where this actually matters is `edge-pertento`** — the first real multi-user deployment, and the only
 one that will have accounts that are not the owner's. `officer-dev` is a development machine and will not
 be multi-user; alpha is the owner's own. Check edge-pertento's disk before it gains more accounts.
 **On a host that cannot enforce, the platform says so** — "policy recorded, not enforceable here" — rather
 than storing numbers that do nothing. A feature that silently does nothing is worse than one that admits
 it cannot.
 ## Open questions
 None outstanding for phase 4. The four that were here are answered above.
   holds globally; the same question exists per team and is not answered here.
@@ -21,21 +21,67 @@ ssh br@deadpool-rezio-bridge    # not implied
 ## Officer platforms
-Seven, all running.
+Eight, all running. **Verified 2026-08-27** — every row below was read off the machine, not recalled.
-| Host                         | Tailnet IP  | Login       | Checkout                            | Domain                            |
+| Host                         | Tailnet IP  | Login                                     | Port     | Checkout                            | Domain                            |
-| ---------------------------- | ----------- | ----------- | ----------------------------------- | --------------------------------- |
+| ---------------------------- | ----------- | ----------------------------------------- | -------- | ----------------------------------- | --------------------------------- |
-| `officer-dev`                | 100.64.0.13 | `pastilhas` | `~/officer-dev/platform`            | `platform.officer.dev`            |
+| `officer-dev`                | 100.64.0.13 | `pastilhas`                               | 9000     | `~/officer-dev/platform`            | `platform.officer.dev`            |
-| `alpha`                      | 100.64.0.1  | `pastilhas` | `~/officerdev/platform`             | `officer.pastilhas.dev`           |
+| `alpha`                      | 100.64.0.1  | `pastilhas`                               | 9000     | `~/officerdev/platform`             | `officer.pastilhas.dev`           |
-| `fofos`                      | 100.64.0.17 | `pastilhas` | `~/officerdev/platform`             | `officer.fofosfluffybastards.com` |
+| `fofos`                      | 100.64.0.17 | `pastilhas`                               | 9000     | `~/officerdev/platform`             | `officer.fofosfluffybastards.com` |
-| `macbookpro`                 | 100.64.0.9  | `pastilhas` | `~/projects/officer-suite/platform` | `macbookpro.pastilhas.dev`        |
+| `macbookpro`                 | 100.64.0.9  | `pastilhas`                               | **9010** | `~/projects/officer-suite/platform` | `macbookpro.pastilhas.dev`        |
-| `edge-pertento-bridge`       | 100.64.0.15 | `pastilhas` | `~/officerdev/platform`             | `edge.pertento.ai`                |
+| `macbruno`                   | 100.64.0.22 | **`brunoalcadapadezmonteirodaconceicao`** | 9000     | `~/officerdev/platform`             | — (none yet)                      |
-| `production-pertento-bridge` | 100.64.0.12 | `pastilhas` | `~/officerdev/platform`             | `officer.pertento.ai`             |
+| `production-pertento-bridge` | 100.64.0.12 | `pastilhas`                               | **9010** | `~/officerdev/platform`             | `officer.pertento.ai`             |
-| `deadpool-rezio-bridge`      | 100.64.0.21 | **`br`**    | `/home/br/officerdev/platform`      | `officer.rezio.dev` `[pending]`   |
+| `edge-pertento-bridge`       | 100.64.0.15 | `pastilhas`                               | 9000     | `~/officerdev/platform`             | `edge.pertento.ai`                |
 | `deadpool-rezio-bridge`      | 100.64.0.21 | **`br`**                                  | 9000     | `/home/br/officerdev/platform`      | `officer.rezio.dev` `[pending]`   |
 **THE PORT IS NOT ALWAYS 9000.** Two hosts run on 9010 and it is in `OFFICERDEV_PORT` in each checkout's
 `.env`. This is not a footnote: on 2026-08-27 a health check against 9000 on `production-pertento-bridge`
 hit one of Pertento's own apps, which answered `403`, and that was read as Officer failing after a
 deploy. Take the port from the `.env`, never from habit.
 **`production-pertento-bridge` also runs eight processes that are NOT Officer** — `Dashboard`, `Tracking`,
 `Uptime` and five `Crons *`. They are production-critical and belong to Pertento. Anything sweeping over
 `pm2 list` must filter to `officer` and `officer-*`, and a restart there must name its target.
 Only `platform.officer.dev` is public (77.42.39.155). The rest resolve to tailnet addresses and are
 reachable from inside only.
 ## `pm2` is not on the PATH of a non-interactive shell
 `ssh host 'pm2 jlist'` runs a NON-interactive, NON-login shell. zsh reads `~/.zshenv` for those and reads
 neither `~/.zshrc` nor `~/.zprofile` — so a pm2 installed by nvm or Homebrew is invisible to an
 orchestrator even though the daemon is running and healthy.
 **This read as "pm2 is not installed" three times on 2026-08-27**, and twice sent someone diagnosing a
 machine with nothing wrong with it. `claude` on a fresh install has the same shape.
 Fixed at the source on the two hosts where it bit — `production-pertento-bridge` (nvm) and `macbruno`
 (Homebrew at `/opt/homebrew`, which is on no default PATH on Apple Silicon) — by appending a
 marker-guarded block to `~/.zshenv`. Everything else already worked.
 If a command comes back empty over SSH, look for the binary on disk before concluding it is absent:
 ```bash
 ssh host 'ls /opt/homebrew/bin/pm2 /usr/local/bin/pm2 ~/.nvm/versions/node/*/bin/pm2 2>/dev/null'
 ```
 ## Deliberately skipped
 A host here is NOT a deploy target. A rollout names it as skipped and moves on — it is not a failure,
 and it must not be reported as one.
 None today. `edge-pertento-bridge` was here from 2026-08-23 and came back up on 2026-08-24; it is a
 deploy target again and its row is in the table above.
 It was down long enough to matter, so expect it to be behind: when it returned it was 215 commits back at
 `2026.08.22.02`, with no `roles` table and no commanders. A host coming off this list needs its schema
 brought forward before it is treated as ordinary.
 On 2026-08-23 the deploy agent spent four attempts and up to 60s per try on this host before reporting
 it unreachable — TCP on 22 accepted, then no SSH banner. That work was correct and entirely wasted, which
 is what this section exists to prevent: a host that is known to be down should cost a line in a report,
 not a retry budget.
 ### Names that disagree with themselves
 Three hosts answer to more than one name, and `tailscale status` is not always the one in use:
@@ -1,6 +0,0 @@
 {
  "host": "127.0.0.1",
  "port": 3333,
  "enable_request_logging": false,
  "last_updated": "2025-12-24T04:27:17.443375"
 }
@@ -1,6 +1,6 @@
 {
  "name": "officer",
-  "version": "2026.08.23.01",
+  "version": "2026.08.27.01",
  "private": true,
  "type": "module",
  "workspaces": [
@@ -30,7 +30,7 @@
    "build:dashboard": "bun run ./scripts/build/dashboard.ts",
    "db:gen": "cd src/databases/officer_db && bun run generate",
    "db:push": "bun run scripts/gen-plugin-schemas.ts && cd src/databases/officer_db && bun run push",
-    "postdb:push": "bun run --env-file=.env scripts/backfill-session-models.ts",
+    "postdb:push": "bun run --env-file=.env scripts/backfill-session-models.ts && bun run --env-file=.env scripts/seed-roles.ts",
    "db:migrate": "cd src/databases/officer_db && bun run migrate",
    "dev:emailer": "cd src/workspaces/emailer && bun run dev",
    "format": "{ git diff --name-only HEAD -- 'src/**/*.ts' 'src/**/*.tsx'; git ls-files --others --exclude-standard -- 'src/**/*.ts' 'src/**/*.tsx'; } | xargs -r prettier --write",
@@ -39,7 +39,8 @@
    "setup": "bash scripts/install.sh",
    "check:theme": "bun scripts/check-theme-tokens.ts",
    "docs:check": "bun run scripts/docs-check.ts",
-    "skills:platform": "bun run scripts/gen-platform-skill.ts"
+    "skills:platform": "bun run scripts/gen-platform-skill.ts",
    "plugins:check": "bun run scripts/plugins-check.ts"
  },
  "dependencies": {
    "@anthropic-ai/claude-agent-sdk": "^0.2.41",
@@ -0,0 +1,92 @@
 # Plugins
 `EXTRACTING-A-PLUGIN.md` is the runbook for turning a platform feature into a plugin, and
 `EXTRACT-A-PLUGIN-PROMPT.md` is the way to hand that to a fresh agent. This file is for the concepts a
 plugin author needs that are not procedure.
 **This directory holds documentation, not plugins.** Every plugin is its own repository; `plugins/<name>/`
 appears by `git clone` when somebody installs one, and is gitignored here.
 ---
 ## Affordances
 **`docs/affordances.md` is the authority** — what one is, the three tests for whether something qualifies,
 the file format and how they reach the agent. Read it before writing one. What follows is only the part
 that is specific to shipping one from a plugin.
 > An affordance is something the surface on the other end of the conversation offers the agent — declared
 > by the code that implements it, and read by the agent at runtime. Not what the agent can do; what the
 > client will honour.
 A plugin ships an `affordances/` directory of markdown-with-frontmatter in its repository. Installing
 copies it to `capabilities/affordances/<publisher>/<appName>/`, uninstalling removes it — the same shape
 as `assets/` and `publishAssets`, and the namespace comes from where it lands rather than from anything
 inside the file.
 **The test that catches most bad ones: can it be fixed instead?** If the answer is yes, fix it. An
 affordance describing a defect gives that defect a rationale, and the rationale outlives everyone's memory
 that it was a bug. See the two worked examples in `docs/affordances.md`.
 Keep it short — every affordance is loaded into every conversation on this machine, including turns that
 have nothing to do with your plugin.
 ### A plugin-contributed one, for reference## Notifications — the same shape, for push
 A plugin can also declare what its push notifications MEAN. Same mechanism, different store:
 ```
 capabilities/notifications/
  officerdev/music/
    catalogue.yaml
 ```
 ```yaml
 nowPlaying:
  title: 'Now playing'
  route: 'officer://music/{id}'
 ```
 That becomes the code `officerdev/music:nowPlaying`. A push carries the code and integers — never content —
 and the device renders the title and follows the route. The point is that **adding a notification is a
 server change and never an app build**, because the mapping is synced to the device rather than compiled
 into it.
 **The namespace comes from where the file lands, not from what it says.** Writing `officer/core:test` as a
 key in your own catalogue produces `<you>/<yourplugin>:officer/core:test`, not the core code — the same
 rule as `mountPrefix`, and pinned by test in `src/servers/notifications/catalogue.test.ts`.
 An entry needs a `title`; `body`, `target`, `route` and `thread` are optional, `thread` defaults to your
 namespace, and unknown keys are dropped rather than forwarded to the device. Broken YAML in one plugin's
 catalogue is skipped without affecting anyone else's.
 See `docs/push-notifications.md`.
 ### A plugin-contributed one, for reference
 This is the gitea plugin's, and it shows what these are for: the agent cannot discover from the
 filesystem that `tea` is authenticated, or that it should prefer `git` for the things git already does.
 ```markdown
 ---
 name: Gitea
 description: Use when working with git repositories, or with Gitea issues and pull requests.
 version: 1
 ---
 For anything git already does — clone, fetch, pull, push, branches, tags — use plain `git`. It talks
 to the server directly.
 For anything git does not — pull requests, issues, comments, releases, creating a repository — use
 `tea`. It is already logged in as the current user, with that user's own permissions. Do not
 configure it, and do not ask the user for a token.
 ```
 ### On the word
 `capability` was taken — `CAPABILITIES` is the permission registry. `skill` was taken twice: by
 `capabilities/skills/` here and by the wider AI ecosystem.
 `affordance` is the exact term for what an environment offers an actor, and the precision earns the
 slight awkwardness: rendering an image is not a skill the agent has, it is something the client on the
 other end permits. Keeping that distinction in the name saves explaining it every time.
@@ -1,92 +1,6 @@
 # Plugins
-`EXTRACTING-A-PLUGIN.md` is the runbook for turning a platform feature into a plugin, and
+**The instructions live in [`AGENTS.md`](AGENTS.md). Read it first — this file only points there.**
 `EXTRACT-A-PLUGIN-PROMPT.md` is the way to hand that to a fresh agent. This file is for the concepts a
 plugin author needs that are not procedure.
-**This directory holds documentation, not plugins.** Every plugin is its own repository; `plugins/<name>/`
+Kept separate so agents that look for `AGENTS.md` by convention find the same guidance as those that
-appears by `git clone` when somebody installs one, and is gitignored here.
+look for `CLAUDE.md`, without the two drifting apart.
 ---
 ## Affordances
 **`docs/affordances.md` is the authority** — what one is, the three tests for whether something qualifies,
 the file format and how they reach the agent. Read it before writing one. What follows is only the part
 that is specific to shipping one from a plugin.
 > An affordance is something the surface on the other end of the conversation offers the agent — declared
 > by the code that implements it, and read by the agent at runtime. Not what the agent can do; what the
 > client will honour.
 A plugin ships an `affordances/` directory of markdown-with-frontmatter in its repository. Installing
 copies it to `capabilities/affordances/<publisher>/<appName>/`, uninstalling removes it — the same shape
 as `assets/` and `publishAssets`, and the namespace comes from where it lands rather than from anything
 inside the file.
 **The test that catches most bad ones: can it be fixed instead?** If the answer is yes, fix it. An
 affordance describing a defect gives that defect a rationale, and the rationale outlives everyone's memory
 that it was a bug. See the two worked examples in `docs/affordances.md`.
 Keep it short — every affordance is loaded into every conversation on this machine, including turns that
 have nothing to do with your plugin.
 ### A plugin-contributed one, for reference## Notifications — the same shape, for push
 A plugin can also declare what its push notifications MEAN. Same mechanism, different store:
 ```
 capabilities/notifications/
  officerdev/music/
    catalogue.yaml
 ```
 ```yaml
 nowPlaying:
  title: 'Now playing'
  route: 'officer://music/{id}'
 ```
 That becomes the code `officerdev/music:nowPlaying`. A push carries the code and integers — never content —
 and the device renders the title and follows the route. The point is that **adding a notification is a
 server change and never an app build**, because the mapping is synced to the device rather than compiled
 into it.
 **The namespace comes from where the file lands, not from what it says.** Writing `officer/core:test` as a
 key in your own catalogue produces `<you>/<yourplugin>:officer/core:test`, not the core code — the same
 rule as `mountPrefix`, and pinned by test in `src/servers/notifications/catalogue.test.ts`.
 An entry needs a `title`; `body`, `target`, `route` and `thread` are optional, `thread` defaults to your
 namespace, and unknown keys are dropped rather than forwarded to the device. Broken YAML in one plugin's
 catalogue is skipped without affecting anyone else's.
 See `docs/push-notifications.md`.
 ### A plugin-contributed one, for reference
 This is the gitea plugin's, and it shows what these are for: the agent cannot discover from the
 filesystem that `tea` is authenticated, or that it should prefer `git` for the things git already does.
 ```markdown
 ---
 name: Gitea
 description: Use when working with git repositories, or with Gitea issues and pull requests.
 version: 1
 ---
 For anything git already does — clone, fetch, pull, push, branches, tags — use plain `git`. It talks
 to the server directly.
 For anything git does not — pull requests, issues, comments, releases, creating a repository — use
 `tea`. It is already logged in as the current user, with that user's own permissions. Do not
 configure it, and do not ask the user for a token.
 ```
 ### On the word
 `capability` was taken — `CAPABILITIES` is the permission registry. `skill` was taken twice: by
 `capabilities/skills/` here and by the wider AI ecosystem.
 `affordance` is the exact term for what an environment offers an actor, and the precision earns the
 slight awkwardness: rendering an image is not a skill the agent has, it is something the client on the
 other end permits. Keeping that distinction in the name saves explaining it every time.
@@ -9,6 +9,27 @@ one.
 ---
 ## Arming for the first time — there is nothing to rehearse against
 General commander doctrine says to run the action once before arming, so it is known to work unattended.
 **That does not apply here, and reading it as "replay the last release" is wrong.**
 Every `deploy/*` tag on the remote already has a success record in `data/deploys/`. The claim script will
 refuse every one of them, and refusing is correct — a claim exists so a release is attempted once, ever.
 So there is no legitimate trigger to rehearse with, and the only way to manufacture one is to tag a
 release, which you must never do.
 So: **arm, and say plainly that the action has never executed under you.** The next real release is the
 first run. That is an honest statement of what is unproven, and it is better than a rehearsal that either
 fights the claim or invents an occasion.
 Two things follow from it, and they are the reason this is fine rather than a gap:
 - The procedure below is already proven — nine releases, nine reports, and the last four ran unattended.
  What is unproven is this loop, not the rollout.
 - Your first real release therefore deserves more narration than later ones, not less. Say what you are
  about to do before the agent starts, so the owner can stop it while stopping it is still cheap.
 ## What wakes you
 You are not a loop. Something fires you, and each time you fire you do exactly one thing: check whether
@@ -136,6 +157,11 @@ That document holds every machine, its tailnet name, **its login user**, its che
 platform runs on it. Read it at the start of every deploy, and treat the hosts marked as having no
 platform as out of scope.
 It also has a **Deliberately skipped** section. A host listed there is not a target: name it as skipped
 in the report and spend nothing on it. On 2026-08-23 a host that was known to be down cost four attempts
 and a minute apiece before being reported unreachable — correct behaviour against a list that had not been
 told. Read that section before you try to reach anything.
 **The login is not always `pastilhas`.** `deadpool-rezio-bridge` runs as `br`, permanently, and more will.
 Take the user from the table — an orchestrator that hard-codes one fails on that host silently, because
 `Permission denied (publickey)` looks like a broken key rather than a wrong username.
@@ -163,7 +189,15 @@ assemble at the end from memory is a report that will be wrong about the host th
   `--porcelain` counts untracked files, and on 2026-08-21 that skipped a host over one stray script a
   fast-forward could never have touched. Untracked files get a note in the report, not a skip. Never
   discard someone's work to ship a release.
-2. `git pull --ff-only`. A non-fast-forward means that checkout has diverged: skip and report.
+2. **`git fetch origin --tags` then `git merge --ff-only <tag>`** — the TAG you are deploying, not
   `master`. `git pull --ff-only` follows the branch, so a commit pushed while you are rolling out lands
   on some hosts and not others, and "deployed the tag" stops being true of any of them. That happened on
   2026-08-23: every host came up one commit past the tag because a docs commit landed mid-rollout. It was
   harmless and it need not have been.
   A non-fast-forward means that checkout has diverged: skip and report. A tag that will not fast-forward
   because the host is AHEAD is the same answer — report it, do not reset.
 3. **Update the plugins.** `bun run plugins:update`. Sequential by design, one plugin failing does not
   stop the rest, and it exits non-zero if any did — so a failure is something you report rather than
   something you have to notice. A failure here is usually an uncommitted change in that plugin's own
@@ -179,6 +213,51 @@ assemble at the end from memory is a report that will be wrong about the host th
 If a host fails, **continue to the next one**. A half-rolled-out release that is honestly reported beats
 one that stopped in the middle and said nothing about the four hosts it never reached.
 ### Schema changes, and why `db:push` cannot be trusted
 **`drizzle-kit push` can fail and still exit 0.** Verified on 2026-08-23 against a scratch database: a
 change that violated a foreign key printed the Postgres error, created part of the change, left the rest
 undone, and returned zero. `bun db:push` wraps it, so a plan step that reads `bun db:push` can report
 success while the schema is half-applied.
 So on any release whose plan says the schema changed:
 **Never take the exit code as the answer. Check the database.** Query for the specific thing the plan
 introduced — the table, the column — on that host, against that host's own database. `Changes applied` on
 stdout is not evidence, and neither is exit 0. A report that says "schema ✓" without a query behind it is
 a guess.
 **Some changes cannot go through `db:push` at all, and the plan should say so.** The shape that fails is
 create-then-constrain: a new table plus a foreign key onto it from an existing column. `push` creates the
 table empty and adds the constraint in the same run, so every existing row violates it. There is no
 ordering of `push` invocations that fixes this, because the seed has to happen between the two halves.
 **When the plan says the schema needs direct SQL — last resort, and only when the plan says it.**
 This is allowed and it is not a licence to improvise. The rules, in order:
 1. **The Drizzle schema is the source of truth, always.** The SQL you run exists to make the database match
   what the schema code already says. If you find yourself writing SQL the schema does not describe, stop —
   that is a code change and it is not yours to make on five production hosts at 3am.
 2. **The plan must contain the exact SQL.** Written by whoever cut the release, reviewed before the tag.
   Do not compose it yourself from the diff, and do not adapt it per host: same statements, every host, or
   the fleet has diverged in a way nothing will detect.
 3. **Idempotent, or guarded.** `create table if not exists`, `insert … on conflict do nothing`,
   `alter table … add constraint` only after checking `pg_constraint`. A deploy that is safe to run twice
   is a deploy that can be retried, and being retryable is what stops a partial rollout becoming a
   forensic exercise.
 4. **Then run `bun db:push` anyway**, and expect it to be a no-op. That is the proof the two agree: if
   `push` still wants to change something after your SQL, the SQL was wrong or incomplete, and that is a
   finding for the report rather than something to push past.
 5. **Verify per host, by query**, and put the result in the report per host. Not "applied on all five" —
   the specific check, and its answer, for each.
 6. **A host where the SQL fails is a failed host.** Report it, move to the next, and do not attempt a
   repair you invented.
 **One thing to refuse outright:** `--force`. It exists to answer prompts unattended, and the prompts it
 answers are the destructive ones. On five hosts holding real data, a flag whose whole job is to say yes to
 "this will truncate a table" is not a convenience. If a change needs `--force` to apply, it needs a human.
 ### Skip the host you are running on
 Entirely. Do not pull it, do not restart anything on it, and **name it in the report as skipped**.
@@ -0,0 +1,113 @@
 /*
  Give a credential to every commander that predates them.
  A commander created before `credential.ts` existed has no `officer.env` and no key row, so it cannot
  reach the platform at all — which is the state that made the first one curl the whisper container
  directly. Deleting and recreating it would fix that and throw away the conversation, which is the one
  thing a commander is: a long-running agreement about a job.
  So this is additive and re-runnable:
  - a commander that already has `officer.env` is left alone, whole;
  - `CLAUDE.md` is APPENDED to, never rewritten — it is a living document its commander has been
    extending, and the whole point of not recreating it is that it survives;
  - the key is named `commander:<dirName>`, so it revokes with the commander like any other.
  Run it after a deploy that introduces credentials, on each host:
      bun run --env-file=.env scripts/backfill-commander-credentials.ts
 */
 import { readFileSync, existsSync, appendFileSync, chmodSync } from 'node:fs';
 import { join } from 'node:path';
 import { getUsers, listCommandHqSessions } from 'officerdb';
 import { writeCommanderCredential, commanderEnvPath } from '../src/servers/api/command-hq/credential';
 import { credentialSection, notifySection } from '../src/servers/api/command-hq/directory';
 import { getCommanderDir } from '../src/servers/data-path';
 import { lookupOsUser } from '../src/servers/os-user';
 /** Best effort, and only for a member: the owner already owns everything under DATA_PATH. */
 async function giveToAccount(osUser: string | null, path: string): Promise<void> {
  if (!osUser) return;
  const ids = await lookupOsUser(osUser);
  if (!ids) return;
  Bun.spawnSync(['sudo', '-n', 'chown', `${ids.uid}:${ids.gid}`, path]);
 }
 // Per user, because `listCommandHqSessions` is scoped by one — which is the right shape everywhere else
 // and only awkward here. There are few accounts and few commanders; this runs once per deploy.
 const rows: Array<{
  dirName: string | null;
  name: string | null;
  userId: number;
  email: string;
  osUser: string | null;
 }> = [];
 for (const user of await getUsers()) {
  for (const row of await listCommandHqSessions(user.id)) {
    rows.push({ dirName: row.dirName, name: row.name, userId: user.id, email: user.email, osUser: user.osUser });
  }
 }
 if (rows.length === 0) console.log('no commanders on this host');
 for (const row of rows) {
  const label = `${row.dirName} (${row.name})`;
  if (!row.dirName) {
    console.log(`skip  ${label} — no directory name`);
    continue;
  }
  const dir = getCommanderDir(row.email, row.dirName);
  if (!existsSync(dir)) {
    console.log(`skip  ${label} — no directory on disk`);
    continue;
  }
  /*
    AGENTS.md where it exists, CLAUDE.md where it does not.
    Since 2026-08-27 a commander's brief is written as AGENTS.md with a CLAUDE.md pointing at it, because
    opencode discovers only the first name. Commanders created BEFORE that have the content in CLAUDE.md
    and no AGENTS.md at all. Appending to the wrong one is the quiet failure this avoids: on a new
    commander it would bury a credential section inside a six-line pointer the agent never reads.
  */
  const brief = existsSync(join(dir, 'AGENTS.md')) ? join(dir, 'AGENTS.md') : join(dir, 'CLAUDE.md');
  /**
   * Append a section only when it is not already described.
   *
   * The marker is a string the section itself contains, so a commander whose CLAUDE.md was hand-edited to
   * describe the same thing does not end up with it twice.
   */
  const appendIfMissing = async (marker: string, lines: string[]): Promise<boolean> => {
    const existing = existsSync(brief) ? readFileSync(brief, 'utf8') : '';
    if (existing.includes(marker)) return false;
    appendFileSync(brief, `\n${lines.join('\n')}`);
    await giveToAccount(row.osUser, brief);
    return true;
  };
  const envPath = commanderEnvPath(row.email, row.dirName);
  if (!existsSync(envPath)) {
    const { path } = await writeCommanderCredential({ userId: row.userId, email: row.email, dirName: row.dirName });
    chmodSync(path, 0o600);
    await giveToAccount(row.osUser, path);
    await appendIfMissing('officer.env', credentialSection(path));
    console.log(`MINT  ${label} — ${path}`);
  } else {
    console.log(`ok    ${label} — already has a credential`);
  }
  /*
    Separately, because it arrived later and the commanders that need it most already have a credential.
    Without it a commander does not know Officer HAS a notification route, so it reaches for whatever its
    harness offers — a different channel, with its own rules about when it may interrupt.
  */
  if (await appendIfMissing('/api/notify/_officer/notify', notifySection())) {
    console.log(`NOTIFY ${label} — told how to reach the owner`);
  }
 }
 process.exit(0);
@@ -89,7 +89,7 @@ async function main(): Promise<void> {
  const { PERMISSIONS } = await import('../src/servers/permissions/registry');
  record(
    checkCount(
-      join(ROOT, 'CLAUDE.md'),
+      join(ROOT, 'AGENTS.md'),
      /([0-9]+|[a-z-]+) entries as of/gi,
      PERMISSIONS.length,
      'permission registry entries',
@@ -38,6 +38,16 @@ const KIND_MEANING: Record<string, string> = {
 export async function renderPlatformSkill(): Promise<string> {
  const { PERMISSIONS } = await import('../src/servers/permissions/registry');
  const { SHORTCUT_SECTIONS } = await import('../src/apps/officer-web/state/shortcuts');
  const enCatalog = (await import('../src/apps/officer-web/locales/en-GB.json')).default as Record<string, unknown>;
  /** Resolve a dot-path against the English catalog. This doc is for agents and stays in one language. */
  const enString = (key: string): string => {
    const value = key.split('.').reduce<unknown>((node, part) => {
      if (node && typeof node === 'object') return (node as Record<string, unknown>)[part];
      return undefined;
    }, enCatalog);
    if (typeof value !== 'string') throw new Error(`gen-platform-skill: no English string for "${key}"`);
    return value;
  };
  const byKind = new Map<string, typeof PERMISSIONS>();
  for (const p of PERMISSIONS) {
@@ -112,14 +122,16 @@ export async function renderPlatformSkill(): Promise<string> {
  out('Derived from `src/apps/officer-web/state/shortcuts.ts`. These have moved several times; quote this');
  out('list rather than remembering one.');
  out();
  // The registry holds catalog keys since the shell was localized; this doc is agent-facing and stays
  // English, so it resolves against en-GB rather than the reader's locale.
  for (const section of SHORTCUT_SECTIONS) {
-    out(`## ${section.title}`);
+    out(`## ${enString(section.titleKey)}`);
-    if (section.note) {
+    if (section.noteKey) {
      out();
-      out(section.note);
+      out(enString(section.noteKey));
    }
    out();
-    for (const s of section.shortcuts) out(`- \`${s.keys}\` — ${s.description}`);
+    for (const s of section.shortcuts) out(`- \`${s.keys}\` — ${enString(s.descriptionKey)}`);
    out();
  }
@@ -0,0 +1,292 @@
 #!/usr/bin/env bun
 /**
 * Counts candidate hardcoded user-facing strings in the web UI.
 *
 * Two jobs. It sizes the localization work (docs/localization.md quotes its output), and once an area
 * reaches zero it becomes the guard that stops the debt coming back — see ZEROED below.
 *
 * It is a heuristic and it is deliberately a FLOOR. It cannot see multi-line JSX text, ternaries
 * inside JSX, strings passed down as props, or anything a plugin renders. A falling number means
 * progress; a zero means "nothing this scanner can see", not "nothing left".
 *
 *   bun scripts/i18n/scan-hardcoded.ts            # summary by area
 *   bun scripts/i18n/scan-hardcoded.ts --files    # worst files first
 *   bun scripts/i18n/scan-hardcoded.ts --list ui.button   # print the strings themselves
 *   bun scripts/i18n/scan-hardcoded.ts --check    # non-zero exit if a zeroed area regressed
 */
 import { readdirSync, readFileSync, statSync } from 'node:fs';
 import { join } from 'node:path';
 const AREAS = [
  { label: 'officer-web (shell)', root: 'src/apps/officer-web' },
  { label: 'officerdev (panels)', root: 'src/workspaces/officerdev/src' },
  { label: 'shared components', root: 'src/workspaces/components' },
 ] as const;
 /**
 * Areas that have been converted and must stay converted. Add an area here the moment it reaches
 * zero — enabling every area on day one would just be red for weeks and get ignored.
 *
 * 'shared components' landed 2026-08-23 (localization phase 1). It holds three `new Error()` messages
 * that must NEVER be translated; they are reported but excluded from the check, which is why the
 * neverTranslate split below has to exist for this entry to be possible at all.
 *
 * 'officer-web (shell)' landed 2026-08-23 (phase 2). It holds no never-translate hits of its own; what it
 * does hold is ~30 `<Untranslated reason="foreign-ui-label">` labels quoted from Google's console, which
 * `stripUntranslated` skips for the same reason.
 *
 * 'officerdev (panels)' landed 2026-08-23 (phase 3). It holds nine `new Error()` messages for whoever is
 * reading a terminal, not a user — same never-translate shape as 'shared components'. Two more strings
 * are marked `i18n-exempt` rather than never-translate: `useTaskRunner.ts`'s "Running:"/"Error:" framing
 * is interleaved with raw stdout/stderr inside one monospace `<pre>` feed, so translating the frame alone
 * would read as broken mid-buffer — the same reasoning as the never-translate list, reached by a
 * different mechanism because it's not a thrown Error.
 */
 const ZEROED: string[] = ['shared components', 'officer-web (shell)', 'officerdev (panels)'];
 const SKIP = /node_modules|\.gen\.|[/\\]locales[/\\]|[/\\]vendor[/\\]|\.test\.|\.d\.ts$/;
 // A quoted literal, single or double. Kept as two groups because JS has no branch reset.
 const Q = String.raw`(?:"([^"\n]{2,120})"|'([^'\n]{2,120})')`;
 /**
 * `neverTranslate` marks a category the doc's "What must never be translated" list forbids converting —
 * so it is reported (an agent should see it and confirm), but excluded from `--check`.
 *
 * Without that split the guard is unusable: an area holding one legitimate `new Error()` can never
 * reach zero, so it could never be added to ZEROED, so the debt guard could never be switched on for
 * it. Counting work that must NOT be done against a target of zero makes the target unreachable.
 */
 const PATTERNS: { kind: string; rx: RegExp; neverTranslate?: true }[] = [
  // >Some visible words<
  //
  // The lookbehind rejects `=>`, so an arrow return type does not read as JSX text: `(id: string) =>
  // Promise<unknown>` was reported as the string "Promise".
  { kind: 'jsx text', rx: /(?<!=)>\s*([A-Z][A-Za-z0-9][^<>{}\n]{2,100}?)\s*</g },
  // placeholder="..." and friends
  {
    kind: 'attributes',
    rx: new RegExp(
      String.raw`\b(?:placeholder|title|aria-label|alt|label|description|tooltip|emptyMessage)\s*=\s*` + Q,
      'g',
    ),
  },
  { kind: 'toast/alert', rx: new RegExp(String.raw`\b(?:toast(?:\.\w+)?|alert|confirm)\s*\(\s*` + Q, 'g') },
  // label: 'Status' — nav items, menus, table columns. The largest hidden category.
  {
    kind: 'object labels',
    rx: new RegExp(
      String.raw`\b(?:label|name|title|heading|placeholder|description|tooltip|emptyText)\s*:\s*` + Q,
      'g',
    ),
  },
  // Thrown Errors are for whoever is reading a terminal at 4am. They stay in one language.
  //
  // Matches a template literal as well as a quoted one: `new Error(\`Whisper returned ${res.status}\`)`
  // was falling through to `template str` and so counted as convertible, which is the opposite of true.
  {
    kind: 'thrown errors',
    rx: new RegExp(String.raw`new Error\(\s*(?:` + Q + String.raw`|\`([^\`]{2,120})\`)`, 'g'),
    neverTranslate: true,
  },
  // `Failed to create ${kind}` — needs interpolation, so it costs more to convert.
  //
  // The lookbehind hands a thrown Error to the category above instead of counting it here as well: a
  // string matched by two patterns is counted twice, and it stayed convertible, so the area could never
  // reach zero however it was treated.
  { kind: 'template str', rx: /(?<!new Error\()`([A-Z][^`\n]{4,100}\$\{[^`]*)`/g },
 ];
 /** Filters out ids, class names, paths, mime types and SCREAMING_CONSTANTS. */
 function isHuman(value: string | undefined): value is string {
  if (!value) return false;
  const s = value.trim();
  if (s.length < 3) return false;
  if (!/[A-Za-z]{3}/.test(s)) return false;
  if (/^[a-z0-9\-_./:]+$/.test(s)) return false;
  if (/^(https?:|\/|#|data:|application\/|image\/)/.test(s)) return false;
  // Allows . and - so credential-format examples like `GOCSPX-...` fall under the same rule.
  if (/^[A-Z0-9_.-]+$/.test(s)) return false;
  // A namespaced storage or channel key: an ALL-CAPS prefix, then a separator, then an interpolation —
  // `FULLSCREEN_PANEL:${workspace.key}`. The SCREAMING_CONSTANT rule above misses it because the
  // interpolated half is lowercase.
  if (/^[A-Z0-9_]{3,}[.:/-]/.test(s)) return false;
  // `Bearer ${token}` is an Authorization header value, not a sentence. Caught by the template-string
  // pattern because it starts with a capital and interpolates; excluded here because an auth scheme
  // followed by a credential is never something a person reads.
  if (/^(Bearer|Basic|Token|Digest)\s/.test(s)) return false;
  // A single token carrying digits AND punctuation is a name, not a sentence — the OCR section's
  // placeholder is the example model file `Qwen2.5-VL-7B-Instruct-q4_k_m.gguf`. Prose has spaces; the
  // whitespace test is what keeps this from eating real one-word labels, which never look like this.
  if (!/\s/.test(s) && /\d/.test(s) && /[-_.]/.test(s)) return false;
  // Tailwind, reached via a `description:`/`label:` key in a classNames object — e.g. sonner's
  // `description: 'group-[.toast]:text-muted-foreground'`.
  //
  // The test is per TOKEN, not on the whole string: every space-separated token must look like a
  // utility (all lowercase, no sentence punctuation) and at least one must carry a variant colon or
  // an arbitrary-value bracket. Testing the whole string instead cost a real label — "Application
  // type:" was filtered because it ends in a colon, which is also how prose introduces a value.
  const tokens = s.split(/\s+/);
  const utilityish = (tok: string) => /^[a-z0-9:_\-[\]().#&/%!]+$/.test(tok);
  if (tokens.every(utilityish) && tokens.some((tok) => /[:[]/.test(tok))) return false;
  return true;
 }
 /**
 * Commented-out code is not user-facing text. `Header.tsx` carries a disabled dev-console button inside
 * a `{/* … *\/}` block, and counting it means the area can never reach zero without editing a comment.
 *
 * Deliberately only two shapes, both unambiguous: a block comment, and a line whose first non-space
 * characters are `//`. Stripping every `//` would eat the tail of any string holding a URL.
 */
 const stripComments = (source: string): string =>
  source.replace(/\/\*[\s\S]*?\*\//g, '').replace(/^[ \t]*\/\/.*$/gm, '');
 /**
 * `<code>`, `<kbd>`, `<pre>` and `<samp>` mark content as code rather than prose — that is what the
 * elements are for. `<code>Authorization: Bearer …</code>` is an HTTP header, which the doc's
 * never-translate list covers as an identifier crossing a boundary, and translating it would break the
 * thing it documents.
 */
 const stripCodeElements = (source: string): string =>
  source.replace(/<(code|kbd|pre|samp)\b[^>]*>[\s\S]*?<\/\1>/g, '<$1/>');
 /**
 * An explicit, per-line opt-out: `// i18n-exempt: <reason>` exempts the NEXT line.
 *
 * For the cases no syntactic rule can reach — chiefly a prompt written for a model rather than a
 * reader. `<Untranslated>` covers JSX; this covers the rest, and the two together mean the scanner does
 * not need another heuristic every time a new shape of never-translate string turns up.
 *
 * A reason is mandatory: the regex will not match a bare `// i18n-exempt`. That is the whole safeguard —
 * somebody has to write down why, and `grep -rn "i18n-exempt"` lists every one for review.
 */
 const stripExemptLines = (source: string): string => {
  const lines = source.split('\n');
  return lines.map((line, i) => (/\/\/\s*i18n-exempt:\s*\S/.test(lines[i - 1] ?? '') ? '' : line)).join('\n');
 };
 /**
 * `<Untranslated reason="…">` marks text that must stay in one language — today, a label quoted from
 * another product's UI, which docs/localization.md classifies as an identifier.
 *
 * Skipped for the same reason `neverTranslate` categories are excluded from `--check`: counting work the
 * doc FORBIDS doing against a target of zero makes the target unreachable. The marker is explicit and
 * carries a reason, so this cannot become a quiet catch-all — unlike a heuristic, somebody has to write
 * it and say why.
 */
 const stripUntranslated = (source: string): string =>
  source.replace(/<Untranslated\b[^>]*>[\s\S]*?<\/Untranslated>/g, '<Untranslated/>');
 function* walk(dir: string): Generator<string> {
  let entries: string[];
  try {
    entries = readdirSync(dir);
  } catch {
    return;
  }
  for (const entry of entries) {
    const path = join(dir, entry);
    if (SKIP.test(path)) continue;
    let isDir = false;
    try {
      isDir = statSync(path).isDirectory();
    } catch {
      continue;
    }
    if (isDir) yield* walk(path);
    else if (path.endsWith('.tsx') || path.endsWith('.ts')) yield path;
  }
 }
 type Hit = { kind: string; value: string; file: string };
 function scan(root: string): { files: number; hits: Hit[] } {
  const hits: Hit[] = [];
  let files = 0;
  for (const file of walk(root)) {
    files++;
    let source: string;
    try {
      // Exempt lines go FIRST: stripComments would remove the marker they depend on.
      source = stripUntranslated(stripCodeElements(stripComments(stripExemptLines(readFileSync(file, 'utf8')))));
    } catch {
      continue;
    }
    for (const { kind, rx } of PATTERNS) {
      rx.lastIndex = 0;
      for (const match of source.matchAll(rx)) {
        const value = match.slice(1).find((group) => group !== undefined);
        if (isHuman(value)) hits.push({ kind, value: value.trim(), file });
      }
    }
  }
  return { files, hits };
 }
 const args = new Set(process.argv.slice(2));
 const listPrefix = process.argv.includes('--list') ? process.argv[process.argv.indexOf('--list') + 1] : undefined;
 const results = AREAS.map((area) => ({ ...area, ...scan(area.root) }));
 const kinds = PATTERNS.map((p) => p.kind);
 const pad = (s: string | number, n: number) => String(s).padStart(n);
 console.log(
  `${'area'.padEnd(22)} ${pad('files', 5)} ${kinds.map((k) => pad(k.slice(0, 13), 14)).join('')} ${pad('total', 7)}`,
 );
 for (const r of results) {
  const byKind = kinds.map((k) => pad(r.hits.filter((h) => h.kind === k).length, 14)).join('');
  console.log(`${r.label.padEnd(22)} ${pad(r.files, 5)} ${byKind} ${pad(r.hits.length, 7)}`);
 }
 const all = results.flatMap((r) => r.hits);
 const distinct = new Set(all.map((h) => h.value));
 const interpolated = new Set(all.filter((h) => h.kind === 'template str').map((h) => h.value));
 const NEVER_KINDS = new Set(PATTERNS.filter((p) => p.neverTranslate).map((p) => p.kind));
 const convertible = (hits: Hit[]) => hits.filter((h) => !NEVER_KINDS.has(h.kind));
 console.log(
  `${'TOTAL'.padEnd(22)} ${pad(
    results.reduce((n, r) => n + r.files, 0),
    5,
  )} ${kinds.map((k) => pad(all.filter((h) => h.kind === k).length, 14)).join('')} ${pad(all.length, 7)}`,
 );
 console.log();
 console.log(`occurrences        ${all.length}`);
 console.log(`  convertible      ${convertible(all).length}`);
 console.log(`  never-translate  ${all.length - convertible(all).length}  (${[...NEVER_KINDS].join(', ')})`);
 console.log(`distinct strings   ${distinct.size}`);
 console.log(`  needing params   ${interpolated.size}`);
 if (args.has('--files')) {
  console.log('\nworst files:');
  const perFile = new Map<string, number>();
  for (const h of all) perFile.set(h.file, (perFile.get(h.file) ?? 0) + 1);
  for (const [file, n] of [...perFile].sort((a, b) => b[1] - a[1]).slice(0, 25)) {
    console.log(`  ${pad(n, 4)}  ${file}`);
  }
 }
 if (listPrefix) {
  console.log(`\nstrings in files matching "${listPrefix}":`);
  for (const h of all.filter((x) => x.file.includes(listPrefix))) console.log(`  [${h.kind}] ${h.value}`);
 }
 if (args.has('--check')) {
  const regressed = results
    .filter((r) => ZEROED.includes(r.label))
    .map((r) => ({ label: r.label, hits: convertible(r.hits) }))
    .filter((r) => r.hits.length > 0);
  if (regressed.length > 0) {
    console.error('\nThese areas were converted and have regressed:');
    for (const r of regressed) {
      console.error(`  ${r.label}: ${r.hits.length} hardcoded strings`);
      for (const h of r.hits) console.error(`    [${h.kind}] ${h.value}  — ${h.file}`);
    }
    console.error('\nUse a catalog key. See docs/localization.md.');
    process.exit(1);
  }
  console.log(`\ncheck: ok (${ZEROED.length} area(s) held at zero)`);
 }
@@ -66,7 +66,19 @@ const git = (dir: string, args: string[]): string | null => {
  return new TextDecoder().decode(result.stdout).trim() || null;
 };
-const PLUGINS_DIR = resolve(import.meta.dir, '..', 'plugins');
+/*
  Which plugins directory to publish FROM.
  There are two, and they are not the same thing. `platform/plugins/` holds what this machine has
  INSTALLED — updated by `plugins:update`, which is a git pull, and therefore always at whatever version
  was last installed. `officer-dev/plugins/` holds every repo in the org, cloned for working on, and is
  where a release is actually made.
  Publishing from the install directory means the catalogue advertises the version this machine happens
  to be running rather than the version that was released. That is exactly what happened on 2026-08-27:
  21 plugins were tagged and the store went on showing 1.0.0.
 */
 const PLUGINS_DIR = process.env.PLUGINS_DIR ?? resolve(import.meta.dir, '..', 'plugins');
 async function syncOne(dir: string): Promise<Sync | null> {
  const appName = basename(dir);
@@ -109,6 +121,11 @@ async function syncOne(dir: string): Promise<Sync | null> {
    platform: String(manifest.platform ?? '>=1.0.0'),
    label: String(manifest.label ?? appName),
    summary: String(manifest.summary ?? ''),
    // Taken verbatim, NOT validated here. `manifestProblems` already refuses a tag outside the
    // vocabulary at discovery, so anything reaching this point is either valid or belongs to a plugin
    // the platform would not load anyway — and a sync that silently dropped a tag would be a catalogue
    // quietly disagreeing with the repository it claims to mirror.
    tags: Array.isArray(manifest.tags) ? manifest.tags : [],
    color: (manifest.color as string) ?? null,
    tile: (manifest.tile as string) ?? null,
    // Artwork lives in the repo, so the URL is built from the remote rather than stored by hand. Only
@@ -6,13 +6,25 @@
 *   bun run notify:test --user 2                 # someone else
 *   bun run notify:test --code officer/core:job --id 412
 *
- * Talks to the sidecar over loopback, which is how every other producer reaches it — so this exercises
+ * Goes through the PLATFORM, with a key it mints and revokes for the one send — the same door an app or
- * the real path rather than a special one. It reports what the channels actually did, because the thing
+ * a commander uses, so this exercises the real path rather than a special one. It reports what the
- * that wastes a day here is that a send with nothing configured returns success and delivers nothing.
+ * channels actually did, because the thing that wastes a day here is that a send with nothing configured
 * returns success and delivers nothing.
 *
 * It used to POST to the sidecar directly on loopback. That stopped working on 2026-08-25, when the
 * sidecar began requiring proof that the platform is the caller — anything on the machine could otherwise
 * notify any user, which on a box running agents is anything with a shell. The secret lives only in the
 * server's memory, so a CLI cannot present it and should not be able to.
 *
 * Minting a key is legitimate HERE and nowhere else: this runs as the owner, on the owner's machine, with
 * the database open in front of it. Anything that cannot already do that has no business sending either.
 */
 import { readFileSync } from 'node:fs';
 import { join } from 'node:path';
 import { DATA_PATH } from '../src/servers/data-path';
 import { mintApiKey } from '../src/servers/auth-token';
 import { createApiKey, revokeApiKeysByName } from 'officerdb';
 import { PORT, OFFICER_API_URL } from '../src/servers/officer-url.mjs';
 const arg = (name: string): string | undefined => {
  const i = process.argv.indexOf(`--${name}`);
@@ -69,12 +81,37 @@ const body = {
 console.log(`[notify:test] sending ${JSON.stringify(body)}`);
-const res = await fetch(`${base}/_officer/notify`, {
+// A key for this one send, revoked immediately afterwards whatever happens. Named so a leftover from a
 // killed run is obvious in the key list rather than looking like something a person made.
 const KEY_NAME = 'notify:test (temporary)';
 await revokeApiKeysByName(userId, KEY_NAME).catch(() => {});
 const { secret, keyHash, prefix } = mintApiKey();
 await createApiKey({ userId, name: KEY_NAME, keyHash, prefix });
 const publicHost = (() => {
  try {
    return process.env.PUBLIC_URL ? new URL(process.env.PUBLIC_URL.replace(/^"|"$/g, '')).host : undefined;
  } catch {
    return undefined;
  }
 })();
 let res: Response;
 try {
  res = await fetch(`${OFFICER_API_URL}/api/notify/_officer/notify`, {
    method: 'POST',
-  headers: { 'content-type': 'application/json', 'X-Officer-User': String(userId) },
+    headers: {
      'content-type': 'application/json',
      Authorization: `Bearer ${secret}`,
      // Origin validation matches Host against PUBLIC_URL, so a bare loopback request is refused.
      Host: publicHost ?? `127.0.0.1:${PORT}`,
    },
    body: JSON.stringify(body),
    signal: AbortSignal.timeout(20_000),
-});
+  });
 } finally {
  await revokeApiKeysByName(userId, KEY_NAME).catch(() => {});
 }
 const out = (await res.json()) as { ok?: boolean; error?: string; results?: Array<Record<string, unknown>> };
@@ -0,0 +1,161 @@
 /*
  Is every plugin checkout still a well-formed clone of its own repository?
  ── Why a script and not care ──
  On 2026-08-27 one commit had to go into all twenty-one plugin repos. Seven pushes failed, each for a
  different reason, and none of the reasons had anything to do with the commit:
    · six remotes were HTTPS, which cannot authenticate non-interactively — they simply hung and failed
    · three checkouts were behind their published remote, so the push was rejected as non-fast-forward
    · one (`offscale`) had a fetch refspec and an upstream naming a branch called `main` that does not
      exist on the remote. That one is the reason this file exists: every command reported on a phantom.
      `git push` said "Everything up-to-date" while `git status` said the branch had diverged, and the
      repository was actually fine. Twenty minutes went into a repo with nothing wrong with it.
    · one remote URL had no `.git` suffix, so the catalogue published a clone URL unlike every other
  None of that is visible until you try to push, which is the worst possible moment to find out — you are
  mid-task, across twenty-one repositories, and the failures look like they are about your change.
  ── What it checks, and what it deliberately does not ──
  Only mechanical facts with one right answer: the remote's URL form, the fetch refspec, the branch, its
  upstream, and whether the checkout has diverged. It does not judge content, does not fetch by default
  (that would make a local check depend on the network), and never writes — `--fix` is a separate flag so
  that running the check can never be the thing that changes your tree.
 */
 import { readdirSync, existsSync, statSync } from 'node:fs';
 import { join } from 'node:path';
 /*
  Which plugins directory to check.
  There are two as of 2026-08-27: `platform/plugins/` — what this machine has INSTALLED — and
  `officer-dev/plugins/`, every repo in the org cloned side by side for working on. They hold different
  sets, so the check has to be pointable at either rather than assuming the one it happens to sit next to.
 */
 const PLUGINS_DIR = process.env.PLUGINS_DIR ?? join(import.meta.dir, '..', 'plugins');
 const HOST = 'git@gitea.officer.dev';
 const BRANCH = 'master';
 const REFSPEC = '+refs/heads/*:refs/remotes/origin/*';
 const FIX = process.argv.includes('--fix');
 const FETCH = process.argv.includes('--fetch');
 const git = (dir: string, args: string[]): string | null => {
  const p = Bun.spawnSync(['git', '-C', dir, ...args], { stdout: 'pipe', stderr: 'pipe' });
  return p.exitCode === 0 ? p.stdout.toString().trim() : null;
 };
 type Problem = { plugin: string; what: string; fix?: () => void };
 const problems: Problem[] = [];
 const dirs = readdirSync(PLUGINS_DIR, { withFileTypes: true })
  // `statSync().isDirectory()`, not the dirent's — a Dirent for a SYMLINK to a directory answers false to
  // `isDirectory()` and true to `isSymbolicLink()`, so filtering on the dirent silently skips every
  // symlinked plugin. `platform/plugins/` is symlinks into the workspace clones since 2026-08-27, which
  // would have made this report "0 plugin repositories, all well-formed" — a green check over nothing.
  // `discover.ts` already does it this way, at line 239, for the same reason.
  .filter((e) => !e.name.startsWith('.') && e.name !== 'node_modules')
  .filter((e) => {
    try {
      return statSync(join(PLUGINS_DIR, e.name)).isDirectory();
    } catch {
      return false; // a broken symlink, which the checks below have nothing useful to say about
    }
  })
  .map((e) => e.name)
  .filter((name) => existsSync(join(PLUGINS_DIR, name, '.git')))
  .sort();
 /*
  A repo with no `manifest.ts` is not a plugin, and that is not drift.
  `av-club` is the case: a standalone media service living in the plugins org, intended to become a
  plugin in time. Checking it against a plugin's conventions would report its branch name as a defect
  forever, and a check that cries wolf is one people stop reading.
  Presence is the declaration here exactly as it is in `plugins/discover.ts` — the manifest is what makes
  something a plugin, so its absence is what makes something not one yet.
 */
 const notYet = dirs.filter((name) => !existsSync(join(PLUGINS_DIR, name, 'manifest.ts')));
 const checkable = dirs.filter((name) => !notYet.includes(name));
 for (const name of checkable) {
  const dir = join(PLUGINS_DIR, name);
  const expected = `${HOST}:plugins/${name}.git`;
  // 1. The remote, exactly. SSH because that is what can push unattended, and `.git` because a URL unlike
  //    every other is the one an installer trips over.
  const url = git(dir, ['remote', 'get-url', 'origin']);
  if (url !== expected) {
    problems.push({
      plugin: name,
      what: `remote is ${url ?? 'missing'}, expected ${expected}`,
      fix: () => void git(dir, ['remote', 'set-url', 'origin', expected]),
    });
  }
  // 2. The fetch refspec. A narrowed one (a --single-branch clone) hides every other branch; a WRONG one
  //    makes git report on a branch that does not exist, which is the failure that cost the most time.
  const refspecs = (git(dir, ['config', '--get-all', 'remote.origin.fetch']) ?? '').split('\n').filter(Boolean);
  if (refspecs.length !== 1 || refspecs[0] !== REFSPEC) {
    problems.push({
      plugin: name,
      what: `fetch refspec is ${refspecs.join(' + ') || 'unset'}, expected ${REFSPEC}`,
      fix: () => {
        git(dir, ['config', '--unset-all', 'remote.origin.fetch']);
        git(dir, ['config', '--add', 'remote.origin.fetch', REFSPEC]);
      },
    });
  }
  // 3. The branch, and what it tracks.
  const branch = git(dir, ['rev-parse', '--abbrev-ref', 'HEAD']);
  if (branch !== BRANCH) {
    problems.push({ plugin: name, what: `on branch ${branch ?? '?'}, expected ${BRANCH}` });
    continue; // the checks below are all about this branch
  }
  const upstream = git(dir, ['config', '--get', `branch.${BRANCH}.merge`]);
  if (upstream !== `refs/heads/${BRANCH}`) {
    problems.push({
      plugin: name,
      what: `${BRANCH} tracks ${upstream ?? 'nothing'}, expected refs/heads/${BRANCH}`,
      fix: () => void git(dir, ['branch', `--set-upstream-to=origin/${BRANCH}`, BRANCH]),
    });
  }
  // 4. Uncommitted work, and divergence. Not fixable here — both need a human decision about the content.
  const dirty = git(dir, ['status', '--porcelain']);
  if (dirty) problems.push({ plugin: name, what: `${dirty.split('\n').length} uncommitted file(s)` });
  if (FETCH) git(dir, ['fetch', '-q', 'origin']);
  const counts = git(dir, ['rev-list', '--left-right', '--count', `origin/${BRANCH}...HEAD`]);
  if (counts) {
    const [behind, ahead] = counts.split(/\s+/).map(Number);
    if (behind) problems.push({ plugin: name, what: `${behind} commit(s) behind origin/${BRANCH}` });
    if (ahead) problems.push({ plugin: name, what: `${ahead} commit(s) NOT PUSHED` });
  }
 }
 const skipped = notYet.length ? `  (${notYet.length} not a plugin yet: ${notYet.join(', ')})` : '';
 if (!problems.length) {
  console.log(`plugins:check — ${checkable.length} plugin repositories, all well-formed${skipped}`);
  process.exit(0);
 }
 for (const p of problems) console.error(`  ${p.plugin}: ${p.what}`);
 if (FIX) {
  const fixable = problems.filter((p) => p.fix);
  for (const p of fixable) p.fix!();
  console.error(`\nplugins:check --fix — repaired ${fixable.length} of ${problems.length}; re-run to confirm.`);
  console.error('Divergence and uncommitted work are never repaired here: both need a decision about content.');
 } else {
  console.error(
    `\nplugins:check — ${problems.length} problem(s). \`bun run plugins:check --fix\` repairs the mechanical ones.`,
  );
 }
 process.exit(1);
@@ -0,0 +1,67 @@
 /**
 * Seed the `roles` table with the roles the platform's own code names.
 *
 * Runs from `postdb:push`, so every machine gets the rows on its next schema push rather than needing a
 * per-server step in a deploy plan. Bun fires `pre`/`post` hooks for colon-named scripts — the same
 * mechanism `backfill-session-models.ts` relies on.
 *
 * ── Why these four are `isSystem` ──
 *
 * Each is named by name somewhere in the code: this file matches `'Developer'`, `'Admin'` and `'Member'`
 * by name on every run, and `bootstrap.ts` writes `'Super Admin'`. Renaming or deleting one of those is not
 * a data change, it is a code change that has not happened — so the flag exists for the delete and rename
 * paths to refuse on, rather than for the failure to turn up later as a missing database role or an
 * account that cannot log in.
 *
 * ── `description` versus `grantsPostgres`/`grantsDocker` ──
 *
 * `seedRole` treats these two kinds of column differently, and it matters here specifically because this
 * is the one caller that seeds `isSystem: true` rows. `description` is written once, on insert, and never
 * touched again — an edit made on one server must not be reverted by the next deploy. `grantsPostgres` and
 * `grantsDocker` ARE re-asserted every run for a system role, because they are not the operator's data,
 * they are what "Developer" MEANS — the same standing as the name itself. `rolePermitsDevTools()` used to
 * be that declaration, hardcoded as `role === 'Developer'`; this table is where it lives now, and this
 * SEED array is the only place either flag is set for these four roles. See `seedRole`'s own comment in
 * `officer_db/src/roles/queries.ts` for the mechanics.
 *
 * ── What this deliberately does NOT do ──
 *
 * Never overwrite `description`, as above. And never touch a CUSTOM role's grants — those are set through
 * `PATCH /api/roles/:name/grants` (`setRoleGrants`), which itself refuses to touch a system role for the
 * mirror-image reason: writing there would look like it worked and then silently revert on the next run of
 * this script.
 */
 import { seedRole, waitForDatabase } from '../src/databases/officer_db/src/index';
 type SeedRoleEntry = { name: string; description: string; grantsPostgres?: boolean; grantsDocker?: boolean };
 // Match today's behaviour exactly: only Developer passed `rolePermitsDevTools` before this table existed,
 // so Developer is the only role seeded with either flag true.
 const SEED: SeedRoleEntry[] = [
  { name: 'Super Admin', description: 'Full authority over the platform, and an OS account with sudo' },
  { name: 'Admin', description: 'Administers the platform. No operating-system privilege' },
  {
    name: 'Developer',
    description: 'A member who is also trusted with developer tooling on the machine',
    grantsPostgres: true,
    grantsDocker: true,
  },
  { name: 'Member', description: 'The default. Reaches only what their role has been granted' },
 ];
 async function main(): Promise<void> {
  await waitForDatabase();
  let created = 0;
  for (const role of SEED) {
    if (await seedRole({ ...role, isSystem: true })) created += 1;
  }
  console.log(`[seed:roles] ${created} seeded, ${SEED.length - created} already present (of ${SEED.length})`);
 }
 // Never fatal. This runs from a `post` hook after a schema push, and a seed that cannot write must not make
 // a successful push look like a failed one — the rows are additive and the next push tries again.
 main()
  .catch((err: unknown) => {
    console.error('[seed:roles] could not seed:', err instanceof Error ? err.message : err);
  })
  .finally(() => process.exit(0));
@@ -100,6 +100,11 @@ fail() {
 ANSWERS_FILE="${ANSWERS_FILE:-}"
 # DOCKER_NETWORK included so officer-setup's Proxy step lands on the SAME bridge Docker
 # was told to use here, rather than each script independently defaulting to "services" and
 # happening to agree only because nobody has customised either yet. lib/docker.sh sets
 # DOCKER_NETWORK at source time (SETUP_DOCKER_NETWORK env var, else "services"), so it is
 # always defined by the time this runs, regardless of whether the Docker step itself ran.
 save_answers() {
  [[ -n "$ANSWERS_FILE" ]] || return 0
  cat >"$ANSWERS_FILE" <<EOF
@@ -107,6 +112,7 @@ save_answers() {
 MACHINE_ROLE=${MACHINE_ROLE}
 SETUP_USERNAME=${USERNAME}
 OFFICER_ROOT=${OFFICER_ROOT}
 SETUP_DOCKER_NETWORK=${DOCKER_NETWORK}
 EOF
  chmod 600 "$ANSWERS_FILE"
 }
@@ -165,25 +171,39 @@ ONLY_STEP="${ONLY_STEP:-}"
 # Keyed on the step title, so the sections themselves stay Linux code with no
 # `if macos` branches threaded through them. The reason is printed, because a
 # silent skip and a missing step look identical.
-declare -A MACOS_SKIP=(
+#
-  ["User account"]="accounts are System Settings' business on a Mac, not a script's"
+# A `case` rather than an associative array — `declare -A` is bash 4+, and macOS's own
-  ["Disk space"]="ballast and swap tuning are server concerns"
+# stock `/bin/bash` is 3.2 (Apple hasn't shipped a newer one since bash went GPLv3), with
-  ["Locale"]="macOS manages locale itself"
+# nothing newer installed on a fresh machine. An array keyed on the step title would parse-
-  ["Timezone"]="macOS manages the timezone itself"
+# fail the instant this file is sourced, before a single step could run — which is exactly
-  ["Swap"]="macOS sizes its own swap dynamically"
+# what happened here until it was measured. Prints the reason on stdout, so the caller reads
-  ["Emergency disk ballast"]="a server trick for a machine nobody is sitting at"
+# it with `$(...)`; exit status says whether the title matched anything at all.
-  ["earlyoom"]="Linux OOM killer tuning; macOS has its own memory pressure handling"
+macos_skip_reason() {
-  ["inotify watch limit"]="Linux inotify; macOS watches files through FSEvents"
+  case "$1" in
-  ["Sleep and suspend"]="a laptop SHOULD sleep — this stops a server from doing it"
+    "User account") echo "accounts are System Settings' business on a Mac, not a script's" ;;
-  ["Boot hang"]="a systemd boot ordering fix"
+    "Disk space") echo "ballast and swap tuning are server concerns" ;;
-  ["SSH access"]="hardening a door a dev machine should not be opening"
+    "Locale") echo "macOS manages locale itself" ;;
-  ["DNS"]="systemd-resolved"
+    "Timezone") echo "macOS manages the timezone itself" ;;
-  ["Network address"]="netplan, and a laptop moves between networks by design"
+    "Swap") echo "macOS sizes its own swap dynamically" ;;
-  ["fail2ban"]="brute-force protection for an exposed SSH port"
+    "Emergency disk ballast") echo "a server trick for a machine nobody is sitting at" ;;
-  ["Unattended upgrades"]="apt; macOS updates through Software Update"
+    "earlyoom") echo "Linux OOM killer tuning; macOS has its own memory pressure handling" ;;
-  ["Firewall"]="ufw; macOS has its own application firewall"
+    "inotify watch limit") echo "Linux inotify; macOS watches files through FSEvents" ;;
-  ["Shell"]="zsh is already the default, and tmux is a choice you make yourself"
+    "Sleep and suspend") echo "a laptop SHOULD sleep — this stops a server from doing it" ;;
-)
+    "Boot hang") echo "a systemd boot ordering fix" ;;
    "SSH access") echo "hardening a door a dev machine should not be opening" ;;
    "DNS") echo "systemd-resolved" ;;
    "Network address") echo "netplan, and a laptop moves between networks by design" ;;
    "fail2ban") echo "brute-force protection for an exposed SSH port" ;;
    "Unattended upgrades") echo "apt; macOS updates through Software Update" ;;
    "Firewall") echo "ufw; macOS has its own application firewall" ;;
    "Shell") echo "zsh is already the default, and tmux is a choice you make yourself" ;;
    *) return 1 ;;
  esac
 }
 # `${var,,}` (case-insensitive compare below) is bash 4+ too — this is the portable
 # pre-4 substitute, not a style choice.
 lower() { tr '[:upper:]' '[:lower:]' <<<"$1"; }
 step() {
  CURRENT_STEP="$1"
@@ -191,16 +211,19 @@ step() {
  # which one it is. Twenty-six sections, one place.
  declare -F report_section >/dev/null && report_section "$1"
-  if [[ "${OS:-}" == "macos" && -n "${MACOS_SKIP[$1]:-}" ]]; then
+  if [[ "${OS:-}" == "macos" ]]; then
    local _skip_reason
    if _skip_reason="$(macos_skip_reason "$1")"; then
      echo ""
      echo -e "${BOLD}── $1 ──${NC}"
-    echo -e "   ${GREEN}SKIP${NC}: not on macOS — ${MACOS_SKIP[$1]}"
+      echo -e "   ${GREEN}SKIP${NC}: not on macOS — ${_skip_reason}"
      SKIP_STEP=true
      return
    fi
  fi
  if [[ -n "$ONLY_STEP" ]]; then
-    if [[ "${1,,}" == "${ONLY_STEP,,}" ]]; then
+    if [[ "$(lower "$1")" == "$(lower "$ONLY_STEP")" ]]; then
      SKIP_STEP=false
      echo ""
      echo -e "${BOLD}── $1 ──${NC}"
@@ -508,6 +531,24 @@ ask_officer_root() {
 # both of which abort the step.
 user_group() { id -gn "${1:-$USERNAME}" 2>/dev/null || echo "${1:-$USERNAME}"; }
 # Run a command as the created account, e.g. `run_as_owner git clone ...`.
 #
 # On Linux this whole script runs as root — refused otherwise, see the pre-flight check
 # above — so `sudo -u "$USERNAME"` from root needs no password; sudo lets root become
 # anyone freely. On macOS the script deliberately never escalates (Homebrew refuses to run
 # as root), so the process already IS "$USERNAME", and re-invoking sudo for the SAME
 # account asks for a real password — potentially many times in one run, dev.sh calls this
 # shape roughly ten times — or fails outright on an account with no sudo rights at all.
 # `dev.sh`'s git/bun/deno/claude/opencode/editor helpers all route through this rather than
 # hand-rolling `sudo -H -u "$USERNAME" ...` each time, so macOS behaviour lives in one place.
 run_as_owner() {
  if [[ "${OS:-}" == "macos" ]]; then
    "$@"
  else
    sudo -H -u "$USERNAME" "$@"
  fi
 }
 # Run a block as the created user (login shell, inherits HOME)
 as_user() {
  sudo -u "$USERNAME" -i bash -c "$1"
@@ -47,8 +47,8 @@ MACHINE_SETUP_DEV_LOADED=1
 # has never been configured — the fresh machine this script exists for — reading
 # the current value aborted the run before the section had printed anything.
 # Missing a value is an answer here, not a failure.
-git_get() { (cd / && sudo -H -u "$USERNAME" git config --global --get "$1" 2>/dev/null) || true; }
+git_get() { (cd / && run_as_owner git config --global --get "$1" 2>/dev/null) || true; }
-git_set() { (cd / && sudo -H -u "$USERNAME" git config --global "$1" "$2"); }
+git_set() { (cd / && run_as_owner git config --global "$1" "$2"); }
 # Is there anything configured at all?
 git_has_identity() { [[ -n "$(git_get user.name)" || -n "$(git_get user.email)" ]]; }
@@ -102,7 +102,7 @@ install_oh_my_zsh() {
  # failed died here, silently, because the output is redirected: the run just
  # stopped after apt finished installing zsh, with nothing said. Observed on a
  # fresh Hetzner VPS, 2026-08-14.
-  sudo -H -u "$USERNAME" sh -c \
+  run_as_owner sh -c \
    "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended >/dev/null 2>&1 ||
    true
  # Belt and braces: `|| true` above already makes the last command succeed, and
@@ -155,7 +155,19 @@ nvim_latest_version() {
 #
 # The old install is removed only after the download has succeeded, so a failed
 # fetch leaves the working copy alone.
 #
 # This had NO macOS branch at all until it was caught here: unconditionally fetched
 # nvim-linux-<arch>.tar.gz regardless of $OS, which 404s on a Mac. Not a crash — the
 # caller's `if nvim_install; then … else warn …` catches the failure and reports it as
 # ERRORS+=("Neovim: install failed") rather than aborting the run — but Neovim never
 # actually landed. brew has a real, current formula, so that's the macOS path instead of
 # reaching for a macOS release asset the way lazygit's fix did.
 nvim_install() {
  if [[ "${OS:-}" == "macos" ]]; then
    brew install neovim
    return
  fi
  local asset tarball dest
  asset="$(nvim_asset)"
  tarball="/tmp/nvim-linux-${asset}.tar.gz"
@@ -187,11 +199,11 @@ nvim_clone_config() {
  local repo="$1" dest="${USER_HOME}/.config/nvim"
  install -d -m 0755 -o "$USERNAME" -g "$(user_group)" "${USER_HOME}/.config"
-  (cd / && sudo -H -u "$USERNAME" git clone --depth 1 "$repo" "$dest" >/dev/null 2>&1) || return 1
+  (cd / && run_as_owner git clone --depth 1 "$repo" "$dest" >/dev/null 2>&1) || return 1
  # The starter is a template, not something to track. Left in place for a
  # config of the user's own, which they will want to keep pulling.
-  [[ "$repo" == *LazyVim/starter* ]] && sudo -u "$USERNAME" rm -rf "${dest}/.git"
+  [[ "$repo" == *LazyVim/starter* ]] && run_as_owner rm -rf "${dest}/.git"
  return 0
 }
@@ -230,6 +242,18 @@ node_installed_major() { node -v 2>/dev/null | sed 's/^v//; s/\..*//'; }
 install_node() {
  local major="$1"
  # NodeSource's setup script adds an apt repository — it is Debian/Ubuntu-only by name
  # and by mechanism (checks for dpkg internally), so there is nothing to point it at on
  # macOS. Homebrew's `node`/`nodejs` formula (both names resolve, confirmed) tracks only
  # the current release rather than an arbitrary major the way NodeSource's per-major
  # scripts do — same tradeoff this codebase already accepts for Docker and Xcode CLT on
  # macOS: brew's own version, not a pinned one.
  if [[ "${OS:-}" == "macos" ]]; then
    pkg_install_now nodejs
    return
  fi
  # NodeSource publishes one setup script per major. Checked before it is piped
  # into a shell, because a 404 page piped to bash is a confusing way to fail.
  curl -fsS -o /dev/null "https://deb.nodesource.com/setup_${major}.x" || {
@@ -358,7 +382,7 @@ ensure_bun_symlink() {
 install_bun() {
  local tag="${1:-}"
  [[ -n "$tag" ]] || return 1
-  (cd / && sudo -H -u "$USERNAME" bash -c "curl -fsSL https://bun.sh/install | bash -s '${tag}'") >/dev/null 2>&1
+  (cd / && run_as_owner bash -c "curl -fsSL https://bun.sh/install | bash -s '${tag}'") >/dev/null 2>&1
  [[ -x "${USER_HOME}/.bun/bin/bun" ]]
 }
@@ -367,7 +391,7 @@ install_pm2() { npm install -g pm2 >/dev/null 2>&1; }
 deno_installed() { command -v deno &>/dev/null || [[ -x "${USER_HOME}/.deno/bin/deno" ]]; }
 install_deno() {
-  (cd / && sudo -H -u "$USERNAME" bash -c 'curl -fsSL https://deno.land/install.sh | sh') >/dev/null 2>&1
+  (cd / && run_as_owner bash -c 'curl -fsSL https://deno.land/install.sh | sh') >/dev/null 2>&1
  [[ -x "${USER_HOME}/.deno/bin/deno" ]]
 }
@@ -434,16 +458,16 @@ agent_is_npm_install() { [[ "$(readlink -f "$(agent_path "$1")" 2>/dev/null)" ==
 agent_version() {
  local bin
  bin="$(agent_path "$1")"
-  [[ -n "$bin" ]] && (cd / && sudo -H -u "$USERNAME" "$bin" --version 2>/dev/null | head -1)
+  [[ -n "$bin" ]] && (cd / && run_as_owner "$bin" --version 2>/dev/null | head -1)
 }
 install_claude_code() {
-  (cd / && sudo -H -u "$USERNAME" bash -c "set -e; curl -fsSL ${CLAUDE_INSTALL_URL} | bash") >/dev/null 2>&1
+  (cd / && run_as_owner bash -c "set -e; curl -fsSL ${CLAUDE_INSTALL_URL} | bash") >/dev/null 2>&1
  [[ -x "$(agent_bin claude)" ]]
 }
 install_opencode() {
-  (cd / && sudo -H -u "$USERNAME" bash -c "set -e; curl -fsSL ${OPENCODE_INSTALL_URL} | bash") >/dev/null 2>&1
+  (cd / && run_as_owner bash -c "set -e; curl -fsSL ${OPENCODE_INSTALL_URL} | bash") >/dev/null 2>&1
  [[ -x "$(agent_bin opencode)" ]]
 }
@@ -471,7 +495,7 @@ editor_candidates() {
 # `|| true` for the same reason git_get has it: "not set" is an answer, and an
 # assignment from a function that exits non-zero aborts the run under `set -e`.
-current_editor() { (cd / && sudo -H -u "$USERNAME" bash -lc 'echo "${EDITOR:-}"' 2>/dev/null) || true; }
+current_editor() { (cd / && run_as_owner bash -lc 'echo "${EDITOR:-}"' 2>/dev/null) || true; }
 set_system_editor() {
  local editor="$1" path
@@ -81,6 +81,12 @@ LAST_SKIPPED=()
 # distribution's default alongside it. It stays in core because anything that
 # compiles a native module needs it, but it is the one to move out first if that
 # ever bites.
 #
 # inotify-tools is `inotifywait`, and it is what lets a COMMANDER react the
 # moment a file lands instead of polling for it. Without it a watcher can only
 # ask "is there anything new?" on a timer, which is both slower and more work —
 # and the commander has no way to know the tool is missing until it tries. macOS
 # has no equivalent in the package sets here; a commander there polls.
 pkgs_core() {
  case "$PM" in
    apt)
@@ -102,24 +108,25 @@ pkgs_core() {
      # broken rather than a package being absent.
      echo curl ca-certificates gnupg git jq unzip \
        apt-transport-https lsb-release software-properties-common \
-        wget zip brotli build-essential python3 btop htop tree tmux ripgrep fd-find net-tools eza \
+        wget zip brotli build-essential python3 btop tree tmux ripgrep fd-find net-tools eza \
-        poppler-utils radicale fail2ban unattended-upgrades
+        inotify-tools poppler-utils fail2ban unattended-upgrades
      ;;
    pacman)
      echo curl ca-certificates gnupg git jq unzip \
-        wget zip brotli base-devel python btop htop tree tmux ripgrep fd net-tools eza \
+        wget zip brotli base-devel python btop tree tmux ripgrep fd net-tools eza \
-        poppler radicale fail2ban
+        inotify-tools poppler fail2ban
      ;;
    dnf)
      echo curl ca-certificates gnupg2 git jq unzip \
-        wget zip brotli python3 btop htop tree tmux ripgrep fd-find net-tools eza \
+        wget zip brotli python3 btop tree tmux ripgrep fd-find net-tools eza \
-        poppler-utils radicale fail2ban
+        inotify-tools poppler-utils fail2ban
      ;;
    brew)
      # curl, unzip and the TLS roots ship with macOS; the compilers come from
      # the Xcode command line tools, which is not a formula — see xcode_clt_*.
      # brotli is here because macOS ships the library but not the CLI.
-      echo gnupg git jq wget brotli btop htop tree ripgrep fd eza poppler radicale
+      #
      echo gnupg git jq wget brotli btop tree ripgrep fd eza poppler
      ;;
  esac
 }
@@ -247,13 +254,20 @@ pkg_install() {
 # passed by value cannot be told apart from an empty one once it has been through
 # word splitting.
 #
 # Copies by name via eval rather than `local -n` — namerefs are bash 4.3+, and macOS's
 # stock bash is 3.2. This is the idiom namerefs replaced: build the local array by
 # expanding the CALLER's array name inside a double-quoted eval, which bash 3.2 has always
 # supported. `$2`/`$3` are trusted call-site literals (`present`, `missing`), never
 # user input, so the eval is not taking anything untrusted.
 #
 # Returns non-zero when there is nothing to do, or when the answer was no — in
 # both cases the caller should skip its action. LAST_INSTALLED is cleared on a
 # refusal so the summary does not claim work that never happened.
 announce_plan() {
  local label="$1"
-  local -n _present="$2"
+  local -a _present _missing
-  local -n _missing="$3"
+  eval "_present=(\"\${$2[@]}\")"
  eval "_missing=(\"\${$3[@]}\")"
  echo ""
  info "${label} — installs what is missing, keeps what you already have"
@@ -59,12 +59,35 @@ authorized_key_count() {
 has_authorized_key() { (($(authorized_key_count) > 0)); }
-# Everything about ~/.ssh that has to be true for sshd to use it at all. sshd
+# Everything that has to be true for sshd to use ~/.ssh at all. sshd's StrictModes
-# ignores an authorized_keys file that is group- or world-writable, and does so
+# (on by default, and nothing here turns it off) checks the HOME DIRECTORY too, not
-# silently from the client's point of view — the login just fails.
+# just .ssh — this used to check only .ssh, which is the shape of bug that is hardest
 # to notice: an account whose home came from somewhere other than THIS script's own
 # adduser call (cloud-init, a prior useradd, LDAP, or simply an account that already
 # existed) can have a group- or world-writable home directory, and sshd refuses
 # authorized_keys under it silently. The .ssh directory and the key both look
 # completely correct — because they are — and nothing here used to say why the
 # login still failed.
 fix_ssh_permissions() {
-  local dir
+  local dir home mode
  dir="$(user_ssh_dir)"
  home="$USER_HOME"
  if [[ -d "$home" ]]; then
    # GNU stat's -c, tried first since this step only ever runs on Linux (MACOS_SKIP)
    # — with a BSD fallback anyway rather than a call that silently returns nothing on
    # whatever this is next tested against, the same trap officer-setup's layout.sh
    # file_owner() hit for the same reason.
    mode="$(stat -c %a "$home" 2>/dev/null || stat -f %Lp "$home" 2>/dev/null)"
    # 0022 is the group-write and other-write bits together. Cleared rather than
    # forced to a fixed mode — 0755 vs 0750 is a real choice some setups make on
    # purpose, and this only removes the bits sshd actually refuses to see.
    if [[ -n "$mode" ]] && ((8#$mode & 0022)); then
      chmod go-w "$home"
      warn "${home} was group/world-writable (${mode}) — sshd's StrictModes refuses authorized_keys under a writable home regardless of .ssh's own permissions; cleared"
    fi
  fi
  [[ -d "$dir" ]] || install -d -m 0700 -o "$USERNAME" -g "$(user_group)" "$dir"
  chmod 700 "$dir"
  [[ -f "$dir/authorized_keys" ]] && chmod 600 "$dir/authorized_keys"
@@ -466,32 +466,73 @@ disable_sleep() {
 # systemd-networkd actually manages the network — a server or cloud image, via
 # cloud-init and netplan — it does that in milliseconds and is load-bearing.
 #
-# Where NetworkManager owns the network instead, systemd-networkd runs nothing,
+# Where NetworkManager owns the network instead, systemd-networkd configures
-# but the wait-online unit is still enabled and waits for a link that will never
+# nothing, but the wait-online unit is still enabled and waits for a link that
-# be configured. It gives up after its full timeout, on every boot.
+# will never come up. It gives up after its full timeout, on every boot.
 #
 # So the fix is masking one unit, and only on the second stack. Do NOT
 # `systemctl disable --now systemd-networkd` to achieve the same thing: on a
 # networkd-managed box that brings it up with no network on the next boot, no
 # ssh, and nothing but the provider's rescue console.
 #
 # ── "is networkd running" is the wrong question ──
 #
 # It was the test here until 2026-08-24, and it is why this section did nothing
 # on the machine it was written for. Both stacks can be ACTIVE at once: on the
 # dev box NetworkManager owned enp1s0 and wlp2s0, systemd-networkd was up and
 # managing not one of eighty links, and wait-online still burned its full two
 # minutes on every boot — `Timeout occurred while waiting for network
 # connectivity`, at 18:31:05 to 18:33:05, in the journal.
 #
 # What matters is whether networkd CONFIGURED anything, which `networkctl` will
 # say. A link it owns reads `configured`; a link it is ignoring reads
 # `unmanaged`. If every link is unmanaged, the wait cannot ever be satisfied and
 # masking it is safe.
 WAIT_ONLINE_UNIT=systemd-networkd-wait-online.service
 # Reported to the operator, so it has to describe the machine rather than pick a
 # winner: both daemons running with networkd idle is the exact case this section
 # used to get wrong, and printing "NetworkManager" for it hid that.
 network_manager_name() {
-  if systemctl is-active --quiet NetworkManager.service 2>/dev/null; then
+  local nm=no nd=no
  systemctl is-active --quiet NetworkManager.service 2>/dev/null && nm=yes
  systemctl is-active --quiet systemd-networkd.service 2>/dev/null && nd=yes
  if [[ $nm == yes && $nd == yes ]]; then
    if networkd_configures_a_link; then
      echo "both — networkd configures at least one link"
    else
      echo "NetworkManager (networkd is up but configures nothing)"
    fi
  elif [[ $nm == yes ]]; then
    echo "NetworkManager"
-  elif systemctl is-active --quiet systemd-networkd.service 2>/dev/null; then
+  elif [[ $nd == yes ]]; then
    echo "systemd-networkd"
  else
    echo "neither — unclear"
  fi
 }
-# Is the wait actually pointless here? NetworkManager in charge and networkd not.
+# Does networkd actually configure a link on this machine?
-# Anything else, including "cannot tell", is left alone.
+#
 # `networkctl list --no-legend` puts the SETUP state last on each line. Anything
 # other than unmanaged/pending/n-a means networkd owns that link and the wait is
 # real work. Missing networkctl counts as "yes, it does" — an unanswerable
 # question must not be read as permission to mask.
 networkd_configures_a_link() {
  command -v networkctl &>/dev/null || return 0
  networkctl list --no-legend 2>/dev/null | awk '{ print $NF }' |
    grep -qvE '^(unmanaged|pending|n/a)$'
 }
 # Is the wait actually pointless here? NetworkManager in charge, and networkd
 # either absent or configuring nothing. Anything else, including "cannot tell",
 # is left alone.
 wait_online_is_spurious() {
-  systemctl is-active --quiet NetworkManager.service 2>/dev/null &&
+  systemctl is-active --quiet NetworkManager.service 2>/dev/null || return 1
-    ! systemctl is-active --quiet systemd-networkd.service 2>/dev/null
+  systemctl is-active --quiet systemd-networkd.service 2>/dev/null || return 0
  ! networkd_configures_a_link
 }
 # What that unit actually cost on this boot, straight from systemd's own
@@ -245,7 +245,18 @@ tailscale_needs_logout() {
 # Routing has to be on before this machine can forward anyone else's packets,
 # whether as an exit node or as a subnet router. Written as a drop-in so it is
 # visible as this script's doing.
 # Both this and install_exit_node_tuning below are Linux-only — sysctl.d, systemd's
 # networkd-dispatcher, ethtool NIC offload flags, none of which macOS has an equivalent
 # concept for. Tailscale itself DOES support acting as an exit node from macOS (that's the
 # `--advertise-exit-node` flag on `tailscale up`, untouched by this guard) — what's
 # unavailable is specifically this forwarding-throughput tuning, which is also a much
 # narrower loss on a Mac: the file's own MACOS_SKIP already treats a laptop advertising as
 # an exit node as an edge case, not the common path a homelab box is.
 enable_ip_forwarding() {
  if [[ "${OS:-}" == "macos" ]]; then
    warn "IP-forwarding tuning is Linux-only (sysctl.d) — skipping; the exit node still works, just untuned"
    return 0
  fi
  cat >"$TS_EXIT_SYSCTL" <<'EOF'
 # Written by machine-setup: required to forward traffic for other tailnet nodes,
 # as an exit node or as a subnet router.
@@ -265,6 +276,10 @@ EOF
 # once, because the settings are per-interface and do not survive the link going
 # down and back up.
 install_exit_node_tuning() {
  if [[ "${OS:-}" == "macos" ]]; then
    warn "NIC offload tuning is Linux-only (networkd-dispatcher, ethtool) — skipping"
    return 0
  fi
  pkg_is_installed networkd-dispatcher || pkg_install_now networkd-dispatcher
  mkdir -p "$(dirname "$TS_DISPATCHER")"
@@ -48,7 +48,15 @@ tool_is_installed() { command -v "$(tool_command "$1")" &>/dev/null; }
 # The installers
 # -----------------------------------------------------------------------------
 # The installer script this used is literally named install_update_linux.sh — there is no
 # upstream equivalent for macOS to swap in, so this is brew there instead of a raw fetch.
 # All three tools are real Homebrew formulas (confirmed against the live catalogue), which
 # also means macOS gets `brew upgrade` maintenance the raw-fetch path never had.
 tool_install_lazydocker() {
  if [[ "${OS:-}" == "macos" ]]; then
    brew install lazydocker
    return
  fi
  curl -fsSL https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh |
    DIR=/usr/local/bin bash
 }
@@ -57,7 +65,16 @@ tool_install_lazydocker() {
 # x86_64, so an arm machine downloaded a 404 and tar failed halfway through the
 # run. lazygit spells the architectures x86_64 and arm64, which is neither of the
 # two spellings ARCH uses, hence the mapping.
 #
 # The URL was also hardcoded to `_Linux_` — brew handles macOS instead of this needing a
 # second literal-string branch, see tool_install_lazydocker above for why brew and not a
 # Darwin asset name here.
 tool_install_lazygit() {
  if [[ "${OS:-}" == "macos" ]]; then
    brew install lazygit
    return
  fi
  local version asset url
  case "$ARCH" in
    amd64) asset="x86_64" ;;
@@ -82,7 +99,14 @@ tool_install_lazygit() {
 # Quiet on purpose. The installer ends by printing how to add starship to bash,
 # zsh, ion, tcsh and xonsh — five shells' worth of instructions for a step that
 # already writes the zsh config itself. Errors still come through.
 #
 # starship's own installer IS cross-platform (unlike the two above), but brew on macOS
 # keeps it consistent with the other two tools and gets it `brew upgrade` maintenance.
 tool_install_starship() {
  if [[ "${OS:-}" == "macos" ]]; then
    brew install starship
    return
  fi
  curl -fsSL https://starship.rs/install.sh | sh -s -- -y -b /usr/local/bin >/dev/null
 }
@@ -46,7 +46,9 @@ while [[ $# -gt 0 ]]; do
      shift
      ;;
    -l | --list)
-      grep -oP '^step "\K[^"]+' "${BASH_SOURCE[0]}"
+      # Portable ERE + sed rather than GNU grep's -P/\K — BSD grep on macOS has no -P at
      # all and errors immediately ("invalid option -- P"), confirmed live.
      grep -E '^step "' "${BASH_SOURCE[0]}" | sed -E 's/^step "([^"]+)".*/\1/'
      exit 0
      ;;
    -h | --help)
@@ -114,15 +116,17 @@ info "Machine:  ${OS_NAME} (${ARCH})"
 info "Packages: ${PM:-none detected}"
 [[ "$IS_WSL" == true ]] && warn "WSL detected — the suspend, logind and boot-hang steps do not apply here"
-# Everything below this line is written against apt and systemd. Detection above
+# Everything below this line is written against apt and systemd, with real macOS/brew
-# recognises pacman, dnf and brew so the branches have somewhere to hang, but
+# branches threaded through where a Mac needs different behaviour (MACOS_SKIP for whole
-# nothing implements them yet — and running the apt path on Arch would half-build
+# steps that are server-only, `$OS == macos` for the rest). Detection above also recognises
-# a machine and stop somewhere unhelpful. Refuse clearly instead, and relax this
+# pacman and dnf so THEIR branches have somewhere to hang, but nothing implements those yet
-# list one entry at a time as each package manager grows a real path.
+# — running the apt path on Arch would half-build a machine and stop somewhere unhelpful.
 # Refuse clearly instead, and relax this list one entry at a time as each package manager
 # grows a real path.
 case "$PM" in
-  apt) ;;
+  apt | brew) ;;
  "") fail "Could not find a package manager for '${OS_NAME}'." ;;
-  *) fail "${OS_NAME} uses ${PM}, which this script does not implement yet — apt-based systems only, so far." ;;
+  *) fail "${OS_NAME} uses ${PM}, which this script does not implement yet — apt and brew only, so far." ;;
 esac
 ask_machine_role
@@ -404,7 +408,9 @@ fi
 step "System update"
 if ! skip; then
-  mapfile -t UPGRADABLE < <(pkg_upgradable)
+  # `mapfile` is bash 4+; macOS's stock bash is 3.2. This is the portable substitute.
  UPGRADABLE=()
  while IFS= read -r _line; do UPGRADABLE+=("$_line"); done < <(pkg_upgradable)
  echo ""
  info "System update — upgrades installed packages to their latest versions"
@@ -1170,18 +1176,22 @@ elif ! skip; then
  echo ""
  info "Boot hang — a unit that can add two minutes to every boot"
  echo "     On a machine where NetworkManager owns the network, systemd-networkd"
-  echo "     runs nothing — but systemd-networkd-wait-online is still enabled, and"
+  echo "     configures nothing — but systemd-networkd-wait-online is still"
-  echo "     waits for a link that will never come up. It gives up after its full"
+  echo "     enabled, and waits for a link that will never come up. It gives up"
-  echo "     timeout, every single boot."
+  echo "     after its full timeout, every single boot."
  echo ""
  echo "     Note both daemons can be running at once. What decides it is whether"
  echo "     networkd CONFIGURED a link, not whether it is up."
  echo ""
  echo "     network managed by:  $(network_manager_name)"
  echo "     that unit took:      ${WAIT_ONLINE_TIME:-it did not run}  on this boot"
  if ! wait_online_is_spurious; then
    echo ""
-    echo "     systemd-networkd is live here, so that unit is doing real work."
+    echo "     systemd-networkd configures a link here, so that unit is doing"
    echo "     real work."
    echo "     Masking it would be how this machine comes up with no network."
-    SUMMARY+=("Boot hang: nothing to fix — networkd is in charge")
+    SUMMARY+=("Boot hang: nothing to fix — networkd configures a link")
  else
    echo ""
    if is_role dev; then
@@ -2475,7 +2485,9 @@ EOF
  echo "     which is why git's own core.editor is deliberately not set: git"
  echo "     falls back to \$EDITOR, so setting it here covers everything."
  echo ""
-  mapfile -t EDITORS < <(editor_candidates)
+  # mapfile is bash 4+; macOS's stock bash is 3.2.
  EDITORS=()
  while IFS= read -r _line; do EDITORS+=("$_line"); done < <(editor_candidates)
  if ((${#EDITORS[@]} == 0)); then
    warn "no editor found to offer — skipping"
  else
@@ -50,7 +50,9 @@ while [[ $# -gt 0 ]]; do
      shift
      ;;
    -l | --list)
-      grep -oP '^step "\K[^"]+' "${BASH_SOURCE[0]}"
+      # Portable ERE + sed rather than GNU grep's -P/\K — BSD grep on macOS has no -P at
      # all and errors immediately ("invalid option -- P"), confirmed live.
      grep -E '^step "' "${BASH_SOURCE[0]}" | sed -E 's/^step "([^"]+)".*/\1/'
      exit 0
      ;;
    -h | --help)
@@ -143,6 +145,13 @@ else
  echo "     would have answered are asked below instead."
 fi
 # proxy.sh set PROXY_NET from $SETUP_DOCKER_NETWORK when it was SOURCED, before the answers
 # file above could have populated that variable — so it needs re-deriving now the same way
 # ENV_PORT/ENV_PUBLIC_URL/POSTGRES_URL are recovered below. Without this a customised bridge
 # name from machine-setup silently would not carry over, and Proxy would default back to
 # "services" regardless of what Docker was actually told to use.
 PROXY_NET="${SETUP_DOCKER_NETWORK:-$PROXY_NET}"
 # ── the account ──
 #
 # A remembered answer can go stale: the account it names may have been renamed or
@@ -211,8 +220,11 @@ fi
 echo ""
 info "What Officer needs from this machine"
-mapfile -t MISSING < <(missing_tools)
+# mapfile is bash 4+; macOS's stock bash is 3.2, so this reads line-by-line instead.
-mapfile -t MISSING_OPT < <(missing_optional_tools)
+MISSING=()
 while IFS= read -r _line; do MISSING+=("$_line"); done < <(missing_tools)
 MISSING_OPT=()
 while IFS= read -r _line; do MISSING_OPT+=("$_line"); done < <(missing_optional_tools)
 for t in "${REQUIRED_TOOLS[@]}"; do
  if command -v "$t" &>/dev/null; then
@@ -274,7 +286,9 @@ if ! skip; then
  echo "     To put data/ on a bigger volume later, symlink it — that is a"
  echo "     decision about storage rather than about how Officer is laid out."
-  mapfile -t WRONG_OWNER < <(layout_wrong_owner)
+  # mapfile is bash 4+; macOS's stock bash is 3.2.
  WRONG_OWNER=()
  while IFS= read -r _line; do WRONG_OWNER+=("$_line"); done < <(layout_wrong_owner)
  if ((${#WRONG_OWNER[@]} > 0)); then
    echo ""
    warn "these exist but do not belong to ${USERNAME}:"
@@ -47,10 +47,16 @@ fail() {
 ONLY_STEP="${ONLY_STEP:-}"
 # `${var,,}` (case-insensitive --only compare below) is bash 4+. macOS's stock /bin/bash is
 # 3.2 — confirmed live: "bad substitution" — and under this script's `set -e` that means
 # `--only <step>` killed the ENTIRE run on macOS, not just the comparison. This is the
 # portable pre-4 substitute.
 lower() { tr '[:upper:]' '[:lower:]' <<<"$1"; }
 step() {
  CURRENT_STEP="$1"
  if [[ -n "$ONLY_STEP" ]]; then
-    if [[ "${1,,}" == "${ONLY_STEP,,}" ]]; then
+    if [[ "$(lower "$1")" == "$(lower "$ONLY_STEP")" ]]; then
      SKIP_STEP=false
      echo ""
      echo -e "${BOLD}── $1 ──${NC}"
@@ -134,7 +140,39 @@ ask_required() {
 user_group() { id -gn "${1:-$USERNAME}" 2>/dev/null || echo "${1:-$USERNAME}"; }
 # The bound address(es) of whatever is LISTENing on a TCP port — one per line, formatted
 # like `127.0.0.1:5432` or `*:5432`. Used both to ask "is anything on this port at all" and
 # "is it bound wide enough for a container to reach" (Postgres and the Proxy section ask
 # opposite versions of that question).
 #
 # `ss` (iproute2) is Linux-only — no equivalent ships with it on macOS. `lsof` is the
 # portable answer: present on every macOS install by default, and common enough on Linux
 # (already a REQUIRED_TOOL nowhere here, so this still prefers `ss` there since that is the
 # surface this was written and tested against) that branching by OS rather than picking one
 # tool for both keeps each path exactly as capable as it always was.
 listening_addrs() {
  local port="$1"
  if [[ "$(uname -s)" == "Darwin" ]]; then
    lsof -nP -iTCP -sTCP:LISTEN 2>/dev/null | awk -v p=":${port}\$" '$9 ~ p {print $9}'
  else
    ss -ltn 2>/dev/null | awk -v p=":${port}\$" '$4 ~ p {print $4}'
  fi
 }
 # Run something as the account that owns the install. Officer's files, its
 # node_modules and its pm2 process list all belong to that account, not to root —
 # a repository cloned as root is one the owner cannot pull.
-as_owner() { (cd "${2:-/}" && sudo -H -u "$USERNAME" bash -c "$1"); }
+#
 # On Linux this script runs as root (that's the whole point of sudo -H -u here: dropping
 # from root down to the owning account). On macOS it never escalates — officer-setup.sh
 # refuses to even start under sudo there, "the account running this IS the owner" — so the
 # process already IS $USERNAME, and re-invoking sudo for the SAME account asks for a real
 # password on every single call (Dependencies, Schema, Build, Secrets, Services, Repository
 # all go through this) or fails outright without sudo rights at all.
 as_owner() {
  if [[ "$(uname -s)" == "Darwin" ]]; then
    (cd "${2:-/}" && bash -c "$1")
  else
    (cd "${2:-/}" && sudo -H -u "$USERNAME" bash -c "$1")
  fi
 }
@@ -24,15 +24,20 @@ OFFICER_SETUP_BUILD_LOADED=1
 # attached. drizzle-kit then fails instead of waiting, which is the outcome you
 # want at 3am.
 push_schema() {
-  sudo -u "$USERNAME" bash -c "cd '$(platform_dir)' && bun db:push </dev/null" 2>&1
+  as_owner "cd '$(platform_dir)' && bun db:push </dev/null" 2>&1
 }
 # What tables the schema will create, read from the aggregator rather than
 # guessed. This is what makes the section able to say what it is about to do.
 #
 # Portable ERE + sed rather than GNU grep's -P/lookbehind: BSD grep on macOS has no -P at
 # all (confirmed live — errors immediately), and its 2>/dev/null here would have hidden that
 # and reported "0 tables" on every macOS run instead, cosmetic but silently wrong.
 schema_table_count() {
  local dir
  dir="$(platform_dir)/src/databases/officer_db/src"
-  grep -oP "^export \* from '\./\K[\w-]+(?=/schema')" "$dir/schema.ts" 2>/dev/null | while read -r f; do
+  grep -E "^export \* from '\./" "$dir/schema.ts" 2>/dev/null |
    sed -E "s/^export \* from '\.\/([A-Za-z0-9_-]+)\/schema'.*/\1/" | while read -r f; do
    grep -c "pgTable(" "$dir/$f/schema.ts" 2>/dev/null || true
  done | awk '{s+=$1} END {print s+0}'
 }
@@ -43,7 +48,7 @@ schema_table_count() {
 # Not optional and not cosmetic: without it the server has no page to serve. It
 # is gitignored, so a fresh clone never has one.
 gen_index() {
-  sudo -u "$USERNAME" bash -c "cd '$(platform_dir)' && bun gen:index '$ENV_PUBLIC_URL'" 2>&1
+  as_owner "cd '$(platform_dir)' && bun gen:index '$ENV_PUBLIC_URL'" 2>&1
 }
 gen_index_output() { echo "$(platform_dir)/src/apps/officer-web/index.gen.html"; }
@@ -31,14 +31,32 @@ env_exists() { [[ -f "$(env_file)" ]]; }
 # One value out of an existing .env, without sourcing it — the file holds
 # secrets and arbitrary shell would run as root.
 #
 # Checks the OFFICERDEV_-prefixed key first, matching the priority `OFFICERDEV_X ?? X`
 # gives it at runtime — write_env ALWAYS writes prefixed keys (see below), so plain `env_get
 # PORT` used to compare against a key that could never appear in a file this script wrote,
 # and always came back empty. That silently defeated the resume block below it was written
 # to fix, and the Environment step's own re-run showed the wrong default. Verified against a
 # real written .env: `env_get PORT` -> [], `env_get OFFICERDEV_PORT` -> [9000], before this.
 # Falls back to the bare key so an old, hand-written unprefixed file still works, same as the
 # runtime does.
 env_get() {
  [[ -r "$(env_file)" ]] || return 0
-  awk -F= -v k="$1" '
+  awk -F= -v k="$1" -v pk="OFFICERDEV_$1" '
-    $1 == k {
+    $1 == pk {
      v = substr($0, index($0, "=") + 1)
      gsub(/^"|"$/, "", v)
      print v
      exit
    }
    $1 == k && !found {
      v = substr($0, index($0, "=") + 1)
      gsub(/^"|"$/, "", v)
      bare = v
      found = 1
    }
    END {
      if (bare != "") print bare
    }' "$(env_file)"
 }
@@ -111,7 +129,12 @@ ENVF
 # is any better a guess.
 tailnet_hostname() {
  local dns ip
-  dns="$(tailscale status --json 2>/dev/null | grep -oP '"DNSName":\s*"\K[^"]+' | head -1)"
+  # jq over grep -oP: this output is real JSON, and GNU grep's -P/\K doesn't exist on BSD
  # grep at all (confirmed live — errors visibly), which used to leak straight to the
  # terminal since only the `tailscale` call's stderr was suppressed, not the grep's. jq is
  # already an unconditional dependency elsewhere in this script (proxy.sh), so this is
  # strictly a correctness improvement even setting the portability problem aside.
  dns="$(tailscale status --json 2>/dev/null | jq -r '.Self.DNSName // empty')"
  dns="${dns%.}"      # MagicDNS reports it fully qualified, with a trailing dot
  dns="${dns%%.*}"    # and we want the short name
  if [[ -n "$dns" ]]; then
@@ -39,6 +39,13 @@ layout_dirs() {
  echo "$(layout_items_dir)"
 }
 # A file's owning username, portably: GNU stat (Linux) takes `-c %U`, BSD stat (macOS) has
 # no `-c` at all and wants `-f %Su` instead — confirmed live, GNU form exits
 # "illegal option -- c" under macOS's stat. Try GNU first since that is the common case,
 # fall back to BSD rather than branching on an OS variable this file does not otherwise
 # track.
 file_owner() { stat -c %U "$1" 2>/dev/null || stat -f %Su "$1"; }
 # Created owned by the account, because everything that writes into them runs as
 # the account: the platform under pm2, the app store's compose files, the item
 # store the agent authors into.
@@ -58,7 +65,7 @@ layout_wrong_owner() {
  local dir
  while read -r dir; do
    [[ -d "$dir" ]] || continue
-    [[ "$(stat -c %U "$dir")" == "$USERNAME" ]] || echo "$dir"
+    [[ "$(file_owner "$dir")" == "$USERNAME" ]] || echo "$dir"
  done < <(layout_dirs)
 }
@@ -62,7 +62,7 @@ pg_client_installed() {
 # entry, no add-apt-repository. Non-fatal — an install without psql is a working platform,
 # just a more annoying one to operate.
 install_pg_client() {
-  local major codename
+  local major
  major="$(pg_client_major)"
  [[ -n "$major" ]] || {
    warn "could not read a major version out of PG_IMAGE=${PG_IMAGE} — skipping the client"
@@ -74,6 +74,49 @@ install_pg_client() {
    return 0
  fi
  if [[ "$(uname -s)" == "Darwin" ]]; then
    install_pg_client_macos "$major"
    return $?
  fi
  install_pg_client_linux "$major"
 }
 # Homebrew's `postgresql@<major>` matches the apt path's own logic: the version has to agree
 # with the server's, not just be "a psql". It is keg-only — Homebrew never links more than one
 # Postgres onto PATH by default, because a dev machine plausibly has several majors installed
 # for different projects — so `brew install` alone does not make `psql` resolve. Symlinking
 # only the four client binaries this platform actually uses, rather than `brew link --force`ing
 # the whole keg, is the same caveat Homebrew's own postgresql formula prints; force-linking
 # would silently steal `psql` from whatever other major was linked before this ran.
 install_pg_client_macos() {
  local major="$1" prefix
  command -v brew &>/dev/null || {
    warn "Homebrew is not installed — cannot install postgresql@${major}. Run machine-setup.sh first."
    return 1
  }
  prefix="$(brew --prefix)"
  brew install "postgresql@${major}" &>/dev/null || {
    warn "brew install postgresql@${major} failed"
    return 1
  }
  local bin
  for bin in psql pg_dump pg_dumpall pg_restore; do
    [[ -x "${prefix}/opt/postgresql@${major}/bin/${bin}" ]] || continue
    ln -sf "${prefix}/opt/postgresql@${major}/bin/${bin}" "${prefix}/bin/${bin}"
  done
  pg_client_installed || {
    warn "psql is not version ${major} after installing — check: brew list postgresql@${major}"
    return 1
  }
  ok "psql $(psql --version | grep -oE '[0-9]+\.[0-9]+' | head -1) installed via Homebrew"
 }
 install_pg_client_linux() {
  local major="$1" codename
  codename="$(. /etc/os-release && echo "${VERSION_CODENAME:-}")"
  [[ -n "$codename" ]] || {
    warn "could not work out this release's codename — cannot add the PostgreSQL repository"
@@ -121,7 +164,12 @@ pg_container_running() { docker ps --filter "name=^${PG_CONTAINER}$" --format '{
 # Is something already answering on the port? A Postgres the user runs their own
 # way is a perfectly good answer, and finding out by failing to bind is not.
-pg_port_in_use() { ss -ltn 2>/dev/null | grep -qE "127\.0\.0\.1:${PG_PORT}\b|\*:${PG_PORT}\b|0\.0\.0\.0:${PG_PORT}\b"; }
+#
 # `ss` is Linux-only; `listening_addrs` (lib/base.sh) is the portable version, branching to
 # `lsof` on macOS. Confirmed empirically to fail silently the old way: `ss` doesn't exist on
 # macOS, its "command not found" was swallowed by `2>/dev/null`, and an empty grep result
 # reported the port as free even when something WAS listening.
 pg_port_in_use() { [[ -n "$(listening_addrs "$PG_PORT")" ]]; }
 # Bound to loopback, deliberately, and the reason is worth keeping next to the
 # line it explains.
@@ -189,9 +237,19 @@ ENVF
  return 0
 }
 # Failure has to mean failure. The bare awk one-liner this replaced printed nothing and
 # still exited 0 when the file existed but had no POSTGRES_PASSWORD= line — so the caller's
 # `pg_compose_exists && PG_EXISTING_PASSWORD="$(pg_password_from_env_file)"` treated that as
 # success with an EMPTY password, and built POSTGRES_URL with a blank credential instead of
 # falling through to provision fresh. Only reachable via a hand-edited/corrupted .env, since
 # write_pg_compose always writes the line — but "reuse a blank password" is the wrong
 # direction to fail in even for an edge case that rare.
 pg_password_from_env_file() {
  [[ -r "$(pg_env_file)" ]] || return 1
-  awk -F= '/^POSTGRES_PASSWORD=/ { print substr($0, index($0, "=") + 1); exit }' "$(pg_env_file)"
+  local pw
  pw="$(awk -F= '/^POSTGRES_PASSWORD=/ { print substr($0, index($0, "=") + 1); exit }' "$(pg_env_file)")"
  [[ -n "$pw" ]] || return 1
  printf '%s' "$pw"
 }
 pg_compose_up() { as_owner "docker compose --project-directory '$(pg_service_dir)' up -d" /; }
@@ -32,6 +32,13 @@ load_machine_answers() {
      MACHINE_ROLE) if [[ -z "$MACHINE_ROLE" ]]; then MACHINE_ROLE="$value"; fi ;;
      SETUP_USERNAME) if [[ -z "$USERNAME" ]]; then USERNAME="$value"; fi ;;
      OFFICER_ROOT) if [[ -z "$OFFICER_ROOT" ]]; then OFFICER_ROOT="$value"; fi ;;
      # The bridge machine-setup told Docker to use — proxy.sh's PROXY_NET otherwise
      # defaults to "services" independently and can only agree with this by coincidence.
      # PROXY_NET is a top-level assignment evaluated when proxy.sh is SOURCED, which
      # happens before this function is ever called — officer-setup.sh re-derives it from
      # SETUP_DOCKER_NETWORK right after calling this, same pattern as ENV_PORT/
      # ENV_PUBLIC_URL/POSTGRES_URL below it.
      SETUP_DOCKER_NETWORK) if [[ -z "${SETUP_DOCKER_NETWORK:-}" ]]; then SETUP_DOCKER_NETWORK="$value"; fi ;;
    esac
  done <"$MACHINE_ANSWERS"
  return 0
@@ -69,7 +76,19 @@ tool_why() {
 # The account has to exist before anything is written to its home.
 owner_exists() { id "$USERNAME" &>/dev/null; }
 # `getent` is Linux/glibc — not present on stock macOS at all (confirmed: "command not
 # found" on a real machine; it only appeared to work in earlier testing because this dev
 # session's shell profile shims it, which a fresh install does not have). Reproduced live:
 # this returned the WRONG, hardcoded `/home/<user>` fallback on a real macOS run just now,
 # and `install -d` then failed on it outright ("Operation not supported") since /home isn't
 # a real, writable path on macOS.
 #
 # `eval echo ~"$USERNAME"` is the portable replacement — tilde expansion resolves through
 # whatever the OS's own user database is (NSS on Linux, Directory Services on macOS)
 # without naming either. A nonexistent user leaves the tilde word unexpanded (`~name`
 # rather than a path), which is how the fallback below still triggers for that case.
 resolve_user_home() {
-  USER_HOME="$(getent passwd "$USERNAME" 2>/dev/null | cut -d: -f6)"
+  USER_HOME="$(eval echo ~"$USERNAME" 2>/dev/null)"
  [[ "$USER_HOME" == "~"* ]] && USER_HOME=""
  [[ -n "$USER_HOME" ]] || USER_HOME="/home/${USERNAME}"
 }
@@ -58,7 +58,9 @@ proxy_ask() {
 # reads like a firewall fault. So the bind ADDRESS is what gets checked.
 proxy_require_listening() {
  local port="$1" listen
-  listen="$(ss -ltnH "sport = :$port" 2>/dev/null | awk '{print $4}')"
+  # `ss` is Linux-only; `listening_addrs` (lib/base.sh) branches to `lsof` on macOS. Same
  # silent-empty-result failure mode as postgres.sh's pg_port_in_use if this were left as-is.
  listen="$(listening_addrs "$port" | head -1)"
  [[ -n "$listen" ]] || {
    warn "nothing is listening on port ${port} — start Officer first"
    return 1
@@ -170,7 +172,15 @@ proxy_wait_for_dns() {
    info "(Tailnet: the certificate can issue without this, but the name will not resolve until it exists.)"
  while ((elapsed < timeout)); do
    # `getent` is glibc/Linux-only — absent on macOS (confirmed: "command not found" on a
    # real machine), silently swallowed by 2>/dev/null, which would have spun this through
    # its full 30-minute timeout regardless of whether the record actually resolved.
    # `dscacheutil` is macOS's own equivalent, consulting the same system resolver.
    if [[ "$(uname -s)" == "Darwin" ]]; then
      got="$(dscacheutil -q host -a name "$domain" 2>/dev/null | awk '/^ip_address:/ {print $2; exit}')"
    else
      got="$(getent hosts "$domain" 2>/dev/null | awk '{print $1}' | head -1)"
    fi
    if [[ "$got" == "$want" ]]; then
      ok "${domain} resolves to ${want}"
      return 0
@@ -194,8 +204,18 @@ proxy_ensure_network() {
 # NPM binds its admin UI to the tailnet IP. If docker starts before tailscaled that
 # address does not exist yet and the WHOLE container fails to start, not just that port.
 #
 # Docker Desktop on macOS has no systemd unit to order — it is a GUI app the OS launches, not
 # a service tailscaled could be declared a dependency of — and this account does not run as
 # root there either, so `mkdir -p /etc/systemd/...` would fail on permissions rather than do
 # something merely unnecessary. Same shape as machine-setup's MACOS_SKIP: skip with a reason
 # rather than let a Linux-only action fail confusingly.
 proxy_order_docker_after_tailscaled() {
  [[ "$CHALLENGE" == "dns" ]] || return 0
  if [[ "$(uname -s)" == "Darwin" ]]; then
    ok "Docker Desktop has no systemd unit to order — skipping"
    return 0
  fi
  local f=/etc/systemd/system/docker.service.d/10-after-tailscaled.conf
  [[ -f "$f" ]] && return 0
  mkdir -p "$(dirname "$f")"
@@ -378,8 +398,20 @@ proxy_get_token() {
 # bypass ufw entirely. The symptom is a 504 that looks like a network fault. A container
 # upstream would need none of this, which is why container upstreams are preferable when
 # there is a choice.
 # `ufw` is Debian/Ubuntu — no macOS equivalent through this interface (pf/pfctl is a
 # different rule syntax entirely, and the Application Firewall machine-setup's own
 # MACOS_SKIP already documents for "Firewall" is per-APP, not per-subnet/per-port). Skipped
 # rather than guessed at: Docker Desktop for Mac also runs containers inside its own VM, so
 # bridge-to-host traffic does not cross the real host firewall the same way it does when
 # Docker runs directly on a Linux kernel — an unverified pf rule here could be solving a
 # problem macOS's Docker networking model does not actually have.
 proxy_allow_bridge_to_host() {
  local port="$1" subnet
  if [[ "$(uname -s)" == "Darwin" ]]; then
    ok "no ufw on macOS — Docker Desktop's own networking model handles bridge-to-host, skipping"
    BRIDGE_GATEWAY="$(docker network inspect "$PROXY_NET" -f '{{(index .IPAM.Config 0).Gateway}}')"
    return 0
  fi
  subnet="$(docker network inspect "$PROXY_NET" -f '{{(index .IPAM.Config 0).Subnet}}')"
  if ufw status 2>/dev/null | grep -q "${port}.*${subnet%%/*}"; then
    ok "ufw already allows the bridge to reach port ${port}"
@@ -35,7 +35,7 @@ bootstrap_secret_store() {
  # From the repo, because the module derives the install root as the parent of
  # the working directory — the same rule as src/servers/data-path.ts.
-  sudo -u "$USERNAME" bash -c "cd '$(platform_dir)' && bun --eval \"
+  as_owner "cd '$(platform_dir)' && bun --eval \"
    const { getKey } = await import('officerdb/secret-store');
    getKey('jwt');
  \"" >/dev/null 2>&1 || return 1
@@ -44,13 +44,6 @@ CORE_PROCESSES=(
  "officer-claude-code|bun|run src/servers/sidecar/claude/user-instance.ts"
  "officer-opencode|bun|run src/servers/sidecar/opencode/index.ts"
  "officer-pty|node|src/servers/sidecar/pty/index.mjs"
  # Calendar and contacts, CORE since 2026-08-19 rather than an app-store entry.
  #
  # It was a Docker service because the app store made everything one, not because Radicale needs a
  # container — it is a ~2MB Python package, and this sidecar spawns it directly on loopback. A personal
  # server having a calendar is not an integration with something you already run; it is the baseline.
  # Radicale needs `python3` and the `radicale` package, both installed by machine-setup.
  "officer-caldav|bun|run src/servers/sidecar/caldav/index.ts"
  # Push notifications, CORE since 2026-08-19. Built 2026-07-31, then switched off on 2026-08-13 with
  # memos and photos when it was slated to become a plugin — the only one of the three never extracted,
  # so it sat mounted nowhere with its schema commented out.
@@ -62,6 +55,11 @@ CORE_PROCESSES=(
  "officer-notify|bun|run src/servers/sidecar/notify/index.ts"
 )
 # Calendar and contacts are NOT here. They were core from 2026-08-19 until 2026-08-27, when caldav became
 # a plugin: it declares its own sidecar, its own `radicale` dependency and its own two screens, and the
 # generated ecosystem file gains an `officer-caldav` entry when it is installed. A fresh machine runs five
 # processes instead of seven, and gets a calendar by installing one plugin.
 write_ecosystem() {
  local dest entry name script args
  dest="$(ecosystem_file)"
@@ -101,24 +99,36 @@ FOOTER
 }
 pm2_start() {
-  sudo -u "$USERNAME" bash -c "cd '$(platform_dir)' && pm2 startOrRestart '$(ecosystem_file)' --update-env" 2>&1
+  as_owner "cd '$(platform_dir)' && pm2 startOrRestart '$(ecosystem_file)' --update-env" 2>&1
 }
-pm2_save() { sudo -u "$USERNAME" pm2 save 2>&1; }
+pm2_save() { as_owner "pm2 save" 2>&1; }
 # Survive a reboot. `pm2 startup` PRINTS a command for root to run rather than
 # doing it — so this runs what it prints, which is the whole point of already
 # being root here.
 #
 # `systemd` is hardcoded because that IS the only path today — pm2's own "platform" argument
 # has to be `launchd` on macOS instead, generating a LaunchAgent plist rather than a systemd
 # unit, and running it is a separate mechanism (`launchctl load`, not "eval a printed sudo
 # command"). That is real, separate work rather than a one-line swap, so this skips with a
 # stated reason on macOS instead of pretending the systemd path could ever produce anything
 # usable there — matches the same call this codebase already made for the Tailscale exit-node
 # NIC tuning and the proxy's systemd docker-ordering fix.
 pm2_enable_startup() {
  if [[ "$(uname -s)" == "Darwin" ]]; then
    warn "pm2 boot-persistence needs a launchd plist on macOS, not a systemd unit — not implemented yet"
    return 1
  fi
  local cmd
-  cmd="$(sudo -u "$USERNAME" bash -c "cd '$(platform_dir)' && pm2 startup systemd -u '$USERNAME' --hp '$USER_HOME'" 2>/dev/null | grep -E '^sudo ' | tail -1)"
+  cmd="$(as_owner "cd '$(platform_dir)' && pm2 startup systemd -u '$USERNAME' --hp '$USER_HOME'" 2>/dev/null | grep -E '^sudo ' | tail -1)"
  [[ -z "$cmd" ]] && return 1
  eval "${cmd#sudo }"
 }
 # One line per process: name, status, restarts.
 pm2_status_lines() {
-  sudo -u "$USERNAME" pm2 jlist 2>/dev/null |
+  as_owner "pm2 jlist" 2>/dev/null |
    node -e '
      let s = ""; process.stdin.on("data", (d) => (s += d)).on("end", () => {
        let apps = []; try { apps = JSON.parse(s); } catch { }
@@ -1,140 +1,10 @@
 /**
- * Regenerate `TODO.md` — the index over `todo/`.
+ * Regenerate `TODO.md` — the index over `todo/`. `bun run todo:index` after any change to the tree.
 *
- * The index is the one file everybody reads, so it is the one most able to lie. It is generated rather
+ * The logic lives in `src/servers/api/todos/todo-tree.ts`, shared with the `/api/todos` router so the
- * than maintained: `bun run todo:index` after any change to `todo/`, and it cannot drift from the tree
+ * board and this CLI cannot disagree about the format; this file is only the command.
 * it describes.
 */
-import { readFileSync, readdirSync, writeFileSync, statSync } from 'node:fs';
+import { writeIndex } from '../src/servers/api/todos/todo-tree';
 import { join } from 'node:path';
-const ROOT = new URL('..', import.meta.url).pathname;
+writeIndex();
-const OUT = join(ROOT, 'todo');
+console.log('TODO.md regenerated');
 export type Item = {
  id: string;
  title: string;
  theme: string;
  status: string;
  created: string;
  /** `urgent` or empty — see todo/README.md for why there is no scale. */
  priority: string;
  due: string;
  order: number;
  file: string;
 };
 /** Minimal frontmatter reader — `key: value`, values optionally JSON-quoted. No YAML dependency. */
 export function frontmatter(text: string): Record<string, string> {
  const end = text.indexOf('\n---', 4);
  if (!text.startsWith('---') || end === -1) return {};
  const out: Record<string, string> = {};
  for (const line of text.slice(4, end).split('\n')) {
    const m = line.match(/^([a-z_]+):\s*(.*)$/);
    if (!m || !m[1]) continue;
    const raw = (m[2] ?? '').trim();
    out[m[1]] = raw.startsWith('"') ? (JSON.parse(raw) as string) : raw;
  }
  return out;
 }
 export function readTree(): { themes: { theme: string; heading: string; items: Item[] }[] } {
  const themes = readdirSync(OUT)
    .filter((d) => statSync(join(OUT, d)).isDirectory())
    .sort()
    .map((theme) => {
      const files = readdirSync(join(OUT, theme)).filter((f) => f.endsWith('.md'));
      const meta = frontmatter(readFileSync(join(OUT, theme, '_index.md'), 'utf8'));
      const items = files
        .filter((f) => f !== '_index.md')
        .map((f) => {
          const fm = frontmatter(readFileSync(join(OUT, theme, f), 'utf8'));
          return {
            id: fm.id ?? `${theme}/${f.replace(/\.md$/, '')}`,
            title: fm.title ?? f,
            theme,
            status: fm.status ?? 'open',
            created: fm.created ?? '',
            priority: fm.priority ?? '',
            due: fm.due ?? '',
            order: Number(fm.order ?? 0),
            file: `todo/${theme}/${f}`,
          };
        })
        .sort((a, b) => a.order - b.order);
      return { theme, heading: meta.heading ?? theme, items };
    });
  return { themes };
 }
 const HEADER = `# TODO — the index
 Deferred work. **The items live in \`todo/\`, one file each**, grouped by theme; this file is the map
 over them and is GENERATED — run \`bun run todo:index\` after any change rather than editing it here.
 Format and the two-way-sync contract: \`todo/README.md\`.
 **Context, corrected 2026-08-07.** This list used to open by saying Officer was "collapsing from
 multi-tenant / open-source-ready to a **single-user platform**", and told you to treat multi-tenant
 indirection as accidental complexity. **That direction was reversed.** The permission model shipped on
 2026-08-07 to serve a real goal — deploy to the company server, onboard people, give each one their own
 Gitea account through the platform. Per-user scoping is now a requirement, and the items that proposed
 deleting it have been removed rather than left to mislead the next reader.
 What did NOT reverse: \`execution\` permissions (terminal, chat, tasks, files, desktop, browser) run as
 the owner's OS user and can never be granted. Indirection there really is accidental complexity.
 `;
 function render(): string {
  const { themes } = readTree();
  const open = themes.reduce((n, t) => n + t.items.filter((i) => i.status !== 'done').length, 0);
  const done = themes.reduce((n, t) => n + t.items.filter((i) => i.status === 'done').length, 0);
  const rows = themes
    .filter((t) => t.items.length)
    .map((t) => {
      const o = t.items.filter((i) => i.status !== 'done').length;
      const d = t.items.length - o;
      return `| [${t.heading}](todo/${t.theme}/) | ${o} | ${d} |`;
    });
  const recent = themes
    .flatMap((t) => t.items)
    .filter((i) => i.status !== 'done')
    .sort((a, b) => b.created.localeCompare(a.created))
    .slice(0, 10)
    .map((i) => `- \`${i.created}\` **${i.title}** — [${i.id}](${i.file})`);
  // A theme holding only prose has no row above, and an entry nobody can see is the failure mode this
  // whole split risks. List them explicitly rather than letting them age out of view.
  const notes = themes.filter((t) => !t.items.length).map((t) => `- [${t.heading}](todo/${t.theme}/_index.md)`);
  // Urgent goes above everything. An item the owner called urgent, sorted in among seventy-five others
  // by theme, is an item nobody sees on the day it matters.
  const urgent = themes
    .flatMap((t) => t.items)
    .filter((i) => i.status !== 'done' && i.priority === 'urgent')
    .sort((a, b) => (a.due || '9999').localeCompare(b.due || '9999'))
    .map((i) => `- ${i.due ? `**due ${i.due}** — ` : ''}**${i.title}** — [${i.id}](${i.file})`);
  return [
    HEADER,
    ...(urgent.length ? [`## Urgent\n`, ...urgent, ``] : []),
    `## Themes\n`,
    `**${open} open, ${done} closed**, across ${rows.length} themes.\n`,
    `| Theme | Open | Closed |`,
    `| --- | --- | --- |`,
    ...rows,
    ``,
    `## Records — no items, kept for the reasoning\n`,
    ...notes,
    ``,
    `## Newest ten\n`,
    ...recent,
    ``,
  ].join('\n');
 }
 if (import.meta.main) {
  writeFileSync(join(ROOT, 'TODO.md'), render());
  console.log('TODO.md regenerated');
 }
@@ -0,0 +1,271 @@
 # Frontend Apps
 Shared patterns and conventions for all frontend applications (dashboard, editor, runtime).
 ## UI Components
 ### shadcn/ui (Base)
 Location: `src/workspaces/components/ui/`
 Standard shadcn/ui components with Tailwind CSS. Import via:
 ```tsx
 import { Button } from "@/components/ui/button";
 import { Dialog, DialogContent, DialogTrigger } from "@/components/ui/dialog";
 ```
 ### Custom Components
 Location: `src/workspaces/components/`
 Built on top of shadcn primitives:
 - `Avatar.tsx` - User avatars
 - `Card.tsx` - Custom card wrapper
 - `ColorPicker.tsx` - Color selection
 - `DataTable/` - Table with sorting, filtering, pagination (see below)
 - `Dialogs/` - Common dialog patterns
 - `ErrorDialogs/` - Error display dialogs
 - `MetricCard.tsx` - Stats display card
 - `SearchInput.tsx` - Search with debounce
 - `Select.tsx` - Enhanced select
 - `Slider/` - Custom slider
 - `Tabs/` - Enhanced tabs
 ### DataTable + useDataControl
 A complete data table solution with sorting, filtering, and pagination.
 **Pattern:**
 ```tsx
 import { DataTable, useDataControl } from '@/components/DataTable';
 function JobsLibrary() {
  const { jobs } = useJobs();
  const dataController = useDataControl<Job>(jobs || []);
  return (
    <>
      {/* Wire search input to controller */}
      <SearchInput
        value={dataController.searchQuery}
        handleSearch={dataController.setSearchQuery}
      />
      <DataTable<Job>
        dataController={dataController}
        pageSize={10}
        columns={[
          { field: 'id', label: 'ID', sortKey: 'id' },
          { field: 'type', label: 'Type', sortKey: 'type' },
          {
            field: 'status',
            label: 'Status',
            condition: view === 'All',  // conditional column
            format: ({ value, item }) => <Badge>{value}</Badge>
          },
          {
            label: 'Actions',
            format: ({ item }) => <ActionsCell job={item} />
          },
        ]}
      />
    </>
  );
 }
 ```
 **useDataControl returns:**
 - `data` - Current page of filtered/sorted data
 - `rawData` - Original unfiltered data
 - `searchQuery`, `setSearchQuery` - Search state
 - `searchKeys`, `setSearchKeys` - Which fields to search
 - `sortedBy`, `setSortedBy`, `sortBy` - Sort state
 - `sortKey`, `sortDirection` - Parsed sort info
 - `currentPage`, `changePage`, `pageCount` - Pagination
 - `pageSize`, `setPageSize` - Items per page
 - `setCustomSort` - Custom sort function
 **Column options:**
 - `field` - Key in data object
 - `label` / `labelMobile` - Header text
 - `sortKey` - Enable sorting on this column
 - `format` - Custom render: `({ value, item, data, idx }) => ReactNode`
 - `condition` - Show/hide column: `boolean | () => boolean`
 - `tooltip` - Header tooltip text
 - `headerClassName` / `cellClassName` - Styling
 **Features:**
 - Auto-generates columns from data if not specified
 - Resets to page 1 on search/sort change
 - Search strips diacritics for accent-insensitive matching
 - Built-in pagination bar (shows when data exceeds pageSize)
 ## Hooks
 Location: `src/workspaces/hooks/src/`
 ### Data Fetching - `useClient`
 HTTP client with auth token handling:
 ```tsx
 const client = useClient();
 const data = await client.get<User[]>("/users");
 await client.post("/experiments", payload);
 ```
 Methods: `get`, `getText`, `getBlob`, `post`, `put`, `patch`, `delete`
 Auto-attaches Bearer token from localStorage/sessionStorage.
 ### Forms - `useForm`
 Custom form hook (not react-hook-form):
 ```tsx
 const { state, formRef, update, reset, isValid } = useForm<FormState>(
  initialState,
  validateFn
 );
 return <form ref={formRef}>...</form>;
 ```
 Features:
 - Auto-syncs form inputs with state via `name` attribute
 - Handles checkboxes, radios, selects, number inputs
 - Nested object support via data attributes
 - Validation function support
 ### Other Hooks
 - `useAuth/` - Authentication state and methods
 - `useDebounce` - Debounced values
 - `useDragAndDrop` - Drag and drop functionality
 - `useFullscreen/` - Fullscreen API wrapper
 - `useIsMobile` - Responsive breakpoint detection
 - `useLocalStorageState` - Persisted state
 - `useMounted` - Component mount status
 - `usePopover` - Popover state management
 - `useTimeout` - Timeout management
 - `useTimer` - Interval-based timer
 - `useChatWebSocket` - the chat socket, with reconnect + replay cursor
 - `usePanelChannel` - panel-to-panel signals (refresh buses, NOT selection — selection is the URL)
 - `useJobs` - background jobs
 - `useCustomSorter`, `useImageLoader`, `useIsProduction`, `usePhotoEditor`
 ## State Management
 Uses React Query cache as both server and client state manager.
 ### Global State - `useGlobal`
 Uses React Query cache as a global state store (no Context providers needed):
 ```tsx
 const [value, setValue, refresh, reset] = useGlobal<string>("SIDEBAR_STATE", "expanded");
 // Any component using the same key shares state and reacts to changes
 setValue("collapsed");
 ```
 How it works:
 - `enabled: false` + `staleTime: Infinity` = never fetches, just stores
 - Automatic re-renders when state changes
 - Visible in React Query DevTools
 - Supports functional updates: `setValue(prev => ...)`
 ### URL Query State - `useQueryState`
 Syncs state with URL query parameters:
 ```tsx
 const [page, setPage, reset, clear] = useQueryState<number>("page", 1);
 const [filter, setFilter] = useQueryState<string>("filter", null, true); // isGlobal = true
 ```
 Features:
 - Updates URL via `history.replaceState` (no page reload)
 - `isGlobal = true`: persists across navigation, uses `useGlobal` internally
 - `isGlobal = false`: local to component, uses `useState`
 - Auto-rebuilds URL when pathname changes (preserves global query state)
 - Type coercion based on `defaultValue` type
 ### Server State
 Domain-specific hooks in `state/` directories wrap React Query:
 ```tsx
 // src/workspaces/hooks/src/useJobs.ts
 const { jobs, isLoading } = useJobs();
 ```
 ### When to Use What
 | Scenario | Hook |
 |----------|------|
 | API data | Domain hooks (`useJobs`, `useModels`, …) |
 | Shared UI state | `useGlobal` |
 | URL-driven state (filters, pagination) | `useQueryState` |
 | Component-only state | `useState` |
 | Shared UI state that must survive a refresh, per tab | `useSessionState` |
 | Persisted to localStorage | `useLocalStorageState` |
 ## Event Handlers
 **Always use `ev` for event parameters**, not `e`:
 ```tsx
 // ✅ Good
 onChange={(ev) => setName(ev.target.value)}
 onKeyDown={(ev) => {
  if (ev.key === 'Enter') {
    ev.preventDefault();
    handleSubmit();
  }
 }}
 const handleSubmit = async (ev: React.FormEvent) => {
  ev.preventDefault();
  // ...
 };
 // ❌ Bad
 onChange={(e) => setName(e.target.value)}
 ```
 ## React 19 Patterns
 **RefObject includes null**: In React 19, `useRef` returns `RefObject<T | null>`. Update prop types accordingly:
 ```tsx
 // ✅ Good - allow null in ref type
 type PanelProps = {
  triggerRef: React.RefObject<HTMLButtonElement | null>;
 };
 // ❌ Bad - will error when passing useRef result
 type PanelProps = {
  triggerRef: React.RefObject<HTMLButtonElement>;
 };
 ```
 **Hook return types**: Use `ReturnType<typeof hookName>` for typing hook returns in props:
 ```tsx
 import { useJobs } from 'hooks/useJobs';
 type TopHeaderProps = {
  manager: ReturnType<typeof useJobs>;
 };
 ```
 ## Error Handling
 **Toast notifications** via Sonner:
 ```tsx
 import { toast } from "sonner";
 toast.error("Something went wrong");
 toast.success("Saved successfully");
 ```
 API errors automatically trigger via `useClient.config.onError`.
 ## Further Reading
 - `../../CLAUDE.md` — architecture and the frontend route conventions
 - `../../docs/navigation-audit.md` — **authoritative** on routing and selection. The short version:
  addressable state lives in the URL (`useParams` / `?selected=`), never in a channel or a global; rows
  and nav items are real `<Link>`/`<NavLink>`s. Read it before building a screen that selects things.
 - `../../CONVENTIONS.md` — component organisation and React patterns
 - `../workspaces/officerdev/APP_CONVENTIONS.md` — panel apps and the AppRegistry
@@ -1,271 +1,6 @@
 # Frontend Apps
-Shared patterns and conventions for all frontend applications (dashboard, editor, runtime).
+**The instructions live in [`AGENTS.md`](AGENTS.md). Read it first — this file only points there.**
-## UI Components
+Kept separate so agents that look for `AGENTS.md` by convention find the same guidance as those that
-
+look for `CLAUDE.md`, without the two drifting apart.
 ### shadcn/ui (Base)
 Location: `src/workspaces/components/ui/`
 Standard shadcn/ui components with Tailwind CSS. Import via:
 ```tsx
 import { Button } from "@/components/ui/button";
 import { Dialog, DialogContent, DialogTrigger } from "@/components/ui/dialog";
 ```
 ### Custom Components
 Location: `src/workspaces/components/`
 Built on top of shadcn primitives:
 - `Avatar.tsx` - User avatars
 - `Card.tsx` - Custom card wrapper
 - `ColorPicker.tsx` - Color selection
 - `DataTable/` - Table with sorting, filtering, pagination (see below)
 - `Dialogs/` - Common dialog patterns
 - `ErrorDialogs/` - Error display dialogs
 - `MetricCard.tsx` - Stats display card
 - `SearchInput.tsx` - Search with debounce
 - `Select.tsx` - Enhanced select
 - `Slider/` - Custom slider
 - `Tabs/` - Enhanced tabs
 ### DataTable + useDataControl
 A complete data table solution with sorting, filtering, and pagination.
 **Pattern:**
 ```tsx
 import { DataTable, useDataControl } from '@/components/DataTable';
 function JobsLibrary() {
  const { jobs } = useJobs();
  const dataController = useDataControl<Job>(jobs || []);
  return (
    <>
      {/* Wire search input to controller */}
      <SearchInput
        value={dataController.searchQuery}
        handleSearch={dataController.setSearchQuery}
      />
      <DataTable<Job>
        dataController={dataController}
        pageSize={10}
        columns={[
          { field: 'id', label: 'ID', sortKey: 'id' },
          { field: 'type', label: 'Type', sortKey: 'type' },
          {
            field: 'status',
            label: 'Status',
            condition: view === 'All',  // conditional column
            format: ({ value, item }) => <Badge>{value}</Badge>
          },
          {
            label: 'Actions',
            format: ({ item }) => <ActionsCell job={item} />
          },
        ]}
      />
    </>
  );
 }
 ```
 **useDataControl returns:**
 - `data` - Current page of filtered/sorted data
 - `rawData` - Original unfiltered data
 - `searchQuery`, `setSearchQuery` - Search state
 - `searchKeys`, `setSearchKeys` - Which fields to search
 - `sortedBy`, `setSortedBy`, `sortBy` - Sort state
 - `sortKey`, `sortDirection` - Parsed sort info
 - `currentPage`, `changePage`, `pageCount` - Pagination
 - `pageSize`, `setPageSize` - Items per page
 - `setCustomSort` - Custom sort function
 **Column options:**
 - `field` - Key in data object
 - `label` / `labelMobile` - Header text
 - `sortKey` - Enable sorting on this column
 - `format` - Custom render: `({ value, item, data, idx }) => ReactNode`
 - `condition` - Show/hide column: `boolean | () => boolean`
 - `tooltip` - Header tooltip text
 - `headerClassName` / `cellClassName` - Styling
 **Features:**
 - Auto-generates columns from data if not specified
 - Resets to page 1 on search/sort change
 - Search strips diacritics for accent-insensitive matching
 - Built-in pagination bar (shows when data exceeds pageSize)
 ## Hooks
 Location: `src/workspaces/hooks/src/`
 ### Data Fetching - `useClient`
 HTTP client with auth token handling:
 ```tsx
 const client = useClient();
 const data = await client.get<User[]>("/users");
 await client.post("/experiments", payload);
 ```
 Methods: `get`, `getText`, `getBlob`, `post`, `put`, `patch`, `delete`
 Auto-attaches Bearer token from localStorage/sessionStorage.
 ### Forms - `useForm`
 Custom form hook (not react-hook-form):
 ```tsx
 const { state, formRef, update, reset, isValid } = useForm<FormState>(
  initialState,
  validateFn
 );
 return <form ref={formRef}>...</form>;
 ```
 Features:
 - Auto-syncs form inputs with state via `name` attribute
 - Handles checkboxes, radios, selects, number inputs
 - Nested object support via data attributes
 - Validation function support
 ### Other Hooks
 - `useAuth/` - Authentication state and methods
 - `useDebounce` - Debounced values
 - `useDragAndDrop` - Drag and drop functionality
 - `useFullscreen/` - Fullscreen API wrapper
 - `useIsMobile` - Responsive breakpoint detection
 - `useLocalStorageState` - Persisted state
 - `useMounted` - Component mount status
 - `usePopover` - Popover state management
 - `useTimeout` - Timeout management
 - `useTimer` - Interval-based timer
 - `useChatWebSocket` - the chat socket, with reconnect + replay cursor
 - `usePanelChannel` - panel-to-panel signals (refresh buses, NOT selection — selection is the URL)
 - `useJobs` - background jobs
 - `useCustomSorter`, `useImageLoader`, `useIsProduction`, `usePhotoEditor`
 ## State Management
 Uses React Query cache as both server and client state manager.
 ### Global State - `useGlobal`
 Uses React Query cache as a global state store (no Context providers needed):
 ```tsx
 const [value, setValue, refresh, reset] = useGlobal<string>("SIDEBAR_STATE", "expanded");
 // Any component using the same key shares state and reacts to changes
 setValue("collapsed");
 ```
 How it works:
 - `enabled: false` + `staleTime: Infinity` = never fetches, just stores
 - Automatic re-renders when state changes
 - Visible in React Query DevTools
 - Supports functional updates: `setValue(prev => ...)`
 ### URL Query State - `useQueryState`
 Syncs state with URL query parameters:
 ```tsx
 const [page, setPage, reset, clear] = useQueryState<number>("page", 1);
 const [filter, setFilter] = useQueryState<string>("filter", null, true); // isGlobal = true
 ```
 Features:
 - Updates URL via `history.replaceState` (no page reload)
 - `isGlobal = true`: persists across navigation, uses `useGlobal` internally
 - `isGlobal = false`: local to component, uses `useState`
 - Auto-rebuilds URL when pathname changes (preserves global query state)
 - Type coercion based on `defaultValue` type
 ### Server State
 Domain-specific hooks in `state/` directories wrap React Query:
 ```tsx
 // src/workspaces/hooks/src/useJobs.ts
 const { jobs, isLoading } = useJobs();
 ```
 ### When to Use What
 | Scenario | Hook |
 |----------|------|
 | API data | Domain hooks (`useJobs`, `useModels`, …) |
 | Shared UI state | `useGlobal` |
 | URL-driven state (filters, pagination) | `useQueryState` |
 | Component-only state | `useState` |
 | Shared UI state that must survive a refresh, per tab | `useSessionState` |
 | Persisted to localStorage | `useLocalStorageState` |
 ## Event Handlers
 **Always use `ev` for event parameters**, not `e`:
 ```tsx
 // ✅ Good
 onChange={(ev) => setName(ev.target.value)}
 onKeyDown={(ev) => {
  if (ev.key === 'Enter') {
    ev.preventDefault();
    handleSubmit();
  }
 }}
 const handleSubmit = async (ev: React.FormEvent) => {
  ev.preventDefault();
  // ...
 };
 // ❌ Bad
 onChange={(e) => setName(e.target.value)}
 ```
 ## React 19 Patterns
 **RefObject includes null**: In React 19, `useRef` returns `RefObject<T | null>`. Update prop types accordingly:
 ```tsx
 // ✅ Good - allow null in ref type
 type PanelProps = {
  triggerRef: React.RefObject<HTMLButtonElement | null>;
 };
 // ❌ Bad - will error when passing useRef result
 type PanelProps = {
  triggerRef: React.RefObject<HTMLButtonElement>;
 };
 ```
 **Hook return types**: Use `ReturnType<typeof hookName>` for typing hook returns in props:
 ```tsx
 import { useJobs } from 'hooks/useJobs';
 type TopHeaderProps = {
  manager: ReturnType<typeof useJobs>;
 };
 ```
 ## Error Handling
 **Toast notifications** via Sonner:
 ```tsx
 import { toast } from "sonner";
 toast.error("Something went wrong");
 toast.success("Saved successfully");
 ```
 API errors automatically trigger via `useClient.config.onError`.
 ## Further Reading
 - `../../CLAUDE.md` — architecture and the frontend route conventions
 - `../../docs/navigation-audit.md` — **authoritative** on routing and selection. The short version:
  addressable state lives in the URL (`useParams` / `?selected=`), never in a channel or a global; rows
  and nav items are real `<Link>`/`<NavLink>`s. Read it before building a screen that selects things.
 - `../../CONVENTIONS.md` — component organisation and React patterns
 - `../workspaces/officerdev/APP_CONVENTIONS.md` — panel apps and the AppRegistry
@@ -78,8 +78,6 @@ export function App() {
                entry keep working. Only DIRECTORIES live here — an open file stays `?view=`, since it is
                what is on top of you rather than where you are. */}
            <Route path="/files/*" element={<Dashboard.FilesScreen />} />
            <Route path="/calendar" element={<Dashboard.CalendarScreen />} />
            <Route path="/contacts" element={<Dashboard.ContactsScreen />} />
            <Route path="/command-hq" element={<Dashboard.CommandHqScreen />} />
            <Route path="/command-hq/:sessionId" element={<Dashboard.CommandHqScreen />} />
            <Route path="/app-store" element={<Dashboard.AppStoreScreen />} />
@@ -91,13 +89,15 @@ export function App() {
            {/* Installed plugins. Core routes above stay hand-written; everything below is generated from
                what is installed, because a bundler cannot follow a runtime import specifier. The wildcard
                hands the whole subtree to the plugin's own router, which react-router nests natively. */}
            {/* One pair per SCREEN, not per plugin — `screenId` is the key, because a plugin with two
                screens (caldav: Calendar and Contacts) contributes two entries sharing one `appName`. */}
            {installedPlugins.flatMap((plugin) => [
-              <Route key={plugin.appName} path={plugin.route} element={<Dashboard.PluginScreen {...plugin} />} />,
+              <Route key={plugin.screenId} path={plugin.route} element={<Dashboard.PluginScreen {...plugin} />} />,
              // The section pair, exactly as the core screens do it (`/soulseek/:section`): the plugin's
              // panels read `useParams` themselves, so which section is open is the URL rather than state
              // passed between them.
              <Route
-                key={`${plugin.appName}-section`}
+                key={`${plugin.screenId}-section`}
                path={`${plugin.route}/:section`}
                element={<Dashboard.PluginScreen {...plugin} />}
              />,
@@ -106,7 +106,11 @@ export function App() {
            <Route path="/system-monitor/:scope" element={<Dashboard.SystemMonitorScreen />} />
            {/* TEMPORARY / EXPERIMENTAL — offline file transfer over animated QR codes */}
            <Route path="/qr-transfer" element={<Dashboard.QrTransferScreen />} />
-            <Route path="/minesweeper" element={<Dashboard.MinesweeperScreen />} />
+            <Route path="/sendoff" element={<Dashboard.SendOffScreen />} />
            <Route path="/todos" element={<Dashboard.TodosScreen />} />
            <Route path="/bots" element={<Dashboard.BotsScreen />} />
            {/* Route pair: `/bots` is the new-bot state, `/bots/:sessionId` is one of them. */}
            <Route path="/bots/:sessionId" element={<Dashboard.BotsScreen />} />
            <Route path="/activity" element={<Dashboard.ActivityScreen />} />
            <Route path="/activity/:id" element={<Dashboard.ActivityScreen />} />
@@ -7,8 +7,10 @@ import { Input } from '@/components/ui/input';
 import { Label } from '@/components/ui/label';
 import { Button } from '@/components/ui/button';
 import { Card } from '@/components/Card';
 import { useTranslation } from '@/lib/i18n';
 export function ForgotPassword() {
  const { t } = useTranslation();
  const client = useClient('/api/auth');
  const [isSubmitting, setIsSubmitting] = useState(false);
  const [done, setDone] = useState(false);
@@ -34,29 +36,29 @@ export function ForgotPassword() {
    <Card className="md:py-12 md:px-24 flex flex-col gap-6">
      {done ? (
        <div className="text-center">
-          <h2 className="text-2xl font-bold text-duck-dark mb-2">Check your email</h2>
+          <h2 className="text-2xl font-bold text-duck-dark mb-2">{t('auth.checkEmail')}</h2>
          <div className="text-sm text-duck-dark/60">
            <p>
              A password reset link has been sent to <strong>{state.email}</strong>.
            </p>
-            <p>Click it to reset your password.</p>
+            <p>{t('auth.checkEmailHint')}</p>
          </div>
        </div>
      ) : (
        <>
          <div className="text-center">
-            <div className="text-duck-dark text-2xl font-bold">Forgot Password</div>
+            <div className="text-duck-dark text-2xl font-bold">{t('auth.forgotTitle')}</div>
-            <div className="text-duck-dark/60">Enter your email to receive a reset link</div>
+            <div className="text-duck-dark/60">{t('auth.forgotSubtitle')}</div>
          </div>
          <form ref={formRef} onSubmit={handleSubmit} className="grid gap-4">
            <Label className="grid gap-2">
-              <span className="text-duck-dark/70">Email</span>
+              <span className="text-duck-dark/70">{t('auth.email')}</span>
              <Input
                className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
                type="email"
                name="email"
-                placeholder="you@example.com"
+                placeholder={t('auth.emailPlaceholder')}
                autoComplete="email"
              />
            </Label>
@@ -74,7 +76,7 @@ export function ForgotPassword() {
            <div className="text-center text-sm text-duck-dark/60">
              <p>
                <Link to="/" className="text-duck-forest underline hover:text-duck-forest/80">
-                  Back to login
+                  {t('auth.backToLogin')}
                </Link>
              </p>
            </div>
@@ -4,8 +4,10 @@ import { Button } from '@/components/ui/button';
 import { Card } from '@/components/Card';
 import { cn } from '@/lib/utils';
 import { useResetPassword } from './useResetPassword';
 import { useTranslation } from '@/lib/i18n';
 export function ResetPassword() {
  const { t } = useTranslation();
  const { formRef, isValid, tokenStatus, isSubmitting, handleSubmit } = useResetPassword();
  const loading = tokenStatus === 'loading';
  const invalid = tokenStatus === 'invalid';
@@ -15,45 +17,45 @@ export function ResetPassword() {
    <>
      {loading && (
        <Card className="py-12 px-24 flex flex-col gap-6">
-          <div className="text-center text-duck-dark/60">Verifying...</div>
+          <div className="text-center text-duck-dark/60">{t('auth.verifying')}</div>
        </Card>
      )}
      {invalid && (
        <Card className="py-12 px-24 flex flex-col gap-6">
          <div className="text-center">
-            <div className="text-duck-dark text-2xl font-bold">Invalid Link</div>
+            <div className="text-duck-dark text-2xl font-bold">{t('auth.invalidLink')}</div>
-            <div className="text-duck-dark/60">This reset link is invalid or has expired.</div>
+            <div className="text-duck-dark/60">{t('auth.invalidLinkHint')}</div>
          </div>
        </Card>
      )}
      <Card className={cn('flex flex-col gap-6', hideform && 'hidden')}>
        <div className="text-center">
-          <div className="text-duck-dark text-2xl font-bold">Reset Password</div>
+          <div className="text-duck-dark text-2xl font-bold">{t('auth.resetTitle')}</div>
-          <div className="text-duck-dark/60">Enter your new password</div>
+          <div className="text-duck-dark/60">{t('auth.resetSubtitle')}</div>
        </div>
        <form ref={formRef} onSubmit={handleSubmit} className="grid gap-4">
          <div className="grid md:flex gap-4">
            <Label className="grid gap-2 flex-1">
-              <span className="text-duck-dark/70">Password</span>
+              <span className="text-duck-dark/70">{t('auth.password')}</span>
              <Input
                className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
                type="password"
                name="password"
-                placeholder="Min 12 characters"
+                placeholder={t('auth.minChars')}
                autoComplete="new-password"
              />
            </Label>
            <Label className="grid gap-2 flex-1">
-              <span className="text-duck-dark/70">Confirm Password</span>
+              <span className="text-duck-dark/70">{t('auth.confirmPassword')}</span>
              <Input
                className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
                type="password"
                name="confirmPassword"
-                placeholder="Confirm your password"
+                placeholder={t('auth.confirmPlaceholder')}
                autoComplete="new-password"
              />
            </Label>
@@ -65,7 +67,7 @@ export function ResetPassword() {
              disabled={!isValid || isSubmitting}
              className="w-full h-11 bg-duck-yellow hover:bg-duck-yellow/90 text-duck-teal font-bold text-lg transition-all duration-200 hover:scale-105 cursor-pointer disabled:opacity-50 disabled:hover:scale-100"
            >
-              {isSubmitting ? 'Resetting...' : 'Reset Password'}
+              {isSubmitting ? 'Resetting...' : t('auth.resetTitle')}
            </Button>
          </div>
        </form>
@@ -4,8 +4,10 @@ import { toast } from 'sonner';
 import { useMounted } from 'hooks/useMounted';
 import { useForm } from 'hooks/useForm';
 import { useClient } from 'hooks/useClient';
 import { useTranslation } from '@/lib/i18n';
 export const useResetPassword = () => {
  const { t } = useTranslation();
  const isMounted = useMounted();
  const navigate = useNavigate();
  const client = useClient('/api/auth');
@@ -44,7 +46,7 @@ export const useResetPassword = () => {
        password: state.password,
        verificationCode,
      });
-      toast.success('Password reset successfully. Please sign in.');
+      toast.success(t('auth.resetOk'));
      navigate('/');
    } catch (ex) {
      const error = ex as { message?: string };
@@ -7,8 +7,10 @@ import { Input } from '@/components/ui/input';
 import { Label } from '@/components/ui/label';
 import { Card } from '@/components/Card';
 import { useForm } from 'hooks/useForm';
 import { useTranslation } from '@/lib/i18n';
 export function Bootstrap() {
  const { t } = useTranslation();
  const authClient = useClient('/api/auth');
  const navigate = useNavigate();
  const [isSubmitting, setIsSubmitting] = useState(false);
@@ -30,7 +32,7 @@ export function Bootstrap() {
        password: state.password,
        confirmPassword: state.confirmPassword,
      });
-      toast.success('Administrator account created. Please sign in.');
+      toast.success(t('auth.bootstrapOk'));
      navigate('/');
    } catch (ex) {
      const error = ex as { message?: string };
@@ -43,35 +45,35 @@ export function Bootstrap() {
  return (
    <Card className="md:min-w-[480px] flex flex-col gap-6">
      <div className="text-center">
-        <div className="text-duck-dark text-2xl font-bold">Welcome, Admin</div>
+        <div className="text-duck-dark text-2xl font-bold">{t('auth.bootstrapTitle')}</div>
-        <div className="text-duck-dark/60">Create your administrator account</div>
+        <div className="text-duck-dark/60">{t('auth.bootstrapSubtitle')}</div>
      </div>
      <form ref={formRef} onSubmit={handleBootstrap} className="grid gap-4">
        <Label className="grid gap-2">
-          <span className="text-duck-dark/70">Name</span>
+          <span className="text-duck-dark/70">{t('auth.name')}</span>
          <Input
            className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
            type="text"
            name="name"
-            placeholder="Your name"
+            placeholder={t('auth.namePlaceholder')}
            autoComplete="name"
          />
        </Label>
        <Label className="grid gap-2">
-          <span className="text-duck-dark/70">Email</span>
+          <span className="text-duck-dark/70">{t('auth.email')}</span>
          <Input
            className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
            type="email"
            name="email"
-            placeholder="admin@example.com"
+            placeholder={t('auth.adminEmailPlaceholder')}
            autoComplete="email"
          />
        </Label>
        <Label className="grid gap-2">
-          <span className="text-duck-dark/70">Username</span>
+          <span className="text-duck-dark/70">{t('auth.username')}</span>
          <Input
            className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
            type="text"
@@ -83,23 +85,23 @@ export function Bootstrap() {
        <div className="grid md:flex gap-4">
          <Label className="grid gap-2 flex-1">
-            <span className="text-duck-dark/70">Password</span>
+            <span className="text-duck-dark/70">{t('auth.password')}</span>
            <Input
              className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
              type="password"
              name="password"
-              placeholder="Min 12 characters"
+              placeholder={t('auth.minChars')}
              autoComplete="new-password"
            />
          </Label>
          <Label className="grid gap-2 flex-1">
-            <span className="text-duck-dark/70">Confirm Password</span>
+            <span className="text-duck-dark/70">{t('auth.confirmPassword')}</span>
            <Input
              className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
              type="password"
              name="confirmPassword"
-              placeholder="Confirm your password"
+              placeholder={t('auth.confirmPlaceholder')}
              autoComplete="new-password"
            />
          </Label>
@@ -8,12 +8,14 @@ import { toast } from 'sonner';
 import { useForm } from 'hooks/useForm';
 import { useAuth } from 'hooks/useAuth';
 import { useGlobal } from 'hooks/useGlobal';
 import { useTranslation } from '@/lib/i18n';
 const initialState: LoginFormState = {
  // email: 'pastilhas@pastilhas.dev',
  // password: '',
 };
 export function Login() {
  const { t } = useTranslation();
  const [isSubmitting, setIsSubmitting] = useState(false);
  const { state, formRef, update, isValid } = useForm<LoginFormState>(initialState, validateForm);
  const { signin } = useAuth();
@@ -40,20 +42,20 @@ export function Login() {
  return (
    <Card className="md:py-6 md:px-24 md:min-w-[480px] flex flex-col gap-6">
      <div className="text-center">
-        <div className="text-duck-dark text-2xl font-bold">Welcome Back</div>
+        <div className="text-duck-dark text-2xl font-bold">{t('auth.signInTitle')}</div>
-        <div className="text-duck-dark/60">Sign in to your account</div>
+        <div className="text-duck-dark/60">{t('auth.signInSubtitle')}</div>
      </div>
      <form ref={formRef} onSubmit={handleSubmit} className="grid gap-4">
        <Label className="grid gap-2">
-          <span className="text-duck-dark/70">Email or username</span>
+          <span className="text-duck-dark/70">{t('auth.emailOrUsername')}</span>
          <Input
            className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
            // `text`, not `email`: the browser refuses to submit a username under type="email", so the
            // field would have validated the user out of an account they have.
            type="text"
            name="email"
-            placeholder="you@example.com"
+            placeholder={t('auth.emailPlaceholder')}
            // `username` rather than `email`, which is what password managers expect for a field that
            // takes either — and it is the value they already store beside the password.
            autoComplete="username"
@@ -61,12 +63,12 @@ export function Login() {
        </Label>
        <Label className="grid gap-2">
-          <span className="text-duck-dark/70">Password</span>
+          <span className="text-duck-dark/70">{t('auth.password')}</span>
          <Input
            className="h-11 bg-background/60 border-duck-dark/20 text-duck-dark placeholder:text-duck-dark/40"
            type="password"
            name="password"
-            placeholder="Your password"
+            placeholder={t('auth.passwordPlaceholder')}
            autoComplete="current-password"
          />
        </Label>
@@ -90,7 +92,7 @@ export function Login() {
          {/* </p> */}
          <p>
            <Link to="/auth/forgot-password" className="text-duck-forest underline hover:text-duck-forest/80">
-              Forgot password?
+              {t('auth.forgotPassword')}
            </Link>
          </p>
        </div>
@@ -1,3 +1,5 @@
 import { useTranslation } from '@/lib/i18n';
 type DebugPanelProps = {
  fullControlMode: boolean;
  cameraInfo: {
@@ -13,9 +15,10 @@ type DebugPanelProps = {
 };
 export function DebugPanel({ fullControlMode, cameraInfo, modelInfo }: DebugPanelProps) {
  const { t } = useTranslation();
  return (
    <div className="fixed top-4 left-4 bg-black/80 text-white p-4 rounded text-xs font-mono space-y-2 z-[100]">
-      <div className="font-bold text-blue-400">Controls:</div>
+      <div className="font-bold text-blue-400">{t('auth.debug.controls')}</div>
      <div className={fullControlMode ? 'text-green-300' : 'text-yellow-300'}>
        Mode: {fullControlMode ? 'FULL CONTROL' : 'ROTATION ONLY'}
      </div>
@@ -29,12 +32,12 @@ export function DebugPanel({ fullControlMode, cameraInfo, modelInfo }: DebugPane
      <div>* Ctrl+Alt+Enter: Toggle full control</div>
      <div>* Ctrl+Alt+D: Toggle debug panel</div>
-      <div className="font-bold text-green-400 pt-2">Camera:</div>
+      <div className="font-bold text-green-400 pt-2">{t('auth.debug.camera')}</div>
      <div>Position: [{cameraInfo.cameraPosition.map((v) => v.toFixed(2)).join(', ')}]</div>
      <div>Target: [{cameraInfo.target.map((v) => v.toFixed(2)).join(', ')}]</div>
      <div>Zoom: {cameraInfo.zoom.toFixed(2)}</div>
-      <div className="font-bold text-yellow-400 pt-2">Model:</div>
+      <div className="font-bold text-yellow-400 pt-2">{t('auth.debug.model')}</div>
      <div>Position: [{modelInfo.position.map((v) => v.toFixed(2)).join(', ')}]</div>
      <div>Rotation: [{modelInfo.rotation.map((v) => v.toFixed(2)).join(', ')}]</div>
      <div>Scale: {modelInfo.scale.toFixed(2)}</div>
@@ -2,6 +2,7 @@ import { useEffect, useRef, useState } from 'react';
 import { Link, useParams } from 'react-router';
 import { useClient } from 'hooks/useClient';
 import { Radio, FileText, Activity as ActivityIcon } from 'lucide-react';
 import { useTranslation } from '@/lib/i18n';
 type TaskRow = { id: string; source: 'harness'; cwd: string; sizeBytes: number; updatedAt: number; active: boolean };
 type DetachedRow = { id: string; source: 'detached'; path: string; announcedAt: number };
@@ -15,6 +16,7 @@ const MAX_LINES = 600;
 // params (`task=` for a harness file, `path=` for a detached job), so the URL carries the id only and
 // the screen re-derives the param from the registry row — one address shape for both kinds.
 export const ActivityScreen = () => {
  const { t } = useTranslation();
  const { token, get } = useClient();
  const [reg, setReg] = useState<Registry>({ tasks: [], detached: [] });
  const [regLoaded, setRegLoaded] = useState(false);
@@ -87,30 +89,32 @@ export const ActivityScreen = () => {
    <div className="flex h-full w-full">
      <aside className="flex w-72 shrink-0 flex-col overflow-y-auto border-r border-border p-3">
        <div className="mb-3 flex items-center gap-2 text-sm font-semibold text-foreground">
-          <ActivityIcon size={16} className="text-primary" /> Activity
+          <ActivityIcon size={16} className="text-primary" /> {t('activity.title')}
        </div>
        <div className="mb-1 px-1 text-xs font-medium uppercase tracking-wide text-muted-foreground">
-          Background tasks
+          {t('activity.backgroundTasks')}
        </div>
-        {reg.tasks.length === 0 && <p className="px-2 py-1 text-xs text-muted-foreground">none running</p>}
+        {reg.tasks.length === 0 && (
-        {reg.tasks.map((t) => (
+          <p className="px-2 py-1 text-xs text-muted-foreground">{t('activity.noneRunning')}</p>
        )}
        {reg.tasks.map((task) => (
          <Link
-            key={t.id}
+            key={task.id}
-            to={`/activity/${encodeURIComponent(t.id)}`}
+            to={`/activity/${encodeURIComponent(task.id)}`}
-            className={rowCls(selectedId === t.id)}
+            className={rowCls(selectedId === task.id)}
-            title={t.cwd}
+            title={task.cwd}
          >
            <span
-              className={`inline-block h-2 w-2 shrink-0 rounded-full ${t.active ? 'bg-success animate-pulse' : 'bg-muted-foreground/40'}`}
+              className={`inline-block h-2 w-2 shrink-0 rounded-full ${task.active ? 'bg-success animate-pulse' : 'bg-muted-foreground/40'}`}
            />
-            <span className="truncate font-mono text-xs">{t.id}</span>
+            <span className="truncate font-mono text-xs">{task.id}</span>
          </Link>
        ))}
        {reg.detached.length > 0 && (
          <div className="mb-1 mt-4 px-1 text-xs font-medium uppercase tracking-wide text-muted-foreground">
-            Detached
+            {t('activity.detached')}
          </div>
        )}
        {reg.detached.map((d) => (
@@ -169,7 +173,7 @@ export const ActivityScreen = () => {
                      no run called <span className="font-mono">{selectedId}</span> is in the registry — it finished, or
                      it never started.{' '}
                      <Link to="/activity" className="underline">
-                        Back to the list
+                        {t('activity.backToList')}
                      </Link>
                    </>
                  ) : (
@@ -187,7 +191,7 @@ export const ActivityScreen = () => {
          </>
        ) : (
          <div className="flex h-full items-center justify-center text-sm text-muted-foreground">
-            Select a task to follow its live output
+            {t('activity.selectTask')}
          </div>
        )}
      </main>
@@ -0,0 +1,175 @@
 import { useState } from 'react';
 import { Bot, Check, Pencil, Plus, Trash2, X } from 'lucide-react';
 import { Link, useNavigate, useParams } from 'react-router';
 import { useClaudeSessions, type ClaudeSessionSummary } from 'state/useClaudeSessions';
 /**
 * The bots, as cards — the same object Command HQ gives a commander.
 *
 * ── Why not the chat session list ──
 *
 * A bot IS a chat underneath, and that is an implementation detail nobody using this should have to hold.
 * The generic session list says "conversation, last touched at" because that is what a conversation is. A
 * bot is a thing you name, check on, and eventually delete — so it gets a card with its name, its id, and
 * whether it is watching, exactly as a commander does.
 *
 * ── The id pill ──
 *
 * A commander shows `#54`, its directory. A bot has no directory of its own — they share one — so its id
 * is the first eight characters of its session, which is also what an `@mention` carries. Seeing the same
 * eight characters in both places is the point: the pill is what you type to reference it.
 */
 const shortId = (id: string) => id.slice(0, 8);
 type CardProps = {
  bot: ClaudeSessionSummary;
  selected: boolean;
  onRename: (id: string, title: string) => Promise<unknown>;
  onDelete: (id: string) => Promise<unknown>;
 };
 const BotCard = ({ bot, selected, onRename, onDelete }: CardProps) => {
  const navigate = useNavigate();
  const [confirming, setConfirming] = useState(false);
  const [renaming, setRenaming] = useState(false);
  const [draft, setDraft] = useState(bot.title);
  const commit = async () => {
    const next = draft.trim();
    setRenaming(false);
    if (next && next !== bot.title) await onRename(bot.id, next);
  };
  return (
    <div
      className={`group relative flex flex-col gap-1.5 rounded-xl border bg-background p-3 transition-colors hover:border-primary/40 hover:bg-muted/40 ${
        selected ? 'border-primary/60 ring-1 ring-primary/30' : 'border-border'
      }`}
    >
      {/* The whole card is the link, with the controls layered above it — same arrangement as a commander
          card, so a click anywhere opens the bot and the buttons still work. */}
      {!renaming && <Link to={`/bots/${bot.id}`} className="absolute inset-0" aria-label={bot.title} />}
      <div className="flex items-center gap-2 pr-12">
        <Bot className="size-3.5 shrink-0 text-muted-foreground" />
        {renaming ? (
          <form
            className="z-10 flex min-w-0 flex-1 items-center gap-1"
            onSubmit={(ev) => {
              ev.preventDefault();
              void commit();
            }}
          >
            <input
              autoFocus
              value={draft}
              onChange={(ev) => setDraft(ev.target.value)}
              onKeyDown={(ev) => ev.key === 'Escape' && setRenaming(false)}
              className="min-w-0 flex-1 rounded border bg-transparent px-1 py-0.5 text-sm"
            />
            <button type="submit" className="rounded p-0.5 text-primary" aria-label="Save name">
              <Check className="size-3.5" />
            </button>
          </form>
        ) : (
          <>
            <span className="truncate text-sm font-medium">{bot.title || '(unnamed)'}</span>
            <span className="shrink-0 font-mono text-[11px] text-muted-foreground" title={bot.id}>
              #{shortId(bot.id)}
            </span>
          </>
        )}
      </div>
      <div className="flex items-center justify-between text-[11px] text-muted-foreground">
        <span>
          {bot.messageCount} message{bot.messageCount === 1 ? '' : 's'}
        </span>
        <span title={bot.updatedAt}>{new Date(bot.updatedAt).toLocaleDateString()}</span>
      </div>
      {confirming ? (
        <div className="absolute right-1.5 top-1.5 z-10 flex items-center gap-1 rounded-lg bg-background/95 p-0.5 shadow">
          <button
            onClick={() => {
              void onDelete(bot.id);
              // Leaving the route pointed at something that no longer exists would render an empty chat.
              if (selected) void navigate('/bots');
            }}
            className="rounded p-1 text-destructive hover:bg-destructive/10"
            title="Delete this bot"
          >
            <Check className="size-3.5" />
          </button>
          <button onClick={() => setConfirming(false)} className="rounded p-1 opacity-50 hover:opacity-100">
            <X className="size-3.5" />
          </button>
        </div>
      ) : (
        !renaming && (
          <div className="absolute right-1.5 top-1.5 z-10 flex items-center gap-0.5 opacity-0 transition-opacity focus-within:opacity-100 group-hover:opacity-100">
            <button
              onClick={() => {
                setDraft(bot.title);
                setRenaming(true);
              }}
              className="rounded p-1 text-muted-foreground hover:text-foreground"
              title="Rename"
            >
              <Pencil className="size-3.5" />
            </button>
            <button
              onClick={() => setConfirming(true)}
              className="rounded p-1 text-muted-foreground hover:text-destructive"
              title="Delete"
            >
              <Trash2 className="size-3.5" />
            </button>
          </div>
        )
      )}
    </div>
  );
 };
 export const BotsList = () => {
  const { sessionId } = useParams();
  const { sessions, isLoading, renameSession, deleteSession } = useClaudeSessions(null, {
    chatContext: { context: 'bots' },
  });
  return (
    <nav className="flex size-full flex-col">
      <header className="flex items-center justify-between border-b px-3 py-2">
        <span className="text-sm font-medium">
          {sessions.length} {sessions.length === 1 ? 'bot' : 'bots'}
        </span>
        {/* `/bots` with no id IS the new-bot state: an empty composer, and the first sentence arms it. */}
        <Link to="/bots" title="New bot" className="text-muted-foreground hover:text-foreground">
          <Plus className="size-4" />
        </Link>
      </header>
      {isLoading ? (
        <p className="p-3 text-xs text-muted-foreground">Loading…</p>
      ) : sessions.length === 0 ? (
        <div className="flex flex-1 flex-col items-center justify-center gap-2 p-4 text-center">
          <Bot className="size-7 text-muted-foreground" />
          <p className="text-sm text-muted-foreground">No bots yet.</p>
          <p className="text-[11px] leading-relaxed text-muted-foreground">
            Say what you want watched — “notify me when x.com is down” — and it arms itself.
          </p>
        </div>
      ) : (
        <ul className="flex flex-1 flex-col gap-2 overflow-auto p-2">
          {sessions.map((bot) => (
            <li key={bot.id}>
              <BotCard bot={bot} selected={bot.id === sessionId} onRename={renameSession} onDelete={deleteSession} />
            </li>
          ))}
        </ul>
      )}
    </nav>
  );
 };
@@ -0,0 +1,59 @@
 import type { LayoutNode } from 'officerdev';
 import { WorkspaceView, ChatPanelWrapper } from 'officerdev';
 import { useParams } from 'react-router';
 import { useAuthoredLayout } from 'state/useAuthoredLayout';
 import { defaultLayout } from './defaultLayout';
 import { BotsList } from './BotsList';
 /**
 * `/bots` — one sentence arms a watch, and the conversation stays open to widen it.
 *
 * ── The same shape as Command HQ ──
 *
 * A narrow list on the left, the conversation on the right, and the selection in the URL as a route pair:
 * `/bots` is the new-bot state, `/bots/:sessionId` is one of them. That is the convention
 * `docs/navigation-audit.md` sets and the one Command HQ already follows, so a bot is linkable and a
 * reload keeps the one you were reading.
 *
 * ── Why the panels are supplied here rather than registered ──
 *
 * Every bot runs in one shared directory, which the server resolves from `context: 'bots'`. The registry's
 * `officerdev/chat` derives its context from the workspace and would land on none of it — it would list
 * and resume the caller's HOME, which is exactly what this screen did on its first outing. `components` is
 * the prop for a screen that supplies its own chat panel, and it carries the header, so the picker lists
 * bots rather than every chat on the machine.
 *
 * The instructions a bot runs under are `$DATA_PATH/<email>/bots/CLAUDE.md`, written by the server on
 * every turn — `api/bots/brief.ts`.
 */
 const CHAT_CONTEXT = { context: 'bots' } as const;
 const BotsChat = ({ panelId }: { panelId: string }) => {
  const { sessionId } = useParams();
  return (
    <div className="flex h-full min-h-0 flex-col">
      {/* `sessionId ?? null` — null is "the screen chose a new chat", which is not the same as having no
          opinion. On `/bots` with no id that is exactly right: an empty composer waiting for the sentence. */}
      <ChatPanelWrapper panelId={panelId} chatContext={CHAT_CONTEXT} sessionId={sessionId ?? null} />
    </div>
  );
 };
 export const BotsScreen = () => {
  const workspace = useAuthoredLayout('screens/bots', defaultLayout as LayoutNode);
  return (
    <WorkspaceView
      workspace={workspace}
      locked
      appTypes={{ allowed: ['bots-list', 'bots-chat'], fallback: 'bots-chat' }}
      components={{
        'bots-list': BotsList,
        // No header picker: the cards on the left are the list, and a second one in the panel bar would be
        // the same choice offered twice. Command HQ does not have one either, for the same reason.
        'bots-chat': BotsChat,
      }}
    />
  );
 };
@@ -0,0 +1,16 @@
 import type { LayoutNode } from 'officerdev';
 // The bots down the left, the conversation on the right — the same division Command HQ makes, and for the
 // same reason: the list is names and the right-hand side is the only thing anybody reads.
 //
 // No category pane. Commanders have one because a commander is a job somebody files; a bot is a sentence,
 // and a filter over a handful of one-line watches would be furniture.
 export const defaultLayout: LayoutNode = {
  type: 'group',
  id: 'bots-root',
  direction: 'horizontal',
  children: [
    { node: { type: 'panel', id: 'bots-list', appType: 'bots-list' }, size: 24 },
    { node: { type: 'panel', id: 'bots-chat', appType: 'bots-chat' }, size: 76 },
  ],
 };
@@ -0,0 +1 @@
 export { BotsScreen } from './BotsScreen';
@@ -1,27 +0,0 @@
 import type { LayoutNode } from 'officerdev';
 import { WorkspaceView } from 'officerdev';
 import { useDashboardState } from 'state/useDashboardState';
 import { defaultLayout } from './defaultLayout';
 // /calendar uses the Workspace/Panel system (like /command-hq): the calendar list on the left, the
 // selected calendar's agenda on the right. Both panels read the officer-caldav sidecar through the
 // /api/caldav auth proxy, which holds no DAV credentials of its own.
 //
 // There is no :param route pair here and so no <Navigate> guard: a collection id is a DAV path with
 // slashes in it, so the selection lives in ?collection= on this same route. An absent or unknown value
 // resolves to the first collection inside the panels rather than by redirecting, because until the
 // collection list has loaded there is no canonical URL to redirect to.
 export const CalendarScreen = () => {
  const workspace = useDashboardState<LayoutNode>('screens/calendar', defaultLayout);
  return (
    <div className="h-full w-full pt-2">
      <WorkspaceView
        workspace={workspace}
        locked
        appTypes={{ allowed: ['calendar-nav', 'calendar-view'], fallback: 'calendar-view' }}
      />
    </div>
  );
 };
@@ -1,11 +0,0 @@
 import type { LayoutNode } from 'officerdev';
 export const defaultLayout: LayoutNode = {
  type: 'group',
  id: 'calendar-root',
  direction: 'horizontal',
  children: [
    { node: { type: 'panel', id: 'calendar-nav', appType: 'calendar-nav' }, size: 22 },
    { node: { type: 'panel', id: 'calendar-view', appType: 'calendar-view' }, size: 78 },
  ],
 };
@@ -1 +0,0 @@
 export * from './CalendarScreen';
@@ -12,6 +12,7 @@ import { Dialog, DialogContent, DialogHeader, DialogTitle, DialogDescription } f
 import { useClient } from 'hooks/useClient';
 import { Card } from '@/components/Card';
 import { useChat, EmbeddableChat } from 'officerdev';
 import { useTranslation } from '@/lib/i18n';
 type CapabilitySummary = {
  dirName: string;
  name: string;
@@ -23,6 +24,8 @@ export type CapabilityDetail = CapabilitySummary & {
  rawFrontmatter: string;
  filePath: string;
  chatSessionId: string | null;
  /** Only tasks carry this today: the plugin that ships it, or null/absent when it is the owner's own. */
  plugin?: string | null;
 };
 type CapabilityListProps = {
@@ -277,12 +280,18 @@ export const CapabilityChat = ({
  description,
  onResponseEnd,
 }: CapabilityChatProps) => {
  const { t } = useTranslation();
  const seedFile = `${kind.toUpperCase()}.md`;
  const genericPrefix = `<frontmatter>\ninput file: ${filePath}\n${seedFile}: ${filePath}\ndir: ${resourceDir}\n\nBe aware of any extra files alongside the same dir as the ${kind} file we're handling, for possible extra context. You can also, if pertinent, create scripts or other files that will help you in the future.\n</frontmatter>`;
  const promptFrontmatter = isNew ? (buildCreationPrefix(kind, filePath, resourceDir) ?? genericPrefix) : genericPrefix;
  /*
    The composer's PRE-FILLED text, which the reader sees and edits — so it is translated. The hidden
    `promptFrontmatter` above is not: that one instructs the agent and carries file paths, and is
    machine-facing rather than something anybody reads.
  */
  const defaultInput = isNew
-    ? (description ?? `Help me create the content for this new ${kind} file`)
+    ? (description ?? t('capability.createPrompt', { kind: kind.toLowerCase() }))
-    : `Help me understand and improve this ${kind} file`;
+    : t('capability.improvePrompt', { kind: kind.toLowerCase() });
  const chat = useChat(undefined, undefined, { replaceUrl: false });
@@ -301,6 +310,7 @@ export const CapabilityChat = ({
 };
 export const FrontmatterBlock = ({ yaml }: { yaml: string }) => {
  const { t } = useTranslation();
  const [open, setOpen] = useState(false);
  return (
@@ -310,7 +320,7 @@ export const FrontmatterBlock = ({ yaml }: { yaml: string }) => {
        className="flex w-full items-center gap-1.5 px-3 py-1.5 text-duck-dark/50 hover:text-duck-dark/70 cursor-pointer transition-colors"
      >
        <ChevronRight className={`h-3.5 w-3.5 transition-transform ${open ? 'rotate-90' : ''}`} />
-        <span className="text-xs font-medium">Frontmatter</span>
+        <span className="text-xs font-medium">{t('capability.frontmatter')}</span>
      </button>
      {open && (
        <pre className="px-4 pb-3 text-xs text-duck-dark/60 whitespace-pre-wrap font-mono leading-relaxed">{yaml}</pre>
@@ -330,6 +340,7 @@ export const CapabilityList = ({
  showCreate,
  onShowCreateChange,
 }: CapabilityListProps) => {
  const { t, tUi } = useTranslation();
  const client = useClient();
  const qc = useQueryClient();
  const [internalCreating, setInternalCreating] = useState(false);
@@ -356,7 +367,7 @@ export const CapabilityList = ({
      setNewName('');
      onCreate(res.dirName);
    } catch {
-      toast.error(`Failed to create ${kind}`);
+      toast.error(t('capability.createFailed', { kind: kind.toLowerCase() }));
    }
  };
@@ -427,7 +438,7 @@ export const CapabilityList = ({
            <input
              value={internalSearch}
              onChange={(ev) => setInternalSearch(ev.target.value)}
-              placeholder={`Search ${kind.toLowerCase()}s...`}
+              placeholder={t('capability.searchPlaceholder', { kind: `${kind.toLowerCase()}s` })}
              className="w-full rounded border border-duck-dark/15 bg-background/80 pl-7 pr-2 py-1 text-base md:text-sm text-duck-dark placeholder:text-duck-dark/30 focus:outline-none focus:ring-1 focus:ring-duck-teal/30"
            />
          </div>
@@ -452,7 +463,7 @@ export const CapabilityList = ({
          <p className="text-sm text-duck-dark/40 px-4 py-6 text-center">No {kind.toLowerCase()}s found</p>
        )}
        {items.length > 0 && filtered.length === 0 && (
-          <p className="text-sm text-duck-dark/40 px-4 py-6 text-center">No matches</p>
+          <p className="text-sm text-duck-dark/40 px-4 py-6 text-center">{t('capability.noMatches')}</p>
        )}
      </div>
    </>
@@ -469,6 +480,7 @@ export const CapabilityList = ({
 * them for free — no reset effect racing the navigation. `edit` also makes the editor pane linkable.
 */
 export const CapabilityPage = ({ kind, endpoint, queryKey, basePath }: CapabilityPageProps) => {
  const { t, tUi } = useTranslation();
  const client = useClient();
  const qc = useQueryClient();
  const navigate = useNavigate();
@@ -497,7 +509,7 @@ export const CapabilityPage = ({ kind, endpoint, queryKey, basePath }: Capabilit
      navigate(basePath, { replace: true });
      await qc.invalidateQueries({ queryKey: [queryKey] });
    } catch {
-      toast.error(`Failed to delete ${kind}`);
+      toast.error(t('capability.deleteFailed', { kind: kind.toLowerCase() }));
    }
  };
@@ -526,9 +538,19 @@ export const CapabilityPage = ({ kind, endpoint, queryKey, basePath }: Capabilit
                <ArrowLeft className="h-4 w-4 text-duck-dark/60" />
              </Link>
              <span className="text-sm font-medium text-duck-dark/70 flex-1">
-                {detail?.name ?? `Select a ${kind.toLowerCase()}`}
+                {detail?.name ?? t('capability.selectOne', { kind: kind.toLowerCase() })}
              </span>
-              {detail && (
+              {/*
                A plugin's capability is read where it lives, in a git checkout that `plugins:update`
                pulls. So there is nothing to offer here: an edit would be overwritten by the next update,
                and the delete refuses server-side (409). Say whose it is instead of showing two controls
                that cannot work.
              */}
              {detail?.plugin ? (
                <span className="text-xs text-duck-dark/40">
                  {t('capability.fromPlugin', { plugin: detail.plugin })}
                </span>
              ) : detail ? (
                <>
                  <button
                    onClick={() => setEditing(!editing)}
@@ -543,7 +565,7 @@ export const CapabilityPage = ({ kind, endpoint, queryKey, basePath }: Capabilit
                    <Trash2 className="h-3.5 w-3.5 text-duck-dark/50 hover:text-red-500" />
                  </button>
                </>
-              )}
+              ) : null}
            </div>
            <div className="overflow-y-auto flex-1 p-6">
              {detail?.rawFrontmatter && <FrontmatterBlock yaml={detail.rawFrontmatter} />}
@@ -554,10 +576,10 @@ export const CapabilityPage = ({ kind, endpoint, queryKey, basePath }: Capabilit
                  </ReactMarkdown>
                </article>
              ) : detail ? (
-                <p className="text-sm text-duck-dark/40 text-center mt-12">Empty file</p>
+                <p className="text-sm text-duck-dark/40 text-center mt-12">{t('capability.emptyFile')}</p>
              ) : (
                <p className="text-sm text-duck-dark/40 text-center mt-12">
-                  Select a {kind.toLowerCase()} to view its contents
+                  {t('capability.selectToView', { kind: kind.toLowerCase() })}
                </p>
              )}
            </div>
@@ -606,10 +628,10 @@ export const CapabilityPage = ({ kind, endpoint, queryKey, basePath }: Capabilit
          </DialogHeader>
          <div className="flex justify-end gap-2 mt-2">
            <Button variant="outline" onClick={() => setDeleteConfirm(false)} className="cursor-pointer">
-              Cancel
+              {tUi('button.cancel')}
            </Button>
            <Button variant="destructive" onClick={handleDelete} className="cursor-pointer">
-              Delete
+              {t('capability.delete')}
            </Button>
          </div>
        </DialogContent>
@@ -9,6 +9,7 @@ import { errorText } from 'helpers/error-text';
 import { useDashboardState } from 'state/useDashboardState';
 import type { ClaudeSessionDetail } from 'state/useClaudeSessions';
 import { defaultLayout, hasAppType } from './defaultLayout';
 import { useTranslation } from '@/lib/i18n';
 // How many messages to render on first open (anchored to the bottom); scroll-up pages older ones in.
 const CHAT_TAIL = 20;
@@ -18,6 +19,7 @@ type SessionListPageProps = {
 };
 export const SessionListPage = ({ isNew }: SessionListPageProps) => {
  const { t } = useTranslation();
  // The group is a path suffix now, not ?cwd= — see officerdev/apps/ChatHistory/chat-routes.ts.
  const { sessionId, '*': splat } = useParams<{ sessionId: string; '*': string }>();
  const groupCwd = cwdFromSplat(splat);
@@ -122,7 +124,7 @@ export const SessionListPage = ({ isNew }: SessionListPageProps) => {
        // Falling back to a bare id still opens a usable pane, but silently: you get an empty chat and
        // no hint that the transcript could not be read, which is indistinguishable from a new session.
        // Most often the id is stale — the transcript was deleted or pruned out from under the link.
-        toast.error(`Could not load this conversation: ${errorText(err, 'not found')}`);
+        toast.error(t('chatHistory.loadFailed', { reason: errorText(err, 'not found') }));
        setSelected({ id: sessionId });
      }
    })();
@@ -1,12 +1,16 @@
 import { CodeEditorView } from 'officerdev';
 import { Widget } from 'widgets/Widget';
 import { useTranslation } from '@/lib/i18n';
-export const CodeEditor = () => (
+export const CodeEditor = () => {
  const { t } = useTranslation();
  return (
    <div className="h-full w-full flex items-center justify-center">
-    <Widget title="Code Editor" className="h-[70vh] w-[70vw] overflow-hidden" resizable moveable>
+      <Widget title={t('nav.codeEditor')} className="h-[70vh] w-[70vw] overflow-hidden" resizable moveable>
        {/* The screen is the one editor that owns the address bar, so the open file is `?file=`. The panel
          wrapper deliberately does not pass this: a dashboard can hold two editors. */}
        <CodeEditorView className="h-full w-full" urlState />
      </Widget>
    </div>
-);
+  );
 };
@@ -1,6 +1,6 @@
 import { useEffect } from 'react';
 import type { LayoutNode } from 'officerdev';
-import { WorkspaceView } from 'officerdev';
+import { WorkspaceView, useCommanderFilesPanel } from 'officerdev';
 import { useDashboardState } from 'state/useDashboardState';
 import { defaultLayout, isLegacyThreeColumn } from './defaultLayout';
@@ -10,6 +10,7 @@ import { defaultLayout, isLegacyThreeColumn } from './defaultLayout';
 export const CommandHqScreen = () => {
  const workspace = useDashboardState<LayoutNode>('screens/command-hq', defaultLayout);
  const ephemeral = useCommanderFilesPanel();
  /*
    Move a saved three-column layout onto the two-column one.
@@ -26,6 +27,9 @@ export const CommandHqScreen = () => {
  return (
    <div className="h-full w-full pt-2">
      {/* The commander's own file browser is a layout of its own, rendered beside this one — it never
          enters `workspace.value`, so this screen stays locked and the allow-list does not have to know
          about it. Same trade `/files` makes for the file viewer. */}
      <WorkspaceView
        workspace={workspace}
        locked
@@ -33,6 +37,7 @@ export const CommandHqScreen = () => {
          allowed: ['command-hq-categories', 'command-hq-grid', 'command-hq-detail'],
          fallback: 'command-hq-detail',
        }}
        ephemeral={ephemeral}
      />
    </div>
  );
@@ -1,21 +0,0 @@
 import type { LayoutNode } from 'officerdev';
 import { WorkspaceView } from 'officerdev';
 import { useDashboardState } from 'state/useDashboardState';
 import { defaultLayout } from './defaultLayout';
 // /contacts — the CardDAV half of the same sidecar as /calendar; see CalendarScreen for why the selected
 // collection is a query param rather than a route segment.
 export const ContactsScreen = () => {
  const workspace = useDashboardState<LayoutNode>('screens/contacts', defaultLayout);
  return (
    <div className="h-full w-full pt-2">
      <WorkspaceView
        workspace={workspace}
        locked
        appTypes={{ allowed: ['contacts-nav', 'contacts-view'], fallback: 'contacts-view' }}
      />
    </div>
  );
 };
@@ -1,11 +0,0 @@
 import type { LayoutNode } from 'officerdev';
 export const defaultLayout: LayoutNode = {
  type: 'group',
  id: 'contacts-root',
  direction: 'horizontal',
  children: [
    { node: { type: 'panel', id: 'contacts-nav', appType: 'contacts-nav' }, size: 22 },
    { node: { type: 'panel', id: 'contacts-view', appType: 'contacts-view' }, size: 78 },
  ],
 };
@@ -1 +0,0 @@
 export * from './ContactsScreen';
@@ -3,6 +3,9 @@ import { useParams, Link } from 'react-router';
 import { Loader2, CheckCircle2, XCircle, Ban, Clock, ArrowLeft, Square, Film, Music } from 'lucide-react';
 import { useClient } from 'hooks/useClient';
 import { toast } from 'sonner';
 import { useTranslation } from '@/lib/i18n';
 type TFn = ReturnType<typeof useTranslation>['t'];
 // Detail view for a `download` job — a compact two-phase progress readout (metadata → download), polled
 // from the job's persisted progress (the executor emits counter snapshots, not per-item events).
@@ -29,26 +32,40 @@ type DownloadJob = {
 const POLL_MS = 1500;
 const isTerminal = (s: string) => s === 'completed' || s === 'failed' || s === 'stopped' || s === 'interrupted';
-const statusBadge = (status: string) => {
+// Takes `t` because it is a module-level helper, not a component — the alternative is a hook
 // call outside a component body.
 const statusBadge = (status: string, t: TFn) => {
  switch (status) {
    case 'running':
      return {
        icon: <Loader2 className="h-4 w-4 animate-spin" />,
-        label: 'Running',
+        label: t('jobs.status.running'),
        cls: 'text-amber-600 dark:text-amber-500',
      };
    case 'pending':
-      return { icon: <Clock className="h-4 w-4" />, label: 'Queued', cls: 'text-blue-600 dark:text-blue-400' };
+      return {
        icon: <Clock className="h-4 w-4" />,
        label: t('jobs.status.queued'),
        cls: 'text-blue-600 dark:text-blue-400',
      };
    case 'completed':
-      return { icon: <CheckCircle2 className="h-4 w-4" />, label: 'Completed', cls: 'text-duck-teal' };
+      return { icon: <CheckCircle2 className="h-4 w-4" />, label: t('jobs.status.completed'), cls: 'text-duck-teal' };
    case 'failed':
-      return { icon: <XCircle className="h-4 w-4" />, label: 'Failed', cls: 'text-red-600 dark:text-red-400' };
+      return {
        icon: <XCircle className="h-4 w-4" />,
        label: t('jobs.status.failed'),
        cls: 'text-red-600 dark:text-red-400',
      };
    case 'stopped':
-      return { icon: <Ban className="h-4 w-4" />, label: 'Stopped', cls: 'text-duck-dark/50 dark:text-foreground/50' };
+      return {
        icon: <Ban className="h-4 w-4" />,
        label: t('jobs.status.stopped'),
        cls: 'text-duck-dark/50 dark:text-foreground/50',
      };
    default:
      return {
        icon: <XCircle className="h-4 w-4" />,
-        label: 'Interrupted',
+        label: t('jobs.status.interrupted'),
        cls: 'text-orange-600 dark:text-orange-400',
      };
  }
@@ -100,6 +117,7 @@ export const PhaseBar = ({
 };
 export const DownloadJobDetail = () => {
  const { t } = useTranslation();
  const { id } = useParams<{ id: string }>();
  const client = useClient();
  const [job, setJob] = useState<DownloadJob | null>(null);
@@ -134,9 +152,9 @@ export const DownloadJobDetail = () => {
    if (!id) return;
    try {
      await client.post(`/jobs/${id}/stop`, {});
-      toast.success('Stop requested');
+      toast.success(t('jobs.stopRequested'));
    } catch {
-      toast.error('Failed to stop');
+      toast.error(t('jobs.stopFailed'));
    }
  };
@@ -149,14 +167,14 @@ export const DownloadJobDetail = () => {
  if (!job)
    return (
      <div className="flex-1 flex flex-col items-center justify-center gap-3 text-duck-dark/60 dark:text-foreground/60">
-        <span>Job not found.</span>
+        <span>{t('jobs.notFound')}</span>
        <Link to="/jobs" className="text-duck-teal hover:underline">
-          Back to jobs
+          {t('jobs.backToJobs')}
        </Link>
      </div>
    );
-  const badge = statusBadge(job.status);
+  const badge = statusBadge(job.status, t);
  const running = !isTerminal(job.status);
  const p = job.progress;
  const isAudio = job.inputs?.format !== 'video';
@@ -197,7 +215,7 @@ export const DownloadJobDetail = () => {
            onClick={stop}
            className="flex items-center gap-1.5 px-3 py-1.5 text-xs rounded-md bg-red-500/10 text-red-600 dark:text-red-400 hover:bg-red-500/20 cursor-pointer transition-colors"
          >
-            <Square className="h-3 w-3" /> Stop
+            <Square className="h-3 w-3" /> {t('jobs.stop')}
          </button>
        )}
      </div>
@@ -206,14 +224,14 @@ export const DownloadJobDetail = () => {
        <div className="mx-auto flex max-w-md flex-col gap-5">
          <div className="text-sm text-duck-dark/60 dark:text-foreground/60">{phaseLabel}</div>
          <PhaseBar
-            label="Titles"
+            label={t('jobs.titles')}
            c={p?.meta ?? { done: 0, failed: 0, total: 0 }}
            active={p?.phase === 'metadata'}
            savedLabel="found"
            failedLabel="skipped"
          />
          <PhaseBar
-            label="Download"
+            label={t('jobs.download')}
            c={p?.dl ?? { done: 0, failed: 0, total: 0 }}
            active={p?.phase === 'download'}
            savedLabel="saved"
@@ -18,6 +18,7 @@ import { Button } from '@/components/ui/button';
 import { WorkspaceLayout } from 'officerdev';
 import type { LayoutNode, PanelComponents } from 'officerdev';
 import { randomId } from 'helpers/random-id';
 import { useTranslation } from '@/lib/i18n';
 type Cost = { inputTokens: number; outputTokens: number; totalUSD: number };
@@ -162,6 +163,7 @@ type ToolCallEntryProps = {
 };
 const ToolCallEntry = ({ entry }: ToolCallEntryProps) => {
  const { t } = useTranslation();
  const [expanded, setExpanded] = useState(false);
  return (
@@ -183,14 +185,14 @@ const ToolCallEntry = ({ entry }: ToolCallEntryProps) => {
      {expanded && (
        <div className="p-2.5 space-y-2 border-t border-duck-dark/10">
          <div>
-            <div className="text-[10px] text-duck-dark/40 uppercase mb-1">Input</div>
+            <div className="text-[10px] text-duck-dark/40 uppercase mb-1">{t('jobs.input')}</div>
            <pre className="text-duck-dark/60 whitespace-pre-wrap break-words text-[11px] max-h-40 overflow-y-auto">
              {JSON.stringify(entry.toolInput, null, 2)}
            </pre>
          </div>
          {entry.output !== undefined && (
            <div>
-              <div className="text-[10px] text-duck-dark/40 uppercase mb-1">Output</div>
+              <div className="text-[10px] text-duck-dark/40 uppercase mb-1">{t('jobs.output')}</div>
              <pre
                className={`whitespace-pre-wrap break-words text-[11px] max-h-60 overflow-y-auto ${entry.isError ? 'text-red-500' : 'text-duck-dark/60'}`}
              >
@@ -236,6 +238,7 @@ const DEFAULT_LAYOUT: LayoutNode = {
 };
 const StepsPanel = () => {
  const { t } = useTranslation();
  const ctx = useJobPanel();
  const {
    displaySteps,
@@ -255,7 +258,7 @@ const StepsPanel = () => {
  return (
    <div className="flex h-full flex-col overflow-hidden">
      <div className="px-3 py-2 border-b border-duck-dark/10">
-        <h2 className="text-xs font-medium text-duck-dark/60 uppercase tracking-wider">Steps</h2>
+        <h2 className="text-xs font-medium text-duck-dark/60 uppercase tracking-wider">{t('jobs.steps')}</h2>
      </div>
      <div className="flex-1 overflow-y-auto">
        {displaySteps.map((step, i) => {
@@ -336,6 +339,7 @@ const StepsPanel = () => {
 };
 const OutputPanel = () => {
  const { t } = useTranslation();
  const ctx = useJobPanel();
  const { selectedKey, outputMap, streamingMap, outputPanelRef } = ctx;
@@ -345,7 +349,7 @@ const OutputPanel = () => {
  return (
    <div className="flex h-full flex-col overflow-hidden">
      <div className="px-3 py-2 border-b border-duck-dark/10 flex items-center gap-2">
-        <h2 className="text-xs font-medium text-duck-dark/60 uppercase tracking-wider">Output</h2>
+        <h2 className="text-xs font-medium text-duck-dark/60 uppercase tracking-wider">{t('jobs.output')}</h2>
        {selectedKey && (
          <span className="text-xs text-duck-dark/40 truncate">
            {selectedKey.includes(':') ? selectedKey.split(':')[1] : `step ${Number(selectedKey) + 1}`}
@@ -355,12 +359,12 @@ const OutputPanel = () => {
      <div ref={outputPanelRef} className="flex-1 overflow-y-auto p-3 space-y-2 font-mono text-xs">
        {!selectedKey && (
          <div className="flex items-center justify-center h-full text-duck-dark/30 text-sm font-sans">
-            Select a step or sub-task to view output
+            {t('jobs.selectStep')}
          </div>
        )}
        {selectedKey && selectedOutputs.length === 0 && !selectedStreaming && (
          <div className="flex items-center justify-center h-full text-duck-dark/30 text-sm font-sans">
-            No output yet
+            {t('jobs.noOutput')}
          </div>
        )}
        {selectedOutputs.map((entry) => {
@@ -385,6 +389,7 @@ const OutputPanel = () => {
 };
 export const PipelineJobDetail = () => {
  const { t } = useTranslation();
  const { id } = useParams<{ id: string }>();
  const client = useClient();
@@ -792,15 +797,15 @@ export const PipelineJobDetail = () => {
  );
  if (isLoading) {
-    return <div className="flex h-full items-center justify-center text-duck-dark/30 text-sm">Loading...</div>;
+    return <div className="flex h-full items-center justify-center text-duck-dark/30 text-sm">{t('jobs.loading')}</div>;
  }
  if (!job) {
    return (
      <div className="flex h-full flex-col items-center justify-center gap-3 text-duck-dark/30 text-sm">
-        <span>Job not found</span>
+        <span>{t('jobs.notFound')}</span>
        <Link to="/jobs" className="text-duck-teal text-xs hover:underline">
-          Back to jobs
+          {t('jobs.backToJobs')}
        </Link>
      </div>
    );
@@ -821,7 +826,11 @@ export const PipelineJobDetail = () => {
      <Card className="px-4 py-3 shrink-0">
        <div className="flex items-center gap-3">
          {/* The other two job detail panes already do this; this was the last imperative back in Jobs. */}
-          <Link to="/jobs" aria-label="Back to jobs" className="p-1 rounded hover:bg-duck-dark/10 cursor-pointer">
+          <Link
            to="/jobs"
            aria-label={t('jobs.backToJobs')}
            className="p-1 rounded hover:bg-duck-dark/10 cursor-pointer"
          >
            <ArrowLeft className="h-4 w-4 text-duck-dark/60" />
          </Link>
          <div className="flex-1 min-w-0">
@@ -837,7 +846,7 @@ export const PipelineJobDetail = () => {
          {isRunning && (
            <Button variant="outline" size="sm" onClick={handleStop} className="gap-1.5">
              <Square className="h-3 w-3" />
-              Stop
+              {t('jobs.stop')}
            </Button>
          )}
        </div>
@@ -852,13 +861,13 @@ export const PipelineJobDetail = () => {
            {displayCost && (
              <>
                <div className="flex items-center gap-1.5 text-duck-dark/60">
-                  <span className="text-duck-dark/40">Tokens:</span>
+                  <span className="text-duck-dark/40">{t('jobs.tokens')}</span>
                  <span className="font-mono tabular-nums">
                    {formatTokens(displayCost.inputTokens)} in / {formatTokens(displayCost.outputTokens)} out
                  </span>
                </div>
                <div className="flex items-center gap-1.5 text-duck-dark/60">
-                  <span className="text-duck-dark/40">Cost:</span>
+                  <span className="text-duck-dark/40">{t('jobs.cost')}</span>
                  <span className="font-mono tabular-nums">{formatCost(displayCost.totalUSD)}</span>
                </div>
              </>
@@ -22,6 +22,7 @@ import { Card } from '@/components/Card';
 import { ScriptJobDetail } from './ScriptJobDetail';
 import { DownloadJobDetail } from './DownloadJobDetail';
 import { PipelineJobDetail } from './JobDetail';
 import { useTranslation } from '@/lib/i18n';
 type JobSummary = {
  id: string;
@@ -99,6 +100,7 @@ const useJobsData = () => {
 type JobRowProps = { job: JobSummary; onAction: (ev: MouseEvent, job: JobSummary) => void };
 const JobRow = ({ job, onAction }: JobRowProps) => {
  const { t } = useTranslation();
  const { id: activeId } = useParams<{ id: string }>();
  const isRunning = job.status === 'running';
  const target = basename(job.target);
@@ -126,7 +128,7 @@ const JobRow = ({ job, onAction }: JobRowProps) => {
      </Link>
      <button
        onClick={(ev) => onAction(ev, job)}
-        title={isRunning ? 'Stop' : 'Delete'}
+        title={isRunning ? t('jobs.stop') : 'Delete'}
        className="shrink-0 mr-2 p-1.5 rounded-md text-duck-dark/40 hover:text-red-500 hover:bg-red-500/10 md:opacity-0 group-hover:opacity-100 transition-opacity cursor-pointer"
      >
        {isRunning ? <Square className="h-4 w-4" /> : <Trash2 className="h-4 w-4" />}
@@ -144,6 +146,7 @@ const PanelHeader = ({ children }: { children: ReactNode }) => (
 // real event is wired to it. Sends { type: 'test' }, which reaches every configured channel — Discord
 // today, APNs and FCM once their credentials exist. Delete this once a real producer replaces it.
 const TestNotificationButton = () => {
  const { t } = useTranslation();
  const client = useClient();
  const [sending, setSending] = useState(false);
@@ -157,12 +160,12 @@ const TestNotificationButton = () => {
      );
      const results = res?.results ?? [];
      if (results.length === 0) {
-        toast.warning('No channels configured');
+        toast.warning(t('jobs.noChannels'));
      } else {
        toast.success(results.map((r) => `${r.channel}: ${r.sent} sent`).join(', '));
      }
    } catch {
-      toast.error('Failed to send notification');
+      toast.error(t('jobs.notifyFailed'));
    } finally {
      setSending(false);
    }
@@ -172,7 +175,7 @@ const TestNotificationButton = () => {
    <button
      onClick={send}
      disabled={sending}
-      title="Send a test notification to every configured channel"
+      title={t('jobs.testNotification')}
      className="ml-auto shrink-0 flex items-center gap-1 text-xs font-medium text-duck-dark/50 hover:text-duck-teal cursor-pointer disabled:opacity-40"
    >
      <Bell className="h-3.5 w-3.5" />
@@ -182,6 +185,7 @@ const TestNotificationButton = () => {
 };
 const ActiveJobsPanel = () => {
  const { t } = useTranslation();
  const { jobs, isLoading, act } = useJobsData();
  const active = [
    ...jobs.filter((j) => j.status === 'running'),
@@ -191,15 +195,17 @@ const ActiveJobsPanel = () => {
    <div className="h-full p-2">
      <Card className="h-full flex flex-col overflow-hidden">
        <PanelHeader>
-          <h2 className="text-sm font-semibold text-duck-dark">Running &amp; Queued</h2>
+          <h2 className="text-sm font-semibold text-duck-dark">{t('jobs.runningQueued')}</h2>
          {active.length > 0 && <span className="text-xs text-duck-dark/40">{active.length}</span>}
          <TestNotificationButton />
        </PanelHeader>
        <div className="flex-1 overflow-y-auto">
          {isLoading ? (
-            <div className="flex items-center justify-center h-full text-duck-dark/30 text-xs">Loading…</div>
+            <div className="flex items-center justify-center h-full text-duck-dark/30 text-xs">{t('jobs.loading')}</div>
          ) : active.length === 0 ? (
-            <div className="flex items-center justify-center h-full text-duck-dark/30 text-xs">Nothing running</div>
+            <div className="flex items-center justify-center h-full text-duck-dark/30 text-xs">
              {t('jobs.nothingRunning')}
            </div>
          ) : (
            active.map((job) => <JobRow key={job.id} job={job} onAction={act} />)
          )}
@@ -211,6 +217,7 @@ const ActiveJobsPanel = () => {
 // Bottom-left panel: finished / failed / stopped, newest first, searchable.
 const HistoryJobsPanel = () => {
  const { t } = useTranslation();
  const { jobs, isLoading, act, clearHistory } = useJobsData();
  const [search, setSearch] = useState('');
  const history = jobs
@@ -224,12 +231,12 @@ const HistoryJobsPanel = () => {
    <div className="h-full p-2">
      <Card className="h-full flex flex-col overflow-hidden">
        <PanelHeader>
-          <h2 className="text-sm font-semibold text-duck-dark shrink-0">History</h2>
+          <h2 className="text-sm font-semibold text-duck-dark shrink-0">{t('jobs.history')}</h2>
          <div className="relative flex-1">
            <Search className="absolute left-2.5 top-1/2 -translate-y-1/2 h-3.5 w-3.5 text-duck-dark/40" />
            <input
              type="text"
-              placeholder="Search…"
+              placeholder={t('jobs.search')}
              value={search}
              onChange={(ev) => setSearch(ev.target.value)}
              className="w-full pl-8 pr-3 py-1 text-sm rounded-md border border-duck-dark/15 bg-background/60 text-duck-dark placeholder:text-duck-dark/30 focus:outline-none focus:ring-1 focus:ring-duck-teal/40"
@@ -238,16 +245,16 @@ const HistoryJobsPanel = () => {
          {history.length > 0 && (
            <button
              onClick={clearHistory}
-              title="Delete all finished jobs"
+              title={t('jobs.deleteFinished')}
              className="shrink-0 text-xs font-medium text-duck-dark/50 hover:text-red-500 cursor-pointer"
            >
-              Clear all
+              {t('jobs.clearAll')}
            </button>
          )}
        </PanelHeader>
        <div className="flex-1 overflow-y-auto">
          {isLoading ? (
-            <div className="flex items-center justify-center h-full text-duck-dark/30 text-xs">Loading…</div>
+            <div className="flex items-center justify-center h-full text-duck-dark/30 text-xs">{t('jobs.loading')}</div>
          ) : history.length === 0 ? (
            <div className="flex items-center justify-center h-full text-duck-dark/30 text-xs">
              {search ? 'No matches' : 'No finished jobs'}
@@ -263,6 +270,7 @@ const HistoryJobsPanel = () => {
 // ── Right panel: the selected job's detail, by mode (script terminal / pipeline steps) ──
 const JobDetailPanel = () => {
  const { t } = useTranslation();
  const { id } = useParams<{ id: string }>();
  const client = useClient();
  const [mode, setMode] = useState<string | null>(null);
@@ -284,7 +292,7 @@ const JobDetailPanel = () => {
      <div className="h-full p-2">
        <Card className="h-full flex flex-col items-center justify-center gap-2 text-duck-dark/30">
          <Inbox className="h-8 w-8" />
-          <span className="text-sm">Select a job</span>
+          <span className="text-sm">{t('jobs.selectJob')}</span>
        </Card>
      </div>
    );
@@ -301,7 +309,7 @@ const JobDetailPanel = () => {
  if (mode === 'notfound') {
    return (
      <div className="h-full p-2">
-        <Card className="h-full flex items-center justify-center text-duck-dark/50 text-sm">Job not found.</Card>
+        <Card className="h-full flex items-center justify-center text-duck-dark/50 text-sm">{t('jobs.notFound')}</Card>
      </div>
    );
  }
@@ -4,6 +4,9 @@ import { Loader2, CheckCircle2, XCircle, Ban, Clock, ArrowLeft, Square } from 'l
 import { useClient } from 'hooks/useClient';
 import { toast } from 'sonner';
 import { PhaseBar, type DownloadProgress } from './DownloadJobDetail';
 import { useTranslation } from '@/lib/i18n';
 type TFn = ReturnType<typeof useTranslation>['t'];
 type ScriptJob = {
  id: string;
@@ -27,36 +30,46 @@ const isTerminal = (s: string) => s === 'completed' || s === 'failed' || s === '
 const isDownloadProgress = (p: unknown): p is DownloadProgress =>
  !!p && typeof p === 'object' && 'meta' in p && 'dl' in p;
-const statusBadge = (status: string, exitCode: number | null) => {
+// Takes `t` because it is a module-level helper, not a component.
 const statusBadge = (status: string, exitCode: number | null, t: TFn) => {
  switch (status) {
    case 'running':
      return {
        icon: <Loader2 className="h-4 w-4 animate-spin" />,
-        label: 'Running',
+        label: t('jobs.status.running'),
        cls: 'text-amber-600 dark:text-amber-500',
      };
    case 'pending':
-      return { icon: <Clock className="h-4 w-4" />, label: 'Queued', cls: 'text-blue-600 dark:text-blue-400' };
+      return {
        icon: <Clock className="h-4 w-4" />,
        label: t('jobs.status.queued'),
        cls: 'text-blue-600 dark:text-blue-400',
      };
    case 'completed':
-      return { icon: <CheckCircle2 className="h-4 w-4" />, label: 'Completed', cls: 'text-duck-teal' };
+      return { icon: <CheckCircle2 className="h-4 w-4" />, label: t('jobs.status.completed'), cls: 'text-duck-teal' };
    case 'failed':
      return {
        icon: <XCircle className="h-4 w-4" />,
-        label: `Failed${exitCode != null ? ` (exit ${exitCode})` : ''}`,
+        label: exitCode != null ? t('jobs.failedWithCode', { code: exitCode }) : t('jobs.status.failed'),
        cls: 'text-red-600 dark:text-red-400',
      };
    case 'stopped':
-      return { icon: <Ban className="h-4 w-4" />, label: 'Stopped', cls: 'text-duck-dark/50 dark:text-foreground/50' };
+      return {
        icon: <Ban className="h-4 w-4" />,
        label: t('jobs.status.stopped'),
        cls: 'text-duck-dark/50 dark:text-foreground/50',
      };
    default:
      return {
        icon: <XCircle className="h-4 w-4" />,
-        label: 'Interrupted',
+        label: t('jobs.status.interrupted'),
        cls: 'text-orange-600 dark:text-orange-400',
      };
  }
 };
 export const ScriptJobDetail = () => {
  const { t } = useTranslation();
  const { id } = useParams<{ id: string }>();
  const client = useClient();
@@ -137,9 +150,9 @@ export const ScriptJobDetail = () => {
    if (!id) return;
    try {
      await client.post(`/jobs/${id}/stop`, {});
-      toast.success('Stop requested');
+      toast.success(t('jobs.stopRequested'));
    } catch {
-      toast.error('Failed to stop');
+      toast.error(t('jobs.stopFailed'));
    }
  };
@@ -153,15 +166,15 @@ export const ScriptJobDetail = () => {
  if (!job) {
    return (
      <div className="flex-1 flex flex-col items-center justify-center gap-3 text-duck-dark/60 dark:text-foreground/60">
-        <span>Job not found.</span>
+        <span>{t('jobs.notFound')}</span>
        <Link to="/jobs" className="text-duck-teal hover:underline">
-          Back to jobs
+          {t('jobs.backToJobs')}
        </Link>
      </div>
    );
  }
-  const badge = statusBadge(job.status, job.exitCode);
+  const badge = statusBadge(job.status, job.exitCode, t);
  const running = !isTerminal(job.status);
  return (
@@ -185,7 +198,7 @@ export const ScriptJobDetail = () => {
            onClick={stop}
            className="flex items-center gap-1.5 px-3 py-1.5 text-xs rounded-md bg-red-500/10 text-red-600 dark:text-red-400 hover:bg-red-500/20 cursor-pointer transition-colors"
          >
-            <Square className="h-3 w-3" /> Stop
+            <Square className="h-3 w-3" /> {t('jobs.stop')}
          </button>
        )}
      </div>
@@ -193,14 +206,14 @@ export const ScriptJobDetail = () => {
      {isDownloadProgress(job.progress) && (
        <div className="px-5 py-4 border-b border-duck-dark/10 flex flex-col gap-4">
          <PhaseBar
-            label="Titles"
+            label={t('jobs.titles')}
            c={job.progress.meta}
            active={job.progress.phase === 'metadata'}
            savedLabel="found"
            failedLabel="skipped"
          />
          <PhaseBar
-            label="Download"
+            label={t('jobs.download')}
            c={job.progress.dl}
            active={job.progress.phase === 'download'}
            savedLabel="saved"
--- a/Show More
+++ b/Show More