WI-H06: Provision Clerk and Sentry
WI-H06: Provision Clerk and Sentry
Problem
WI-H04 (#12) covered four services. Neon and Cloudflare are provisioned and proven working; Clerk and Sentry are not, and nothing needs them until WI-012 and WI-013.
In scope
| Service | Secrets | Needed by |
|---|---|---|
| Clerk | CLERK_JWT_KEY (PEM public key, a Wrangler secret) | WI-013 |
| Clerk | CLERK_PUBLISHABLE_KEY | the client sign-in flow, a later item |
| Clerk | CLERK_WEBHOOK_SIGNING_SECRET | webhook reconciliation only — not WI-013 (ADR-0005) |
| Sentry | SENTRY_DSN, SENTRY_AUTH_TOKEN | WI-012 |
Out of scope
- Clerk application settings — OTP configuration, providers, the prebuilt UI — all WI-013.
- Sentry alerting rules and source-map upload configuration.
- Any paid tier. Both stay free; an upgrade needs an ADR.
Definition of done
- Both accounts exist, on free tiers.
- Secrets set as GitHub repository secrets.
- Each secret proven non-empty by a job that consumes it.
-
.env.exampleupdated with the names.
Verification
The middle DoD line is the one that matters. During #12, gh secret list showed NEON_API_KEY, the API confirmed it as a repository Actions secret with a creation timestamp, and the scope was correct — and the value was empty. Only a job that consumed it revealed that (secret length: 0).
“The secret is set” is not a checkable claim. Run something that uses it.
Notes
Clerk’s free tier is 50,000 monthly retained users, changed February 2026 (ADR-0005). Published material and model training data widely still quote 10,000 — that figure is stale.
Deferred deliberately: provisioning credentials months before the code that uses them means rotating them before first use.