The admin CLI could list invite codes but not make them. It authenticates with the admin password, and createInviteCode accepted only an admin DID's service-auth token or an account session, so there was nothing for a create command to call.
createInviteCode now also accepts the admin password over HTTP Basic, as the reference PDS gates it. The Basic header goes through require_admin, so it gets the same per-address rate limit, fail-closed behaviour and 401 as the admin routes, and a wrong password never falls through to the session path. An admin caller, by password or by DID, may name any forAccount, whose issuance toggle still applies. A code minted with no forAccount is attributed to nobody. A session still cannot attribute a code to another account.
The CLI gains invite create (--use-count, --count, --for-account,
--json), invite disable ..., and invite disable-account /
enable-account. --count calls createInviteCode once per code rather
than routing createInviteCodes, which would mean choosing a wire value
for the reference PDS's "admin" pseudo-account. invite disable takes
codes only, because disableInviteCodes here ignores the lexicon's
accounts field.
The README said the CLI issued invite codes, which it did not. Its Binaries section now lists the actual commands.
Tests cover an unattributed code that peek and reserve then accept, a code for a named account, an unknown account (404), a disabled account (403 InviteIssuanceDisabled), and a wrong password (401).
Reported as https://tangled.org/ngerakines.me/atproto-crates/issues/9
Kata: atproto-crates#kgkn