Piik/docs/todo.md

Current TODO Ledger

Last reviewed: 2026-09-25

Only Now is executable. Product modules own behavior; Git/PRs own completed history. A parked idea is not implementation authority.

Now

• Passive App attachment: design hold. Site mode authorizes one selected origin and supplies native media without starting a local room server. A passive replacement needs an accepted site-consent/discovery flow; it must not admit arbitrary sites or add another runtime owner. Keep Site mode until that decision; removal of the Demo prefill does not authorize changing site trust.
• Complete manual accessible-name review. Verify the empty video's screen-reader output: Chromium exposes an unavailable-media description despite the literal shared-picture label and no media error. Also review accessible naming on disabled tooltip wrappers and the UI catalogue's paired-character example; automated checks leave those for manual review.
• Refine the isolated room-interaction prototype. Review chat, optional danmaku and participant-targeted reactions for usability, placement and intended cross-view synchronization. Preserve room authorization and media-route owners. Accept its combined layout: sharing settings with the picture, floating chat without page reflow and room actions before diagnostics. Check narrow-screen keyboard avoidance, its theater entry and participant menu on real devices; keep chat available independently of sharing. Retain current room creation: the first share creates a room, an existing room can resume, and stopping media keeps the opted-in interaction session. Do not add visit-triggered creation or a separate pre-share room-creation entry. This experiment does not authorize integration or publication.
• Room voice: design before implementation. The voice assessment maps current owners, mature options and a staged verification plan. Resolve total voice membership/topology, P2P-only deployment coverage, speaking authority and the Host-commentary compatibility boundary before implementation. Validate source-audio isolation from received speech before exposing simultaneous sharing and voice. Keep room authority, microphone and screen lifetimes distinct; no new room store, screen-tree reversal or automatic mesh/SFU controller is approved.
• Verify media fidelity independently of voice. Verify actual left/right separation through Browser, Native and SFU paths; receive-side stereo negotiation alone does not establish audible fidelity. Assess HDR capture to correct SDR output for ordinary viewers before full HDR, with issue #420 as the reported case. Full HDR and surround sound remain design decisions. These findings do not establish physical device acceptance or authorize a new release.

Awaiting Device Or Reporter Evidence

