step 1/4: the permission engine is called permissions, not capabilities

The word meant four different things in this repo, not the three the offscale
doc records:

  1. the permission registry              → RENAMED here
  2. $OFFICER_ROOT/capabilities/ items    → kept; this is what capabilities are
  3. sidecar routing keys                 → step 3, becoming `handles`
  4. Lightning wallet features            → kept; a domain term, and on the wire
                                            to the mobile apps

The fourth was not in the doc and a global find-and-replace would have broken
the mobile wallet, which reads `{ kind, capabilities: Capability[] }` from the
wallet sidecar. So this renamed against an explicit file allowlist rather than
by sweeping the tree, and `CapabilityPage.tsx` — the UI for the item store, and
correctly named already — was left alone.

Moved: servers/capabilities/ → servers/permissions/, capability-gate.ts →
permission-gate.ts, users/capabilities-routes.ts → permissions-routes.ts,
hooks/useCapabilities.ts → usePermissions.ts. Identifiers follow.

Three breaks the typechecker could not see, all found by exercising it live.

The route paths moved with the prose sweep, so the server served
/user/permissions while the frontend still called /user/capabilities. A 404 on
every page load, and tsgo clean throughout.

The response FIELD moved too. `client.get<SelfPermissions>()` is an unchecked
cast, so `data.capabilities` became `undefined` at runtime with no compile
error — `can()` would have answered "no" to everything and the dock would have
emptied itself.

And the grants list was passed straight out of the database, so it arrived as
`{ role, capability, level }` while the screen read `grant.permission`. Every
role would have rendered as holding nothing. It is now mapped in the route:
the wire says `permission`, the column still says `capability`, and step 2
therefore changes nothing any client can see.

The stale react-query keys were the quiet one: two files still invalidated
['self-capabilities'] after the hook moved to ['self-permissions'], so
installing a plugin would have silently stopped refreshing the dock.

The database is untouched — `role_capabilities` and its `capability` column are
step 2, and the two call sites that cross that boundary say so in a comment.
Round-tripped the 9 live grants through the admin endpoint to prove the PUT
contract survived: 9 before, 9 after, Member's three intact.

Also reverted prettier churn on five landing-page files that a broad --write
picked up. Second time today; the lesson is not sticking.

tsgo clean. 797 tests, 787 pass, same 7 pre-existing failures — two of which
now read "path → permission" rather than "path → capability".

src/servers/api/chat/agent-panels-routes.ts

@@ -14,9 +14,9 @@ import { OFFICER_API_URL } from '../../officer-url.mjs';
 /**
  * The browser's half of the address book: name a panel, look up what a panel is, rename, remove.
  *
- * Mounted on the chat router rather than given its own prefix, because it is the same capability —
+ * Mounted on the chat router rather than given its own prefix, because it is the same permission —
  * these routes create and name Claude sessions, which is what `chat` already grants. A new top-level
- * mount would have meant a new capability entry claiming the same authority under a second name.
+ * mount would have meant a new permission entry claiming the same authority under a second name.
  *
  * The agent-facing door is separate and deliberately so: `servers/api/agent-handoff/router.ts`.
  */

src/servers/api/chat/chat.ts

@@ -59,8 +59,8 @@ async function chatIdentity(user: { id: number; email: string }): Promise<ChatId
 // by id. `handleOpenCodeChat` carried a comment calling itself owner-only; nothing enforced it.
 //
 // So this is a stopgap, not a design: `who.isOwner` applied at every door below, until OpenCode carries an
-// identity the way `spawnClaudeAsMember` does. Restrict here rather than at the capability layer because
-// `chat` is one capability covering both harnesses, and splitting it would strand the grants already issued.
+// identity the way `spawnClaudeAsMember` does. Restrict here rather than at the permission layer because
+// `chat` is one permission covering both harnesses, and splitting it would strand the grants already issued.
 // The matching refusal on the execution path is in `websocket.ts` → `handleChat`.
 import { transcribeAudio } from '../stt/transcribe';
 import { registerAgentPanelRoutes } from './agent-panels-routes';

src/servers/api/chat/list-models.ts

@@ -40,7 +40,7 @@ export function invalidateModelCache(): void {
 }
 
 type OpenCodeModel = {
-  capabilities?: { input?: { image?: boolean }; reasoning?: boolean };
+  permissions?: { input?: { image?: boolean }; reasoning?: boolean };
 };
 
 type ProvidersResponse = {
@@ -69,13 +69,13 @@ async function listOpenCodeModels(): Promise<ModelInfo[]> {
           provider: providerId,
           contextWindow: 200000,
           maxTokens: 8192,
-          reasoning: model?.capabilities?.reasoning ?? false,
+          reasoning: model?.permissions?.reasoning ?? false,
           // Was hardcoded `false`, correctly, while nothing carried images — the composer gates on this
-          // flag, so advertising `true` offered a capability that did not exist. Images are now plumbed
+          // flag, so advertising `true` offered a permission that did not exist. Images are now plumbed
           // through `OpenCodeRunParams` to `opencode run --file`, so the honest answer is the model's
           // own: OpenCode publishes it per model and we had never read it. Defaults to false, so a model
-          // that does not declare the capability keeps the affordance hidden rather than offering it.
-          images: model?.capabilities?.input?.image ?? false,
+          // that does not declare the permission keeps the affordance hidden rather than offering it.
+          images: model?.permissions?.input?.image ?? false,
         });
       }
     }