Repository navigation
ISOs armed with Zoom capture off are loud now (T3.7 / #470) - #502
Merged
Merged
Conversation
) Seen live 2026-09-10: recording started with ISOs enabled and 7 Zoom guests selected while Engine was off. Program recorded normally. All 7 ISO streams sat at framesWritten 0 with no file created, recording.warning null and no per-stream warning. Turning Engine on mid-recording opened the writers lazily at their first frame, so the operator silently lost the head of every ISO. It cannot be caught downstream, which is why nothing caught it: an ISO writer opens LAZILY at its first frame, so a source that never produces one leaves no stream behind to carry a warning. The only place that knows is the arming decision, so IsoCapturePreflight is consulted FIRST in IsoHealthWarning, ahead of the per-stream scan that had nothing to report. Two rules in the policy: - It reads the ENGINE-reported capture state (rawMediaActive), not the button we last pressed. CLAUDE.md is explicit that the Capture UI reflects engine truth, and a warning keyed on intent would miss a capture that stopped on its own. - UNKNOWN is not a problem. Before the first snapshot arrives we cannot tell capture-off from not-yet-reported, and warning on a state we have not observed is how an indicator gets trained into background noise. Breaks nothing else: the message names the count, says what to do, and says WHY turning Engine on later is not a fix. 6 policy tests; 2224 MediaCore and 1465 WinUI tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014yuH7EMvWCWdkhvevrtMyJ
iamfatness
force-pushed
the
feat/iso-capture-warning
branch
from
September 12, 2026 15:38
6d692c6 to
b85ca54
Compare
iamfatness
added a commit
that referenced
this pull request
Sep 12, 2026
Nine items closed and two partial, all shipped in beta-2026-09-12-e1223d3 and none of them live-checked: T1.12 #475 join-time prompts answered #493 T1.13 #473 media decoder failures are loud #494 (observability ONLY) T2.6 #438 packaging spec reconciled #504 T2.7 #474 one shortcut, uninstall cleans up #497 T2.8 #469 recordings resolve absolute #496 T2.9 #466 recording lifecycle survives a stream #499 T2.10 #468 sender health stops lying #499 T3.2 #440 WebView2 message #504 T3.7 #470 ISOs armed with capture off warn #502 T3.8 #482 ISO frames conform to the writer #503 T2.1 #433 PARTIAL — WER dumps are HKLM-only T3.5 #476 PARTIAL — the rest is a product call Each row keeps the thing that is expensive to rediscover rather than just a tick: T2.8 records that the issue's premise was wrong (the default was already absolute; a persisted relative preference bypassed it), T3.8 records that its end-to-end test is a guard which passes either way, T2.6 records that dropping MSIX cost auto-update, and T2.1 records the measurement proving a per-user installer cannot enable crash dumps. Tier 1 now has ONE open item, and it is waiting on a decision rather than effort: T1.11 step 1 needs a change to the Take path itself, because a plain cut never captures the outgoing scene. That is written into the row so the next session does not rediscover it and ship it blind. Two entries came out of the work rather than the list: #505 (the per-layer border controls are vestigial — the core forces borderStyle="none" on every route layer, so they cannot do anything) and the T1.11 ruling. The honest header: the binding constraint is now T0.1 and a live check, not engineering capacity. Claude-Session: https://claude.ai/code/session_014yuH7EMvWCWdkhvevrtMyJ Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #470.
Live 2026-09-10: recording started with ISOs enabled and 7 Zoom guests selected while Engine was off. Program recorded normally. All 7 ISO streams sat at
framesWritten: 0with no file created,recording.warning: null, and no per-stream warning. Turning Engine on mid-recording opened the writers lazily at their first frame — so you silently lost the head of every ISO.Why nothing caught it
It cannot be caught downstream. An ISO writer opens lazily at its first frame, so a source that never produces one leaves no stream behind to carry a warning. Every existing check scans streams that don't exist yet.
The only place that knows is the arming decision, so
IsoCapturePreflightis consulted first inIsoHealthWarning, ahead of the per-stream scan that had nothing to report.Two rules worth keeping
rawMediaActive), not the button we last pressed. CLAUDE.md is explicit that the Capture UI reflects engine truth, and a warning keyed on intent would miss a capture that stopped on its own.The message names the count, says what to do, and says why turning Engine on later isn't a fix.
6 policy tests; 2224 MediaCore and 1465 WinUI tests pass.
How to test it: arm Program + ISOs with Zoom guests selected, leave Engine off, and open the record flyout — the warning should appear before you start, not after the show.
🤖 Generated with Claude Code
https://claude.ai/code/session_014yuH7EMvWCWdkhvevrtMyJ