Show HN: 緑色のテストは証明にならない – C/C++およびファームウェア修正の検証ツール

We unfix your fix —to prove it.

AIが記述したC/C++およびファームウェアのための第二の鍵

あなたのAIエージェントは修正したと言っています。Unfixはコードを記述しません — バグを再現し、修正を適用し、証拠を再実行してから、修正を元に戻してバグが戻ってくるかを確認します。そして、決定的な判定を下します：VERIFIED（検証済み）、REJECTED（却下）、またはNOT VERIFIABLE（検証不能）（証拠が判断できない場合）。

unfix · nucleo-demo

［画像: REJECTEDを示すUnfixターミナル：修正がバグを検出するテストを弱めている］

実際の実行：この「修正」は、失敗していたテストをパスに変えてしまいました。Unfixがそれを捉えました。

実際のハードウェアでご覧ください

AIが修正を作成しました。それは本物ですか？

1分46秒 · 音声オン · 作業名cplusの下で録画

1. 01 · 実際のバグ

   Unfixはファームウェアをビルドし、NUCLEOボードにフラッシュしてテストを実行します。テストは3回中3回失敗します：カウンターは42であるべきですが、41です。

2. 02 · 偽の修正

   この「修正」はunity_failをunity_passに変えます。CIは緑色になるでしょう。UnfixはREJECTEDと判定し、その行を指摘します。

3. 03 · 正直な修正

   ボード上での8つの独立したチェック — 修正前はバグがあり、修正後は3回中3回で消え、他に何も壊れておらず、元に戻すとバグが戻ってきます。VERIFIED。

問題

緑色のテストは証明にならない。CおよびC++では、「修正」がバグを隠蔽してもパスしてしまうことがあります。

メモリエラー、競合状態、不安定な失敗は、AIコーディングエージェント — そして疲れた人間 — がショートカットするまさにその場所です。エージェントは成功を報告しますが、バグは出荷されます。

Sanitizersが無効化されている

ASanやTSanが実行されなくなるため、クラッシュは消えます — メモリエラーがなくなったからではありません。

テストが弱められている

アサーションが緩められたり、失敗するケースがスキップされたりするため、テストスイートはバグの周りで緑色になります。

修正ではなく遅延

sleepを入れることで、あるマシンでは競合状態がまれになります。しかし、フィールドや実際のボードでは依然として失敗します。

仕組み

修正を作成した人から独立した検証ツール

1. 01

   再現

   クリーンなサンドボックスでビルドし、ベースバージョンでバグが毎回失敗することを確認します — 一度きりではなく、毎回です。

2. 02

   修正の適用

   PRやエージェントからパッチを取得し、Sanitizersをオンにして参照テストを再実行します。

3. 03

   元に戻すチェック

   修正を削除し、失敗が戻ってくることを確認します。戻ってこない場合、そのテストは何の証明にもなりませんでした。

4. 04

   アンチマスキングスキャン

   diffで無効化されたSanitizers、弱められたアサーション、追加された遅延をフラグ付けします。

VERIFIED — バグは修正されました、証拠付き
REJECTED — 修正されていないか、隠蔽されている
NOT VERIFIABLE — 証拠が判断できない；明確に述べられています
実行を見る

実際のバグ、実際のボードで、初回実行から判定まで。

STM32 NUCLEO-F401RE上のファームウェアプロジェクト。ターミナルアプリの編集されていないスクリーンショット。

01 · プロジェクトを開く

プロジェクト、ボード、テストを見つけます。

プロジェクトタイプ、接続されたボード、ST-Linkプローブ、サンドボックスが、何も実行される前にチェックされます。開始するにはワンキーです。

［画像: Unfixスタート画面：プロジェクトnucleo-f401re-demo、ボードNUCLEO-F401RE検出、Docker準備完了］

02 · バグの再現

ビルド、フラッシュ、失敗。3回中3回。

ファームウェアはコンテナ内でARM用にビルドされ、ボードにフラッシュされます。バグは毎回失敗しなければなりません — そうでなければ、証明するものがありません。

