A sidecar already gets a port and nothing here changes that: it binds 0, the
kernel picks, it announces the number. That is right for what it is - a private
detail between two processes, loopback, re-chosen every restart, and nothing
outside Officer needs it.
A port something ELSE connects to is a different thing. A plugin serving a
website has to be reachable from nginx, which means the number must survive a
restart and be knowable by whoever writes the proxy configuration. Ephemeral
fails both, which is why the first site plugin was going to hardcode 3011 and
hope.
So: `extraPorts: [{ name: 'site', preferred: 3011 }]` in a manifest, allocated at
install, persisted in plugin_ports, and delivered as PORT_SITE in the sidecar's
pm2 environment. Environment rather than the registration socket because a socket
answer arrives after the process has already had to decide what to bind, and pm2
is the only thing that can tell a process something before it starts.
What the platform guarantees is the part per-plugin config could never do: no two
plugins are ever handed the same number. That is a unique index rather than a
convention, because a collision is not a duplicate row - it is two services
fighting over a listener where the loser fails to bind and the winner is whoever
started first.
`preferred` is a wish, not a claim. A plugin usually arrives after the thing that
connects to it, and moving that configuration is work the platform can spare
somebody; but a preference that could fail an install would be a claim wearing a
softer word.
Allocations survive uninstall and are released only by purge. The number is
written down where this database cannot see it, so handing it to a different
plugin because this one was briefly removed points that configuration at the
wrong service.
Pm2App gained `env`, emitted as JSON rather than hand-quoted: a port is a number
today, but this is the seam where a path arrives eventually, and one apostrophe
in a value produces a file PM2 cannot parse - which takes every process on the
machine down, not just the plugin's.
Verified: stable across calls, distinct across plugins, released cleanly,
honours a preference, and a plugin declaring no ports gets no env key at all.
The documentation, triaged
2026-08-13. A map of what is in here, what it is for, and what should happen to it. Made because there are 42 documents and 13,000 lines, and no way to tell from the filenames which describe the system as it is and which are a record of an afternoon in July.
How much I verified: the classifications below are from filenames, status lines, and greps for things that changed on 2026-08-13. Where I actually read the document or checked the code, it says so. The rest is a starting point for a conversation, not a verdict.
Living — these describe the system and must stay true
| doc | state |
|---|---|
working-on-officer.md |
updated 2026-08-13. Operational guide. |
secret-store.md |
updated 2026-08-13. Built; rotation still open. |
install-variants.md |
new. The branch tree, for discussion. |
http-secure-context-audit.md |
new. What breaks over plain http. |
install-container-testing.md |
new. First container pass and its findings. |
per-user-linux-accounts.md |
partly updated. OFFICER_OS_USERS is gone; check the rest. |
navigation-audit.md |
authoritative on routing. Unverified against tonight's route removals. |
workspace-panels.md + workspace-panel-todo.md |
the panel framework. 1,300 lines combined — likely the biggest cleanup here. |
agent-coordination.md |
the north star for panel work. |
deprovision-os-account.md |
implemented; the 'disabled' stage it may mention was deleted tonight. |
Stale — describe things that changed on 2026-08-13
Each of these references something that no longer exists. Not yet corrected.
sidecar-topology.md— "ecosystem.config.cjs is the source of truth". It is generated now, and holds six processes.sidecar-app-store.md— derives the catalogue fromfull − light. Those files are gone, andcatalogue.test.tswas rewritten.sidecar-bootstrapping.md— "20 PM2 entries, 18 sidecar dirs". Six entries now.mobile-api-keys.md— partly corrected; recheck the origin-checking claims.wallet-key-custody.md—VAULT_STORE_KEYis now the per-purposewalletkey.push-notifications.md— "agreed design, 2026-07-31". Notify is a plugin and unmounted.chat-session-lifetime.md,chat-ui-walkthrough.md— referenceofficer-agent, renamed.
Historical — a record of a moment, and should stay one
Do not rewrite these to match today's code. They document how a decision was reached, and editing them destroys the reasoning. If they mislead, add a dated header pointing forward.
sidecar-audit-2026-07.md(1,377 lines)claude-sidecar-isolation.md— records theofficer-claude→officer-agentrename that preceded tonight'sofficer-agent→officer-claude-codeopen-threads-after-per-user-claude.mdtwo-agent-field-report-2026-08-12.mdapi-method-changes-2026-08-06.md
The opencode cluster — nine documents for one migration
opencode-fork-decision · -parity · -api-2-assessment · -phase0-review · -phase1-report ·
-phase1-review · -serve-migration-plan · -serve-path · -testing-checklist
The migration landed — opencode serve is in the sidecar, verified. So
opencode-serve-migration-plan.md saying "Nothing here is implemented" is false.
This is the clearest consolidation candidate in the whole directory: one document recording what was decided and what shipped, replacing nine that describe stages of getting there. I did not do it because it needs reading all nine, and deleting documents unread is not a thing to do at 4am.
The mobile-dav thread — three documents, one conversation
mobile-dav-provisioning · -feedback · -reply. A correspondence. Almost certainly one document.
Unclassified — I have not looked
design-language-interface · file-sync · jobs-unification · mobile-photo-sync-api ·
nextcloud-replacement · agent-git-identity
The plugin split, which affects most of the above
A core install is six processes. Everything else is a plugin, switched off tonight but present on disk. Most documents here were written when the estate was twenty processes and every one of them was simply "there", so they describe availability that no longer holds.
The useful rewrite is usually one line, not a rewrite: say whether the thing described is core or a plugin, and if a plugin, that it is not mounted on a fresh install.