MEMORY PROTOCOL — system_state + session_logs (Supabase, project jzfxvkkgxcibliqmkjlu)

Two tables are the durable, machine-readable memory of system reality. They OUTRANK prose summaries and .md notes when they disagree — those are stale until proven otherwise.

• system_state — canonical ground-truth baseline. One row per tracked component (key unique). Columns: category, status (live | partial | specced | stub | not_started | reference), summary, detail jsonb. This is what's actually true right now.
• session_logs — append-only, one row per working session: summary, changes, open_loops, next_actions.

START every session (do this before planning work):

1. select key, category, status, summary from system_state order by category, key; — load the real baseline.
2. select session_date, summary, open_loops, next_actions from session_logs order by ended_at desc limit 3; — load recent continuity.
3. Trust these over any prior chat summary or memory file. If a claim here conflicts with a .md, the table wins until you re-verify against the live repo/services.

END every session (before you sign off):

1. For every component you changed or learned new truth about, UPSERT its system_state row (on conflict (key) do update ... set updated_at=now()). Keep status honest.
2. INSERT one session_logs row recapping what changed, open loops, and next actions.

Connection: creds in ~/.config/0hr/supabase.env (SUPABASE_DB_URL). No psql/supabase CLI on this machine — use a pg client (e.g. a quick node script) or the service key in apps/portal/.env.local (SUPABASE_SERVICE_KEY). Never let these tables drift; a wrong baseline is worse than none.