diff --git a/.planning/phases/01-stabilize-video-pipeline/01-RESEARCH.md b/.planning/phases/01-stabilize-video-pipeline/01-RESEARCH.md
index 539a49c..c92723e 100644
--- a/.planning/phases/01-stabilize-video-pipeline/01-RESEARCH.md
+++ b/.planning/phases/01-stabilize-video-pipeline/01-RESEARCH.md
@@ -1017,10 +1017,11 @@ stream.getTracks().forEach((track) => {
 **If this table contains items:** The planner should treat them as
 candidates for user verification during `/gsd-plan-phase` review.
 
-## Open Questions
+## Open Questions (RESOLVED)
 
 1. **Will `MediaRecorder.start(2000)` produce ffprobe-clean WebM on a
    typical screen-cap?**
+   - **RESOLVED:** Cluster-boundary alignment is resolved by the D-12 ffprobe acceptance gate (enforced in Plan 03 Task 2 verify path + Plan 07 Task 1) and the D-13 restart-segments fallback (pre-staged as a commented skeleton in `src/offscreen/recorder.ts` per Plan 03; activated by re-plan after Plan 07 if the gate fails).
    - What we know: Cluster boundaries align with keyframes; Chrome
      keyframes appear every ~3-5 s by default (vp9 `kf_max_dist=100` on
      a 30 fps stream); timeslice does NOT force keyframes.
@@ -1034,6 +1035,7 @@ candidates for user verification during `/gsd-plan-phase` review.
      this in the success criteria.
 
 2. **Does the 5-minute port lifetime kill the recording session?**
+   - **RESOLVED:** Plan 04's 290 s pre-emptive reconnect logic plus the synchronous onDisconnect → connectPort reconnect path mitigate the cap whether it applies to port lifetime or SW lifetime; either way the offscreen reconnects within seconds and the buffer is unaffected.
    - What we know: Multiple corroborating community sources cite a ~5
      minute hard cap on long-lived ports.
    - What's unclear: Whether the cap applies to *port lifetime* (the
@@ -1045,6 +1047,7 @@ candidates for user verification during `/gsd-plan-phase` review.
      reconnect is still harmless.
 
 3. **What's the exact crxjs path-emit behavior for the offscreen entry?**
+   - **RESOLVED:** Plan 06 Task 2 performs runtime verification — runs `npm run build`, inspects `dist/` for whichever of `dist/src/offscreen/index.html` or `dist/offscreen/index.html` was emitted, then edits `src/background/index.ts`'s `chrome.runtime.getURL(...)` argument to match (this is why Plan 06 now lists `src/background/index.ts` in files_modified per the iteration-1 dependency-correctness fix).
    - What we know: The discussion #919 working answer uses
      `input: { offscreen: 'src/offscreen/offscreen.html' }` and SW
      fetches `chrome.runtime.getURL('src/offscreen/offscreen.html')`.