naudachu
8b1b11001a
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>
7.2 KiB
AGENTS.md — internal/config
Three files: what this project is, who this machine is, and what was last written into the project's agent-harness tree. The only package in the tree that imports yaml.
| file | what is in it |
|---|---|
config.go |
Project, Logins and Scaffold (the three files), Resolve/ResolveOutsideAProject/Require, Resolved with Complete and Redacted, the KETTLE_* overrides, and the 0600 write |
The split is the whole design
<project>/.kettle/config.yaml login: noodles a NAME, never a token
repo: owner/name
~/.config/kettle/logins.yaml logins: [{name, url, user, scopes, token}]
mode 0600
<project>/.kettle/scaffold.yaml version: v1.4.0 a note, load-bearing
out: .claude for nothing
The third file is the newest and the least important, which is exactly why it is
a file of its own — see Unknown keys are an error below. It records what
kettle gen scaffold last wrote into the project and which build wrote it, so
kettle config can say when a project's skills are four releases behind the
binary reading them. Nothing resolves from it. Delete it and you lose the
warning and nothing else.
user and scopes are documentation and nothing else — nothing is checked
against either, and no request is refused because of one. scopes is what the
token was minted with, as Gitea spells it (write:issue, write:repository),
and it is written down because the instance will not answer the question:
GET /user/tokens needs basic auth rather than token auth, so a token cannot be
asked what it may do. What it buys is a 403 that can be read — kettle auth list
and kettle config show what was recorded, and an empty list means "nobody wrote
it down", never "none".
A token in a file inside a working tree ends up in a commit. Not always, not immediately, and not by anyone careless — but a project config is exactly the file somebody eventually decides to share, and a secret that has ever been pushed has to be rotated. So the project pins a login by name, and the name is worth nothing on its own, which is what makes it safe to keep in a repository.
Which tokens this computer holds is a fact about the computer, the way which issues
a tree holds is a fact about the tree. SaveLogins writes 0600 into a 0700
directory; nothing else on the machine has any business reading it. $KETTLE_CONFIG_HOME
relocates it — the test suite sets it, so a run can neither read nor overwrite the
developer's own tokens — and $XDG_CONFIG_HOME is honoured too.
Nothing prints a token. Redacted is what a receipt gets; kettle config shows
(set).
Resolution, and why it fails early
Resolve merges three sources — the project config, the machine's login file, and
the environment — into Resolved, which is everything the transport needs.
Every failure names the file it read and the command that fixes it. "401 Unauthorized" is what happens when this function is allowed to return a half-filled struct, and a 401 names nothing an operator can act on.
The same discipline splits the two "missing" answers: a missing config.yaml is
ErrNoConfig, not an empty config, because "this project has not been told which
tracker it belongs to" and "it belongs to no tracker" are different answers and only
one is fixed by running init. A missing login file, by contrast, is an empty
list — a machine with no logins yet is an ordinary machine.
Complete is that assertion on its own, as a method, because the two questions are
different: kettle config wants to show a half-filled configuration and
everything that dials wants to refuse one. Require is Resolve plus
Complete; gitea.New and cmd/release call Complete
themselves, so a client can never be built from a struct that is missing a field.
ResolveOutsideAProject is for the one caller that legitimately stands nowhere near
a project: cmd/release, run from a fresh clone. The
marker is gitignored, so a clone has none and a build tool must not create one — and
with no marker there is nothing to merge, so the environment is the
configuration. A marker that is there is read as always, so the same command run
from a maintainer's own checkout picks up the login pinned in it. Every other caller
wants Resolve, where "no project" is the answer rather than a state to work
around: a push that quietly ran against whatever was in the environment would be a
push into somebody else's repository.
ReadProjectFile exists for exactly one caller: kettle init, which is creating
the marker LoadProject walks for, and on a dry run may not have created it at all.
Overrides
| variable | shadows |
|---|---|
KETTLE_LOGIN |
login: in the project config |
KETTLE_REPO |
repo: in the project config |
KETTLE_URL |
the login's url |
KETTLE_TOKEN |
the login's token |
KETTLE_CONFIG_HOME |
the directory holding logins.yaml |
Each wins over the file it shadows. They exist for CI, for a one-off run against another instance, and for anyone who would rather not have a token on disk at all.
Unknown keys are an error
Not a silent drop. An older binary reading a newer config would otherwise delete the setting it did not recognize the next time it wrote the file — which is a data-loss bug that only shows up on the machine running the older build.
The price is that a field added here is a one-way door for the file that holds
it. scopes: was the first one to prove it: a login file written by a binary
that has the field cannot be read by one that does not — the older build stops
with "unknown field" rather than dropping the line. That is acceptable for
logins.yaml, which is machine-local and whose reader is the one binary the
operator upgrades; it would not be acceptable for config.yaml, which is
committed and read by whatever version each machine happens to have. Adding a
field to the project file means answering that first, out loud, here.
scaffold.yaml exists because that answer came back "no". Recording which build
wrote a project's .claude/ tree wanted two keys, and putting them in
config.yaml would have made every older kettle in the world stop reading a
committed file. A separate file written and read by one binary about one
directory carries the same cost for nothing: an older build never opens it.
What does not belong here
A request, a store path, an issue. This package reads and writes three files and
answers "who am I and where am I pointed"; gitea takes the
answer and dials, and the paths themselves come from
project.
Keeping this file true
- Scope:
config.go— the three files, their fields, the overrides, the file modes. - Update it when a field is added to any of them (the block above is the contract), an override is added or renamed, the location or mode of the login file changes, or the unknown-key policy changes.
- Do not move a credential into the project file, and if that ever changes, the argument above is what has to be answered first.