The plugin and the binary shipped on two release cadences and nothing on an operator's machine ever checked that the one they installed described the other. The generated flag block existed precisely so a renamed flag could not ship with documentation recommending the old one — and then shipped one version behind the registry it came from, which is the same bug one hop downstream. So the prose moved into the binary. `internal/scaffold` embeds every document; `kettle init` and `kettle gen scaffold` write them into a project's own `.claude/`. The two cannot disagree because there is one artefact. The namespace survived the move. A project's skills are flat, so the prefix is spelled into the directory name (`kettle-issue`); a project's *commands* take their namespace from a subdirectory, so `commands/kettle/init.md` is still `/kettle:init`. Four of the six command files are thin pointers at a skill, and that is what kept ~1,600 lines of `/kettle:…` cross-references true without a rewrite. `init` and `auth` lost `disable-model-invocation: true` — being a command is that property — and `auth` now restricts `allowed-tools` so a model cannot reach `kettle auth add` at all. `gen scaffold` writes files whole rather than splicing a region. The old refusal protected somebody's hand-written prose around the block; that prose is embedded now, so there is none to protect, and preserving local edits would freeze a project's documentation at whatever version first initialized it. `--check` warns before an upgrade discards one. The plugin's `agents-sync.sh` — 141 lines of Python behind a filename that said `.sh` — became `internal/mirror` and `kettle mirror`. Same seven branches, same refusal to merge two real files that differ, now with a table test per branch and a check that a repair converges in one pass. `--hook` is the PreToolUse form and exits 0 on every path including a panic. It is opt-in per project, which is strictly narrower than the plugin hook that was on for everybody who installed it. `kettle init --interactive` walks a person through the login, the token (read with the echo off, so it lands in no history and no file), the repository, the `.claude/` tree and the mirror hook. It refuses a stdin that is not a terminal and names the flags instead: every question it asks has one, and it performs nothing itself, so an interactive run and a flag run are one code path. Two rules that used to be prose are now the binary's: init refuses a linked worktree and names the main checkout, and writing into an existing `.claude/settings.json` is refused with the snippet printed rather than reformatting a file the operator commits. The scaffold version stamp went to its own `.kettle/scaffold.yaml` rather than into `config.yaml`, because unknown keys there are a hard error and that file may be committed and read by whatever build each machine has. golang.org/x/term becomes a direct dependency; it was already in the tree indirectly, so no module was added. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.3 KiB
AGENTS.md — cmd/release
The release tool: publishes a Gitea release for this repository, from this
repository's own code. Driven by make release TAG=v1.2.3, never by a user.
| file | what is in it |
|---|---|
main.go |
flags, argument validation, exit codes — everything that can fail before a socket is opened |
publish.go |
spec, receipt, its own small SDK client, and the converge/upload logic |
release_test.go |
the whole tool against a fake Gitea, including every refusal |
Why it is not a kettle subcommand
kettle's command tree is not just a menu: it is what kettle gen scaffold
writes a project's skills and commands from. A verb added there arrives in the
documentation an agent loads and in the reference an operator reads, and "publish
a release" is not something either of them does. Publishing is build
infrastructure — it runs once, on a tag, by the person cutting it — and the thing
users install should not carry it.
It is still this module's code, built on the same Gitea SDK, and that is the point: the release is published by the repository it is a release of, with nothing to trust that is not in this tree and no third-party tool between a tag and what people download.
Why it does not use internal/gitea
internal/gitea is otherwise the one door for
every request. Two reasons this one goes around it, both facts about where it runs
rather than preferences:
- that transport files every request body under
.kettle/payload/, a path resolved from the project marker — and the marker is gitignored, so a fresh clone has none and a build tool has no business creating one; - an asset upload's request body IS the binary. Filing a 20 MB multipart body as JSON in a scratchpad helps nobody.
What it does not reinvent is credentials or error vocabulary.
internal/config resolves the instance, the token
and the repository exactly as kettle does — through ResolveOutsideAProject,
which falls back to the environment when there is no marker and reads the project
config when there is — and gitea.Fail turns an SDK (response, error) pair into
the same *APIError a kettle push would report, so "the tracker said no" has one
spelling in the tree.
Idempotent end to end
A tag that already has a release reuses it, an asset whose name is already there is replaced, and a run repeated because the first died half way through converges on the same release with the same assets — not a second release with doubled attachments.
Reuse alone would only make a re-run not fail; it would not make it converge. A
second run with corrected notes has to leave the release holding the corrected notes,
or the retry that fixed the mistake published the mistake again. Empty notes mean
"leave what is there", not "clear them": --notes-file is how notes are supplied,
and a run that supplied none is not asking for the release to be emptied.
A 404 from the release lookup is an answer — it is what "no release yet" looks like — and anything else is reported, because "the instance refused us" and "there is nothing there" must not both read as "create one".
The by-tag route is a lookup through the tag, and a draft need not have one, so a
404 there is followed by a scan of the release listing before anything is created.
Without it a retried --draft publish would file a second release for one tag —
which is the failure this whole section exists to prevent, arriving through the one
door that looks like the ordinary case.
Order of operations
Everything that can be wrong in the arguments is reported before a release exists to be half-published:
--tagis required;- every asset is stat'ed up front — a release that exists with half its assets on it, published by a run that then failed on a typo, is the failure this prevents;
- two files with one basename are refused, because an attachment is addressed by name and the second would silently replace the first while the receipt claimed both went up;
- notes are read from disk;
- only then does anything dial. The attachment listing is read once, before the first upload, so the names that matter are the ones that were there when the run started.
Usage
Through the Makefile, which adds the three refusals that make a release
reproducible — dirty tree, TAG that is not what git describe reports, tag not
pushed to the remote:
make release TAG=v1.2.3 [NOTES=notes.md] [TITLE="…"]
Directly, when the Makefile is not what you want:
KETTLE_URL=… KETTLE_TOKEN=… KETTLE_REPO=owner/name \
go run ./cmd/release --tag v1.2.3 --notes-file notes.md dist/kettle_* dist/SHA256SUMS
--draft and --prerelease are there; --target names the commitish a tag is
created from when the tag does not exist yet.
Keeping this file true
- Scope:
main.go,publish.goand their test — the argument checks, the convergence rules, and the two decisions above about what this tool does not share withkettle. - Update it when a flag is added, the idempotency rules change, it starts or
stops borrowing something from
internal/, or the Makefile's refusals change. - Do not move any of this into
kettle's command registry without answering the first section — a verb here becomes documentation an agent loads.