docs(01): mark Open Questions RESOLVED in research per checker iteration 1

Renames "## Open Questions" header to "## Open Questions (RESOLVED)" and
adds inline RESOLVED markers to each of the three questions:
- Q1 (MediaRecorder timeslice cluster alignment) → D-12 ffprobe gate
  (Plan 03 Task 2 + Plan 07 Task 1) + D-13 fallback (pre-staged skeleton
  in src/offscreen/recorder.ts per Plan 03)
- Q2 (5-minute port lifetime cap) → Plan 04's 290 s pre-emptive reconnect
  plus synchronous onDisconnect → connectPort reconnect path
- Q3 (crxjs path-emit behavior) → Plan 06 Task 2 runtime verification +
  conditional src/background/index.ts edit

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-15 16:50:40 +02:00
parent 519a0d8a99
commit 576280f6aa

View File

@@ -1017,10 +1017,11 @@ stream.getTracks().forEach((track) => {
**If this table contains items:** The planner should treat them as **If this table contains items:** The planner should treat them as
candidates for user verification during `/gsd-plan-phase` review. 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 1. **Will `MediaRecorder.start(2000)` produce ffprobe-clean WebM on a
typical screen-cap?** 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 - What we know: Cluster boundaries align with keyframes; Chrome
keyframes appear every ~3-5 s by default (vp9 `kf_max_dist=100` on keyframes appear every ~3-5 s by default (vp9 `kf_max_dist=100` on
a 30 fps stream); timeslice does NOT force keyframes. 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. this in the success criteria.
2. **Does the 5-minute port lifetime kill the recording session?** 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 - What we know: Multiple corroborating community sources cite a ~5
minute hard cap on long-lived ports. minute hard cap on long-lived ports.
- What's unclear: Whether the cap applies to *port lifetime* (the - 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. reconnect is still harmless.
3. **What's the exact crxjs path-emit behavior for the offscreen entry?** 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 - What we know: The discussion #919 working answer uses
`input: { offscreen: 'src/offscreen/offscreen.html' }` and SW `input: { offscreen: 'src/offscreen/offscreen.html' }` and SW
fetches `chrome.runtime.getURL('src/offscreen/offscreen.html')`. fetches `chrome.runtime.getURL('src/offscreen/offscreen.html')`.