Integration — plugging into the live API

Turning it on

One block, before the scripts, on whichever pages should run live:

<!-- 1. config (omit entirely to stay on static data) -->
<script>
window.SUPREME_CONFIG = {
  mode:            'supabase',   // 'static' | 'rest' | 'supabase'
  supabaseUrl:     'https://<project>.supabase.co',
  supabaseAnonKey: '<anon key>',
  token:           session.access_token,   // the signed-in admin's JWT
  cacheMinutes:    10,
  staleAfterDays:  7
};
</script>

<!-- 2. load order matters: data, then adapter, then the page -->
<script src="_data.js"></script>
<script src="_api.js"></script>
<script>
  SupremeData.setAdmin(currentAdminId);
  await SupremeData.load();   // fills CLIENTS / SHELF / NOMINEES / RUNBOOKS in place
  render();                    // existing page code, unchanged
</script>

What the API has to return

Two options. Either PostgREST directly against the schema, in which case _api.js already knows the table and column names, or a single bootstrap endpoint if you would rather assemble it server-side.

The one thing that will break at 15 admins

Three teams of five all pull work at the same time. A naive select … limit 10 for update makes fourteen of them wait behind the first. The schema ships a claim function that does not:

update public.tasks t
   set status = 'claimed', claimed_by = p_admin_id, claimed_at = now()
 where t.id in (
   select id from public.tasks
    where status = 'open'
    order by priority, id
    limit p_limit
    for update skip locked          -- each admin gets DIFFERENT rows
 )
returning t.*;

Call it as rpc/claim_tasks with { p_admin_id, p_limit }. There is also release_stale_claims() — run it on a schedule so work claimed by someone who then logged off does not sit invisible forever.

Schema notes worth keeping

• Credentials are a separate table. client_credentials holds the Companies House authentication code and Gateway user ID under tighter RLS than the client record. An admin sees a code only while they hold live work on that client. Do not merge it back into clients for convenience — the whole point is that a company name and an auth code are not the same class of data.
• Nominee records are personal identity data. Same pattern: visible to supervisors, and to the admin holding that person's task. Nothing broader.
• RLS wraps auth.uid() in a subselect so it evaluates once per query rather than once per row, and the helper functions live in a private schema with execute revoked from anon and authenticated.
• Every foreign key has its own index. Postgres does not create these automatically and their absence is the usual reason a dashboard like this gets slow six months in.
• The queue index is partial — where status = 'open' — so it stays small no matter how many completed tasks pile up behind it.
• ch_verified_at is the freshness contract. Set it on every live Companies House read. Anything older than seven days is surfaced as unverified, because the whole pack is built on the principle that the register is live and our copy of it is not.
• task_events is append-only. There is no update or delete policy on it deliberately.

Scaling to 3 teams of 5

The schema carries teams and admins with a day_capacity defaulting to ten. v_admin_load gives live per-person load — claimed, awaiting confirmation, and closed in the last seven days — which is what a team lead needs to see rather than a total.

Order to build in