# Phase 3: SPEC §10 smoke verification + DOM/event-log verification - Discussion Log

> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

**Date:** 2026-05-20
**Phase:** 03-spec-10-smoke-verification-dom-event-log-verification
**Areas discussed:** Phase 3 plan structure & breadth, SPEC §10 #8 password handling, rrweb v2 upgrade scope, RAM ceiling §10 #9 verification approach

---

## Gray area selection (multiSelect)

User picked all 4 gray areas presented — consistent with feedback-no-unilateral-scope-reduction memory pattern.

---

## Phase 3 plan structure & breadth

| Option | Description | Selected |
|--------|-------------|----------|
| Thin — 3 plans | rrweb DOM harness + event-log harness + §10 sweep VERIFICATION. rrweb v2 + RAM slip to Phase 4. | |
| Standard — 4 plans | Thin + 1 of (rrweb v2 upgrade OR RAM verification). | |
| Thick — 5 plans | Standard + both deferred items (rrweb v2 upgrade + RAM programmatic measurement). | ✓ |

**User's choice:** Thick — 5 plans (with clarification — see follow-up below)

**Follow-up clarification (composition mismatch with Q3/Q4):**

Q1 "Thick" literal reading would include rrweb v2 upgrade + RAM programmatic measurement as separate plans. But Q3 chose "Defer rrweb v2 to Phase 4" and Q4 chose "RAM = best-effort + operator note". Spirit interpretation: 5 atomic plans for structural granularity, with each plan tightly scoped per Q2/Q3/Q4.

| Sub-option | Description | Selected |
|--------|-------------|----------|
| Spirit interpretation | 5 atomic plans tightly scoped per Q2/Q3/Q4 (rrweb DOM harness + event-log harness + §10 #8 verify + §10 #9 best-effort + §10 sweep VERIFICATION). | ✓ |
| Literal Q1 reading | 5 plans incl. rrweb v2 upgrade + RAM programmatic — Q3/Q4 misclicks. | |
| Compromise mix | 5 plans with rrweb v2 RESEARCH ONLY (no upgrade) + RAM best-effort folded into §10 sweep. | |

**Notes:** Spirit interpretation locked. Final 5-plan composition documented in CONTEXT.md D-P3-01.

---

## SPEC §10 #8 password handling (charter tension surface)

| Option | Description | Selected |
|--------|-------------|----------|
| Verify existing minimum + mark partial | Harness assertion verifies existing target.type==='password' filter at src/content/index.ts:82; mark PARTIAL in VERIFICATION.md with charter citation. | ✓ |
| Explicit OUT OF SCOPE | No harness assertion; existing filter is incidental defense-in-depth. | |
| Full mitigation (rrweb maskInputFn) | Wire rrweb v2 maskInputFn + extend filter to data-sensitive guards; contradicts charter. | |

**User's choice:** Verify existing minimum + mark partial (Recommended)

**Notes:** Honor charter literally ("we don't care about privacy hardening" 2026-05-20) while preserving existing defense-in-depth. Plan 03-03 verifies the existing filter without expanding scope. VERIFICATION.md marks #8 as PARTIAL with charter citation.

---

## rrweb v2 upgrade scope

| Option | Description | Selected |
|--------|-------------|----------|
| Defer to Phase 4 | rrweb 2.0.0-alpha.4 stable across 9 plans; defer research + upgrade to Phase 4 hardening. | ✓ |
| Research only in Phase 3 (light) | gsd-phase-researcher spawn to verify alpha-pin safety + stable v2 ship status; no code change. | |
| Research + upgrade in Phase 3 (full) | Research + upgrade now; 1 extra plan; risks regression. | |

**User's choice:** Defer to Phase 4 (Recommended)

**Notes:** alpha-pin proven stable through Phase 1 + Phase 2 + 29/29 UAT GREEN. ROADMAP explicitly notes "Deferred to Phase 4 if Phase 3 plans are tight" — honored.

---

## RAM ceiling §10 #9 verification approach

| Option | Description | Selected |
|--------|-------------|----------|
| Best-effort + operator/alpha note | Mark §10 #9 N/A-in-harness in VERIFICATION.md with operator instructions for chrome://memory-internals or chrome://extensions service-worker memory display; alpha-tester observation. | ✓ |
| Programmatic via puppeteer.Page.metrics | Add A29 harness assertion: puppeteer.Page.metrics() returns JSHeapUsedSize/JSHeapTotalSize; assert < 50 MB. | |
| chrome.devtools Memory API — full path | Most accurate; longest dev path; research-heavy. | |

**User's choice:** Best-effort + operator/alpha note (Recommended)

**Notes:** Honors feedback-trust-harness-over-manual-uat.md (manual surface limited to genuine non-automatable case). chrome.devtools Memory API is research-heavy + out of charter for verification-phase scope. Optional puppeteer.Page.metrics scaffolding may be added in Plan 03-04 if practical without research budget.

---

## Claude's Discretion

Captured in CONTEXT.md D-P3-01 "Claude's Discretion" subsection:
- Harness assertion numbering (A29+ for new Phase 3 assertions)
- Probe page composition for §10 #4 (synthetic vs real-world)
- Event-log trigger strategy for §10 #5 (synthetic vs natural)
- Sequencing within Wave 2 (parallelization audit per plan-checker)

---

## Deferred Ideas

All deferred items captured in CONTEXT.md `<deferred>` section:
- Phase 4: rrweb v2 stable upgrade, programmatic RAM measurement, REQ-password-confidentiality v2 candidate, audit P1 #11/#14/#15 polish, 2 ffprobe/ffmpeg vitest flakes, cursor visibility refinement, dark-surface logo contrast, setimmediate polyfill hardening, ROADMAP backfill
- v2 / SRV milestone: server upload (SRV-01), AI diagnostics (SRV-02), automatic ticketing (SRV-03), analytics dashboard (SRV-04), audio recording (CAP-01)

---

## Session efficiency notes

- User batched all 4 gray areas in 1 AskUserQuestion (multiSelect)
- All 4 area-specific questions presented in 1 AskUserQuestion call (4 questions batch)
- 1 follow-up clarification for Q1↔Q3/Q4 composition tension
- Total: 3 user-interaction turns (gray-area selection + question batch + clarification)
- Aligned with user's "minimum friction everywhere" pattern + saved memory feedback-no-unilateral-scope-reduction