［画像: Unfix /bug: ファームウェアビルド済み、ボードフラッシュ済み、カウンターテスト3回中3回失敗］

03 · 修正のチェック

8つの独立したチェック、ボード上でライブ。

テストは弱められていません。修正前はバグがありましたが、修正後は消えました。他のすべては依然としてパスしています。そして、修正を外すとバグが戻ってきます。

［画像: Unfix修正チェック中：8つのチェック、ボード上でテスト実行中］

04 · 判定

デモでは：31秒でVERIFIED — 証拠を添付して。

あなたのフォルダに適用するか、ブランチを作成するか、HTMLレポートをエクスポートします。修正が不正なものであった場合、ページ上部にあるようにREJECTEDが表示されるでしょう。

［画像: デモでのUnfix VERIFIED：修正はバグを削除し、8つの独立したチェックによって31秒で証明］

実行場所

あなたのチームがすでに使用しているツールの中に。

GitHub Action (デモ)

デモリポジトリのプルリクエスト上で

デモリポジトリでは、GitHubチェックが判定と証拠をPRに直接投稿するため、レビュー担当者はマージ前に修正が本物かどうかを確認できます。

デモリポジトリでは今日、PRチェックが実行されています。パートナー統合も準備中です。

デモリポジトリからの実際のコメント（作業名cplusの下で投稿）。

実際のプルリクエストを見る：#1 (VERIFIED)、#2 (REJECTED)。

［画像: Unfix GitHub PRコメント：REJECTED、パッチはメモリおよびスレッドチェックを無効化し、バグを隠蔽している］

AIエージェント内で

Claude Code、Codexなどのエージェント向けのMCPツール。エージェントが修正し、Unfixが完了したかどうかを判断します。

ターミナルで

セットアップ、調査、デモ用の/bug、/fix、/checkを備えたシンプルなコマンドストリームアプリ。

実際のボード上で

ホストではなくボード上でテストするチームのために、ハードウェアでフラッシュ、実行、チェックを行います。

公開ベンチマーク

10件のAI生成C/C++パッチを実際のバグに対してテストしました。Unfixは4件を検証し、6件を却下しました。

有名なオープンソースC/C++プロジェクトから実際のバグを取得し、Codex CLIに修正させ、Unfixに各修正を、エージェントには隠されていたメンテナー自身の参照テストに対して評価させました。これらのテストを選択するルールは、エージェントが実行される前に固定されており（1件の文書化された例外、fmt-4960）、アンチチートテストが不正行為を防ぎます。

fmt spdlog zlib-ng cpp-peglib

ケース、パッチ、判定はGitHubで

4

VERIFIED

6

REJECTED

0

UNRESOLVED

カバーされたバグタイプ：ASan下のメモリエラー、TSan下の同時フラッシュ競合、エッジケースとロジックエラー — ファームウェアコードに近い純粋なCケースを含む。

［画像: USB経由で接続されたSTM32 NUCLEO-F401REボード、ステータスLEDが点灯］

私たちのデモが実行されるNUCLEO-F401RE。

ファームウェア

ラップトップだけでなく、あなたのボード上でも検証済み。

ほとんどの組み込みチームはハードウェアでテストします。Unfixは、実際のセットアップで既存のフラッシュおよびテストツールを駆動し、通常は混同される結果を分離します。

現在、ST-Link経由でSTM32 NUCLEOボードで実行中です。

あなたのリグ上でのテストごとの判定（/check）

FIXED 変更前にテストが失敗し、現在はパスしています。

BROKEN 変更前はパスしていましたが、変更で失敗します。

FLAKY ON THE BENCH 変更がなくてもテストは不安定です。結果を信頼する前にリグを修正してください。

FLAKY, WORSE 以前は不安定でしたが、変更によって著しく悪化しました。

単一のバグ修正の場合、/fixは1つの判定を下します：VERIFIED、REJECTED、またはNOT VERIFIABLE。

規制対象チーム向け

medtechなどのチーム向け、「エージェントが言った」が答えにならない場所。

