platform/todo/fleet/a-way-to-mark-a-commit-this-one-ships-so-a.md at 530e5880e18027854994c649b938d9cb9c42cc45

Files

T

pastilhasandClaude Opus 5 530e5880e1 todo: what tonight's deploy work left behind, and two items it closed

Closed:

- fleet/an-orchestrator-that-acts-on-every-server-at — built, and as none of the three shapes it
  proposed. Not a script, not a screen, not a chat capability: an agent handed a written procedure and a
  server list it has to read rather than one baked into it. All three verified facts in the item earned
  their place; two things it did not anticipate are now new items.
- fleet/a-way-to-mark-a-commit-this-one-ships-so-a — built as a TAG, which the item explicitly ruled out.
  The owner reversed it, and the argument that changed his mind is recorded: a codeword can be written by
  accident, because every document about deploying contains it, so the trigger needs rules about where in
  a subject line it sits and a rule like that is one somebody eventually gets wrong.

Opened, all from tonight and all with the evidence attached:

- a deploy verifies pm2 and not that the app serves anything — the commander raised this against itself
- the commander cannot finish its own host, so one machine is always a build behind
- the watcher loop is rewritten by an agent every arming, so its correctness is re-rolled each time
- plugins:update restarts every sidecar, so a report naming only officer understates what moved
- an agent spawned by a background job is invisible in the UI while being perfectly readable
- AskUserQuestion can fail to parse its own call
- a commander opened from /chat loses its commander controls, because isCommander comes from the screen
  rather than the session

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-21 20:27:00 +00:00

2.7 KiB

Raw Blame History

id, title, theme, status, created, date_source, order

id	title	theme	status	created	date_source	order
fleet/a-way-to-mark-a-commit-this-one-ships-so-a	A way to mark a commit "this one ships", so a release is not just `master`'s tip	fleet	done	2026-08-21	stated	2

A way to mark a commit "this one ships", so a release is not just master's tip. Wanted 2026-08-21. No version numbers — not now — and not a tag: the owner does not want a second ref to mint and push for something the commit itself could carry. So a codeword in the commit message, and the fleet updater pulls to the newest commit carrying it rather than to whatever master points at.

That distinction is the whole value: today a server updates to the tip, so an in-progress commit ships the moment it is pushed. A marker makes shipping a deliberate act while leaving the push unchanged.

Shape to settle when it is built:

A trailer, not a word in prose — Release: yes on its own line, in the same family as Co-Authored-By. git log --grep='^Release:' --format=%H -1 then gives the target SHA in one command, and no commit message that merely talks about a release matches by accident.
The trade against a tag, stated honestly: a tag can be moved or deleted when a release turns out to be bad; a commit message cannot be edited once pushed. Un-marking means marking a newer commit — which is a forward-only, revert-shaped workflow. That is a fine answer, but it should be a chosen one.
The updater then does a checkout at that SHA, not a pull — same discipline the plugin-pinning item asks for: verify rev-parse HEAD matches, or refuse.

Done 2026-08-21 — as a tag, which is what this item ruled out. The owner reversed it on being shown the trade: "we don't even need a code word if we tag with deploy/date and the version". deploy/<version>, e.g. deploy/2026.08.21.02.

The argument that changed it was not about refs at all. A codeword can be written by accident: every document about deploying contains it, this file included, and so does every conversation planning one — so the trigger needs rules about where in the subject line it sits, and a rule like that is one somebody eventually gets wrong. A tag cannot be typed into prose. It also names its own version, which a codeword does not, and git ls-remote --tags answers "is there one" without fetching.

The cost this item correctly identified is real and was accepted: a tag is a second ref to mint and push. It is two commands in the release recipe.

What replaced the "un-marking is forward-only" worry: the deploy is idempotent by a local record, not by the ref. scripts/deploy-claim.sh takes one claim per version and never gives it back to a machine, so a tag being moved or deleted cannot cause a second rollout.

2.7 KiB Raw Blame History

2.7 KiB

Raw Blame History