token-minting skill: split CI_RELEASE_TOKEN (org-secret, admin-gated PUT) from the fully-agent-runnable repo-secret tokens #460

New issue

Closed

opened 2026-07-03 19:42:53 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-03 19:42:53 +00:00

Owner

Problem

The token-minting skill's "These are yours to rotate" callout groups provision-ci-release-token with tap/scoop/flux as fully agent-run. But CI_RELEASE_TOKEN is an ORG secret whose PUT needs the admin PAT agents are blocked from (infra#452 trap #4). Only its mint + SSM-stash are agent-runnable; the org-secret write is operator-gated. scoop and tap set repo secrets (fully agent-runnable, no admin PAT - infra#454 confirmed scoop). So the skill overstates ci-release as fully self-serve.

Fix (narrow)

In the callout and/or the per-script list, distinguish repo-secret tokens (scoop, tap - fully yours) from the ci-release org-secret (mint + stash yours, the org PUT is the operator's admin-PAT step). Make clear that hitting the CI_RELEASE_TOKEN wall does not mean "park it back to Kai" wholesale - the agent still mints + stashes; only the final org-secret PUT is hers. flux is a read-only bot token (no secret-PUT contention), fine where it is.

Do NOT touch claim #1 (the --aws line)

Leave the "from any box with AWS/SSM (--aws on a warded engineer...)" line exactly as is. Kai is giving the dispatch hosts real AWS creds (ward#579), so that claim is becoming true - walking it back would be wrong.

Watch the size cap

The SKILL.md sits right at the 4000-char cap (trimmed to 3997 in infra#454). This edit must stay under 4000 - trim elsewhere sentence-by-sentence if needed, without dropping the affirmative rule or any script mapping.

infra#454 (the callout), infra#452 trap #4 (the org-secret admin gate), ward#579 (the --aws line - do not touch), ward#576.

## Problem The token-minting skill's "These are yours to rotate" callout groups `provision-ci-release-token` with tap/scoop/flux as fully agent-run. But **`CI_RELEASE_TOKEN` is an ORG secret** whose PUT needs the admin PAT agents are blocked from (infra#452 trap #4). Only its **mint + SSM-stash are agent-runnable**; the org-secret write is operator-gated. scoop and tap set **repo** secrets (fully agent-runnable, no admin PAT - infra#454 confirmed scoop). So the skill overstates ci-release as fully self-serve. ## Fix (narrow) In the callout and/or the per-script list, **distinguish repo-secret tokens** (scoop, tap - fully yours) **from the ci-release org-secret** (mint + stash yours, the org PUT is the operator's admin-PAT step). Make clear that hitting the `CI_RELEASE_TOKEN` wall does not mean "park it back to Kai" wholesale - the agent still mints + stashes; only the final org-secret PUT is hers. flux is a read-only bot token (no secret-PUT contention), fine where it is. ## Do NOT touch claim #1 (the --aws line) Leave the "from any box with AWS/SSM (`--aws` on a warded engineer...)" line **exactly as is**. Kai is giving the dispatch hosts real AWS creds (ward#579), so that claim is becoming **true** - walking it back would be wrong. ## Watch the size cap The SKILL.md sits right at the 4000-char cap (trimmed to 3997 in infra#454). This edit must stay **under 4000** - trim elsewhere sentence-by-sentence if needed, without dropping the affirmative rule or any script mapping. ## Related infra#454 (the callout), infra#452 trap #4 (the org-secret admin gate), ward#579 (the --aws line - do not touch), ward#576.

coilyco-ops commented

2026-07-03 19:43:14 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-infrastructure-460 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-03T19:43:08Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-infrastructure-460` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-03T19:43:08Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-03 19:54:20 +00:00

docs(skills): split CI_RELEASE_TOKEN org-secret from repo-secret tokens in token-minting

coilysiren closed this issue

2026-07-03 19:54:20 +00:00

coilysiren commented

2026-07-03 19:56:20 +00:00

Author

Owner

WARD-OUTCOME: done - token-minting SKILL.md now splits the fully-agent-run repo-secret tokens (tap/scoop, plus read-only flux) from CI_RELEASE_TOKEN, whose org-secret PUT stays operator-gated.

The substance of this was small and the framing was already 90% right - the real work was fitting the new nuance into a file that was already dead flush against the 4000-char cap. Adding a clear repo-vs-org split paragraph cost ~460 chars, so most of the effort was a sentence-by-sentence trim pass everywhere else to claw it back to 3984 without dropping a single script mapping or the affirmative 'the grant IS a script you run' rule. That fought back more than the actual idea did.

One nice surprise: reading the scripts to get the split exactly right showed tap is actually SSM-only (it sets no Forgejo secret at all), and scoop's own header comment already contrasts itself against CI_RELEASE_TOKEN's admin-PAT org PUT - so the source agreed with the issue framing and I could describe each token precisely rather than hand-wave 'repo secrets'.

Left the --aws line untouched per the issue (ward#579 is making it true). Fairly confident in the result - all the size/skill/layout hooks pass and pylint rates the tree 10/10. Only rough edge worth noting: the pylint pre-commit hook wants to write to a root-owned /opt/uv/python and fails in this container until you redirect UV_PYTHON_INSTALL_DIR to a writable path - an environment wrinkle, not a code one, but it'll bite any docs-only commit here. Might be worth a follow-up to point that dir somewhere writable by default.

WARD-OUTCOME: done - token-minting SKILL.md now splits the fully-agent-run repo-secret tokens (tap/scoop, plus read-only flux) from CI_RELEASE_TOKEN, whose org-secret PUT stays operator-gated. The substance of this was small and the framing was already 90% right - the real work was fitting the new nuance into a file that was already dead flush against the 4000-char cap. Adding a clear repo-vs-org split paragraph cost ~460 chars, so most of the effort was a sentence-by-sentence trim pass everywhere else to claw it back to 3984 without dropping a single script mapping or the affirmative 'the grant IS a script you run' rule. That fought back more than the actual idea did. One nice surprise: reading the scripts to get the split exactly right showed tap is actually SSM-only (it sets no Forgejo secret at all), and scoop's own header comment already contrasts itself against CI_RELEASE_TOKEN's admin-PAT org PUT - so the source agreed with the issue framing and I could describe each token precisely rather than hand-wave 'repo secrets'. Left the --aws line untouched per the issue (ward#579 is making it true). Fairly confident in the result - all the size/skill/layout hooks pass and pylint rates the tree 10/10. Only rough edge worth noting: the pylint pre-commit hook wants to write to a root-owned /opt/uv/python and fails in this container until you redirect UV_PYTHON_INSTALL_DIR to a writable path - an environment wrinkle, not a code one, but it'll bite any docs-only commit here. Might be worth a follow-up to point that dir somewhere writable by default.