What it creates
pithy add testers wrote the wiring; pithy testers is the command surface; Using Testers is what you do once it stands.
pithy testers provisionOne thing: the prebuilt Worker that hosts the daily pass, bound as TESTERS_DAILY.
No bucket. No index. No secret.
The short list is the point
A capability that needs less provisioning is one an adopter is more likely to finish setting up.
Skip provisioning entirely and everything works except the 05:00 pass — you would run pithy testers run yourself, on your own schedule.
No secret to provision
The confirmation link is a random token on the tester’s own row, not a signature.
Two things follow from that:
pithy testers invite builds a working invitation against any environment, because there is no per-environment signing key to have provisioned first.
Removing a tester actually revokes their link. A signed link could only expire — the signature stays valid until its clock runs out, whatever you do to the row behind it. A token on a row disappears when the row does.
That is also what makes the opt-out rotation work: withdrawing rotates the token, which kills every link already sitting in that tester’s inbox.
What you set up yourself
pithy add testers
pithy migrate
pithy testers provisionSet baseUrl before you send anything. An email cannot carry a relative link, and a nudge with a broken link is worse than a nudge you did not send.
Add the email capability to the same Worker if it is not there. Invitations and nudges are enqueued through it — so they inherit its retries, its suppression list and its bounce handling, rather than opening a second delivery path with none of them.
What provisioning cannot do for you
Adding an address to a Play email list is a manual step in Play Console, because the Play Developer API has no way to do it. See gaps in Play APIs.
That is not a gap in this command. It is a gap in the store’s API, and it is why the tester journey is two emails rather than one.