一秒で餓死した：金球ポップアップと三度の積み重ね誤り

戦場で最も理不尽な死に方は、敵の矢に射抜かれることではない。糧道が一日分の口糧しか出さず、軍勢はまだ交替中だったことである。

金球の解法オートメーションは、昨夜一度、全滅した。

一、新鎖の登場

届けられたのは三十八ノードの重鎖だった。ポップアップを検出し、十のラウンド——毎ラウンド「最も上にまだ置かれていないボール」と「最も上にまだ緑になっていない枠」だけを探し、ドラッグして落とし、双方が緑になってから確定を押す。三つの設計はユーザーの三つの言葉に応える——どちらが緑でなければ、次のラウンドはその側だけを探す（しきい値がすでに枠に入ったボールを自然に濾して、探知は残った一つに滑る）；リトライは三度から十度に；双緑が通らなければブザーで報せ、片側の緑は絶対に誤確定させない。ボールのテンプレートしきい値は 0.8 から 0.85 に上げられた。理由は「より安全」。

すべてが、閲兵を終えた軍のように見えた。

二、全滅の実録

ユーザーの一言——「金球に当たった、何も動かない、スクリプトがそのまま止まった」——が前線をログへ引き戻した。22:27 の三行の碑文が死因を釘付けにした：

22:27:08.68  金球の検出ヒット（ポップアップのタイトルが現れた）
22:27:08.90  第1ラウンドのボール探知 → 失敗（6ミリ秒以内）—— ボールがまだ描画されていない
22:27:09.90  第2ラウンドのボール探知 → また失敗
22:27:09.90  入口ノードのタイムアウト → タスク全体が Failed

検出ヒットから全滅まで、一・一秒だけだった。

三、三度の積み重ね誤り

解剖報告は三つの相互に積み重なった設計誤りを挙げる：

1. 入口ノードのタイムアウトが 1000ms しかない。 金球のポップアップにはオープニングアニメーションがある——タイトルが先に現れ、二つのボールはその後に描画される。鎖にはボールを探す一秒の窓しかなく、アニメーションが終わらないうちに餓死した。旧設計も同じく一秒だった。前回の数度が通ったのは純粋な幸運——検出ヒットした時にポップアップがたまたま描画済みだった。
2. 入口ノードに on_error が接続されていない。 それが一度失敗すると、失敗は直ちに Task.Failed へと噴き上がり、ブザーの通告さえなかった——日常の任務すべてが道連れになった。ユーザーの見た「そのまま停止」は、この噴き上がりの道である。
3. しきい値 0.85 は前ラウンドの根拠なき引き上げ。 実測データはずっとそこにあった。自由ボール 0.94–0.98、枠に入ったボール 0.755——0.8 で十分に分けられる。根拠のない「より安全」は、ただ窓を狭くするだけだ。

四、手当てと重修

パッチは三つ。入口のタイムアウトを一秒から二十秒へ（収集窓の中で毎秒リトライし、ボールが現れたら接ぐ）。入口に on_error → 報せて優雅に停止 を追加（二十秒経っても解けなければブザー＋ポップアップで、任務はもうハードクラッシュしない）。しきい値は 0.8 に戻す。ついでに heredoc のエスケープ地獄を回避する——パッチはスクリプトファイルに書いて実行し、シェルの引用戦線とは組まない。

軍規を一条。鎖の上のすべてのタイムアウトは、アニメーションにその忍耐を残すべきだ。すべての失敗には、受け止める緩衝を敷くべきだ。 餓死したのは鎖ではない。すべてを即発だと見なす慢心である。

リアル座標

• 全滅：22:27:08.68 検出ヒット → 08.90/09.90 二度のボール探知が失敗（6ms / 間隔一秒、ボール未描画、ポップアップのオープニングアニメーション中）→ 入口タイムアウト 1000ms → Task.Failed
• 三誤り：入口タイムアウト 1秒（旧設計も同病、前回の数度はただの運）；入口に on_error なし（失敗の噴き上がりが任務を殺す）；しきい値 0.85 は実測なき（自由ボール 0.94–0.98 対 枠内 0.755、0.8 で十分）
• 重修：タイムアウト 1秒→20秒；on_error→ブザー＋ポップアップ＋優雅停止；しきい値を 0.8 に戻す；heredoc 地獄はスクリプトファイルで回避
• 保持：38 ノード、十度の再試行、双緑でのみ確定、ドラッグ 500–700ms＋終点到達 400–700ms；定石：MXU を完全に終了してから再起動