Capabilities
What each one is for is the capability catalog; what a capability is is its own page; what installing one writes is bindings and tables.
| Package | pithy add | |
|---|---|---|
@pithy-sh/auth | auth | Passwordless sign-in, sessions, devices |
@pithy-sh/payments | payments | Five rails, one entitlement model |
@pithy-sh/storage | storage | Objects on R2, with revocable shares |
@pithy-sh/media | media | A backend per media type, plus enrichment |
@pithy-sh/email | email | Templates, a send log, suppression |
@pithy-sh/vector | vector | Semantic search on Vectorize |
@pithy-sh/artifacts | artifacts | Git repositories for your customers, on Cloudflare Artifacts |
@pithy-sh/secrets | secrets | Encrypted values, rotation, a master key |
@pithy-sh/turnstile | turnstile | The humanity check |
@pithy-sh/i18n | i18n | Negotiation, catalogs, formatting |
@pithy-sh/audit | audit | The queryable trail |
@pithy-sh/consent | consent | An append-only consent record, from a checkbox to a signed authorization |
@pithy-sh/support | support | An inbox, classified on your own AI |
@pithy-sh/testers | testers | The twelve-for-fourteen clock |
@pithy-sh/ledger | ledger | Balances that cannot go negative |
@pithy-sh/leaderboard | leaderboard | Ranked boards, calendar windows |
@pithy-sh/rating | rating | Elo, Glicko-2, TrueSkill |
@pithy-sh/multiplayer | multiplayer | Authoritative turn-based sessions |
@pithy-sh/matchmaking | matchmaking | Four ways into a session |
Plus two that ship inside another package. controlplane is a pithy add argument that ships inside @pithy-sh/core, and mcp one that ships inside @pithy-sh/auth, beside auth, with its own manifest, pithy.mcp.manifest.json — so @pithy-sh/controlplane and @pithy-sh/mcp are packages that have never existed.
Infrastructure
| Package | |
|---|---|
@pithy-sh/core | The contract. createBackend, the seams, the error taxonomy, the migration runner, the naming facade, the control-plane seam |
@pithy-sh/cli | The pithy command |
@pithy-sh/cloudflare | The REST client. Provisioning’s outbound half — never in a request handler |
@pithy-sh/ui-core | What both screen sets share: useRead, useAction, Redirect and the route table. It imports nothing but React |
@pithy-sh/ui-react | The screens pithy ui add react copies. It re-exports useRead, useAction and Redirect from @pithy-sh/ui-core, so screens scaffolded earlier keep resolving |
@pithy-sh/ui-react-native | The screens pithy ui add react-native copies into an Expo app: every ui-react screen in React Native primitives, under the same names and string keys |
@pithy-sh/vite | The Vite plugin |
The one that is not MIT
Which reach a Cloudflare account, and when
@pithy-sh/cloudflare is the only outbound one, and it runs from the CLI or CI with your API token. It never appears in a request handler, and its failures carry cloudflare/* codes.
Every capability runs inside your Worker, against your bindings. The control-plane seam is inbound — a management client calling your Worker with a key you registered — and its failures carry controlplane/* codes.
They share a name and nothing else.
Two that ship no bindings
@pithy-sh/i18n and @pithy-sh/turnstile declare none at all.
i18n is negotiation and catalogs; Turnstile is a middleware plus a public sitekey in config and a secret in the registry.
The naming rule across all of them
A capability’s name is one segment doing five jobs — the pithy add argument, the migration namespace, the pithy_<name>_* table prefix, the error-code domain and the audit-action domain, plus the catalog key.
One rule, so one capability’s contributions cannot collide with another’s — and merge order stops being something anyone has to reason about.