Project Name: Portable SiXiS Protocol — make non-Tommy operators able to drive discovery drills end-to-end without local CLI

Surfaced by Quang's 2nd-user test 2026-05-11 (breakdown event 05:05 UTC, draft 0ee1a2f5-e316-425a-9784-8f38ba33a17a). Quang submitted a project from his PC via dashboard.sixis.ai/new-project as owner=quangholio — that part worked. He then copied the bootstrap prompt and pasted it into his Claude Code on his PC. His Claude hit a real wall:

> "Local sixis.py CLI requires sixis_dashboard.db (SQLite) at the repo root. It doesn't exist on this PC. Per the wizard's own injected context, 'Local SQLite is an archive a[ssist]'..."

The architectural gap: the discovery-drill bootstrap prompt template (prompt_templates.discovery_drill v3) embeds LOCAL CLI commands like `cd ~/Documents/Claude/Projects/SixiS/projects/dashboard_v0_1 && python3 scripts/sixis.py log-discovery-answer --draft-id X --question Y --answer Z`. These assume:
- The operator has Tommy's full dashboard_v0_1 repo cloned locally
- A working sixis_dashboard.db SQLite file exists at the repo root (it's gitignored — built locally on first run)
- Python deps installed (psycopg, etc.)
- SIXIS_OPERATOR env var configured
- For some commands: SIXIS_DATABASE_URL pointing at the right Supabase DSN
- For session-start: ~/.claude/commands/sixis-cron-setup.md and ~/.claude/commands/sixis-pickup.md present in the operator's Claude config dir

None of this exists on Quang's machine. Even if we wanted to install it for him, it crosses the "trust-tier-teammate" boundary the architecture set up — Quang is a public user, not someone we want to onboard as a sysadmin of his own SiXiS workstation.

What needs to change: every substrate-write the discovery drill performs needs to be available as an HTTP endpoint on dashboard.sixis.ai (the wizard backend on Railway). Then the bootstrap prompt for non-Tommy operators uses curl POSTs to those endpoints instead of local CLI calls. The wizard backend already has /api/log-brain-response, /api/report-friction, /api/ui-launch-event, /api/quick-log, /api/declare-convergence, /api/ratify-amendment, /api/generate-council-prompts, /api/operators — but the discovery-drill flow specifically needs:
- /api/log-discovery-answer (one POST per Q&A pair)
- /api/log-discovery-synthesis (final synthesis after the drill)
- /api/log-discovery-complete (drill closure marker)
- /api/promote-draft-to-project (council convergence → project_start event)
- /api/cross-poll (fire a council cross-poll programmatically)
- /api/log-cycle-start, /api/log-cycle-end (cycle lifecycle)
- /api/report-breakdown (already partial via friction; needs explicit endpoint)
- Whatever else the discovery drill touches that I'm forgetting — discovery drill from the live council ratification (Cycle 2 design) lists these CLIs: log-discovery-answer, log-discovery-synthesis, log-discovery-complete, prompt-template add, report-breakdown — only a subset of what a full project run needs

Then the bootstrap prompt template needs to be FORKED or BRANCHED based on operator: Tommy's prompt keeps the local-CLI flavor (faster, no network roundtrip per write), Quang's prompt uses HTTP endpoints. Or: we collapse everything to HTTP-only and Tommy's local CLI becomes a thin wrapper that hits the same endpoints (eliminates the dual codepath at the cost of latency on Tommy's side).

Counter-question to consider: is the right answer instead "stop letting non-Tommy operators run discovery drills, and route them to a guided-by-orchestrator path where Tommy or the daemon drives on their behalf"? That preserves the local-CLI architecture but limits autonomy. The whole point of multi-operator SiXiS was for Quang to spin up his own projects independently — so this counter probably doesn't survive scrutiny, but worth surfacing for the council to weigh.

Tier: 2 (architectural — moves substrate-write authority from local CLI to HTTP endpoints; affects every operator-onboarding story; partially irreversible since once Quang's prompt template uses HTTP, rolling back means breaking him).

Sequencing relative to existing queue:
- Daemon project: independent (daemon writes are server-side, no local CLI involved on operator end)
- Dashboard consolidation (draft 3ba906b2): adjacent — both consolidation and this share the wizard_backend as the cannonical write surface. Could be sequenced as consolidation finishes Tommy's full UI parity, then this expands the API surface to cover full-fat protocol writes.
- Phase E .app bundle: independent (about Tommy's daemon launch story, not operator's discovery flow).

Out of scope: building a full Quang-side desktop app, rewriting Claude Code, replacing Supabase. Just porting the discovery-drill substrate writes to HTTP endpoints + branching the bootstrap prompt template by operator type.

Acceptance criterion: Quang submits a project from his PC, follows the bootstrap prompt end-to-end through discovery → synthesis → council cross-poll → ratification → project_start, all without any local SiXiS install on his machine. Verified by re-running Quang's exact 2nd-user test from 2026-05-11 and getting a green path.