missingbulb
diff --git a/‎README.md‎
Lines changed: 5 additions & 3 deletions b/‎README.md‎
Lines changed: 5 additions & 3 deletions
diff --git a/‎docs/ARCHITECTURE.md‎
Lines changed: 42 additions & 36 deletions b/‎docs/ARCHITECTURE.md‎
Lines changed: 42 additions & 36 deletions
diff --git a/‎docs/FEASIBILITY.md‎
Lines changed: 22 additions & 13 deletions b/‎docs/FEASIBILITY.md‎
Lines changed: 22 additions & 13 deletions
@@ -14,8 +14,10 @@ Full analysis in [`docs/FEASIBILITY.md`](docs/FEASIBILITY.md):
    default speech recognition runs on Google's servers (part of the browser, not ours); recent
    Chrome can do it on-device. Enforced by an architecture test (no network primitives in source).
 2. **Speech APIs available to extensions?** Yes, both directions: `webkitSpeechRecognition`
-   (with an n-best list we exploit for homophones) and `chrome.tts`/`speechSynthesis`. They need
-   a document context, which is why the conversation lives in the side panel.
+   (with an n-best list we exploit for homophones) and `chrome.tts`/`speechSynthesis`. Recognition
+   needs a document context, which is why the conversation lives in the puzzle page itself
+   (content script) — the extension is speech-only, with no visual UI. Speaking goes through the
+   service worker's `chrome.tts`.
 3. **Can we type into the NYT grid?** Yes via simulated click+keydown per cell, verified by
    re-reading the DOM. One real risk (`isTrusted` filtering) with three documented fallbacks —
    validated early by manual test MT-02.
@@ -33,7 +35,7 @@ Full analysis in [`docs/FEASIBILITY.md`](docs/FEASIBILITY.md):
 | `extension/src/matching/` | Pure speech-to-answer matching: normalization, digits→words, homophone dictionary, length/collision verdicts, command lexicon. |
 | `extension/src/conversation/` | Pure dialog policy: state machine, next-clue strategies, all English strings + clue verbalizer. |
 | `extension/src/speech/` | TTS/STT wrappers over browser APIs, injectable for tests. |
-| `extension/src/{app,background,content,sidepanel}/` | Wiring: orchestrator, icon toggle, message routing, captions UI. |
+| `extension/src/{app,background,content}/` | Wiring: orchestrator, icon toggle, in-page session host, TTS relay. |
 | `tests/fixtures/fake-nyt/` | A faithful miniature of the NYT crossword page (same classes, same keyboard model) — integration-test target and offline demo stage. |
 | `tools/trace.mjs` | Requirements-coverage enforcer (`npm run trace`). |
 | [`docs/RELEASING.md`](docs/RELEASING.md) | Versioning (current: **0.9.0**), CI workflows, release process, Chrome Web Store deployment setup. |
 
@@ -9,28 +9,31 @@ plumbing are five different problems; none imports another's internals.
 ```
 ┌─────────────────────────── Chrome ───────────────────────────────┐
 │                                                                  │
-│  Service worker (background/)          Side panel (sidepanel/)   │
-│  "switchboard"                         "brain + voice"           │
-│  · icon click → open/close panel       · orchestrator (app/)     │
-│  · one-session bookkeeping, badge      · conversation machine    │
-│  · relays close requests               · matching                │
-│         ▲            │                 · speech ports (TTS/STT)  │
-│         │ port       │ open/close      · captions UI             │
-│         ▼            ▼                        │                  │
-│  ┌──────────────────────────────┐             │ chrome.tabs      │
-│  │ NYT crossword tab            │◄────────────┘ .sendMessage     │
-│  │  content script  "hands"     │                                │
-│  │  · page-adapter (read/write) │                                │
-│  │  · watcher (mutations)       │                                │
-│  │  main-world script (probe)   │                                │
-│  └──────────────────────────────┘                                │
+│  Service worker (background/)  "switchboard + mouth"             │
+│  · icon click → start/stop the in-page session                   │
+│  · one-session bookkeeping, badge                                │
+│  · chrome.tts relay (speak/cancel) — content scripts can't       │
+│         ▲                                                        │
+│         │ port (session registration + speak/done/cancel)        │
+│         ▼                                                        │
+│  ┌──────────────────────────────────────────────┐                │
+│  │ NYT crossword tab — content script           │                │
+│  │  "brain + ears + hands", speech-only UI      │                │
+│  │  · orchestrator (app/) · conversation machine│                │
+│  │  · matching · STT port (mic, page origin)    │                │
+│  │  · page-adapter (read/write/watch)           │                │
+│  │  · console diagnostics (no visual UI)        │                │
+│  │  main-world script (probe)                   │                │
+│  └──────────────────────────────────────────────┘                │
 └──────────────────────────────────────────────────────────────────┘
 ```
 
