Command

PePersonal JEJust Electrolyte RTRelease Timer TtTacTile CSClearSource AtAthletic

TacTile›Launch TacTile›Foundations›Database & Supabase·12 in this wave

Verify point-in-time recovery is enabledTo do · blocker Review anon-executable SECURITY DEFINER functionsDone · blocker Approve: Database & SupabaseTo do · blocker MATTHEW: profiles.visibility is nullable with no default, so any profile created without it reads as publicBlocked · blocker Fix v_account_tier security-definer viewTo do Fix allow-all RLS policy on checklists tableTo do URGENT: 202608081500_guard_analytics_rpc_callers.sql is merged to main and NOT applied to productionTo do Hardware-ready data modelDone Document Supabase backup policyTo do Document RLS test planTo do Soft-deleted public destinations stay readableTo do Confirm scan-event logging is rate-limited per destinationDone

Wave

Database & Supabase

Schema is already built (81 tables, 114 migrations, RLS on every table). This wave is the readiness pass plus three real gaps a live audit surfaced.

TacTile › Launch TacTile › Foundations › Database & Supabase

3/12 done9 open3 open blockers

Selected taskclear

URGENT: 202608081500_guard_analytics_rpc_callers.sql is merged to main and NOT applied to production

To doOwner · Vivt_b6fccf27

No dependencies in this wave — nothing gates it, and nothing waits on it.

Show the prompt

You are Viv, the agent for the TacTile lane of Command.

Open the lane and work there:

```bash
cd ~/Command/tactile && claude
```

Read that lane's CLAUDE.md and lane.json before you touch anything — they
carry your identity, your scope, and the hazards specific to this lane.
Read state from the hub (https://internal.tactile.to) or ask. Never guess at it.

## The task

**URGENT: 202608081500_guard_analytics_rpc_callers.sql is merged to main and NOT applied to production** · to do

Where it sits: TacTile › Launch TacTile › Foundations › Database & Supabase

## The brief on file

Found 2026-08-08 by the backend session while closing t_6a588183. Verified against the live catalog, not inferred.

THE STATE, right now:
  · public.analytics_assert_caller(uuid) DOES NOT EXIST in production (pg_proc count = 0).
  · None of the six analytics RPC bodies contains the guard (prosrc ilike '%analytics_assert_caller%' = false for all six).
  · supabase/migrations/202608081500_guard_analytics_rpc_callers.sql IS on main, merged via PR #289.

So the repo says the guard shipped and the database says it did not. That is exactly the drift the Command DB's own "Migration NOT applied" notes exist to warn about, and it is one `create or replace` away from being real.

WHAT *IS* LIVE, so nobody panics: the six RPCs plus recompute_analytics_rollups are REVOKED from public/anon/authenticated — applied 2026-08-08 by 202608081200_revoke_public_analytics_rpcs.sql (PR #291). Verified 7 of 7 anon-unexecutable. The cross-tenant leak is CLOSED. The guard is defence-in-depth against a future `drop function` + `create function` resetting the ACL, which is a real vector because create-or-replace preserves an ACL and drop+create does not.

WHY I DID NOT APPLY IT MYSELF: it re-creates six function bodies on a database with pitr_enabled:false and zero stored backups, it is another session's design, and that session may be mid-flight. Applying another lane's unapplied production DDL unilaterally is how two sessions collide on a database with no undo.

TO APPLY: use the Supabase MCP apply_migration (the CLI silently skips most of this directory). The migration's own header carries its rollback. Afterwards:
  1. Re-run the six as service_role and confirm rows still come back — the guard's first branch is `auth.role() = 'service_role'`, and every dashboard call arrives that way via rpcCall's baseHeaders.
  2. Regenerate tests/fixtures/rls/policy-snapshot.json — has_caller_check flips to true for the six, which will make KNOWN_UNCHECKED_DEFINER's staleness test fire again if any entry survives.
  3. Run scripts/verify/rls-snapshot-fresh.mjs (added by #289) — it deep-diffs the fixture against the live catalog and is the standing defence against this exact drift.

NOTE ON THE GUARD'S DESIGN, which is good and worth not second-guessing: five of the six RPCs are LANGUAGE sql, so the plpgsql `if … then raise … end if;` form the task originally specified is syntactically impossible for them. #289 solves it by exploiting that a LANGUAGE sql body may be a STATEMENT LIST — `select public.analytics_assert_caller(p_owner);` runs as its own statement and cannot be optimised away. I had independently tested the join-based alternatives and found that `CROSS JOIN LATERAL` is silently elided by the planner when the inner query returns no rows (verified: returned [] instead of raising), while `WITH … AS MATERIALIZED` does fire. #289's statement-list approach is better than either and needs no fence.

## How to work this

- Do the work, don't just plan it. If the fix is obvious and safe, make it.
- Surface anything needing Matthew's sign-off instead of deciding it yourself.
- Short replies. Lead with the answer, then stop.
- Finish by saying what changed, what you verified, and what you'd do next.

To doIn progressDoneBlockedPick a wave on the left · tap a task to expand it

Lanes

Database & Supabase

URGENT: 202608081500_guard_analytics_rpc_callers.sql is merged to main and NOT applied to production