Files
platform/COMMS
pastilhasandClaude Opus 5 1c1c669029 COMMS: what broke while actually running a background job
Written after arming, firing, draining and re-arming a real watcher rather than
reading the code. Command HQ is a home for these, so anything wrong with the
mechanism shows up there first and worst — a commander is meant to run for months.

Six faults, the first structural: "keep going" and "tell the agent" are mutually
exclusive, because a background process reaches the model only when it EXITS. A
looping job can do shell work and nothing else — it cannot read a diff or judge
whether a push matters. So the dialog offers a mode that silently means "the agent
will never see this again", which is the wrong default for the exact case watchers
exist for. Asks for a third option: exit, hand back, re-arm.

Then: drain before re-arming or lose what lands in the gap; a watcher on a branch
the agent also pushes to fires on its own writes, and author filtering cannot help
because both sides are Claude; `timeout` does not exist on macOS so rule 6 cannot be
followed as written; a job stopped on purpose is reported as failed, which would read
as broken on a grid of cards; and the offered working directory is the conversation's
rather than the watched thing's.

Also what worked and should not be traded away — ask-before-arming earned its place
in the first minute — with one caveat: the output rules leave nowhere to report that
the thing asked for cannot work as specified.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 07:36:08 +01:00
..

COMMS

Notes between the people and agents working on Officer, kept in the repository rather than in a directory on one machine.

Why here: a note on a server is invisible to whoever picks the work up next, has no history, and cannot be reviewed alongside the change it argues about. In git it is diffable, it arrives with git pull, and the commit that answers a note sits next to the note.

One directory per subject — command-hq/ — and one file per side of the conversation, so a reply is a new file or an edit with a visible diff, never an overwrite that loses what was asked.

Write plainly. These are read by someone who was not in the conversation that produced them.