Public Alphaを公開したあと、何をもって『直った』とするのか――RPRの実機不具合から考える

ソフトウェアの修正は「1行直してCI通った」では終わりません。むしろそこからが本当の検証です。ブログはOSSのバグ修正とリリースを、細かく分解して説明しています。PowerShellで作ったJSONのUTF-8 BOMが読み込めない不具合、修正自体は数文字。しかし、それだけでリリースしたら危険です。

AIの鬼が注目すべき視点は、「直った」を複数の状態に分けることです。修正実装、回帰テスト、元の環境での再確認、全体候補の検証、リリース承認、公開判定、公開後の外部readback。7つの段階がすべて別です。特に面白いのは、検証器自体も間違えるという指摘。CI通ってても、demo側が古いwheel名をhard-codeしていて、実はbrowser側が壊れていた。つまり、CI環境とdemo環境が乖離していたわけです。これを見抜くには、単なるテスト自動化ではなく、「いま事実は何か」を何段階にも分けて観測する必要があります。

中小企業の実務でこれが効くのは、修正や改善を「入れた」と「確認した」で区別することです。特にWindows環境でしか起きない、特定業界の実機でしか再現しない不具合は、CI環境のテストだけ通ってても、お客さんのところで即座に戻ってきます。直したと思ったら別の環境で別の問題が出る、その繰り返しを避けるには、修正の段階を分けて、各段階で環境を変えて確認する必要があります。