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

Files

T

pastilhasandClaude Fable 5 6071ded175 todo: one file per item, grouped by theme, with a generated index

TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly
on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with
frontmatter carrying id, status, created date and order, and the prose body copied
across verbatim. TODO.md becomes a generated index (bun run todo:index).

Dates: where an item's prose stated one it is used; otherwise its old section's;
otherwise 2026-08-20, floored at the day before the split rather than invented.
date_source records which.

Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is
the identity, frontmatter is the machine's half and the body is the owner's.

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

2026-08-21 05:42:39 +00:00

1.6 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	open	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.

1.6 KiB Raw Blame History

1.6 KiB

Raw Blame History