You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Harden Review Tutor for unusually long answer streams and simultaneous browser tabs after PR #61 ships.
Context
Local review of PR #61 confirmed the current behavior is correct for the single-user flow, but identified two bounded follow-ups that should not expand the approved page-focused PR:
appendAnswer reparses and rebuilds the complete Markdown tree for every SSE delta. A long answer split into many small chunks can create avoidable main-thread work and clear native text selection.
When a page has no currentQuestionId, reconnect state adopts the newest queued/running question. That is useful for reload recovery, but a second tab can cause a question it started to appear in the first tab.
PR #61 already buffers pre-response events, reconciles canonical state, bounds Markdown recursion, and prevents duplicate active submissions. This issue is about efficiency and explicit multi-tab ownership, not correctness recovery.
Acceptance criteria
Coalesce streamed Markdown renders to at most one DOM update per animation frame while preserving exact accumulated answer text.
Terminal question events render synchronously from canonical state and cannot lose a final delta.
Native selection in an answer is not repeatedly destroyed by multiple deltas in one frame.
Add a deterministic large-stream test that proves bounded render count and exact final output.
Define page/question ownership for reload recovery versus a second active tab without exposing the bearer token or changing the parent Pi session.
A reload can still recover its sole queued/running question.
A separate tab does not silently adopt another tab's new question unless the ownership contract explicitly permits it.
Preserve rt/1 unless a protocol change is demonstrably required; if required, document compatibility before implementation.
Keep the loopback, read-only, bounded-process, persistence, export, and cancellation contracts unchanged.
Review measurement: repeated full Markdown renders reached seconds of parser/DOM work for a tens-of-KiB answer split across hundreds of deltas in happy-dom.
Current multi-tab behavior is intentionally accepted for the local single-tab release and has no P0–P2 impact.
Goal
Harden Review Tutor for unusually long answer streams and simultaneous browser tabs after PR #61 ships.
Context
Local review of PR #61 confirmed the current behavior is correct for the single-user flow, but identified two bounded follow-ups that should not expand the approved page-focused PR:
appendAnswerreparses and rebuilds the complete Markdown tree for every SSE delta. A long answer split into many small chunks can create avoidable main-thread work and clear native text selection.currentQuestionId, reconnect state adopts the newest queued/running question. That is useful for reload recovery, but a second tab can cause a question it started to appear in the first tab.PR #61 already buffers pre-response events, reconciles canonical state, bounds Markdown recursion, and prevents duplicate active submissions. This issue is about efficiency and explicit multi-tab ownership, not correctness recovery.
Acceptance criteria
rt/1unless a protocol change is demonstrably required; if required, document compatibility before implementation.Evidence