Project Name: Dual-Substrate CLI to Supabase Migration

Currently the SiXiS CLI (scripts/sixis.py) writes to local SQLite (sixis_dashboard.db) for all event-emitting subcommands: cross-poll, converge, log-brain-response, event-log, judge-clear, project-start, cycle-start, suggest-accept, log-discovery-answer, log-discovery-synthesis, log-discovery-complete, report-breakdown, etc. The wizard backend on Railway writes directly to Supabase. The two substrates only sync when `sixis publish` runs (which dumps SQLite, pushes the dump to ui/data.json, and the next dashboard load reflects the new state on Supabase via that path).

Why this is a problem in practice:
1. Cross-machine work is broken. Tommy works from multiple computers (this Mac, potentially others). The CLI on another machine writes a DIFFERENT local SQLite, invisible to dashboard.sixis.ai until that machine's `sixis publish` runs. There's no cross-machine real-time visibility into council polls, convergence events, brain responses, etc.
2. Publish is a chokepoint. Every CLI write that should be immediately visible to dashboard.sixis.ai is silently invisible until publish. This shows up as "I logged it but I don't see it on the site" friction.
3. Drift accumulates. Council R1 polls fired via CLI live in SQLite for hours/days until publish. If Tommy never publishes (e.g., cycle is interrupted), those events are stranded local.
4. The `integrate_supabase_v0_1/scripts/pull_supabase_to_sqlite.py` bridge is one-way (Supabase → SQLite) and read-only. There's no reverse bridge for CLI writes. This is the gap the previous council R1 (poll 1ae22158 / convergence d3443664) explicitly flagged as out-of-scope-for-consolidation-but-next-cycle-anchor.

Goal: migrate the ~50 INSERT INTO events / cycles / rules / amendments / etc. call sites in scripts/sixis.py from sqlite3 to psycopg, writing directly to Supabase. Eliminate sixis_dashboard.db as a write-target. Local SQLite becomes either (a) gone entirely, or (b) a transparent local cache populated by pull_supabase_to_sqlite.py for offline read-only browsing.

Scope considerations to fold into discovery:
- Operator attribution mapping: SQLite uses text project_id "p_xxx"; Supabase uses UUID. The CLI needs a uniform resolver (likely a stable hash from slug → UUIDv5).
- Offline mode: do we keep ability to run CLI offline (write SQLite as buffer, sync later) or require always-online?
- Migration of historical SQLite events into Supabase: most are already there via past publishes; check for drift.
- Cycles and projects from cmd_project_start need to land on Supabase too (otherwise the consolidation cycle's a9b97dfc-style local-only-cycle problem recurs).
- DEEPSEEK_API_KEY env handling on non-this-Mac (no Keychain on Linux/Windows; fall back to env var or .sixis/secrets.env per council R1 minority).
- Cross-platform: scripts/sixis.py should run on Linux/Windows for cross-machine use; today it assumes macOS paths in places.
- Substrate event_type enum: local SQLite has different types than Supabase (e.g., 'observation' is in neither but was used). Reconciliation needed.
- Substrate event_source enum: Supabase rejects 'ui'; the wizard backend already learned this. CLI needs to match.
- Path resolution for ~/Documents/Claude/Projects/SixiS/... is Mac-specific. Cross-machine CLI should either (a) be path-agnostic via env vars, or (b) check out the project repo to a known location per-machine.

Constraints:
- Don't break the running daemon (orchestrator_daemon_v0_1/sixis_daemon) which also writes to local SQLite for work_queue, browser_profile_lease, project_brain_threads, intent_log. Those tables are operational not auditable — keep them SQLite for now, OR also migrate.
- Don't break `sixis publish` semantics — it still needs to update ui/data.json on Vercel from a snapshot of current state.
- Don't break Phase E LaunchAgent — the daemon was just shipped and is in 3-reboot acceptance bake.

Tier: 2 (architectural, touches every CLI write path, but reversible — keep both substrates working during migration).

After ship, cross-machine workflow looks like:
- Clone sixis-dashboard repo on any machine
- Set SIXIS_DATABASE_URL + DEEPSEEK_API_KEY env
- Run sixis CLI — writes go to Supabase directly
- dashboard.sixis.ai reflects in real-time (no publish needed for visibility)
- `sixis publish` becomes a deploy operation (push git, wait for Railway/Vercel) not a substrate sync

Council R1 ratified this as the next-cycle anchor; explicit deferral from poll 1ae22158 d3443664. Picking it up now as the natural follow-on to Phase E.