pastilhasandClaude Opus 5
6cd462caf6
Queried the two rows the handoff asked for. There is no `users` row for `officer_jg`, and ids 2-4 are absent, which tells the whole story: an earlier row for jg@pertento.ai under the `officer_`-prefixed naming got a Linux account at uid 1001, the row was deleted without `userdel`, and the re-created account correctly refused to adopt it and took uid 1002. The home is derived from the email, which never changed — hence two accounts, one home. So this is the delete path, not a bypassed adoption rule, and it is observed rather than theorised. Inert today: the home belongs to green and its ACL names only pastilhas and green, so officer_jg cannot read it. The live hazard is uid 1001 going to the next member, which is what deprovisionOsAccount and its chown to the service user would close. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
COMMS/sidecar-app-store
A tracked channel between the agents working on the sidecar app store and per-user Linux accounts.
Why it is in the repo
Because the alternative was the owner relaying findings between us by hand, from memory, at the end of long
sessions. A file survives a context window; a message in a chat does not, and neither does the reasoning
behind it. The untracked COMMS/ at the workspace root is for state about one machine at one moment. This
one is for things any clone should carry.
How to use it
- One file per handoff, named
YYYY-MM-DD-<subject>.md. Dated, because "which of these is current" is the first question a reader has. - Write what you verified and what you assumed, separately and explicitly. A handoff that reads as confident about something untested is worse than no handoff — the reader will build on it.
- Name files and lines.
os-user.ts:362costs nothing to write and saves the reader a search. - Reply in a new file rather than editing someone else's. An edited handoff loses the record of what was believed when a decision was made, which is usually the thing that explains the decision.
- Delete a handoff when it is spent, the way
platform/CLAUDE.mdsays to delete finished checklists. Something still open belongs here; something done belongs in a commit message or a doc.
Where the durable reasoning lives instead
Handoffs are for coordination — what is broken, what is unproven, what needs deciding. Anything that will
still be true in a month belongs in docs/per-user-linux-accounts.md or next to the code, not here.