Jev-Register-Tool

It replays Server Action and magic-link steps over HTTP with no browser. Registration and key creation are automated, onboarding is only partially推进able, and key issuance is the success signal even when gate state looks unsettled.

Choose --mail-backend cf for a self-hosted temp-mail Worker or remail for the paid aggregator. Both expose the same create, list, and wait interface so the stage layer does not change.

Resume skips addresses that already have a key by default, ledger views merge by mailbox, and success.jsonl is account-level while keys.txt is credential-level, so their line counts naturally differ.

Copy .env.example to .env, run tools/run_e2e.py --doctor for a per-backend check, selftest.py for the offline suite, then --count runs plus verify_keys.py and check_deliverables.py for acceptance. Only requests is required.

As of 2026-09-21 the waitlist is gone and the chain shrank from seven stages to four: the site no longer takes an application, and registration directly produces a Welcome to TypeSafe — confirm your email message whose magic link is the login credential. Two site-side criteria back that: POST /login returns x-action-redirect: /login?sent=true and the waitlist parameter no longer works. The apply, watch and claim modes were deleted accordingly.

Registration plus login replays a Server Action and a Stytch magic link in 4.5 to 6.7 s, key creation through POST /api/api-keys takes 1.8 to 5.0 s, and acceptance verification is about 0.6 s per key. Onboarding sits inside the third stage: the first two steps automate, but the final console-survey hop renders without an $ACTION_* hidden field and cannot be submitted, so it is recorded as partial in the ledger rather than treated as a blocker.

Four deliverables under result/: success.jsonl at account level, keys.txt as email----key----id at credential level, keys_verified.json, and apikeys.txt, the metadata-free version of keys.txt written by the same verify pass so the two are set-identical and usable as a cross-check. Credentials are the ones in keys.txt, which holds plaintext API keys and must never be committed. tools/probes/audit_keys_against_site.py reconciles the deliveries against the site's own key list.