pastilhasandClaude Opus 5
b63badaf67
a sweep for remnants after 2026-08-18. nothing was broken - no dangling import, symbol, route or permission key anywhere in src/ - but the platform was still speaking the plugin's vocabulary in a dozen places. the one that mattered is live code rather than prose: ChatPanelWrapper hardcodes workspace.id === 'email' to send context: 'email', which is the frontend half of the pair whose backend half (resolveEmailCwd) carries a fifteen-line justification. the two ends now both say so, including that adding a SECOND id there is the signal the platform needs a real way for a plugin to declare a chat context. the rest: two dead imports left by removing the settings section, an empty 'Email' type-section header, a protocol.ts section header with no members naming the plugin's SSE design, and a queue comment pointing at sidecar/email/sync-runner.ts - a path in another repository now. CLAUDE.md, AGENTS.md and working-on-officer.md described email as a platform feature, an app permission and a pm2 process. those are the files a fresh agent reads first, so they were the highest-risk staleness in the tree. TODO.md's whole Email section moved to the plugin's own repository. it held OPEN items pointing at sidecar/email/store.ts, which is exactly how a leftover list sends someone to edit files that do not exist. the delete-account dialog promised it would remove email accounts and playlists. both tables belong to plugins now, so that cascade only happens where the plugin is installed - it now says 'anything an installed plugin keeps for them' instead of naming two it cannot guarantee. imapflow and mailparser STAY in package.json. the plugin has no package.json of its own and resolves from the platform's node_modules, so removing them would break the installed plugin's sidecar. the fix is giving plugins their own dependency manifest, not deleting these. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
# AGENTS.md
|
|
|
|
Guidance for any coding agent working in the Officer platform repo.
|
|
|
|
**The instructions live in [`CLAUDE.md`](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 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
|
|
that executes code or touches the disk — terminal, chat, tasks, files, desktop, 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"
|
|
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 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
|
|
worth 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.
|