naudachu
e628ad6fd9
BREAKING: the plugin is `kettle`, not `tea`, and its commands are `/kettle:*`. It also now needs a binary on PATH that it did not need before; the README and every skill say how to get one and what a missing one looks like. The plugin was 3800 lines of Python doing what a compiled binary does better, and the name pointed at a tool that no longer takes part: `tea` is Gitea's CLI, and since the transport moved into the binary nothing here shells out to it for issues at all. A plugin named after it was going to keep suggesting otherwise. Deleted: 19 scripts, the 14-file unittest suite, and the tea-guard hook. The guard blocked any `tea` invocation that would run under a login the model picked instead of the operator; the binary holds its own credentials and reads the pinned login out of the project's own config, so that failure is no longer expressible and there is nothing left to police. agents-sync stays — it is about AGENTS.md symlinks and has nothing to do with any of this. What the plugin keeps is what only a plugin can carry: the rules an operator states and a binary cannot enforce. `init` still refuses to run inside a linked worktree and still may not be model-invoked, because which directory is the project is a statement a person makes. The issue format reference stays here and stays the source of truth. The runner subagent is still for batches and still may not decide what an issue says. The command reference in the issue, sync and project skills is GENERATED from the binary's own command registry, between markers, so a flag that changed cannot ship with a skill that recommends the old one. `kettle gen skills --check` exits non-zero when they drift. The generator owns the region and nothing outside it: the frontmatter description, which is what decides whether a skill loads at all, stays hand-written. `use` survives and is the one place `tea` is still named — for releases, webhooks and actions, which kettle does not cover. Its instruction to write `--login "$GITEA_LOGIN"` and let the hook substitute the pin was true until this commit and is now rewritten: `tea` keeps its own configuration, kettle keeps its own, and configuring one configures nothing in the other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
99 lines
4.7 KiB
Markdown
99 lines
4.7 KiB
Markdown
---
|
|
name: auth
|
|
description: 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`. Load when a sync command reports no login, a 401, or an unknown login name, or when the user asks to switch the account this project's issues are pushed under. The OPERATOR picks the login; you never type a token.
|
|
---
|
|
|
|
# /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.
|
|
|
|
**There is no login pinned in `.claude/settings.local.json` any more, and no hook
|
|
that rewrites a `--login` argument.** That mechanism is gone with the Python
|
|
scripts; nothing here reads Claude's settings. If you find a `GITEA_LOGIN` in a
|
|
settings file, it is dead weight from the old plugin.
|
|
|
|
## 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 of `kettle 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 add` takes 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
|
|
|
|
1. See what this machine holds. It never prints a token, and there is no flag to
|
|
make it:
|
|
|
|
```bash
|
|
kettle auth list
|
|
```
|
|
|
|
2. **Nothing there** — stop and hand the operator the command to run themselves:
|
|
|
|
```bash
|
|
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.com
|
|
```
|
|
|
|
`--user` is documentation only. `kettle auth remove <name>` forgets one.
|
|
|
|
3. **Pin the choice into the project.** Ask `kettle config` first and only
|
|
proceed if it answers with a project — `kettle init` in a directory that is
|
|
not one would *create* a project there, which is the one statement that is
|
|
never yours to make (`/kettle:init`):
|
|
|
|
```bash
|
|
kettle config
|
|
kettle init --login noodles
|
|
```
|
|
|
|
`init` on an initialized project prints `already initialized — nothing to do`
|
|
and rewrites only the settings it was given, so the repo pinned earlier stays.
|
|
|
|
4. 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 |
|
|
|
|
**`tea` does not read any of this.** The `tea` CLI keeps its own configuration
|
|
under `$XDG_CONFIG_HOME/tea` and its own logins (`tea logins list`), and
|
|
configuring one tool configures nothing in the other — see `/kettle:use`.
|
|
|
|
**No `kettle` on PATH?** `command not found: kettle` is the whole story. Stop and
|
|
tell the operator to install it: `cd cli && go build -o ~/.local/bin/kettle
|
|
./cmd/kettle` in the marketplace repository (go.mod requires **go 1.26**), or
|
|
`go install git.noodles.cam/claude-skills/marketplace/cli/cmd/kettle@latest`.
|
|
|
|
The full flag table for `auth`, `config` and `init` is the generated block in
|
|
`/kettle:project`.
|