ID9 — Unified Gallery Panel Plan — AI Summary

**Date**: 2026-08-30 | **Source**: a789 (full report, 27 KB)

**Thread**: vibecoder-standalone-mavis (9) | **Operator directive**: r204 continuation, updated

---

TL;DR (5 bullets)

• **One PM2 panel, 8 preview slots, 4 categories**: VSIL (cinematic canvas), Origin (live site DOM), App (VibeCoder shell viewport), Surface (5 sub-states: MAIN / WORKING / DRAFT / PREVIEW / ORIGIN). Preview Strip top bar with 8 chips; Preview Body swaps between 4 host types.

• **No iframe, no postMessage**. Native React component mounted in PM2. Origin uses `fetch` + DOM-inject with server-side sanitization (ALLOWED_ORIGINS allowlist, script stripping). App uses error-boundary'd re-mount.

• **6 new files, ~750 LoC**: `GalleryPreviewBridge` (state + localStorage + event bus, 150 LoC), `PreviewHostVSIL` (wraps VisualCard, 80 LoC), `PreviewHostOrigin` (fetch + sanitize, 120 LoC), `PreviewHostApp` (error boundary + device frame, 100 LoC), `PreviewHostSurface` (5 state handlers, 200 LoC), `PreviewStrip` (chip row, 100 LoC). Plus `capabilities.ts` for Edge Panel introspection.

• **FreshCards primitives are reused as-is**: `<Card>`, `<InnerCard>`, `useInnerCardStack` (DC-VC-3), `<GalleryView>` / `<KanbanView>` / `<ListView>`, `<DatabaseViewSwitcher>`, `SurfaceRegistry`, `SurfaceLifecycleManager`, `<CardChipSystem>`. No fork needed.

• **5 surface states are operator-coined, NOT in FvW v8 yet**: MAIN / WORKING / DRAFT / PREVIEW / ORIGIN are content states (different from the 5 visibility states in workspace-surface-model-2026-07-14). Recommend new pact file `surface-state-enumeration-2026-08-30.md` (1h task, optional).

What this means for the operator

The Gallery is the **operator's single switchboard** between "what's on disk" (MAIN), "what I'm editing" (WORKING), "what I saved" (DRAFT), "what's about to ship" (PREVIEW), and "what's live in production" (ORIGIN). The current ID10 work (Preview Engine, 5 *rendering* modes) covers the operator-mode CSS behaviour (shadow / execution / template / device / breakpoint) but NOT the content-state lifecycle this plan adds. The two are orthogonal and can ship independently.

The plan is **3-4 days, 22-28h** of focused work, additive-only. No pact edits required for v1 (the new surface-state enumeration is recommended but optional). All FreshCards primitives are reused. The 5-line PM2 contract is the same pattern as ID9-Inspector (a788).

What's at risk

1. **Security**: `PreviewHostOrigin` fetches a remote URL and DOM-injects it. Even with server-side sanitization, this is a non-trivial attack surface. Bridge needs an `ALLOWED_ORIGINS` allowlist (or strict CSP) before v1 ships.

2. **Pact gap**: the 5 surface states have no constitutional home. The plan includes a recommended 1h pact add but treats it as optional. If the operator wants to ship the panel without the pact, drift-checks may flag it later.

3. **Edge Panel coupling**: the capability manifest binds the Gallery to the Edge Panel's contextual-tile system. If Edge changes, Gallery needs to re-emit capabilities. Mitigated by treating the manifest as a contract test (refresh on each Edge release).

Open questions (operator decides)

• **Q1 Vendor**: copy new files to `avidtech6/vibecoder-standalone/` (standalone) or to `avidtech6/freshvibestudio/studio/modules/gallery/` (shared with Studio)? Default: shared.

• **Q2 Mount**: auto-register at PM2 boot (always-on) or only when context fires (`studio:asset-bound`)? Default: both — register as always-available + auto-open on context.

• **Q3 Adapter scope**: ship the StudioContext adapter in v1 (drop-in inside Studio) or defer to v2? Default: defer to v2 (panel takes props in v1, adapter is 20 lines for v2).

What doesn't change

• VibeScope's `VisualCard.tsx` (reused as VSIL preview)

• FreshCards primitives (reused as-is)

• ID10 Preview Engine (orthogonal — 5 *rendering* modes, not 5 *content* states)

• ID10 Origin template (reused by `PreviewHostOrigin`)

• The 4 sovereign workspaces

• The PM2 panel manager (same 5-line `addPanel` contract)

Discuss-with-team topics

1. **The MAIN / WORKING / DRAFT / PREVIEW / ORIGIN state machine** — does the team agree with the state machine (§9)? In particular: should "DRAFT → WORKING" be allowed (user clicks Discard)? Should "ORIGIN → MAIN" be auto-fired on deploy, or operator-initiated?

2. **Origin security** — should `PreviewHostOrigin` require an explicit operator allowlist per URL, or rely on the bridge's `ALLOWED_ORIGINS` env var? The former is safer; the latter is faster.

3. **Preview Strip ordering** — the plan places the 3 category chips (VSIL / Origin / App) before the 5 surface state chips (MAIN / WORKING / DRAFT / PREVIEW / ORIGIN). Is the right grouping, or should it be alphabetical? Or by recency?

---

**Word count**: ~470. **Source report**: a789 (full, 27 KB). **Cross-references**: a786 (FreshCards), a787 (VPS), a788 (Inspector), ID10 Preview Engine.