見えていても押せなければ動かない

台帳に出し続けることと、人が使えるようにすることは別。 見えることと、選べることは違う。

実例。マインスイーパの鑑賞装置が 2026-06-24 に完成し、テストも通り、台帳上も「実装済み」だった。 それでも 2026-09-11 に初めて起動されるまで、一度も動かされなかった。毎セッション冒頭の 集約ビューがその項目を出し続けていたので、見えてはいた。足りなかったのは押せる形のほう。 VNC を立てて 遊ぶ.bat を1つ置いた日に、一晩で 1493 局が走った。

構造として、同じ穴が2つ空いていた。

• ランチャーに「AI への発注書」しか並べていなかった。 机でクリックする機構は既にあったのに、 枠が発注専用で、遊ぶ・見る・起動するが並ぶ場所が無かった
• 状態がすべて「作る」側だった。 捕獲→設計→委託可、の3状態しかなく、 「できて、動いていて、使っている」という状態が存在しない。作り終えたものは台帳の行に戻る

判断にも同じ型が出る。「同等物が未取り込みコミットにあるから、そちらを取り込むほうが筋がいい」—— 台帳の整合を優先して、いま押せる物を1つ減らす判断。二重化の回避は正しいが、押せる物を 消してまで守る価値は無い。両方残して後で畳めばいい。

• 完成報告に、次に人間が押せる一手（起動コマンド・URL・ファイルパス）を必ず添える。 「実装済みです」で終える報告は、何年も動かない行を1本増やすのと同じ
• UI を「楽だから」で正当化しない。 本体は問いや機能を押せるものに変えること。 文章で問われると人は答えを組み立てるところから始めるが、選択肢なら押すだけで済む

三か月動かなかった理由は、見えていなかったからではない。押せなかったから。

関連：状態ではなく結果を見せて選ばせる（そちらは選択肢の比較、こちらは完成物の起動）／ 名付けた退避路は発火条件まで書く／verschlimmsweeper