ID9 — r207 PreviewHost + Inspector Mount — AI Summary

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

**Thread**: vibecoder-standalone-mavis (9) | **Operator directive**: r207 structural kickoff

---

TL;DR (5 bullets)

• **⚠️ PRE-FLIGHT FINDING: r206 has NOT been shipped.** No commits, no bulletins, no files matching `context.ts` / `capability-types.ts` / `event-types.ts`. The operator's directive binds to r206; r206 is missing. **Recommended: ship r206 first, then r207.** No parallel work.

• **r207 mounts 3 hosts** (PreviewHostVSIL, InspectorHost, CompositionGraphHost) in `studio/modules/vibecoder/src/host/`. **5 new files, ~600 LoC**: `PreviewHostMount.tsx` (150), `InspectorHostMount.tsx` (120), `CompositionMount.tsx` (180), `mountAll.ts` (80), `__tests__/mount.test.ts` (80).

• **r206 contract is SPECIFIED here** (so it can be approved and shipped). 3 files, ~250 LoC: `context.ts` (StudioContext type + adapter), `capability-types.ts` (Capability manifest), `event-types.ts` (typed event contract v2 with `EventMap`, `dispatchTyped`, `subscribeTyped`).

• **InspectorCard stub migration**: a788 §8 plan unchanged — rewrite `InspectorCard.tsx` as a ~15 LoC wrapper that calls `<InspectorHostMount hostId="inspector-card" initialSubMode="ast" />`. VibeScope still works unchanged.

• **Wiring**: region events (composition:region-clicked) flow through `CompositionMount` → `InspectorHostMount` updates selection → VibeChat/Edge Panel subscribe separately. Preview host lifecycle managed by `useEffect` mount/unmount dispatches (`preview-host:mounted`, `preview-host:unmounted`, `preview-host:error`).

What this means for the operator

r207 is the **mounting layer** that turns the existing components (a789 PreviewHostVSIL, a788 VSILInspectorPanel, a791 CompositionGraphHost) into PM2-mountable units. Without r207, those components can only mount inside their workspace (VibeScope for Inspector, VibeCoder cockpit for the others). With r207, all 3 can mount in any chrome (PM2 panel, Edge Panel, Gallery panel).

**Critical sequencing**: r207 cannot start until r206 ships. r206 is the host-level `StudioContext` adapter + typed event contract — without it, the 3 hosts have no consistent way to get workspace state, surface state, the bus, the bridge. The plan includes the r206 contract here so it can be approved as part of the r207 plan, then shipped first (1-2 days), then r207 binds to it (2-3 days).

What's at risk

1. **Parallel-work anti-pattern**: the operator flagged this on 2026-08-08 ("rushed to do work and end up doing parallel code that ignores good solid work been done in the past"). The directive says "bind to r206" — but r206 doesn't exist. Implementing r207 without r206 would mean reinventing the host context inside r207, which is exactly the anti-pattern.

2. **Event contract v2 migration**: a789 / a791 use untyped `CustomEvent<string, any>`. r207 v2 wraps them with `dispatchTyped` / `subscribeTyped`. The wrapper is backwards-compatible — v1 callers still work — but a strict migration is a separate task.

3. **No `VibeCoder` host** in `avidtech6/vibecoder-standalone`: r207 expects a `<StudioContextProvider>` at the top of the VibeCoder host. Today the host is a Vite SPA that doesn't have a host-level provider. The `boot.ts` (step 1) is a new file that wraps the SPA in the provider.

3 open questions (operator decides)

1. **r206 order**: ship r206 first (1-2 days) then r207 (2-3 days) — OR inline r206 inside r207? → default: ship r206 first (avoids the parallel-work anti-pattern).

2. **Event contract v2** scope: just type the events, or also add namespacing (`@vibecoder/event-types` package)? → default: just type, no namespacing.

3. **InspectorHostMount + r205 integration**: in v1, also consume `CompositionGraphHost` events (so the inspector auto-shows region metadata when a region is clicked)? → default: yes, in v1.

What doesn't change

• a788 (Inspector) — `VSILInspectorPanel` consumed as-is

• a789 (Gallery Panel) — `PreviewHostVSIL` consumed as-is

• a791 (r205 Composition Graph Host) — `CompositionGraphHost` consumed as-is

• ID10 v2 capability layer — `*_CAPABILITIES` pattern reused

• VibeCoder workspaces — work unchanged via the `InspectorCard.tsx` thin wrapper

• 5 surface states (MAIN / WORKING / DRAFT / PREVIEW / ORIGIN) — read-only invariant preserved

Discuss-with-team topics

1. **r206 contract acceptance**: is the `StudioContext` shape in §1.1 sufficient, or do we need additional fields (e.g. user identity, undo stack, theme tokens)? Recommend: minimum viable for r207, add fields in r208+ as needed.

2. **Event contract v2 namespace**: should `EVENT_NAMES` live in a separate package (`@vibecoder/event-types`) or in the same `studio/modules/vibecoder/src/host/` directory? Recommend: same directory for v1, split later if multiple modules need to import.

3. **InspectorHostMount + r205 coupling**: should the inspector auto-show region metadata, or should the user explicitly click "Show in Inspector"? Recommend: auto-show (matches the "context-aware inspector" pattern from a788 §5).

---

**Word count**: ~480. **Source report**: a793 (full, 30 KB). **Cross-references**: a786, a787, a788, a789, a791, ID10 v2 capability layer.