pastilhasandClaude Opus 5
d56be0301d
CLAUDE.md asserted "single-user is a hard invariant, not a stage" while users held six rows and role_capabilities held grants. Every doc that repeated it is corrected here, in prose and in the code comments that carried the same claim. The accurate statement is narrower: one owner who bypasses every check, other accounts holding only what their role is granted, and a set of capabilities — terminal, chat, files, tasks, items, desktop, browser — that are structurally ungrantable because they execute as the owner's OS user. TODO.md gains a Multi-user section for what the read turned up: no way to create a second account, dashboards.id colliding across users, authorize.ts untested, pty/vault/opencode taking no identity, Radicale still owner_only. claude-sidecar-isolation.md's open question is answered rather than left open — the per-email spawn model is dead weight, because chat is an execution capability and no second account can ever reach it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.3 KiB
AGENTS.md
Guidance for any coding agent working in the Officer platform repo.
The instructions live in CLAUDE.md. Read it first — this file only points there.
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
bypasses every permission check), which since 2026-08-07 also admits additional accounts holding a
strict subset of it. Roles are Admin / Member / Developer; what each may reach is decided by
per-role capability grants, resolved on every request.
If a design question turns on "which user", the answer depends on the surface: real for the app
capabilities (gitea, music, photos, email, calendar…), and still always the owner for anything
that executes code or touches the disk — terminal, chat, tasks, files, desktop, browser are
kind: 'execution' and can never be granted. src/servers/capabilities/registry.ts is the authority.
Mounting a router without a registry entry makes the server refuse to boot. Read the "Capabilities"
section of CLAUDE.md before adding one.
This file previously described Officer as strictly single-user with "no tenancy, no roles, no user management". That was written to correct an older drift in the opposite direction — a fictional multi-user intranet with a user-invitation API — and it overshot. Both are now superseded by the paragraph above; treat the capability registry as the source of truth over either.
This repo is one of two. The other, capabilities/, 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— this repo's architecture, conventions and code styledocs/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 worth knowing aboutCONVENTIONS.md— component organisation and React patterns, with rationaleTODO.md— current direction; takes precedence where it disagrees with anything else
Treat the code as the source of truth where anything disagrees with it.