決定論的

判定はビルド、テスト、Sanitizersから得られます — 言語モデルが決定するわけではありません。決定論的なルール、判定にLLMは使用しません。不安定なバグや競合バグは、繰り返し実行によって判断され、単一のパスではありません。

ファイルできる証拠

各実行にはレポートが残ります：再現されたもの、実行されたもの、変更されたもの。IEC 62304スタイルの変更記録に役立ちます。

あなたの環境で実行

クローズドネットワーク向けに構築されています。クラウドなし、LLMなし — Unfixは完全にあなたのマシン上で実行されます。一度セットアップすれば、ビルドとテストはネットワークオフで実行されます。

質問

よくある質問

Unfixとは何ですか？

Unfixは、C、C++、ファームウェアのバグ修正のための独立した検証ツールです。コードを記述しません。開発者またはAIコーディングエージェントによって書かれた修正が、本当にバグを解消しているかを確認し、VERIFIED、REJECTED、またはNOT VERIFIABLE（証拠が判断できない場合）を返します。

Unfixはどのように修正を検証しますか？

ベースバージョンでバグを再現し（毎回失敗しなければなりません）、修正を適用してSanitizersでテストを再実行し、他のテストがまだパスすることを確認してから、修正を削除してバグが戻ってくることを確認します。また、無効化されたSanitizers、弱められたり削除されたテスト、追加された遅延などのマスキングを検出するためにdiffをスキャンします。

なぜ「unfix」なのですか？

修正が機能する最も強力な証明は、それを再び取り外すことだからです：修正を削除したときにバグが戻ってこない場合、そのテストは何の証明にもなりませんでした。

Unfixは判定にLLMを使用しますか？

いいえ。判定はビルド、テスト、Sanitizers、ハードウェア実行から得られます。決定論的なルール、判定にLLMは使用しません。不安定なバグや競合バグは、繰り返し実行によって判断され、単一のパスではありません。

ファームウェアや実際のボードでも動作しますか？

はい。Unfixはファームウェアをビルドし、実際のボード（現在はST-Link経由のSTM32 NUCLEO）にフラッシュし、ハードウェア上でテストを実行できます。/checkは、あなたのリグ上でテストごとの判定を提供します：FIXED（変更前に失敗し、現在はパス）、BROKEN（変更前にパスし、変更で失敗）、FLAKY ON THE BENCH（変更がなくても不安定です。結果を信頼する前にリグを修正してください）、FLAKY, WORSE（以前は不安定で、変更で著しく悪化しました）。単一のバグ修正の場合、/fixは1つの判定：VERIFIED、REJECTED、またはNOT VERIFIABLEを下します。

Unfixはどこで実行されますか？

Claude CodeやCodexなどのAIコーディングエージェント内のMCPツールとして、判定をコメントとして投稿するGitHubプルリクエストチェックとして（デモリポジトリに表示されています。パートナーリポジトリではまだ利用できません）、ターミナルで、そしてあなたのハードウェアリグ上で実行されます。クローズドネットワーク向けに構築されています。クラウドなし、LLMなし — Unfixは完全にあなたのマシン上で実行されます。一度セットアップすれば、ビルドとテストはネットワークオフで実行されます。

公開ベンチマークは何を示しましたか？

オープンソースプロジェクト（fmt、spdlog、zlib-ng、cpp-peglib）からの実際のバグに対して、10件のAI生成C/C++パッチをテストしました。メンテナー自身の隠された参照テストに対して評価した結果、Unfixは4件を検証し、6件を却下しました。

Unfixは誰向けですか？

約20〜200人のエンジニアがいるC/C++および組み込みチーム、特に「エージェントが言った」が受け入れられないmedtechなどの規制対象製品を扱うチーム向けです。

デザインパートナープログラム

実際のバグを1つ持ち込んでください。あなたと一緒に修正を検証します。

私たちは、少数のC/C++および組み込みチーム（20〜200人のエンジニア）と協力して、Unfixを彼ら自身のコードとハードウェアで実行しています。