What is at stake
An operator bootstrapping the credential broker on a second machine opens the Cloudflare dashboard to create the standards-broker API token and finds a token with that exact name already exists. Nothing tells them this is expected. The likely reactions are all bad: they hesitate and ask (costs a round-trip), they reuse the existing token value (impossible — values are shown once — so they may instead roll it, which silently breaks the other machine's broker), or they revoke the "duplicate" afterwards (same breakage). The design is fine; the gap is that the operator learns none of this at the moment of decision. This just happened in practice during a fesk-infra credential rollout: the operator stopped and asked whether the duplicate name was a bug that needed fixing here.
Background
The broker intentionally uses one bootstrap token per machine, all sharing the reserved name standards-broker (BROKER_IDENTITY_NAME in creds-naming.ts). Cloudflare allows duplicate token names. creds login cloudflare identifies this machine's token by ID, not by name, and the reconciliation guard refuses to touch any other token that merely carries the reserved name — precisely to protect other machines' bootstraps. So a second same-named token is the intended multi-machine shape, but neither the docs nor the login flow says so.
Proposal
- In the secrets reference (brokered-provider-credentials section), add two sentences: each machine creates its own
standards-broker token; an existing token with that name belongs to another machine and must be left alone, never reused or revoked.
- In
creds login cloudflare, when the account already shows another token named standards-broker, print a hint with the same content instead of leaving the warning implicit.
Recommended: do both; the login-time hint is what actually reaches the operator standing in the dashboard.
Evidence
packages/standards-cli/src/creds-naming.ts — BROKER_IDENTITY_NAME = 'standards-broker'.packages/standards-cli/src/creds-login-cloudflare.ts — verify-by-ID on login, name-based warning only after the fact.- Reconciliation guard refuses same-named tokens it did not mint (protects other machines).
What is at stake
An operator bootstrapping the credential broker on a second machine opens the Cloudflare dashboard to create the
standards-brokerAPI token and finds a token with that exact name already exists. Nothing tells them this is expected. The likely reactions are all bad: they hesitate and ask (costs a round-trip), they reuse the existing token value (impossible — values are shown once — so they may instead roll it, which silently breaks the other machine's broker), or they revoke the "duplicate" afterwards (same breakage). The design is fine; the gap is that the operator learns none of this at the moment of decision. This just happened in practice during a fesk-infra credential rollout: the operator stopped and asked whether the duplicate name was a bug that needed fixing here.Background
The broker intentionally uses one bootstrap token per machine, all sharing the reserved name
standards-broker(BROKER_IDENTITY_NAMEincreds-naming.ts). Cloudflare allows duplicate token names.creds login cloudflareidentifies this machine's token by ID, not by name, and the reconciliation guard refuses to touch any other token that merely carries the reserved name — precisely to protect other machines' bootstraps. So a second same-named token is the intended multi-machine shape, but neither the docs nor the login flow says so.Proposal
standards-brokertoken; an existing token with that name belongs to another machine and must be left alone, never reused or revoked.creds login cloudflare, when the account already shows another token namedstandards-broker, print a hint with the same content instead of leaving the warning implicit.Recommended: do both; the login-time hint is what actually reaches the operator standing in the dashboard.
Evidence
packages/standards-cli/src/creds-naming.ts—BROKER_IDENTITY_NAME = 'standards-broker'.packages/standards-cli/src/creds-login-cloudflare.ts— verify-by-ID on login, name-based warning only after the fact.