• Self-hosted room creation HTTP 403. Retest affected deployments using the address checks. A stale explicit ALLOWED_ORIGINS overrides PUBLIC_BASE_URL; the sample now follows the public address and Piik identifies its Origin rejection. Reporter configuration and response details are still absent; distinguish Piik's rejection from a proxy/WAF 403 before assigning their cause.
• No available media route. A decline is reported since around v1.4; establish comparable attempts on the same endpoints/network before attributing a version regression. Obtain matched Host/Viewer diagnostics from a failed attempt, with version and mode. Inspect candidate exchange, selected paths, first-frame admission and route rejection separately. The Browser candidate-queue rejection defect is repaired and regression-tested; current STUN reachability and route-lifecycle checks do not establish these reporters' causes. HTTP 1033 belongs to the public-link item below, before media routing. A complete v1.6.3 App report confirms four candidate timeouts without Native share-start or any SDP/ICE signaling. Browser diagnostics are needed to locate prepare delivery, peer initialization or the first offer send; these attempts do not establish an ICE/NAT failure. Locally reproduced Browser construction failures now release owned tracks and reach the existing preparation/recovery owner, but are not proved to be this reporter's cause.
• Camera and Host microphone device coverage. The owner accepted the sharing layout and authorized release with these physical limits recorded. Verify real audio levels/echo, multiple-device replacement and native mixing on target systems, plus phone camera permission, orientation and background use. Keep the existing capture and route owners. The capture assessment owns behavior and separates bounded Windows/browser checks from untested device combinations.
• App public-invitation startup field acceptance. Retest the frequent creation-failure report and the earlier #396 timeout with the updated App. A controlled UDP-blocked/TCP-available reproduction confirms a dependency configuration defect; the existing tunnel now uses cloudflared's bounded protocol fallback and pre-readiness retries within one startup deadline. Runtime evidence separates this fix from DNS, provider and remote access failures. The reporting environments still need version and diagnostic evidence before assigning a cause. Demo access failures and public-link HTTP 1033 also remain unconfirmed: current Demo health/assets and an external-host public-link HTTP/WebSocket gate pass. Check connector reachability separately from WebRTC media availability.
• Interruption during established viewing. A Viewer reportedly returns to P2P connecting after watching for a while. Native receiver renegotiation, retired event delivery and SFU replacement have locally reproduced defects and regression checks, but paired diagnostics and device/network details are still needed to establish this reporter's cause. Include an upstream relay's report when present. The existing five-second Viewer membership grace during signaling loss is unchanged. This is distinct from the first-frame report below.
• Windows 11 capture border remains visible. Identify the App/Browser capture path, Windows build and capture-border permission result. Local checks reproduced a border surviving forced process termination; parent cancellation now uses bounded graceful retirement. Capture evidence verifies the repair and concurrent-capture behavior on Windows 11. The reporter's cause remains unconfirmed; check consent and other active captures.
• Brief connection followed by repeated Viewer loss on v1.5.0. One Viewer reportedly drops just after connection details appear, while other Viewers work; App public-link mode is suspected. Check signaling, first-frame admission and current-edge recovery separately. A delayed-confirmation reproduction establishes one premature candidate replacement; the affected environment and paired diagnostics are still unavailable, so the reporting machine's cause remains unconfirmed.
• App discovery and share-start field acceptance. Retest the missing-window report, an unreachable App despite its process running, and generic share-start failure. Distinguish site authorization, browser permission, control capacity, enumeration and capture startup. A complete v1.6.3 Windows report confirms Auto/Window/1080p30 balanced startup: hardware MFT event timeout, then software probing, then cancellation because capture readiness did not arrive. The stall within probing, teardown or WGC initialization remains unknown; one initial VP8 statistics sample cannot establish its complete output history. Auto now skips the redundant comparison when only VP8 remains. Injected unavailable hardware and exhausted-probe-budget cases both capture and decode locally; the affected machine still needs same-source Auto versus explicit VP8 acceptance. Do not extend deadlines without identifying the blocked stage. Existing H264-retention/ICE-candidate repairs do not establish this cause; other discovery/manual-H264 reports still need paired App/Browser diagnostics.
• Share ends after entering a game. Screen sharing reportedly works until entering a game freezes the picture, followed seconds later by share termination. Version, capture path, codec and matched diagnostics are unknown. Locate the first capture/output, preview-bridge, control or authority failure; distinguish ordinary source silence/resize from target replacement, exclusive fullscreen, display-mode change and device loss. A reproduced downstream retirement race no longer stops the shared source. Controlled-window checks do not reproduce the reporting game/device environment.
• Brief blur followed by immediate recovery. Compare the same source, codec, peers and network with ordinary WebRTC before attributing the report to pooling. The pool checks cover rate-owner retention, publication startup, native recovery probing and ordinary fallback. They do not establish this reporter's capture path or result; correlate actual receiver dimensions, QP, resource adaptation and packet loss.
• Windows 32-bit candidate acceptance. Verify the isolated spike/windows-x86-capture candidate's launch, capture/audio, memory pressure, source replacement and update links on a 32-bit Windows device. WOW64 Host/media checks establish only that environment. Reconcile its scoped SDK/toolchain and atomic-alignment changes with current main when accepted; the experiment is not part of this maintenance release.
• Windows launcher exit after opening the page. A user reports that the mode-selection page opens, then the App console reports Piik App could not open its launcher: exit status 0xc0000005. Recheck on the reporting machine after the browser-handoff repair. The Windows URL-handler crash itself still needs the affected build and process/dump evidence; local checks cannot establish its underlying cause.

Next: P2P Connection And Feedback Evidence

