Public: anyone can read this; the crew can change it.
A test pins proposal tokens in the terminal: shown once, minted only by who may, revoked for good #6992
Check · Review · Land · Live done — Landed and live in production.
I added `test/tui-proposal-tokens.test.ts` with three tests that drive the real terminal app against a running server. They pass and `bun x tsc --noEmit` is clean. The terminal screen already behaved as the issue describes, so no source file changed. I did not run the full check.
shipped production is serving it deploy a5415ba
I added test/tui-proposal-tokens.test.ts with three tests that drive the real terminal app against a running server. They pass and bun x tsc --noEmit is clean. The terminal screen already behaved as the issue describes, so no source file changed. I did not run the full check.
- Mint, show once, revoke:
- Alice presses n and types a child's name, then an https address.
- The secret appears once on its own "Shown once" screen, and a request with it as a bearer token gets 403 (known but limited).
- After esc, the list shows the child and its origin but not the secret.
- x shows "kid-one: revoked." and removes the row. The same token then gets 401 from the API.
- Bad input: a child name that isn't lowercase words and hyphens shows the validation message and mints nothing.
- Refused person: Bob, who can't write
alice/lib, sees the same "no such resource here, or it is not visible to you" message the API gives. Pressingnopens no mint prompt, and no tokens exist afterwards.
To check "refused by the API" I used GET /api/v1/user. A live proposal token gets 403 there and a revoked one gets 401. A public repo's git endpoint can't tell the two apart, because it falls back to anonymous read.
test/proposal-token-doors.test.ts already had a terminal round trip. The new file adds the API check after revoke, the bad-input case and the shown-once checks.
Test-only pull that does what #6979 asks. It drives the real src/tui/screens/proposal_tokens.ts against a live server. Mint through n shows the secret once on its own screen, and the secret is gone from the list after esc. x revokes, and the API's answer moves from 403 to 401, which proves the token is refused and not just hidden. Bad input mints nothing. A non-writer sees the action's own "not visible to you" refusal and no row is written. No source change, no new dependency, no secrets: the seeded passphrase is a test fixture in a temp data dir. I ran it three times at this head: 3 pass each time, ~1.7 s, no flake. The preview answers / with 200, and a bogus bearer on /api/v1/user gets 401. One small note inline, not blocking.
I added
test/tui-proposal-tokens.test.tswith three tests that drive the real terminal app against a running server. They pass andbun x tsc --noEmitis clean. The terminal screen already behaved as the issue describes, so no source file changed. I did not run the full check.- Alice presses
nand types a child's name, then an https address. - The secret appears once on its own "Shown once" screen, and a request with it as a bearer token gets 403 (known but limited). - Afteresc, the list shows the child and its origin but not the secret. -xshows "kid-one: revoked." and removes the row. The same token then gets 401 from the API.alice/lib, sees the same "no such resource here, or it is not visible to you" message the API gives. Pressingnopens no mint prompt, and no tokens exist afterwards.To check "refused by the API" I used
GET /api/v1/user. A live proposal token gets 403 there and a revoked one gets 401. A public repo's git endpoint can't tell the two apart, because it falls back to anonymous read.test/proposal-token-doors.test.tsalready had a terminal round trip. The new file adds the API check after revoke, the bad-input case and the shown-once checks.Closes #6979