"ChromeEmbed v0.1 이 일부러 안 하는 네 큰 것 명명하는 'v1 Boundary' section 가지고 README 와 ship. Lesson 8 이 각자 walk, unlock 할 것, 방금 끝낸 quest 가 build 위해 주는 것."
네 deferred feature
embeds/chrome/README.md 에서, verbatim:
Dock, hybrid, input-only, and DOM tools are intentionally out of v1.
각자 ChromeEmbed 가 가질 수 있는 다른 shape. v0.1 이 하나 (side panel) 골라서 ship. 다른 거 가 future work.
1. Dock
Page 위에 오른쪽 docked 아닌 떠 있고 drag 가능한 Pippa window. 'desktop widget' 에 extension UI 보다 가까움. 구현이 의존:
- Content script 가 absolute z-index 가진 fixed-position element inject (Track 7 Lesson 6 의 shadow root + 2147483647 패턴).
- 그 element 가 cwkPippa 의 /embed/dock route (dock 공간이 더 작아서 /embed/panel 과 다른 surface) 가리키는 iframe host.
- Drag handle, resize affordance, snap-to-edge behavior — 다 content script 안 DOM work.
v1 안 이유: side panel 이 코드의 10% 로 같은 UX 의 90% 풀이. Dock 이 Pippa 가 video player 나 interactive map overlay 하길 원하는 user 한테만 중요 — real 하지만 secondary use case.
2. Hybrid
Side panel AND dock 가 화면에 한 번에, dock 이 quick act 위해 더 작은 payload push 하고 panel 이 deep conversation. User 가 둘 사이 toggle 하거나 하나 pin. 구현:
- Dock 의 모든 work plus panel 과 dock sync 유지하는 hand-off layer (아마 shared chrome.storage + bus 패턴 통해).
- UX 질문이 구현 질문보다 어려움: 언제 어느 거 보임? Dock 의 typing 이 panel chat 으로 보냄, 아니면 quick-act 열기?
v1 안 이유: dock ship 후에도 hybrid 가 v2 feature. ChromeEmbed 가 hybrid mode 에 graft 전 dock 혼자 어떤 느낌인지 배워야.
3. Input-Only
역방향: Pippa 가 page read 대신, Pippa 가 page 의 input field 에 응답 paste. 상상: panel 에서 Pippa 와 chat, 'Insert this reply into the Gmail compose' click, React-friendly fill-input trick (Track 7 Lesson 5) plus preview-and-confirm (Lesson 6) 가 텍스트 맞는 자리에 land.
- 이미 절반-built: Track 7 Lesson 5 와 6 이 기술 ship.
- Schema 추가: Pippa 의 응답이 'paste target' metadata field (어느 input, 어떤 preview text) 필요.
- UX 가 어려운 부분: mutation 이고, mutation 이 신뢰 필요 (Track 7 Lesson 6 의 full 패턴).
v1 안 이유: ChromeEmbed v0.1 이 reading-only — read-and-talk loop 가 대부분 user 가 실제로 원하는 것. Writing 이 real user 요청에 gate 된 v0.2 feature.
4. DOM Tool
Pippa 가 input 너머 page 에 act 위해 쓰는 kit — 버튼 click, section 으로 scroll, 문단 highlight, 특정 element 의 screenshot. 각자 message bus 에 wrap 된 Track 7 의 도구.
- Track 7 Lesson 1 의 dispatcher 패턴이 맞는 shape — 이름 도구 등록, SW → content script → 도구 실행 → 결과 back 으로 route.
- 각 도구: structured args 받고 structured 결과 반환하는 content script 의 함수.
- 함께 user 위해 page 에서 work 하기 위해 Pippa 가 부를 수 있는 API surface 형성.
v1 안 이유: toolset 이 open-ended (모든 새 use case 가 새 도구 추가). Ship 이 실제 use case 가 뭔지 아는 게 필요; v0.1 reads-only 가 가장 작은 useful 것이라서.
Quest 가 v0.2 에 주는 선물
여덟 track 돌아 봐:
- Track 1 — MV3 manifest fundamental.
- Track 2 — long-lived bus 로서 service worker.
- Track 3 — sensor 와 actuator 로서 content script.
- Track 4 — persistent surface 로서 side panel.
- Track 5 — popup / badge / context menu / omnibox — 모든 surface.
- Track 6 — permission 모델과 just-in-time 요청.
- Track 7 — DOM tool: Readability / selection / screenshot / fill-input / preview-and-confirm.
- Track 8 — packaging 과 distribution.
네 deferred feature 각자가 그 building block 을 다르게 compose. Dock = Track 4 (panel 패턴) + Track 7 (DOM injection). Hybrid = Dock + Track 5 의 surface allocation 사고. Input-only = Track 7 Lesson 5 + 6 + Pippa-side schema 추가. DOM Tool = Track 7 Lesson 1 의 dispatcher 패턴, 확장.
Quest 가 ChromeEmbed v0.1 가르친 게 아냐. ChromeEmbed v0.1 read 하고 v0.2 자신 있게 sketch 하게 해 주는 vocabulary 가르침.
Quest 마무리
Manifest V3 service worker 가 뭔지 모르고 Track 1 시작. 여덟 track 후 ClipDeck 을 Create-Read-Update-Delete 통해 따라가고, Pippa ChromeEmbed v0.1 을 file by file walk, 뭘 ship 하고 뭘 defer 할지 배움.
여기서 work: chrome://extensions 열고, 자신이 작성한 unpacked extension load, 원했던 거 하는 거 watch. 다음 ship — Web Store unlisted 로, team 으로, 또는 그냥 자기 daily-driver Chrome 으로. 첫 번째가 가장 어려움; 그 후 모든 것이 이제 소유하는 패턴의 변형.