# External blockers

## Supabase distributed idempotency runtime wiring

- Current implementation in `lib/distributed-idempotency.js` supports Supabase REST mode when:
  - `SUPABASE_URL`
  - `SUPABASE_SERVICE_ROLE_KEY` (preferred) or `SUPABASE_ANON_KEY`
  are present.

- In this workspace execution environment, these credentials were not available, so test execution used the built-in in-memory fallback.

## TODO when env is provisioned

1. Apply migration `db/migrations/007_idempotency_keys.sql` in target Supabase project.
2. Set `SUPABASE_URL` + `SUPABASE_SERVICE_ROLE_KEY` in Vercel/project env.
3. Run:
   - `npm run test:distributed-idempotency`
   - `npm run test:idempotency-sweep`
   - `npm run chk15:adversarial`
4. Re-run live smoke with `CZ_SMOKE_BASE_URL` and attach evidence artifact.
# BLOCKERS (active)

## Distributed idempotency — Supabase env not provisioned in current runtime

- **Impact:** `lib/distributed-idempotency.js` runs in fallback in-memory mode, which is safe for single-instance but weaker for cross-instance replay guarantees.
- **Needed env:**
  - `SUPABASE_URL`
  - `SUPABASE_SERVICE_ROLE_KEY` (preferred) or `SUPABASE_ANON_KEY`
- **Status:** workaround implemented; feature remains functional for development and tests.
- **Next action:** provision env in deployment target and run live validation smoke.