gitignore の中の数字は、捏造に見える

記事を公開する前に、別系統のモデルに批判的レビューをさせている。2026-08-22 に回した1本で、こういう BLOCKER が返ってきた。

全履歴に対する 81.7 / 0.8167 の検索でも、81.7%はこの記事自身にしか存在しなかった。実装、テスト、コミットメッセージには根拠がない。

記事は、敵がコンテナの中に湧いてしまう不具合を直した話で、直したあとの脱出率を「81.7%に戻った」と書いていた。修正コミット 386faaf が実際に記録しているのは 0.9167 から 0.85 への変化だ。85.0% が正しい。

指摘は当たっていたので 85.0% へ直して公開した。そのとき自分は、原因をこう書いた。どこかで転記を間違えたまま、誰も突き合わせていなかった、と。

2026-08-25 に同じ数字をもう一度追いかけて、そこが違うと分かった。

数字は在った

grep -r を作業ツリーに直接かけたら、2箇所で出てきた。

.superpowers/sdd/2026-08-13-prod-run-v06-scavenge/progress.md:34
  脱出率 91.7% のうち約10pt はこの不具合(押し出しを当てると 81.7% で帯の中に戻る)。

.superpowers/sdd/2026-08-13-prod-run-v06-scavenge/task-3-review.md:56
  | Task 3 + 敵を円の外へ押し出す | 81.7%(帯の中に戻る。sim-run 5件すべて緑) |

実装計画の進捗メモだった。「敵を円の外へ押し出す」というのは、このとき検討して採らなかったほうの案だ。81.7% は、その採らなかった案を試したときの実測値だった。

打ち間違えたのではない。隣に並んでいた数字を持ってきていた。

原因が違うと、対策も変わる。転記ミスなら「数字を目で確かめる」で終わる話だが、実際には「どの案の測定値かを取り違えた」なので、確かめるべきは数字の形ではなく出どころのほうになる。

なぜ検索に映らなかったのか

.superpowers/sdd/ には .gitignore が置いてあって、中身は * の一行だけだ。

$ git check-ignore -v .superpowers/sdd/2026-08-13-prod-run-v06-scavenge/progress.md
.superpowers/sdd/.gitignore:1:*    .superpowers/sdd/...

$ git ls-files .superpowers | wc -l
0

追跡されているファイルは0件。git grep も git log -S も、既定では追跡下のファイルしか見ない。だから全履歴をどれだけ掃いても、この2つのファイルは一度も検索対象に入らなかった。

同じ数字が、コマンドを変えるだけで出てくる。探した当時、追跡下だけを見る形は空を返し、無視されたファイルまで届く形は2件を返した。

git grep -n "81\.7" -- .superpowers                            # 空
git grep -n --untracked "81\.7" -- .superpowers                # 空(無視されたファイルは対象外)
git grep -n --no-index "81\.7" -- .superpowers                 # 2件
git grep -n --untracked --no-exclude-standard "81\.7" -- .superpowers   # 2件
grep -rn "81\.7" .superpowers                                  # 2件

--untracked では届かないのが地味に効く。--untracked が拾うのは「追跡されていないファイル」までで、そのうち ignore 規則に当たるものは既定の探索から外れたままになる。届かせるには --no-index を使うか、--untracked と --no-exclude-standard を一緒に渡す。--no-exclude-standard だけを足しても fatal: --[no-]exclude-standard cannot be used for tracked contents で止まる。1つ目と2つ目を試して「無い」と結論すると、そこで終わる。

⚠ ひとつ断っておく。この再現は、いまリポジトリ全体に対して回しても成立しない。 git grep -n "81.7" は現在 49 件を返す。追跡下のファイルに 81.7 が大量に入っているからで、その中身はこの調査の記録そのものだ — レビュー報告、台帳、harness/STATE.md、そしてこの記事。上のコマンドに -- .superpowers を付けてあるのはそのためで、範囲を切らないと当時の状態を再現できない。

そして書いておくと、それは記事を書いた時点で既にそうだった。 訂正を記録したコミットは 2026-08-25 15:12、この記事の初稿は同日 15:33。21分先に、自分で検索対象を作っていた。「探しても出てこなかった」を、出てくるようになってから書いている。

在り処は、コミットメッセージに書いてあった

いちばん決まりが悪いのはここだ。修正コミット 386faaf の本文の末尾に、こう書いてある。

詳細と敵以外の同じ穴の洗い出し結果は .superpowers/sdd/2026-08-13-prod-run-v06-scavenge/task-3-report.md (gitignore対象のため本コミットには含まれない)。

同じディレクトリを名指しして、追跡外であることまで断ってある。読めば分かるように残してあった。検索が届かなかっただけだ。

そして自分も、レビュアーも、その一文を素通りして「実装にもテストにもコミットにも無い」で止まった。

3段の飛躍

やったことを分解すると、飛躍が3つ重なっている。

• 検索して出てこなかった
• だから存在しない
• だから捏造か転記ミスだ

2つ目で既に間違っている。git grep が言えるのは「追跡されているファイルには無い」までで、「リポジトリのディレクトリに無い」ではない。1段目の網の広さを確かめないまま、2段目と3段目を積んでいた。

もっと悪いのは、これが2回起きたことだ。2026-08-22 のレビューが1回目。2026-08-25 に同じ記事群をもう一度別のモデルにかけたとき、そちらも git log --all -S'81.7' と全リビジョンの git grep を回して、「レビュー実施時点では実装・テスト・コミットメッセージに根拠がなかった」という同じ結論に落ちた。道具が同じなら、レビュアーを変えても同じ死角に落ちる。

別系統のモデルに読ませるのは、思い込みを外すためにやっている。それでも、両者が同じコマンドを使うなら、独立した2つの意見にはならない。

どこまでが本当に言えるのか

自分のプロジェクトには「網を狭める変更には、回帰の実例を必ず添える」という規則がある。検出を広げる変更は失敗すればすぐ止まりすぎて分かるが、狭める変更は失敗しても何も起きない、という理由で作ったものだ。

今回はその変種だった。検索の網はもともと狭かった。狭いことを知らずに、網の外を網の結果で語った。

作業中のメモを追跡外に置くこと自体は、たぶん間違っていない。数が多いし、大半は途中で捨てる。困るのは、その状態で「存在しない」と言い切るときだけだ。

2026-08-25 に決めたのは2つ。数字の出どころを探すときは git grep で終わらせず、作業ツリーへ grep -r をもう一度かける。そして、レビュアーに検索させるときは、無視されているディレクトリがあることを先に伝える。

85.0% という訂正自体は正しかった。正しい訂正でも、原因を取り違えたまま出せば、次に同じ穴へ落ちる。

この記事で扱った脱出率とコンテナの当たり判定は、Prod Runで実際に動いているものだ。