After the current phase, measure connection success, time to first picture and failure causes on representative networks, especially App and P2P-only sites. Use existing Debug provenance and selected-path events before adding runtime counters. Separate emitted candidates, actual connection attempts, successful paths and timeouts; keep observations scoped to connection generations and exclude raw endpoints. Establish survey response visibility without treating local listener binding as proof of public reachability. The NAT evidence owns the dependency and observation limits. Compare current P2P/SFU handoffs, including background P2P attempts behind working SFU media, before choosing changes. Preserve one graph and one operation under the routing contract and ADR-0005. Prior ownership audits do not establish better connection success or speed; this note adds no retry policy.

Parked Product Work

1. Representative device/network acceptance. Resume the remaining matrix in verification status when directed, preserving the owner's platform deferrals. Correlate freezes with publisher/receiver evidence before changing media policy. Run physical workloads serially from stable executable paths with cleanup between runs. Before using the optional viewer-mbb benchmark canary, align its injected evidence and capacity assertions with the current sender-owned quality contract; its old Viewer-only trigger is not a valid quality acceptance gate.
2. Broader quality work. Reopen from measured benefit at acceptable complexity. Preserve chosen profiles, bitrate ceilings, endpoint capacity and P2P-first routing unless a new accepted decision supports changing them. No weighted score, all-pairs probes, periodic rebalancing, parent-wide prediction or room-wide minimum. Check whether a quality move merely shifts pressure to another parent's siblings before widening policy.
3. Control/resource fairness and input review. Reassess the authenticated WebSocket/SFU owner, HTTP/body/resource bounds, authorization and error/log handling before adding a queue or limiter. No parallel security framework, accounts, risk score or speculative policy layer. Measure signaling-lock contention and synchronous diagnostic I/O before changing the lock or execution model; their cost remains a tradeoff.
4. Reachable ownership/refactor work. Retain Host/Viewer page media-session extraction as a candidate alongside related behavior changes. Evaluate clear resource owners, fewer shared writers and a smaller change surface under engineering review; file size alone does not justify a split. The completed audits do not close this candidate. Reopen C=3 structural-intent retention and multi-child evidence ownership only with current-contract reproductions. When related behavior changes, compare the Browser/Native recovery budget; preserve Native bridge versus network failure distinctions when sharing code. No new revision namespace, failure-state mirror or topology queue by default. Native Host loopback media failure currently ends the share, although Native publication has its own source. The loopback stream also supplies Browser quality candidates and gates quality/SFU updates; simply ignoring its failure leaves dead consumers. Review those owners and the track-ended handler before changing recovery. This is not an established cause of the game-entry report.
5. Storage fault recovery. Choose and verify a damaged-disk/COMMIT/ROLLBACK recovery policy before adding catch-and-continue or retries. This failure boundary remains unestablished after ordinary persistence checks.
6. Platform output. Reopen for a registered receiver acting as an ordinary Viewer only after the platform-output gate passes.
7. Additional languages. Review community catalogs and their rendered UI following the translation guide. Add website, documentation or App console translations as contributed; verify text direction and layout when a language requires it. Check contributed language names and rendered menu navigation when registering a new catalog.
8. Windows code signing. Revisit after enrollment in a trusted signing service. Sign Piik's executables before archive checksums are computed; signing improves publisher identity but does not guarantee that antivirus cloud scanning stops. Service selection and enrollment remain pending.
9. Gitee download-source warning. Paused by the owner. Keep GitHub primary and retain Gitee; do not add a self-hosted mirror. Chrome still blocks the Gitee attachment when Referer is removed. Reopen for new evidence or a provider review; the warning remains unresolved.
10. 4K in advanced sharing settings. Hold the isolated candidate for joint review with the next room-interaction release; its compatibility and release boundary are not yet accepted. Add 3840x2160 without changing the default or recommended presets. Extend the existing capture, decode and relay bounds together; verify H.264 level negotiation for 4K at 60 fps. Current strict quality messages reject 2160p, so preserve published Browser/App/Server compatibility through explicit receiving-end support before exposing or sending the new setting. Include source replacement, lower outputs and resource limits in acceptance.