Sasori

A scoped collaborative surface between Shay (Azure Peak) and Bernays-class agents. Free-form markdown, rendered live in the Stoka admin shell.

This is the prototype service entity. Its existence answers a single question: what does the smallest possible Tsukuyomi-mediated service look like, end to end, from permit issuance to admin rendering to agent write-access?

Why "Sasori"

In the Akatsuki taxonomy, Sasori is the reviewer — patient, precise, watches the work. As a service entity it plays the same role: a quiet shared surface where the long-running thinking about Tsukuyomi itself gets written down, reviewed, and revised.

It is intentionally not a chat. It is a document under joint authorship. Shay reads it in the admin. Bernays writes to it from the substrate. The wiki cross-references it. Other contributor Claudes — once their skills are wired — will be able to read it too.

What this entity tests

The conversation produced a four-tier trajectory for Tsukuyomi:

By existing at all, Sasori validates Tier 1 end-to-end:

1. Stoka registers the entity (tab_grants row + TAB_REGISTRY entry)
2. Stoka renders the card to the right wallets only
3. Tsukuyomi-side substrate (the markdown file) lives on edward, bind-mounted into the container
4. A Bernays-class agent can write to it freely without a deploy
5. The wiki has a place to point to it

Hard architectural choices still open

These are the forks identified in the conversation. Sasori does NOT settle them — it just makes the conversation easier to have.

1. Whose Claude runs in a contributor's tmux? A: their own (best), B: laptop-only + MCP, C: substrate-shared (what we have today), D: hybrid.
2. How sandbox-strict is the dev tier? Pattern 1's docker-group root-equiv is unresolved. Rootless docker vs socket-proxy vs no-docker-from-IDE.
3. Service registry grain. Per-service or per-sub-service? Sasori is one card; future "Sheeran" might be many.
4. Per-machine awareness. Cards may target edward, VPS, corner0, or specific worktrees.
5. Skill discovery protocol. Wiki manifest? MCP discovery endpoint? Hand-distributed?
6. Cross-contributor coordination. Pull (poll wiki/MCP) or push (notification fabric)?
7. Credential lifecycle. Browser session vs per-MCP token — two layers, different lifetimes.

Substrate facts

• Markdown source: /home/edward/public_apps/StokaSoftware/layer2/sasori/notes.md (host) / /app/layer2/sasori/notes.md (container)
• Bind mount: ./layer2:/app/layer2:rw in docker-compose.yml — edits are live, no rebuild
• Tab id: sasori
• Page: /admin/sasori
• Renderer: existing src/lib/markdown.ts (marked + DOMPurify, sanitized)
• Permit holder (today): Azure Peak (0x137df237acc6d90559fff498d3313aeef4dc5b5c, genesis admin)
• Bernays-side skill: ~/.claude/skills/sasori/SKILL.md — instructs future sessions how to read/write this surface

Open log

Bernays writes here as the conversation evolves. Treat each block as append-only unless explicitly revising.

2026-05-06 — Entity created

First instantiation. Substrate file, admin nav entry, tab registry row, DB grant, Astro page, and Bernays-side skill prepared. Deploy is held — admin/admin_tabs.py and src/ changes need a docker compose up -d --build + ./scripts/build-site.sh cycle to land in production. Layer2 markdown content (this file) is already live-readable from inside the container the moment the page route exists.

Tier 1 hypothesis under test: the smallest viable contributor service is a markdown surface plus a permit grant. If reading and editing this through the admin feels right, Tier 2 (embedded terminal) is the next entity to instantiate. If it feels wrong — too thin, too disconnected, too read-only — that's the signal to redesign before scaling the pattern.

2026-05-06 — Admin nav reset to Akatsuki-only

Shay called for a clean slate. Non-Akatsuki tabs (Specs, Supporters, Crypto pending, Users, Permits, Stripe, Treasury, Newsletter, Submissions, Tracker, Monologue, Staged) were removed from the admin frontend nav. Their .astro pages and admin_tabs.py registry entries were retained as code reference — the rebuild will happen under the new substrate model, not by editing the legacy in place.

Surviving nav: Konan, Deidara, Sasori. Three tabs, all Akatsuki-named, deliberately spare. The point is that the admin shell now reflects the future doctrine — Stoka admin is a launcher for Tsukuyomi-mediated services — not the legacy doctrine where each tab was a hand-built feature page.

2026-05-06 — Role / Tab / Service: three separate entities

New foundational principle.

• Role — what kind of contributor a user is. A property of the user. Future first-class concept; schema TBD. Examples might be genesis, trusted-dev, marketing, researcher, viewer. A user has 0..N roles.
• Tab — a UI surface in the Stoka admin shell. A property of the frontend. Examples: Konan, Deidara, Sasori. A tab is rendered or hidden based on the viewing user's roles, but the tab itself does not encode a role.
• Service — a Tsukuyomi-mediated capability that the substrate materializes for permitted users. A tab MAY be the front-end of a service, but services can also exist without a tab (e.g., a tmux session, an MCP endpoint, a sandbox profile).

Why the separation matters: the legacy admin.tab_grants table directly couples wallets to tabs. That collapses three entities into one and makes role-based reasoning impossible. "Kyle is a trusted-dev" should be a single fact, not a fan-out of 12 tab grants. "Genesis sees everything" should be a single rule, not a backfill of every tab id into one wallet's row.

The new model (to be designed): users.roles[] + services registry + services.required_roles[] + tabs computed from services filtered by user roles. tab_grants becomes legacy / migration source.

This was crystallized as a wiki decision on 2026-05-06.

2026-05-06 — Wiki crystallization

