pastilhasandClaude Opus 5
530e5880e1
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>
51 lines
2.7 KiB
Markdown
51 lines
2.7 KiB
Markdown
---
|
|
id: fleet/a-way-to-mark-a-commit-this-one-ships-so-a
|
|
title: "A way to mark a commit \"this one ships\", so a release is not just `master`'s tip"
|
|
theme: fleet
|
|
status: done
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 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.
|