証拠

バグが修正されたと主張するのは誰にでもできます。このページでは、修正内容、それを守るテスト、そしてバグが再発したときにそのテストが失敗することの証明を示します。

tools/prove_regressions.py から 2026-10-03 に生成 · 4件中4件の回帰テストが空検証でないことを証明済み。

各証明の生成方法

修正後のコードに対して回帰テストを実行します。成功しなければなりません。
ソースを編集して元のバグを戻します。
同じテストをもう一度実行します。今度は実際のアサーション失敗で失敗しなければなりません。コレクションエラーはカウントしません。それはテストが実行されなかったことを意味します。
ファイルを復元し、SHA-256 が元のものと一致することを確認して再実行します。再び成功しなければなりません。

アシスタントは訪問者に対し、webhookが会話内容を運ぶと伝えていました。実際には一切運びません。

コミット e027e6b · apps/gateway/tests/test_webhook_content_claim.py によりガード

Webhook のペイロードは、意図的にターンの「形」だけ、つまりイベント名、タイムスタンプ、ステップ数、クレジットのみを運び、その内容は決して含みません。アシスタントに webhook に会話が含まれるかを尋ねたところ、「はい、各 webhook ペイロードにはそのターンの会話履歴全体が含まれます。」と答えました。これは、許可リストがテストで検証している保証の正反対です。修正前は 6 回の実行中 2 回の捏造を計測しました。

修正したコード、テスト実行	PASS	`21 passed in 1.15s`
バグを再導入、同じテスト	検出	`8 failed, 13 passed in 1.20s`
ファイル復元、テスト実行	PASS	`sha256 a8d4cb0b10787eff…`

このテストは空虚ではありません：バグが再発すると失敗します。

存在しないダッシュボードカードをクリックするよう、オーナーに案内していました。

コミット b4a203a · apps/gateway/tests/test_card_names.py で保護

ナレッジベース、ドキュメント、スタータータイルのすべてが、オーナーに「Send turns to a webhook」というカードを探すよう案内していました。実際のダッシュボードのカード名は「Send events to your own system」です。この名前はナレッジセクションの執筆時に作られたもので、確認されないまま3か所に広まっていました。計測結果：セットアップに関する回答2件中2件が、一度も存在したことのないコントロールを挙げていました。

修正したコード、テスト実行	PASS	`5 passed in 1.12s`
バグを再導入、同じテスト	検出	`3 failed, 2 passed in 1.23s`
ファイル復元、テスト実行	PASS	`sha256 f6348e1a5bbae209…`

このテストは空虚ではありません：バグが再発すると失敗します。

ダークモードの挨拶文はコントラスト比 1.73:1 で表示されており、事実上見えない状態でした。しかも、ガードではこれを検出できませんでした。

コミット ca47f41 · apps/studio/test/themeContrast.test.mjs によるガード

テストではなく、実際の iPhone で撮ったスクリーンショットから発見しました。ウェルカムの挨拶が #3a3a3c にハードコードされており、ダークモードのパネルに対して 1.73:1 でした。最低基準の 4.5:1 を大きく下回り、ほとんど読めません。ダークモードの初回訪問者全員がこれを目にしていました。修正では色をテーマ変数 --pw-mist 経由にし、パネルに追従するようにしました。ガードは現在、色が設定されていることを信用するのではなく、テーマごとの各組み合わせについて実際のコントラスト比を計算します。

修正したコード、テスト実行	PASS	`pass 5, fail 0`
バグを再導入、同じテスト	検出	`pass 3, fail 2`
ファイル復元、テスト実行	PASS	`sha256 54f8802b444b6194…`

このテストは空虚ではありません：バグが再発すると失敗します。

失敗したターンのせいで、訪問者が切断されたストリームの前で永遠に待たされていました。

コミット 4bcc691 · apps/studio/test/streamError.test.mjs によるガード

モデル呼び出しが失敗したとき、サーバーは正しくエラーフレームを送信していました。しかしウィジェットは、ガバナンストレースの分岐がすでに非表示にした要素にメッセージを書き込み、トレースを折りたたむこともしませんでした。訪問者には、すでに失敗したターンで「Reading your message」が点滅し続けるのが見えるだけでした。エラーも、回復も、それを知る手段もありません。エラーテキストは正しく代入されていたのに、どこにも描画されていませんでした。API アカウントのクレジットが尽きた実際の障害中に発見しました。

修正したコード、テスト実行	PASS	`pass 4, fail 0`
バグを再導入、同じテスト	検出	`pass 2, fail 2`
ファイル復元、テスト実行	PASS	`sha256 54f8802b444b6194…`

このテストは空虚ではありません：バグが再発すると失敗します。

運用記録

プラットフォームの裏に何があり、何が未検証か。スクリプトやログで示せることだけを載せています。

バックアップ：毎晩 03:17 UTC、pg_dump --clean --if-exists、gzip。各実行後にプライベート git リモートへプッシュ。最新は 20261003T031701Z。ダンプは 29 件保持。
復元訓練 2026-10-03：ダンプ 20261003T031701Z を同一ホスト上の使い捨て pgvector/pgvector:pg16 コンテナに 2 秒で復元：テナント 34、ナレッジ行 270、テーブル 47。ダンプは 03:17 UTC 時点のもので、13:26 UTC に定期デモクリーンアップが 30 日を超えた放棄済みデモテナントを 1 件削除したため（ゲートウェイログ）、復元結果は訓練時点の本番より 1 テナント多くなっています。
ロールバック：サイト：tools/deploy-site.sh --rollback（シンボリックリンクをもう一度切り替えて前のリリースに戻す）。Studio：tools/deploy-studio.sh --rollback（前のイメージ、ヘルスチェック済み）。
復旧目標：約束していません。夜間ダンプによりデータ損失は最大 1 日分に抑えられます。復元にかかる時間は明示していません。
未検証：1 インスタンスを超える負荷、マルチリージョンのフェイルオーバー、別ホストへの復元。

復元訓練が書き出す docs/ops-record.json より（docs/runbooks/db-backup.md）。

これが証明しないこと

これらは私自身のコードに対するセルフチェックです。特定のテストが特定のバグを検出することを示すものであり、システムに他のバグがないこと、監査が網羅的であったこと、独立した第三者がレビューしたことを示すものではありません。ハーネスはリポジトリにあり、実行すればこの主張を検証できます。

PANTHEON · 証明する: 稼働中のシステムを攻撃 · 監査記録 · ウォークスルー · 実績 · CV