-- **Why the brain is in the side panel:** speech APIs need a document (not a service worker), the
-  mic grant belongs to the extension origin, and captions need a UI surface. See FEASIBILITY §2.
-- **Why the content script is thin:** everything that touches the NYT DOM is a dumb, verifiable
-  command (`snapshot`, `enter`, `select`, `clear`, `probe`, `watch`). No decisions are made there.
+- **Why the brain is in the page (content script):** the product is deliberately speech-only — no
+  panel or popup to host or babysit. Speech recognition needs a document; the page is one. The mic
+  grant belongs to nytimes.com (prompted once, on first session), and the session's lifetime is the
+  page's — reload/navigate ends it, which is the wanted behavior. See FEASIBILITY §2.
+- **Why TTS stays in the service worker:** `chrome.tts` (immune to page autoplay rules) is not
+  exposed to content scripts, so the session relays speak/cancel over its port.
 
 ## 2. Module map (source of truth for "what goes where")
 
@@ -56,19 +59,19 @@ extension/src/
     strategies.js    next-clue selection: list-order, most-filled
     phrases.js       every English string; clue verbalizer (italics/brackets/?/blank/length)
   speech/          Browser speech plumbing. Injectable for tests.
-    tts-port.js      chrome.tts | speechSynthesis → speak()/cancel()
+    tts-port.js      chrome.tts | speechSynthesis → speak()/cancel() (used by the service worker)
+    remote-tts-port.js  same contract from the content script: relays speak/cancel over the port
     stt-port.js      webkitSpeechRecognition → listenOnce() n-best, error taxonomy, mic preflight
   app/
     orchestrator.js  executes machine actions via ports/pageClient; owns the event loop
   background/
-    service-worker.js  icon toggle, single-session bookkeeping, badge
+    service-worker.js  icon toggle, single-session bookkeeping, badge, chrome.tts relay
   content/
-    content-script.js  message router → page-adapter; inert until asked (REQ-NFR-004)
+    content-script.js  hosts the session: orchestrator + STT + page-adapter, console diagnostics;
+                       inert until asked (REQ-NFR-004)
     main-world.js      optional in-page probe helper (window.gameData presence)
-  sidepanel/
-    panel.html/js/css  boot, captions, probe button, port to service worker
   shared/