The conversation reframe (Tsukuyomi as Stoka's capability plane), the four-tier trajectory, the seven open architectural choices, the Sasori prototype, the Akatsuki-only nav doctrine, and the role/tab/service separation were all written into the permanent llm-wiki layer at /home/edward/wiki/wiki/:

• New entity: entities/Tsukuyomi-Substrate.md — the new big-picture doctrine
• New entity: entities/Sasori-Service.md — Sasori specifically
• Updated: entities/Software-Tsukuyomi.md — old framing marked superseded
• Updated: entities/StokaSoftware.md — admin section now reflects Akatsuki-only nav + role separation
• New decision: decisions/admin-nav-akatsuki-only.md
• New decision: decisions/role-vs-tab-separation.md

Future Bernays-class sessions read the wiki to re-enter this thread. The wiki is now the authoritative version; this Sasori file is the running journal.

2026-05-06 — Deidara wrapped, Konan-shell parity for all 3 nav tabs

Deidara was external (deidara.phillyshell.cloud); now wrapped in /admin/deidara as an iframe inside the Konan-shell. CSP frame-ancestors 'self' https://stokasoftware.com swapped in for X-Frame-Options: SAMEORIGIN on phillyshell Caddy. Auth handoff via URL hash (fragment-only, never in HTTP referer).

Sasori was light-by-default; now always-dark to match Konan (#0a0a0a body, .admin-layout > .admin-shell, rgba(255,255,255,*) palette, rgba(16,185,129,*) accent, AdminKonanBubble bottom-right, AdminNav top).

All three Akatsuki nav tabs now visually coherent. Deidara's deeper Tier-2 substrate alignment (real role gating, embedded terminal pattern) deferred until BZ campaign delivers roles.

2026-05-06 — Sasori panel evolves into a question/answer surface

Sasori grew from "shared markdown surface" into "shared markdown + agent-blocked-question surface" today. Added:

• Left sidebar matching the Konan-tab AdminSidebar conventions — sections (Notes / Pending / Archive), .side-list + .side-item cards with dot+label+count, sticky 260px rail.
• Each layer2/sasori/questions/*.md is a switchable file-pane in the main shell. Click any sidebar item to load that pane; URL hash routing (#q-0001) works for direct links.
• Inline answer form rendered for any question with a status: pending frontmatter and an answers: schema. Radio cards use a subtle green-outline glow on selection (no native radio dots — visually-hidden inputs preserve form semantics).
• Lock & Submit button at the end of each form. POSTs to /api/admin/sasori/questions/{id}/answer (genesis-only). Endpoint flips frontmatter to status: answered, appends ## Answer captured to the body, writes a JSONL entry to layer2/sasori/answers-queue/pending.jsonl.
• Auto-detection wired: ~/.claude/skills/sasori/check-pending.sh reads the JSONL vs. a cursor and surfaces new locks. Wired as a Claude Code UserPromptSubmit hook so every prompt auto-checks. Backup of pre-hook settings at ~/.claude/settings.json.bak.sasori-hook.
• Q0001 (Sheeran integration scoping) banked + answered; Q0002 (D-06 + Deidara confirm) banked + pending.

The pattern itself is a substrate primitive: long-form agent questions go to a durable, browseable surface; Shay locks them via UI; agents pick up the answers automatically. No more Telegram dumps.

2026-05-06 — Sheeran integration: native port into Deidara tab (LOCKED)

Q0001 outcome: Q1 picked A_then_C (incremental iframe → C), but Q2 notes superseded with "i think i want to handle the porting of sheeran into a native stokasoftware deidara tab right now." Confirmed in chat. Decision is locked: native port, not iframe. The previously-sketched S.1–S.5 iframe track in BZ PLAN.md is superseded; a fresh per-surface scoping pass for Sheeran's surfaces (Compositions 2, Voice Studio, Brand, etc.) is deferred to a future question card.

The /admin/deidara iframe → deidara.phillyshell.cloud becomes a temporary way-station that progressively gets replaced by native Stoka surfaces. Sheeran the standalone app keeps running for partner workflows (Kyle/Rahul) — no forced migration.

2026-05-06 — Pre-compact handoff

Shay flagged compact incoming. Anticipated next thread: Sasori panel modifications to make the surface faster to use AND to facilitate Deidara-panel reconstruction through agent-driven workflow. The exact modifications are TBD post-compact. State is locked in:

• BZ campaign STATE.md / DECISIONS.md / RUNLOG.md / PLAN.md all current
• Q0001 + Q0002 in layer2/sasori/questions/, both visible in /admin/sasori sidebar
• Auto-trigger hook live
• Skill descriptions current

A clean post-compact resume is one /black-zetsu skill invocation away.

2026-05-06 — Black Zetsu Campaign initiated

Shay declared the role/wallet substrate work (formerly listed as one of the "open work" items in Tsukuyomi-Substrate) foundational — determinant of scope for basically every other Tsukuyomi/Stoka goal. Spun up a long-running campaign to ship it.

Wiki state: wiki/campaigns/black-zetsu/{README,PLAN,STATE,DECISIONS,RUNLOG}.md + wiki/entities/Black-Zetsu-Tab.md. Operational primitive: /black-zetsu skill (registered, harness-discoverable).

Phases: 0 (decision lock) → A (schema + read API + UI) → B (grant/revoke) → C (realtime) → D (MCP) → E (tab gating migration) → F (cascading hooks + self-service inbox) → G (cross-machine JWT, deferred).

Currently in Phase 0 — 7 architectural decisions to lock before any code. Next session: invoke /black-zetsu to walk through DECISIONS.md row-by-row.

The legacy admin.tab_grants (the Sasori bridge) will stay operational until BZ Phase E migrates the tab-gating logic to derive from roles. Sasori's role mapping is provisional in its entity page; firm it up after Phase 0 settles role granularity (D-01).

2026-05-06 — Sasori → White Zetsu rename + first concrete deliverable

Sasori-the-tab is now White Zetsu-the-tab. Same physical surface, reframed conceptually:

• Old framing: agent Q&A surface (Shay ↔ Bernays-class agents)
• New framing: multi-modal facilitation panel — human↔human, human↔AI, human↔AI↔human, configurable, per-role with proper read/write scoping. Every role gets its own WZ panel.

Lore-clean: White Zetsu = plurality / multi-instance worker (fits "every role gets one"); Black Zetsu remains the singular meta-administrative will (the BZ tab).

New nomenclature: the markdown documents inside layer2/white-zetsu/ are now called "zetsu files" going forward. notes.md is a zetsu file. Each questions/<NNNN>-<slug>.md is a zetsu file. Soon: each meetings/<name>.md will be a zetsu file.

First tunnel-vision deliverable (Shay's framing): Discord meeting bot.

• Input surface: Discord bot in the company voice call
• Output surface: White Zetsu page — one dedicated zetsu file per meeting under meetings/
• Function: live AI note-taker / record-keeper for meetings, on-demand
• Why this is the right first deliverable: forces the abstract WZ infrastructure to be real (per-role scoping, file-pane sidebar, live updates), proves the substrate, ships visible value

Q0003 banked with 7 scoping decisions + 1 catch-all. Awaiting UI lock.

Per-user-tmux + multi-role-WZ-scope decisions deferred past this deliverable (they were the original Q0003 plan; reprioritized after Shay's "tunnel-vision toward Discord meeting bot" steer).

2026-05-06 — Discord meeting-bot v1 scaffolded

Q0003 verbally accepted (recommended defaults across all 7 questions). v1 build complete:

• Service: services/discord-meeting-bot/ — py-cord client, slash commands (/wz-record-start, /wz-record-stop, /wz-record-status, genesis-only authz), faster-whisper local + OpenAI Whisper API fallback, custom LivePCMSink for in-memory per-speaker buffering, live-partial transcription every 15s, finalize-pass at stop, atomic zetsu file writes
• Compose: discord-meeting-bot service added under the wz profile so existing rebuilds don't try to pull a GPU image. Mounts layer2/white-zetsu/meetings/ directly so writes show up in the WZ UI without a sync layer. NVIDIA runtime declared
• WZ admin page: new Meetings sidebar section (recording = pulsing red dot, finalized = static blue), one file pane per meeting with frontmatter-driven kicker (Meeting · channel · status)
• Storage: layer2/white-zetsu/meetings/<YYYY-MM-DD-HHMM-channel-slug>.md
• Setup doc: services/discord-meeting-bot/README.md walks Shay through Discord developer-app creation, bot invitation, token + user/guild ID extraction, .env population

Shay-blocked next step: create Discord app, drop token + IDs into .env, then docker compose --profile wz up -d --build discord-meeting-bot. README has the click-by-click steps.

Sample meeting at meetings/2026-05-06-2230-sample-test.md to validate the WZ sidebar rendering — delete once a real meeting appears.

2026-05-06 — Path C live: wz-whisper-service deployed to corner0

Discord meeting bot now uses corner0's idle GTX 1070 Ti for transcription instead of edward (whose 3090s are claimed by Qwen3-VL). Cloud Whisper API stays as a fallback, not a primary.

corner0 service (/root/wz-whisper-service/):

• FastAPI on 100.99.51.87:9099 (tailnet-only)
• faster-whisper large-v3-turbo, compute_type=int8 (Pascal can't do efficient float16 — int8 works clean, ~2.3s model load)
• Bearer-token auth (token saved at /tmp/wz-whisper-token.txt for this session — must be dropped into edward's bot .env)
• Smoke test: 11s JFK clip → 1.2s transcribe (~9x realtime) on the 1070 Ti, perfect transcription
• 980 MB VRAM peak, 7+ GB headroom remaining

edward (bot service):

• transcribe.py adds _transcribe_remote() (httpx multipart POST)
• New default strategy remote_first_cloud_fallback: corner0 first, OpenAI Whisper API on remote failure
• Bot Dockerfile dropped from CUDA base to python:3.11-slim — no GPU needed for the bot itself anymore
• Compose: GPU reservation removed; bot stays under wz profile

Verified: bot's Transcriber class talking to corner0 returns identical results to direct curl. End-to-end Path C operational.

Shay-blocked: Discord bot token + ID setup, drop WHISPER_REMOTE_TOKEN=50386fda4cad2bf4dcbe8f2884e5420c8cfceff24a35bb9cd13cc45b4a653aad into bot .env, docker compose --profile wz up -d --build discord-meeting-bot.

2026-05-07 — First public handoff zetsu published

New zetsu file type: handoffs/. Files with public: true in frontmatter render at https://stokasoftware.com/wz/<slug> — no admin auth, no admin nav, clean reader layout. Files without public: true 404 on the public route (still visible in admin). Admin sidebar gained a Handoffs section + per-file pane with a copy-link affordance.

First publication: 2026-05-07-akatsuki-roles.md — substrate role-naming explainer for Kyle (Pain analogy + Madara/Itachi/Deidara org chart).

• Public URL: https://stokasoftware.com/wz/akatsuki-roles
• Admin pane: /admin/white-zetsu sidebar → Handoffs

2026-05-07T21:20Z — Preprod "unable to connect" drift post-mortem

Edward saw "unable to connect to server" when opening the Debono Preprod card from apps.phillyshell.cloud (with dev-toggle on, URL = https://debono-preprod.phillyshell.cloud/). Pinpointed root cause:

Drift. frontend/src/api/client.js::getApiUrl() hostname ladder had explicit cases for debono-dev / dev2 / dev3 / dev4.phillyshell.cloud — each returns https://${host} so the FE goes same-origin and the VPS Caddy /api/* reverse_proxy forwards to the upstream BE. When the debono-preprod stack was spun up earlier today via /spinup-app, the Caddy block + DNS + portal entry all got wired correctly — but debono-preprod.phillyshell.cloud was never added to client.js. Loading over HTTPS via the tunnel fell through the ladder to the REACT_APP_API_URL default (http://100.111.71.48:7003), which hit:

1. Mixed content — HTTPS page → HTTP API → browser blocks
2. From phone, http://100.111.71.48:7003 is reachable over tailnet but blocked anyway by the mixed-content rule

Fix. 5-line addition to client.js mirroring the dev2/dev3/dev4 cases. Commit 1b38703c. Verified via curl --resolve against 100.95.159.55 (VPS tailnet IP): FE meta sha === BE sha, /api/version + /api/auth/login both route correctly through Caddy.

Lesson — for the spinup-app skill. When spinning up a new debono-* stack via /spinup-app, the Caddy/DNS/portal phases are codified but the frontend api/client.js host-ladder addition is NOT yet in the recipe. Should be: any new tailnet-gated stack that uses the Caddy /api/* proxy pattern needs a matching host === '<new-host>' clause returning https://${host}. Otherwise the FE will load but every call fails. Will surface this gap next time /spinup-app runs a tailnet app variant.

Pinned for future me: if Edward says "unable to connect" on a *.phillyshell.cloud subdomain, FIRST check client.js for the host clause before assuming Caddy / DNS / cert / cookie.

2026-05-07T21:30Z — Build-context drift POST-MORTEM (real root cause)

Earlier post-mortem at T21:20 was incomplete. Actual root cause found:

The client.js host-clause fix I committed at 1b38703c never landed in the served bundle. Reason: /home/edward/public_apps/Debono/docker-compose.preprod.yml had frontend.build.context: ./frontend and backend.build.context: ./backend — relative paths that resolved to /Debono/frontend and /Debono/backend (main worktree, on branch preprod/admin-workspace-cleanup). My fixes were in the campaign worktree at /home/edward/public_apps/.parity-preprod-wt, on branch campaign/public-mini-games-substrate.

When I ran docker compose -f docker-compose.preprod.yml build frontend from /Debono, compose built from /Debono — silently dropping every campaign commit. The --build-arg BUILD_SHA=1b38703c was just stamped into the HTML; the actual JS came from main's old code. Bundle hash: app.135aef21.js (stale). Tunnel served stale bundle. Edward saw "unable to connect" because the stale bundle's getApiUrl() had no debono-preprod clause.

Fix codified. Commit 79aec656 on /Debono/docker-compose.preprod.yml: both backend.build.context and frontend.build.context now point at ../.parity-preprod-wt/{backend,frontend}. Future preprod builds pull from the campaign worktree by default, regardless of which dir compose runs from.

Verified: bundle re-hashed to app.31872f2b.js, contains both debono-preprod (host-clause fix) and hint-sidebar-rail (sidebar glow redesign). Tunnel reachability: 200 on /, 200 on /api/version returning matching SHA, login flow works.

Two sub-rules now in standing memory:

1. feedback_preprod_build_context_invariant.md — preprod compose builds from .parity-preprod-wt, ALWAYS. Probe bundle for expected fix-string post-build; build-sha tag is not proof.
2. feedback_rebuild_be_with_fe_always.md — even FE-only diffs rebuild both services at the same SHA (loop-prevention invariant).

Cross-compact reliability for preprod is now load-bearing on both rules + the codified compose context. Future agents inherit them automatically via MEMORY.md.

2026-05-07T22:05Z — Two reports for Edward (banked to WZ)

1. DLC concept-card carousels — diagnosis (data NOT lost)

Data is fine. Codex confirmed identical populated dlc_concept_packs in BOTH prod (postgres) and preprod (debono_preprod):

• MPJE: 1436 cards / 6 areas
• NAPLEX: 719 cards / 15 areas
• PTCB: 72 cards / 4 areas

Your prewarm content is intact in both DBs. Not the slug-shape recurrence either — wiki/probes/dlc-prewarm-coverage.sh PASS.

Bug is in the request path. GET /api/dlc/{dlc}/carousel is read-only by design (locked by test_get_dlc_carousel_is_read_only_when_uninitialized). Returns whatever's in user_dlc_treadmill.active_card_ids. Frontend ConceptCardCarousel.jsx only calls GET, never POST /api/dlc/{dlc}/treadmill/init. Any entitled user without a pre-existing treadmill row sees [].

Prod-affected counts (entitled users missing the unscoped treadmill row): MPJE 3/6, NAPLEX 4/5, PTCB 1/2. So real users on first-visit hit this. Same on preprod.

Fix is ~10 FE lines: add initializeDlcTreadmill() to frontend/src/api/dlcCarousel.js, call it from ConceptCardCarousel after an empty GET, refetch. Preserves BE contract + test. Full diagnostic at /tmp/codex-dlc-carousel-result.md.

Need your greenlight to ship this fix to preprod (then your eyeball, then prod).

2. Modal-viewport refactor — synthesized opinion

Path B + a single <GameViewportModal> primitive is the right move. Codex + me agree, and exa-search confirms Radix UI's Dialog anatomy is the same shape (modern best-of-breed converged here 2024-25).

Shape:

• One primitive driven by props for everything that varies
• accent="vaccine|infection|molecule|boss|diamond|cram|equipment" + accentRgb escape hatch (Equipment's keystone-derived RGB doesn't fit enum)
• portalSelector configurable, fallbackToBody opt-in, bodyFallbackBehavior ("immediate-then-retarget" preserves BossMap's dead-click-free behavior)
• closeLocked + onRequestClose(reason) — caller computes mid-round lock, primitive doesn't know game internals
• closeButtonHidden / renderHeader={false} — BossMap intentionally has no X; Cram has its own header
• useMapViewportPortalTarget hook factors out the RAF retry + MutationObserver target-removal watching

Path A vs B:

• Path A (z-lift, S-effort): elevate map-internal rails to z>100 with pointer-events: none during modal sessions. Cheap. Lies to assistive tech (chrome appears interactive but is inert). Band-aid.
• Path B (DOM layer split, M-effort): restructure .deck-map-area into <map-chrome-layer> + <map-modal-root> siblings. ~8 files touched. Honest. Future-proof. Recommendation.

Why this primitive shape: eliminates the 5 current shapes (Cluster 1 portal w/RAF, Cluster 1 portal sync, body-portal full-viewport, inline replacement, divergent intake) without special-cases. Configurable knobs cover every existing edge case.

Validation: Radix UI Dialog uses Root/Portal/Overlay/Content/Title/Description/Close as separate slots — accent + behavior via composition not config explosion, portal target overridable, asChild for theming. We're effectively building the Debono-flavored Radix Dialog. Full landmark with 45-component inventory + 11 ship gates lives at wiki/wiki/topics/Map-Viewport-Game-Modal-Canon.md.

Decision needed from you: (a) ship the DLC carousel init fix to preprod next, (b) start the modal refactor on preprod, or (c) both in parallel.

sample-test · 2026-05-06

status: finalized
started: 2026-05-06T22:30:00Z
ended: 2026-05-06T22:32:00Z
duration: 120s
transcript backend: local

This is a placeholder meeting zetsu file dropped during build verification — confirms the WZ sidebar's Meetings section renders, and that meeting file-panes wire up properly.

The discord-meeting-bot service writes real files in this same directory. Once you set up the Discord developer app and drop the bot token in services/discord-meeting-bot/.env, /wz-record-start will produce files like 2026-05-07-0930-company-vc.md automatically.

You can delete this file once a real meeting transcript shows up in the sidebar.

Participants

• Shay (sample) · 137123456789012345

Final transcript

Shay (sample) · 2026-05-06T22:30:05Z

This is a placeholder transcript line.

Shay (sample) · 2026-05-06T22:30:42Z

The bot will write per-speaker chronologically-sorted segments here when a real meeting is finalized.

Why this card exists

Q0001 (Sheeran integration scoping) closed on the integration question — native port into the Deidara tab, not iframe-incremental. But two questions didn't get answered there:

• Q3 of Q0001 (D-06 token scope): not picked
• Q4 of Q0001 (Deidara role v1): blank

Per the question-card protocol, instead of assuming defaults, re-bank them as a fresh card. Tighter scope, faster to lock.

Q1 — D-06 token scope (the last BZ Phase 0 decision)

Recap: bz_xxx tokens are how agents (Bernays-class, Akatsuki, future) authenticate to perform role-management actions via the BZ MCP server. Tokens need scope so a marketing-coordinator agent can't suddenly grant genesis. The question is what shape that scope takes.

Recommended shape (per-role-opaque + allowed_target_roles[] + read_only)

A token row looks like:

admin.bz_tokens:
  token_hash         text PK
  label              text   -- e.g., "marketing-coordinator-2026-05"
  authenticates_as   text   -- e.g., 'pain' (the role this token acts as)
  allowed_target_roles text[]  -- e.g., ['marketing'] — which roles this token can grant/revoke
  read_only          bool   -- if true, list/read only; no mutations
  created_by         text
  created_at         timestamptz
  expires_at         timestamptz nullable
  revoked_at         timestamptz nullable

Auth flow on every MCP call:

1. Look up token_hash → get token row
2. Check revoked_at is null and expires_at (if set) is future
3. If verb is read-only: ✓ proceed
4. If verb is mutating: token must not be read_only, and the target_role must be in allowed_target_roles[]

Why this shape:

• Pain's broad authority + Deidara's narrow authority both express cleanly in the same schema (Pain token has many allowed_target_roles; Deidara has zero — Deidara doesn't need bz_xxx at all)
• Revocation is a single column flip
• Audit: every mutation logs granted_by='bz_token:<label>'
• One row per scope-shape, not per agent — multiple agents can share a marketing-coordinator-2026-05 token

Alternatives

• Per-capability (finer): can_list, can_grant, can_revoke, can_create_role as separate bools. Useful if you ever want a "can list but not change" oversight role. With three coarse roles today, probably overkill.
• JWT with claims: self-describing tokens, no DB lookup. Faster auth path, but JWT revocation requires a denylist (defeating the simplicity). And you've already committed to Supabase JWTs for Realtime (D-05 Path B) — adding a second JWT shape for bz tokens muddies things.
• Hold-decide-later: punt D-06 entirely. Phase A-C only need genesis-only mutations (settled in D-03). Phase D is the first phase that actually needs bz_xxx tokens to exist. So we could settle D-06 when Phase D starts. Risk: Phase D arrives and we're back here making the same call.

Q2 — Deidara role v1 confirm

Current sketch (banked in Q0001's body, re-stated here for self-containment):

This is exactly the Pattern 1 trusted-dev shape from wiki/topics/Partner-Scope-Patterns.md, generalized for any wallet that should hold marketing-content-app authority.

Pick "accept" if this matches your intent for Deidara-the-role. Pick "modify" if you want to add/cut something — describe in the notes.

Q3 — Any final flags before Phase 0 closes?

Once Q1 and Q2 lock, all 7 BZ campaign decisions are settled and Phase A (schema + read API + read-only BZ tab UI + tab_grants backfill) can start. This is your last chance to flag a missed angle, late-arriving constraint, or "wait, what about X?" thought.

Blank = clear to advance.

Debono vaccine-game design hit a decision point: how many vaccines to show the player when the patient profile appears.

The agent outlined three approaches and is leaning curated for v1 with full-panel behind a Challenge toggle later — but wants your call before proceeding.

Vaccine option panel — full panel or curated per case?

When the patient profile appears, what does the player choose from?

• Full panel (~25 ACIP vaccines) — every vaccine on the schedule visible, player taps any combination. Mirrors what a real pharmacist sees. Most pedagogically honest (no help with narrowing down). But long scrollable list on mobile = ugly + slow + intimidating.
• Curated panel (~8-12 vaccines per case) — case authoring includes a "candidate vaccine set" mixing correct answers + plausible distractors (red-herring vaccines). Cleanest UX, mobile-perfect, but slightly easier — the player knows the right answer is somewhere in those 10.
• Hybrid / progressive disclosure — show curated 8-12 by default, with a small "see all 25" expand button for the truly uncertain. Mobile-clean primary path, full-panel option for advanced players.

The tension: pedagogical fidelity (full) vs mobile UX + decision-speed (curated). Brand-asset framing leans curated. Your stated "make them better at this clinical reasoning skill" leans full.

I lean curated for v1 with the option to ship full-panel mode behind the Challenge mode toggle later — but tell me if your gut says full from the start, or if progressive disclosure feels like the right balance.

Which?

Context: this follows a locked decision on hybrid case generation grounded in CDC ACIP with visible citation in-game (versioned JSON → LLM generation → human approval → source footer in UI).

Debono vaccine game design — scoring locked (+15/-5/-10), mode axis mapped (Triage vs Reasoning). Agent blocked on whether to add a patient-population scope picker.

The other open dimension I want your read on: should there be a scope/tier picker like Molecule's small/medium/large/huge?

A natural fit for vaccines would be the patient population axis:

• Pediatric (0-18) — childhood schedule, catch-up
• Adult (19-64) — routine adult, catch-up
• Special populations — pregnancy, immunocompromised, travel, healthcare workers, post-splenectomy
• Mixed — random across all

This would deepen replay (a player who's mastered pediatric can flip to special populations for harder material), and it gives a natural difficulty curve.

Or if you'd rather keep it simple for v1 — just one "Mixed" pool, no scope picker, ship it lean.

Which?

Debono preprod session surfaced two open decisions before the next prod ship.

1. Molecule game public shape: Producer asks whether to lift-and-publish the existing tier-picker game as-is (producer's lean — "90% there, only mobile pass needed") or build a new shape for public.

2. PC-resolution responsive audit scope: Shay reports visual bugs and scaling issues on Surface that make certain things unclickable, while 1440p is flawless. Producer needs:

1. Which surfaces specifically break on Surface — just orb games or broader (combat panels, dashboard map, modal overlays)?
2. Surface resolution + DPI scaling setting (probably 2256×1504 @ 200% on Surface Pro?)
3. Scope for bundled preprod ship — targeted bug fix (fast unblock) vs. full Playwright responsive audit across 6 canonical breakpoints (1280×720 through 2560×1440). Producer notes: "the second is the do-it-once-never-re-litigate approach; brand-asset framing argues for it since these games are about to go public."

These decisions gate what lands in the next preprod→prod promotion. The resolution audit is especially relevant given upcoming public mini-games launch.

Debono agent captured a campaign brief for public mini-games (infection + molecule + vaccine) and is blocked awaiting Shay's call on 4 cross-cutting decisions before any build starts.

Producer proposed 10-week phased plan: Molecule first (easiest — client-side only), Vaccine second (greenfield), Infection last (hardest — needs auth-refactor). Campaign file at /home/edward/wiki/campaigns/public-mini-games/CAMPAIGN.md.

CC-1: Hosting topology — where do public games live? Subdomain + routes, per-game subdomains, or dedicated minigames subdomain?

CC-2: Anonymous session model — no tracking / cookie session / localStorage + optional convert?

CC-3: Funnel intent — lead-gen (drive signups) or brand asset (no conversion pressure)?

CC-4: Mobile-first contract — portrait-only + 375px min, responsive both orientations, or landscape-gaming-first?

Shay said "this is significant and needs to be approached carefully" — the producer anchored that by refusing to build until these are answered.

Debono agent diagnosed a CSS gap in the sidebar tree-label layout and needs you to confirm before shipping a fix.

Context: Investigating why .tree-label text in the Hierarchy sidebar leaves a visible gap before .tree-count on wrapped lines. Diagnosis: word-break: break-word on .tree-label prefers word-boundary breaks, leaving trailing whitespace on partial lines that stretches to the count element.

Proposed fix: Swap word-break: break-word → overflow-wrap: anywhere in HierarchyTree.css line ~388.

Blocker: Agent can't reproduce visually — the bernays-preprod account has an empty TOC even after inserting 5 decks (hierarchy builder needs subtopics + learning_objectives populated).

Pick one:

1. Confirm the diagnosis ("yeah that's it") → agent ships the 1-line CSS change to preprod, you eyeball.
2. Send a screenshot from your populated preprod account so agent can verify against actual rendered behavior before changing anything.

Debono parity agent confessed a process violation: it deployed 4bcbd5aa (nginx defense-in-depth, codex non-blocking) all the way to prod as 7bf1d446, when its autonomy was supposed to be preprod-only. The user caught it. Agent is blocked awaiting decision.

Two options:

1. Roll back prod to f98848d7 — promote debono-{frontend,backend}-prod:rollback-pre-nginx-20260507T044911Z back to :latest, recreate, CF purge, retag canonical. ~2 min.
2. Keep 7bf1d446 in prod — call it a one-off accept; from here forward, autonomous train = preprod-only and you bulk-approve to prod.

Agent says it'll roll back unless told otherwise. Preprod build at a90c7335 is mid-flight codex check and will land in preprod only (corrected understanding). Skill doc needs updating to prevent recurrence.

Why this card exists

Shay's tunnel-vision deliverable: Discord meeting bot → live transcript → one zetsu file per meeting, output rendered on /admin/white-zetsu as a switchable file-pane. This is the first real-world feature that exercises the WZ infrastructure (input surface = Discord, output surface = WZ panel, durable artifact = zetsu file in layer2/white-zetsu/meetings/).

Before building, 7 scoping decisions need to settle. The 8th is the catch-all.

Q1 — Server / voice-channel scope

Default recommendation: company_only_all_voice (the bot joins any voice channel in the company server when triggered). Simple, no per-channel allowlist to maintain, fits "on-demand AI note taker" framing.

If you want to lock it down to one "meetings" channel, that's a 1-line config — easy to flip later.

Q2 — Trigger model

Default recommendation: slash_command_genesis_only for v1. Lowest blast radius. Anyone-can-trigger comes after we know the bot doesn't accidentally record a casual call. Auto-on-call-join is great UX but creates surveillance-ish vibes if not designed carefully.

hybrid is the eventual end-state but builds out of v1 by adding modes incrementally.

Q3 — STT stack

Default recommendation: local_first_cloud_fallback. We have 2x RTX 3090 on edward and faster-whisper benchmarks at ~5x realtime on a 3090 for large-v3. That means a 1-hour meeting transcribes in ~12 min — but if we run it concurrent with audio, we get live transcription with no per-minute cost.

The fallback is critical: when Debono is doing a NAPLEX run or StokaTerminal is hot, GPUs are busy. Cloud fallback (Deepgram or OpenAI Whisper API) means the bot doesn't fail when GPUs are saturated.

If you'd rather skip GPU-management complexity for v1, openai_whisper_api ships fastest (one API call, ~$0.006/min — a 2hr meeting is $0.72).

Q4 — Live vs post

Default recommendation: live_partial_finalize_after. Stream rough chunks into the zetsu file every ~10 seconds (visible immediately on /admin/white-zetsu); when the meeting ends, run a final pass that fixes punctuation, cleans hallucinations, and writes a polished version replacing the live chunks. This is what services like Otter.ai do.

bulk_post_meeting is simpler if live-during-meeting isn't important; live_stream is what you'd want if you're using the bot during a recorded meeting and want to type-along reactions in WZ chat in real time.

Q5 — Naming

Default recommendation: auto_then_rename. Bot auto-names with meetings/YYYY-MM-DD-HHMM-<auto-slug>.md (auto-slug from voice channel name). Rename affordance from the WZ UI lets you retroactively title meetings ("kyle-sheeran-review") once content makes the topic obvious.

Q6 — Diarization

Default recommendation: discord_user_id_map. Discord gives us per-speaker audio streams natively (each user is a separate WebRTC track) — so we don't even need ML diarization for v1. We get speaker labels for free, mapped by Discord user ID. One-time config: {user_id: "Shay"} etc.

If you go cloud-stack on Q3, Deepgram's native diarization is also strong but adds redundant complexity when Discord already gives us per-speaker streams.

Q7 — Hosting + secrets

Default recommendation: edward_docker. Add a discord-meeting-bot service to the existing stokasoftware docker-compose; mount layer2/white-zetsu/meetings/ directly so writes show up in the WZ UI without any sync layer. Token via .env (already-pattern). Health-monitored alongside other Tsukuyomi services.

edward_tmux_env is the lowest-overhead path for a v1 prototype if you don't want to docker-fy it yet.

Q8 — Anything else?

Things I'd flag if not already considered:

• Retention policy: do meeting transcripts get archived, deleted after N days, or kept forever? (My default: kept forever in layer2/white-zetsu/meetings/, since they're inside repo and survive container rebuilds.)
• Who can read meeting zetsu files: under the role/scope substrate, this is a per-role read permission. v1 = genesis-only. v2 = whoever has WZ read access on the meetings sub-pane.
• Recording-consent UX: Discord's TOS requires informed consent. Should the bot post a message in the channel ("🎙 recording started — say /record-stop to halt") on join?
• Transcript editing: post-meeting, can Shay edit a zetsu file from the WZ UI to fix names/typos? (v1: edit on host filesystem; v2: in-UI edit affordance.)

Blank Q8 = clear to start architecture spec after Q1-Q7 lock.

Answer captured

Answered 2026-05-06T22:25:00Z by shay-genesis (verbal: "it looks good") — recommended defaults accepted across the board.

Build kicked off

Spec is being implemented in services/discord-meeting-bot/. Phase 1: scaffold + WZ sidebar Meetings section + compose wiring. Bot runtime requires Shay to (a) create a Discord developer application, (b) drop the token into the StokaSoftware .env — README will guide that step.

Perplexity API key — found

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 — surfaced from a Tobi session log dated 2026-04-16. It's not stored in any active env file or config on disk — only in conversation history. So it's an orphan key from an earlier session. May or may not still be valid (Perplexity keys can be revoked); test before trusting. Native WebSearch is available and was sufficient for this scoping pass — Perplexity isn't load-bearing here.

Inventory — what actually exists

Sheeran (the app)

• Path: /mnt/nvme/ai/projects/Sheeran/ (NVMe, symlinked from /home/edward/apps/Sheeran)
• 7 running containers: backend (8082, FastAPI), frontend (1078, React SPA), dashboard (1079, primary surface), remotion (3124), kdenlive (6080, noVNC), worker, redis (6389)
• Public surface: sheeran.phillyshell.cloud (tailnet-only, Caddy @notTailnet 403)
• Dashboard's primary surface: Compositions 2 review tab — meta.status='review' queue, branch-not-edit iteration model
• Built-in agent terminal: sheeran-agent tmux at #terminal route + reachable from old /admin/deidara/sheeran path (extracted)
• Has its own MCP: sheeran_mcp/ with tools dir — separate token namespace from BZ tokens
• Auth model: tailnet-gated only. No JWT, no SIWE; just "you're on tailnet ↔ you're authorized." Kyle/Rahul granted via Tailscale ACL group:partner + edward FS ACLs.
• Codebase: backend (Python/FastAPI), dashboard (React 19+Vite), frontend (React SPA), worker, MCP, video/stoka-v1 (Remotion compositions)

Deidara (the app — separate from the iframe-tab built earlier today)

• Path: /home/edward/public_apps/StokaSoftware/deidara/ (subfolder inside Stoka, but own nested .git — Stoka's .gitignore excludes it)
• Repo: https://github.com/stokastik-rx/Deidara (private)
• Cloned from Sheeran 2026-04-21, rebranded marketing-app, OIDC-shim'd against Stoka, LLM via host-side deidara-llm-watcher.sh + claude --print (no API keys)
• 7 containers: backend:8086, dashboard:1080, frontend:1081, remotion:3125, kdenlive:6081, worker, redis:6390
• Public surface: deidara.phillyshell.cloud (tailnet-only)
• What was shipped 2026-05-06: /admin/deidara iframe → deidara.phillyshell.cloud with SIWE-token URL-hash auth handoff

Stale wiki claims corrected during inventory

• Sheeran.md wiki entity referenced "Plan A (shipped 2026-04-20)" at stokasoftware.com/admin/deidara/sheeran. GONE — extracted in commit e46a72b4 ("Remove embedded Deidara code"). Route currently 404s.
• It also referenced "Plan B" spec at .planning/deidara-sheeran-port/. DOES NOT EXIST at that path. Closest artifact is .planning/deidara/HANDOFF-SPEC-SESSION.md (2026-04-21) which describes Deidara's extraction, not Sheeran integration.

So we're working on a clean slate for Sheeran-into-Stoka integration. No prior plan to reuse.

The architectural question

"Integrate Sheeran into Stoka admin" decomposes into four real options:

Option A — iframe wrapper (Deidara-pattern-applied-to-Sheeran)

Mirror exactly what was built for Deidara today. /admin/sheeran Astro page → iframe → https://sheeran.phillyshell.cloud/. SIWE-token URL-hash auth handoff. Sheeran's Caddy adds frame-ancestors 'self' https://stokasoftware.com. Konan-shell wrapper.

• ⏱ ~1 work session
• ✓ User opens Stoka admin, clicks Sheeran tab, sees full Sheeran dashboard inline
• ✓ Auth flows through SIWE
• ✗ Sheeran's tabs (Compositions 2, Voice, Brand, etc.) are inside the iframe — Stoka's nav doesn't see them
• ✗ Cross-app coordination (Stoka events ↔ Sheeran events) is via existing sheeran_mcp tokens, not unified
• ✗ Doesn't enable Stoka-side agents to manipulate Sheeran via the BZ-style MCP/role substrate

Option B — Native Astro port (full rewrite)

Bring Sheeran's UI into Stoka's Astro pages directly. Each Sheeran tab becomes a sub-route under /admin/sheeran/*. Sheeran's React state, auth, API client — all replumbed.

• ⏱ 5–10+ work sessions (the stale Plan B estimate was 5–7 weeks)
• ✓ Native UX, no iframe quirks, Stoka nav sees everything
• ✓ Massive deduplication of auth/state/API
• ✗ Abandons working Sheeran codebase; abandons partner workflows Kyle/Rahul depend on
• ✗ Re-implementing kdenlive/Remotion embeds is non-trivial
• ✗ Risk of breaking Kyle/Rahul during migration

Option C — Hybrid: iframe + agentic substrate seam

Same /admin/sheeran iframe wrapper as Option A, but also:

• Stoka admin gets a "context bar" alongside the iframe (recent role activity, BZ feed, MCP token status)

• Sheeran's MCP server (sheeran_mcp) gets a token namespace (shr_xxx style) that BZ-managed roles can mint

• Stoka-side agents (with the right role-derived shr_xxx token) read/write Sheeran state via MCP without going through the iframe

• Live state sync via Supabase Realtime (D-05, once Phase C lands) — Sheeran writes change-events into Stoka's realtime fabric

• ⏱ 2–3 work sessions over Option A + Phase D BZ groundwork

• ✓ Operational UX matches Option A

• ✓ Agentic seam is real — Bernays-class agents coordinate Sheeran activity from Stoka

• ✓ Future-compatible with Option B (each native port replaces a piece of the iframe)

• ✗ Requires Sheeran to expose a richer MCP surface (work on the Sheeran side)

• ✗ Cross-DB or event-bridge work to sync state to Stoka's realtime

Option D — Defer; just add it as an external link

Treat sheeran.phillyshell.cloud as an external service Stoka admin links to but doesn't embed.

• ⏱ 15 minutes
• ✓ Trivial
• ✗ Defeats the point of "integrate Sheeran into Stoka admin"

Recommendation: Option A in one session, then Option C incrementally

Pragmatic phasing:

S.1 unblocks Shay TODAY. S.2–S.4 layer the agentic substrate on top WITHOUT replatforming Sheeran's UI. S.5 is optional and gradual — Stoka swallows the parts of Sheeran that benefit from native UX, but never forces a big-bang migration. Kyle/Rahul never notice anything broke.

Implications for D-06 (token scoping)

Sheeran clarifies the bz_xxx scope question dramatically:

• bz_xxx tokens are exclusively for role-management (BZ campaign scope). Granting/revoking, MCP role-management verbs, role-definition reads.
• Each integrated service has its own token namespace: trk_xxx (tracker), future shr_xxx (sheeran), future dei_xxx (deidara), etc. Service-internal, not BZ.
• D-06's scope is just bz_xxx. Other tokens are out of scope for the BZ campaign.
• Pain holds bz_xxx authority (broad). Deidara holds shr_xxx and dei_xxx (operational, scoped to one or two services).
• Per-role-opaque tokens are sufficient for bz_xxx because the only finer scoping needed is "this token can grant marketing only, not konan" — that's per-target-role scoping within the bz_xxx namespace, which extends per-role-opaque cleanly with an allowed_target_roles[] column.

D-06 simplifies: per-role-opaque bz_xxx tokens with allowed_target_roles[] and read_only flag. Other token namespaces aren't D-06's problem.

Implications for Deidara role v1 definition

Deidara role's permission set finalizes as:

• Tabs: /admin/deidara (iframe to Deidara app), /admin/sheeran (iframe to Sheeran app — once S.1 lands)
• Services manipulable: Sheeran APP (full functionality), Deidara APP (full functionality), Sheeran codebase (/mnt/nvme/ai/projects/Sheeran), Deidara codebase (/home/edward/public_apps/StokaSoftware/deidara/). Both via existing FS ACLs (Pattern 1 trusted-dev shape).
• MCP tokens issued automatically (Phase F hook): shr_xxx (sheeran) + dei_xxx (deidara) + tracker if needed
• Roles can grant/revoke: NONE (operational, not orchestrational)
• Cannot: touch BZ tab, modify role definitions/hooks, push to prod/master, edit Debono/StokaSoftware-core/SoftwareTsukuyomi, sudo on edward

Deidara role v1 is exactly the Pattern-1 trusted-dev shape from wiki/topics/Partner-Scope-Patterns.md, generalized for any wallet that should hold marketing-content-app authority.

Four questions

Q1 — Recommended path. Commit to Option A → C incremental? Or push toward Option B native port immediately?

Q2 — Sheeran tab naming. "Sheeran" (break Akatsuki convention pragmatically) vs Akatsuki-name (Itachi? Kakuzu? Kisame?) vs absorbed into the Deidara tab as a sub-section?

Q3 — Bz_xxx token scope. Settle D-06 at per-role-opaque + allowed_target_roles[] + read_only flag?

Q4 — Deidara role v1 definition. As written above? Anything to add/cut?

Once these land, the BZ campaign resumes — Deidara role banked, D-06 settled, S.1 queued as a sister phase track.

Answer captured

Answered 2026-05-06T21:47:03.142889Z by shay-genesis

Q1 — Recommended path for Sheeran integration

• Choice: Option A → C incremental (recommended): iframe wrap now, agentic seam later

Q2 — Sheeran tab naming

• Notes: uggh actually now that i am thinking about it, i think i want to handle the porting of sheeran into a native stokasoftware deidara tab right now, i think this is important because stokasoftware as a base layer will inherently facilitate the sheeran workflow much better.

Q3 — Settle BZ campaign D-06 (token scope)?

Q4 — Deidara role v1 definition — anything to add/cut?

• (no input)

Mini-games — VaccineOrb-first canon (pivot proposal)

Edward's idea (paraphrased from voice/text): build the web-app native VaccineOrb FIRST so I have a fully-agreed visual template, then derive the mobile mini-game shell from it. He wants to spend compute efficiently — pick the smallest artifact that locks canon, get sign-off, then scale that canon out.

I strongly agree. Recording the pivot here as a question because the answer affects the next ~hour of build cycles.

Why this pivot is correct

1. The orb is the smallest artifact that locks visual canon. 56px component. Radial gradient + spinning ring + pulsing glow + hover/active states. Once locked, accent + glow ratios + dot pulse derive trivially to the mobile shell.
2. Cheap compute per iteration. Single small component on a preview page. Build cycle <2 min. Eyeball cycle is seconds. Iter 2 of the mobile shell built without canon = guessing → likely rejection → wasted compute.
3. Investment, not throwaway. The web app dashboard map will need a VaccineOrb when the actual game ships in Phase 3. Building now is forward-amortized work, not detour.
4. Visual relation matters. Putting the proposed vaccine variants next to the existing InfectionOrb (red, #ef4444) and MoleculeOrb (emerald, #34d399) is the only way to know if a candidate accent reads as "preventive/clinical-cool" vs "the third game's color."

Current state (pre-pivot)

• Iter 1.1 of /preview/public-shell is live at preprod (commit 180636d1).
• It uses a guess at the vaccine accent: cyan #22d3ee. That guess is the open question — un-canonized.
• Infection theme = red #ef4444 (locked, mirrors InfectionOrb.css from the web app).
• Molecule theme = emerald #34d399 (locked, mirrors MoleculeIntakeModal.css from the web app).

Without a confirmed vaccine accent, every iter on the mobile shell is on shifting ground.

Proposed scope (pivot)

Variant candidates (proposal)

Per the design canon (semantic color, distinct from infection-red and molecule-emerald), I'd put forward 4 candidates:

Open: should I add violet #a78bfa as a 5th? It's currently used in our chip system for "etiology" — could conflict, but it's a strong distinct option.

Side-by-side question

I'd render Vaccine variants + Infection + Molecule on the same preview page so the relation is direct. Confirming because if you'd prefer just-vaccine-variants alone (cleaner page), tell me.

What this unblocks

• CP 0.2 (mobile-shell visual checkpoint) gets a confirmed visual canon to anchor on.
• CP 0.3 (subdomain plumbing + Turnstile first-hit UX) can proceed with confirmed accent for vaccines.debono.ai.
• Phase 3 (Vaccine greenfield game) gets a head-start because the orb already exists in the web app dashboard component library.

Two confirmation questions (radio cards above)

1. Variant candidates — confirm or steer (4 default colors, +violet, swap, or single-proposal-cyan).
2. Side-by-side comparison — show Vaccine variants alongside the existing Infection and Molecule orbs on the same page, or vaccine-only?

Once you Lock & Submit, I build the orb + variants page, recreate preprod frontend, surface the URL, and you eyeball + pick.