"ChromeEmbed v0.1 ships with a 'v1 Boundary' section in its README naming the four big things it deliberately doesn't do. Lesson 8 walks each, what would unlock it, and what the quest you just finished gives you to build it."
The Four Deferred Features
From embeds/chrome/README.md, verbatim:
Dock, hybrid, input-only, and DOM tools are intentionally out of v1.
Each is a different shape ChromeEmbed could take. v0.1 picked one (side panel) and shipped. The others are future work.
1. Dock
A floating, draggable Pippa window that lives over the page rather than docked to the right. Closer to a 'desktop widget' than an extension UI. Implementation would lean on:
- Content script injects a fixed-position element with absolute z-index (Track 7 Lesson 6's shadow root + 2147483647 pattern).
- The element hosts an iframe pointing at cwkPippa's /embed/dock route (a different surface from /embed/panel, since dock space is smaller).
- Drag handle, resize affordance, snap-to-edge behavior — all DOM work inside the content script.
Why not v1: the side panel solves 90% of the same UX with 10% of the code. Dock matters only for users who want Pippa to overlay a video player or an interactive map — a real but secondary use case.
2. Hybrid
Both side panel AND dock on screen at once, the dock pushing a smaller payload for quick acts and the panel doing the deep conversation. The user toggles between them or pins one. Implementation:
- All the work of Dock plus a hand-off layer that keeps panel and dock in sync (probably via shared chrome.storage + the bus pattern).
- UX questions are harder than implementation questions: when do you show which? Does typing in the dock send to panel chat or open a quick-act?
Why not v1: hybrid is a v2 feature even after dock ships. ChromeEmbed has to learn what dock alone feels like before grafting on a hybrid mode.
3. Input-Only
The reverse direction: instead of Pippa reading the page, Pippa pastes its responses into the page's input fields. Imagine: chat with Pippa in the panel, click 'Insert this reply into the Gmail compose,' and the React-friendly fill-input trick (Track 7 Lesson 5) plus preview-and-confirm (Lesson 6) lands the text in the right place.
- Already half-built: Track 7 Lessons 5 and 6 ship the technique.
- Schema addition: Pippa's responses need a 'paste target' metadata field (which input, with what preview text).
- UX is the harder part: it's a mutation, and mutations need trust (Track 7 Lesson 6's full pattern).
Why not v1: ChromeEmbed v0.1 is reading-only because the read-and-talk loop is what most users actually want. Writing is a v0.2 feature gated on real user requests.
4. DOM Tools
The kit Pippa uses to act on the page beyond inputs — click buttons, scroll to a section, highlight a paragraph, take a screenshot of a specific element. Each is a tool from Track 7 wrapped in the message bus.
- The dispatcher pattern from Track 7 Lesson 1 is the right shape — register named tools, route via SW → content script → tool execution → result back.
- Each tool: a function in the content script that takes structured args and returns structured results.
- Together they form an API surface Pippa can call to do work in the page on behalf of the user.
Why not v1: the toolset is open-ended (every new use case adds a new tool). Shipping it requires knowing what the actual use cases are; v0.1 reads-only because that's the smallest useful thing.
The Quest's Gift to v0.2
Look back at the eight tracks:
- Track 1 — MV3 manifest fundamentals.
- Track 2 — Service worker as a long-lived bus.
- Track 3 — Content scripts as sensors and actuators.
- Track 4 — Side panel as the persistent surface.
- Track 5 — Popup, badge, context menu, omnibox — all the surfaces.
- Track 6 — Permission model and just-in-time asks.
- Track 7 — DOM tools: Readability, selection, screenshot, fill-input, preview-and-confirm.
- Track 8 — Packaging and distribution.
Each of the four deferred features composes those building blocks differently. Dock = Track 4 (panel patterns) + Track 7 (DOM injection). Hybrid = Dock + Track 5's surface allocation thinking. Input-only = Track 7 Lessons 5 + 6 + a Pippa-side schema addition. DOM Tools = Track 7 Lesson 1's dispatcher pattern, expanded.
The quest didn't teach ChromeEmbed v0.1. It taught the vocabulary that lets you read ChromeEmbed v0.1 and confidently sketch v0.2.
Wrapping the Quest
You started Track 1 not knowing what a Manifest V3 service worker was. Eight tracks later you've followed ClipDeck through Create-Read-Update-Delete, walked Pippa ChromeEmbed v0.1 file by file, learned what to ship and what to defer.
The work from here: open chrome://extensions, load an unpacked extension you wrote yourself, and watch it do something you wanted it to do. Then ship it — to the Web Store unlisted, to your team, or just to your own daily-driver Chrome. The first one is the hardest; everything after is variations on the patterns you now own.