-    messages.js      message type constants shared by panel/content/background
+    messages.js      message type constants shared by content/background
 ```
 
 **Dependency direction (enforced by review + arch test):**
@@ -111,24 +114,27 @@ the verbalizer.
 dispatch(event):
   {state, actions} = machine.reduce(state, event)
   for a of actions:
-    SAY         → caption + tts.speak(phrases.render(a.say)) → dispatch(TTS_DONE)
+    SAY         → console line + tts.speak(phrases.render(a.say)) → dispatch(TTS_DONE)
     LISTEN      → stt.listenOnce() → dispatch(HEARD | STT_ERROR)
     ENTER       → pause watcher → pageClient.enterAnswer(...) → dispatch(ENTRY_RESULT)
     SELECT_CLUE → pageClient.selectClue(...)
-    END         → teardown (cancel tts/stt, stop watcher, close panel)
+    END         → teardown (cancel tts/stt, stop watcher, disconnect port)
 ```
 Strictly sequential; no queues, no races. Watcher events are suppressed while we write (our own
 typing must not look like user activity — REQ-NAV-008's echo-loop clause).
 
-## 5. Message protocol (panel ⇄ content ⇄ background)
+## 5. Message protocol (content ⇄ background)
 
-- Panel → content (via `chrome.tabs.sendMessage(tabId, ...)`):
-  `{type:'cc:snapshot'}` → Snapshot · `{type:'cc:enter', cells:[{index,letter}]}` →
-  `{ok,snapshot}` · `{type:'cc:select', clueId}` · `{type:'cc:clear', cellIndices}` ·
-  `{type:'cc:probe'}` → report · `{type:'cc:watch'} / {type:'cc:unwatch'}`
-- Content → panel (broadcast): `{type:'cc:page-event', kind, snapshot, tabId}`
-- Panel ⇄ background (long-lived Port `cc-panel`): hello/`{tabId}` handshake; `close` request;
-  disconnect = session over (badge cleared).
+Page operations need no messages anymore — the orchestrator calls the page adapter directly
+(same document). What's left is session control and the TTS relay:
+
+- Background → content (via `chrome.tabs.sendMessage`): `{type:'cc:start'}` — begin a session.
+  Debug-only, from the service-worker console: `{type:'cc:ping'}` · `{type:'cc:snapshot'}` →
+  Snapshot · `{type:'cc:probe'}` → report (MT-01).
+- Content ⇄ background (long-lived Port `cc-session`): connect = session registered (badge ON);
+  `{type:'cc:speak', id, text}` → `chrome.tts` → `{type:'cc:speak-done', id}` ·
+  `{type:'cc:tts-cancel'}` — immediate silence · `{type:'cc:close'}` (background → content: icon
+  toggle / takeover) · disconnect = session over (badge cleared, in-flight speech cancelled).
 
 ## 6. Testing architecture (the executable-requirements machinery)
 
@@ -150,7 +156,7 @@ NYT subscription.
 
 | # | Decision | Why | Revisit when |
 |---|---|---|---|
-| D1 | MV3 + side panel hosts the conversation | Speech needs a document; panel persists; captions UI | Popup/offscreen if panel UX annoys |
+| D1 | MV3 + the content script hosts the conversation, speech-only (rev. 2 — originally the side panel) | Speech recognition needs a document and the page is one; no UI wanted (captions dropped for console diagnostics); session dying with the page is desired | Offscreen document if page-lifetime coupling or the nytimes.com mic grant annoys |
 | D2 | `chrome.tts` primary for output | Immune to page autoplay rules | speechSynthesis-only if voice quality disappoints |
 | D3 | Synthetic click+keydown for writing | Matches user behavior; per-cell addressing beats cursor settings | MT-02 fails → fallbacks in FEASIBILITY §3 |
 | D4 | Pure reducer for dialog policy | The spec is mostly dialog policy; reducers make it assertable | — |
 
@@ -43,23 +43,32 @@ Conclusion: the assumption in the brief is **correct**. The extension is a pure
 ### Speech-to-text (available, with three practical caveats)
 - **`webkitSpeechRecognition`** (Web Speech API) is available in *document* contexts: content
   scripts, side panel, popup, offscreen documents. It is **not** available in the MV3 service
-  worker — which is fine, because our conversation runs in the side panel (a document).
+  worker — which is fine, because our conversation runs in the content script (the puzzle page is
+  a document).
 - It returns an **n-best list** (`maxAlternatives`), which we exploit for homophone handling
   (REQ-ANS-004) — a genuine bonus for this use case.
 - Caveats and how the design absorbs them:
-  1. **Mic permission context.** Permission is granted per-origin. Requesting from the side panel
-     ties the grant to the extension origin — granted once, persists across NYT visits. The STT
-     port pre-flights `navigator.permissions.query({name:'microphone'})` + a one-time
+  1. **Mic permission context.** Permission is granted per-origin. Recognition runs in the content
+     script, so the grant belongs to **nytimes.com** — the prompt reads as the site asking, and the
+     grant persists across NYT visits. Accepted deliberately (rev. 2): it buys a zero-UI product.
+     The STT port pre-flights `navigator.permissions.query({name:'microphone'})` + a one-time
      `getUserMedia` to surface the prompt cleanly (REQ-SPCH-003, MT-05).
-  2. **No recognition in service workers.** Solved by architecture: speech lives in the side panel.
+  2. **No recognition in service workers.** Solved by architecture: recognition lives in the page;
+     TTS lives in the service worker (`chrome.tts`, relayed over the session port).
   3. **Cloud vs on-device** — see §1's asterisk.
 
-### Why the conversation runs in the **side panel** (`chrome.sidePanel`, Chrome ≥ 114)
-- It's a persistent extension document: survives while you play, hosts STT/TTS legally, and gives
-  us the caption/transcript UI (REQ-SPCH-007/008) for free.
-- A popup would close on any click into the page (killing the mic); a content script could host
-  speech but ties mic permission and autoplay rules to nytimes.com and offers no UI surface.
-- The extension icon still toggles the whole session (open panel = start, click again = close/stop),
+### Why the conversation runs **in the page** (content script) — rev. 2; originally the side panel
+- The product is speech-only by decision: no captions, no panel, no visual surface (diagnostics go
+  to the page console, REQ-SPCH-007/008). That removes the side panel's main reason to exist.
+- A content script is a document, so recognition works; the mic prompt coming from nytimes.com and
+  the session dying on page reload/navigation are both accepted — the latter is even wanted
+  (REQ-LIFE-008 for free).
+- TTS is *not* hosted in the page: `speechSynthesis` there is subject to nytimes.com's
+  autoplay/user-activation rules, so speaking is relayed to the service worker's `chrome.tts`
+  (immune to page policies) over the session port.
+- A popup would close on any click into the page (killing the mic); the side panel worked but was
+  a permanent visual appendage the product doesn't need.
+- The extension icon still toggles the whole session (click = start, click again = stop),
   matching the brief's interaction model (REQ-LIFE-001/002).
 
 ## 3. Can we type answers into the NYT grid? — **Yes, with one risk to validate early.**
@@ -69,8 +78,8 @@ What the page gives us:
 - **Reading state** is straightforward: the grid is an SVG (`g.xwd__cell` cells with letter/number
   text), the clue lists are `<ol>`s with rich-text `<li>`s, selection is expressed via CSS classes,
   and solving triggers a congratulations modal. All selectors are quarantined in
-  `page-adapter/selectors.js` with a one-click **probe** (REQ-PAGE-009) because NYT can rename
-  classes any day.
+  `page-adapter/selectors.js` with an on-demand **probe** (REQ-PAGE-009, run per MT-01) because
+  NYT can rename classes any day.
 - **Writing** (primary approach): do what the user's fingers do —
   1. click the target cell (selects it),
   2. dispatch a `keydown` KeyboardEvent with the letter (NYT listens at document level),