## [mirendev/runtime#1430](https://github.com/mirendev/runtime/pull/1430)

Still ready for human review. The two new commits take up evanphx's three inline suggestions, and I didn't find anything new that should block.

**`e2e74ef`: neutral `requireCoordinator` wording.** The three errors in `components/runner/nodeadmin.go` now say "this call requires…" and "only the coordinator may call this on a runner". They read correctly whether the refusal comes from node admin, the query service, or the new `coordinatorOnlyExec` wrapper. Nothing in the tree still asserts on the old wording. `exec_v1alpha.SandboxExec` has only `Exec` and `Attach`, and the wrapper guards both, so no exec method gets past the coordinator check through the embedded interface.

**`af42561`: limits in the help, and the runner-renewal warning.** `authRevokeDescription` and the regenerated `docs/docs/command/auth-revoke.md` now cover:
- how hex and decimal input is read
- that the server can't tell a typo from a real serial
- that there's no un-revoke, so you reissue instead
- which certificates it refuses to revoke
- what to do about a leaked runner certificate

The parsing description matches `parseCertSerial`. Digits alone take the decimal branch. A letter, a colon, or `0x` takes the hex branch, which strips the colons. The confirmation prompt does print both forms. The claim that an all-digit hex serial is "vanishingly unlikely" depends on 128-bit serials, and that holds: `caauth.generateSerialNumber` issues them, and the 63-bit generator in `pkg/rpc/cert.go` only makes self-signed certs.

Repeating the runner advice in the stderr warning after a revoke is the right move. As the commit says, `--help` doesn't render `WithDescription`, and the warning is what someone handling a leak will actually read. The advice also matches how revocation behaves. A replacement certificate that was already minted isn't touched. `runner delete` stops further `RefreshCertificate` calls. The audit trail records subject and serial, so the other serials can be found and revoked.

My two earlier human-judgment threads are closed, and the API-certificate guard hasn't changed since the last round.

I'm still not recommending approval in place of a human review, for the reason I gave before. This changes authentication on every HTTP listener the coordinator and runners expose, and it makes boot fail closed based on what's in etcd. A person should sign off on that, even though I have no open defects. I've replied on evanphx's threads with what I see and left closing them to him.

## Replies to existing threads

_Posted to the PR's comment threads when you submit._

- _(reply)_ `af42561` covers this in two places. The `auth revoke` description, which ends up on the generated docs page, says to run `miren runner delete` and then check the audit log for other serials with that runner's subject. The warning printed after every successful revoke says the same thing, which matters because `--help` doesn't render the description. The CLI can't tell from a serial whether it belonged to a runner, so printing the warning every time is the honest choice. I'll leave closing this to you.
- _(reply)_ `e2e74ef` makes all three errors in `requireCoordinator` neutral ("this call requires the coordinator's certificate…", "only the coordinator may call this on a runner…"), so they fit exec/attach, query, and node admin alike. Nothing still asserts on the old wording. I'll leave closing this to you.
- _(reply)_ `authRevokeDescription` now covers the hex/decimal rule, the typo limitation, no un-revoke (reissue instead), the certificates it refuses to revoke, and the runner case. `docs/docs/command/auth-revoke.md` has been regenerated with that text. I checked the parsing description against `parseCertSerial` and they agree. I'll leave closing this to you.

---

**Verdict:** ready