[mthines]

Why

After #702, the deploy run's "Ensure the fixed smoke user exists on preview" step ran but could not create the user (run 39131692320):

error: admin user creation failed (HTTP 403)
  {"code":403,"error_code":"bad_jwt","msg":"invalid JWT: ... token contains an invalid number of segments"}

The preview SUPABASE_SERVICE_ROLE_KEY is a new-generation sb_secret_… key. seed-smoke-user.mjs sent the anon key as apikey and the service key only as Authorization: Bearer. With an opaque secret key, GoTrue then parses the secret as a JWT and rejects it. So the orgs REST smoke stayed skipped.

What changed

• scripts/smoke/seed-smoke-user.mjs: the Auth admin calls (create, list, update) now send the service-role key in both apikey and Authorization. This is the shape scripts/load-test/ already uses, and both key generations accept it (see docs/benchmarking.md). The sign-in check still uses the anon key. The key is also trimmed.

How to verify

Against a local Supabase (CLI default keys):

Keys	Before	After
sb_secret_… + sb_publishable_… (CI's shape)	403 not_admin¹	user created, sign-in verified
same, password drifted	—	password reset, sign-in verified
legacy service_role + anon JWTs	worked	user created, sign-in verified
rerun	—	no-op (already seeded)

¹ Local GoTrue answers the mismatched pair with not_admin; the hosted project answers it with bad_jwt (the CI log above). Both are the same rejection of an anon apikey paired with a secret-key Bearer.

After merge, the deploy run's smoke-preview should log ok — smoke user seeded and the orgs REST suite should run.

User-facing docs/llms.txt: none applied, because this is a CI helper script fix with no user-visible change.

[mthines]

✅ No issues found

One-file CI helper fix: the Auth admin calls now send the service-role key as both apikey and Bearer, the shape scripts/load-test/ already uses. No blocking issues; one optional hardening idea.

_{1 advisory finding below the confidence bar — see Less certain below.}

Checked: 1 of 1 changed file read · 3 possible issues → 0 confirmed → 0 posted

Less certain (1) — advisory, below the confidence bar

• scripts/smoke/seed-smoke-user.mjs:120 — suggestion: The apikey half still relies on each caller passing serviceKey to authFetch. Returning both headers makes the pairing structural, since init.headers overrides the default. (confidence 79)

Review details

Gate	Status	Details
Description vs. code	✅	Description matches the diff: admin calls send the service key as apikey + Bearer; sign-in keeps the anon key.
Prior review feedback	✅	Earlier review comments are resolved.
Documentation	✅	adminAuth() docblock and the key comment explain the pairing; PR body states why no user docs apply.
Self-review signals	✅	No debug logs, leftover TODOs, or unreviewed stubs.
Code review	✅	The multi-lens review found no blocking issues.

Found

Quality — produced 3 → posted inline 0 · cleared 0 · carried forward 0 · deferred 0 · below-bar 1
Dropped — 1 below-bar
Optimality — ran — approach optimal (matches the existing scripts/load-test/ admin-header shape); 0 proposals
Standards — ran — 1 doc (CLAUDE.md), 48 bullets; 0 findings (user-facing-docs rule satisfied by the PR body's none-applied line)
Measurability — ran — quiet: gate 1 not met (CI helper script, no web/mobile/api/worker path)

Run

full · 33 lines in delta · tier deep · depth checkout
⚠️ 2 prepare-time anomalies (reviewer identity unknown (no --reviewer-login / PR_REVIEWER_LOGIN; /user 401s here) — relation defaulted to cross, +1 more)
Integrations — not activated (no manifest or lockfile in the diff)
CI — still pending: Detect changes
Memories — no relevance rules or lessons consulted

^{Nothing to report — severity, reach diagram (impact graph found no consumer or importer), 0 files skipped.}

^{pr-reviewer · commit 423e3b4 · full review · how these findings are produced · updated Oct 18, 2026 1:46pm UTC}