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).