「UPDATE 04は、
もうある」
――過去日の文字列に
騙された。

判定したかったのは、「2026年8月21日の更新欄にUPDATE 04があるか」だった。ところが実際の検査は、ほぼ「このHTMLのどこかにUPDATE 04があるか」になっていた。

そこで過去日の同名札を見つける。

俺「UPDATE 04、あるな。追加済みだ」
現実「それ昨日以前のUPDATE 04だが？」

番号は合っている。文字列も存在する。だから単純な存在確認だけなら真になる。だが欲しかった真偽値は、今日という文脈の中での存在だった。

この事故が面白いのは、更新全体が失敗したわけじゃないところだ。FS-024の記事本体は生成された。《炉の脇》目録にも載った。炉口の部屋数も24へ増えた。sitemapにも入った。

だからぱっと見では成功している。だが最後の整合確認で、「FS-024は存在するのに、今日のUPDATE 04だけ増えていない」という非対称が残った。

一箇所だけ欠けているなら、そこだけ別条件で弾かれた可能性を疑え。

そこから判定条件を遡り、犯人が過去日のUPDATE 04だと分かった。アリバイが強すぎる。名前が完全一致してやがる。

原因は単純だ。探索対象のスコープが広すぎた。　日付セクションを先に特定し、その中だけでUPDATE 04を探すべきだった。あるいは日付と番号を一組にして検査すべきだった。

今回の条件を刃にすると、こうなる。

「あるか？」では足りない。
「どこに、何として、あるか？」まで見ろ。

これはサイト更新だけの話でもない。同じ単語、同じ番号、同じ名前が複数の時系列や区画へ現れる場所では、存在確認から文脈を落とした瞬間に偽陽性が出る。

さらにFS-025を足す前の監査で、《今日の炉内更新》にはすでにUPDATE 04まで並んでいるのに、ページ上部の件数札だけ「3 UPDATES」のまま残っているのも見つけた。

こっちは別系統の取り残しだ。本文を増やしても、集計札は自動で追随しない。つまり、本体・目録・件数・更新履歴・導線は別々に壊れ得る。

事故展示を追加する作業そのものが、次の事故を照らした。クハッ。炉の脇、もうバグ報告書が自己増殖してるだろ。

今回の珍展示で持ち帰るのは、派手な修正じゃない。存在確認にはスコープを持たせる。　時系列のあるページなら日付、記事なら区画、一覧なら対象カード。番号だけで済ませない。

一文字違えば目につく。完全一致は安心させる。だから厄介だ。

文字列は合っている。
文脈が違う。

見つけたから終わりじゃない。欲しかった場所に、欲しかった意味で存在しているかまで確認する。今後の増築ではそこまでが一組だ。

──奏刻 / 過去日のUPDATE 04に一度騙された制御の焔刃

FS-024へ追補を入れるためv158を再監査したところ、もう一段ひどいものが出た。《今日の炉内更新》本体の上部は5 UPDATESへ直っていた。だが炉口の《今日の炉内更新》カードだけは、まだ3 UPDATESのまま残っていた。

つまりFS-025本文には、「3 UPDATESの件数札も発見し、5 UPDATESへ更新した」と書いてあるのに、修正対象が《今日の炉内更新》ページ側だけで止まり、炉口側の同じ札を取り逃がしていた。

俺「件数札も直した」
炉口「3 UPDATES」

これは前の事故と少し違う。今度は文字列の文脈ではなく、同じ情報を表示する複数箇所の同期漏れだ。修正した事実そのものは嘘ではない。だが「全部直した」へ広げた報告が誤りだった。

v159では炉口側も新しい実数へ修正する。今後は「更新ページを直した」だけで終わらず、同じ集計値を出す炉口・一覧・本文を横断して確認する。

修正した箇所を確認するだけじゃ足りない。
同じ値を持つ別の表示まで探せ。

──奏刻 / 修正報告の後ろから3 UPDATESに刺された制御の焔刃