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>
6.4 KiB
description, allowed-tools
| description | allowed-tools |
|---|---|
| Give `kettle` a Gitea credential and choose which login this project runs under — `kettle auth list/add/remove` manages the machine-wide token file, `kettle init --login <name>` pins one of those names into `.kettle/config.yaml`. Invoke when a sync command reports no login, a 401, or an unknown login name, or to switch the account this project's issues are pushed under. The OPERATOR picks the login; you never type a token. | Bash(kettle auth list:*), Bash(kettle config:*) |
/kettle:auth — the credential a project runs under
Two files, and the split is the whole design.
| where | what is in it | who writes it |
|---|---|---|
~/.config/kettle/logins.yaml |
the tokens, one file per machine, mode 0600, outside every working tree | kettle auth add |
<project>/.kettle/config.yaml |
the name of one of those logins, and the tracker repo | kettle init --login … --repo … |
A name is worth nothing on its own, which is what makes it safe to keep in a
file inside a repository. A token in a working tree ends up in a commit
eventually, and a secret that has ever been pushed has to be rotated.
$KETTLE_CONFIG_HOME or $XDG_CONFIG_HOME move the machine file;
KETTLE_LOGIN, KETTLE_URL and KETTLE_TOKEN override it outright, which is
how CI runs with no token on disk.
No credential is pinned in .claude/ anywhere, and no hook rewrites a
--login argument. That mechanism is gone with the Python scripts. If you find
a GITEA_LOGIN in a settings file, it is dead weight from the old plugin — the
only thing kettle ever writes into .claude/settings.json is the optional
AGENTS.md mirror hook, which holds no identity of any kind.
The one hard rule: the operator chooses, and holds the token
- Never pick a login. Not from memory, not from the repo URL, not from a
previous session. Present the choice with
AskUserQuestion— name, url and user out ofkettle auth list— and let the operator answer. Exactly one login on the machine is the only case where you may propose, and you still confirm. - Never type, echo, paste or read a token.
kettle auth addtakes it on stdin precisely so it does not land in shell history; a token that goes through a model's context is a token in a transcript. Adding a login is the operator's own terminal, not a Bash call you make for them.
Steps
-
See what this machine holds. It never prints a token, and there is no flag to make it:
kettle auth list -
Nothing there — stop and hand the operator the command to run themselves:
kettle init --interactive # prompts for it, echo off kettle auth add --name noodles --url https://git.example.com --user naudachu < token.txt pass show gitea/token | kettle auth add --name noodles --url https://git.example.comThe first is the one to suggest to a person at a terminal: it reads the token with the echo turned off, so it is in no history, no file and no scrollback. It is not a command for you to run — it refuses a stdin that is not a terminal, and that refusal is correct.
--useris documentation only, andkettle auth remove <name>forgets one. -
Pin the choice into the project. Ask
kettle configfirst and only proceed if it answers with a project —kettle initin a directory that is not one would create a project there, which is the one statement that is never yours to make (/kettle:init):kettle config kettle init --login noodlesiniton an initialized project printsalready initialized — nothing to doand rewrites only the settings it was given, so the repo pinned earlier stays. -
Confirm with
kettle config. Tell the operator which login is pinned and which file it went in. It is live immediately — nothing caches it, no restart.
login noodles
url https://git.example.com
token (set)
repo claude-skills/marketplace
When it goes wrong
| what you see | what it means |
|---|---|
no login "X" in …/logins.yaml — known: … |
the project pins a name this machine does not hold. Either add it (step 2) or pin one that is there |
no .kettle/ found — searched up from … |
not a project. /kettle:init, and it is the operator's to run |
401 / 403 from a sync command |
report it verbatim. Do not try another login, and do not edit or remove one to route around it — that is somebody's identity, not a setting |
token none in kettle config |
a name is pinned but no credential answers to it |
Scopes: what the token is allowed to do
Gitea mints a token with scopes, spelled <read|write>:<category>. A token made
for issues carries write:issue — and that is enough for everything
/kettle:issue and /kettle:sync do, and not enough for anything
/kettle:api reaches: releases, pull requests, branches, tags and actions all
sit under repository.
| doing | needs |
|---|---|
| pull, push, comment, close, evict | write:issue |
kettle labels |
write:issue |
kettle api on releases, PRs, tags, branches, actions |
write:repository too |
| reading any of those without writing | the read: half is enough |
kettle auth add --scopes write:issue,write:repository writes that down beside
the login. It is a note and nothing else — nothing is checked against it and
nothing is refused because of it. It is worth writing down because the instance
will not answer the question: Gitea's own token listing needs a password rather
than a token, so a token cannot be asked what it may do. kettle auth list and
kettle config show what was recorded; (not recorded) means nobody wrote it
down, never "none".
A 403 from a sync command or from kettle api is usually this and says so.
Minting a new token is the operator's job in the web UI — the same flow as step
2 above, with both scopes ticked this time. Never remove or re-point a login to
route around a 403.
No kettle on PATH? command not found: kettle is the whole story — and it
means the binary that wrote this file has since moved or been removed, because
nothing else could have put it here. Stop and tell the operator to reinstall it:
go install git.noodles.cam/claude-skills/marketplace/cli/cmd/kettle@latest, or
cd cli && make install in a checkout of that repository (go.mod requires
go 1.26).
The full flag table for auth, config and init is the generated block in
/kettle:project.