最初に、見る範囲を決める

scanの入口はScannerクラス。対象パスを絶対パスへ直し、配下のファイルを集め、stackを判定してから、登録済みのcheckを順番に実行する。派手な仕組みではないけど、この順番を固定することが大事だった。

探索時は.git、node_modules、.venv、.terraform、distなどを除外し、ディレクトリ名とファイル名をsortする。シンボリックリンクも追わない。巨大な生成物へ入り込んだり、環境によってレポート順が変わったりするのを避けるためだ。

stack判定は、いま分かるものだけ

Pythonはpyproject.toml、requirements.txt、または.pyファイル。Terraformは.tfファイル。GitHub Actionsは.github/workflows直下のYAML。この3系統だけを、現在の実装ではstackとして判定する。

READMEに将来対応と書いてあるNode.js、Go、Rust、Dockerなどは、まだ検出しない。対応範囲を広く見せるより、実際にcheckとテストが揃っているものだけ返す。

レポートは機械にも人にも読める形にする

YAMLレポートの先頭はschema_version、tool、project、summary、checksの5項目。日時を入れないので、同じリポジトリを同じ環境でscanしたとき、不要な差分が出にくい。

failed checkが見つかっても、診断そのものは正常終了として扱う。コマンドの使い方、対象パス、レポート書き込みなどが壊れた場合だけ、エラー用の終了コードを返す。悪い点数とツールの故障を混ぜないためだ。

scanとレポート出力
harness-baby scan .

# 出力先を変える場合
harness-baby scan /path/to/repository --output /tmp/report.yaml

100点の意味を大きくしすぎない

MVPの採点は単純で、passは1、warnは0.5、failは0。skipは分母から外す。checkごとの重みはすべて1だけど、採点関数自体は明示的なweightを受け取れる。

つまり100点は、登録されているcheckがすべてpassしたという意味でしかない。セキュリティ監査済みでも、本番投入可能でも、自律実行して安全でもない。この点数だけで安全性を判断しない。

Terraformを実行しない理由

Terraformの状態確認でinitやvalidateを自動実行すると、providerの取得やlock fileの更新など、診断の外側まで影響が広がることがある。Harness Babyは.tfファイルや設定、実行ファイルの有無を観察するだけで、Terraformコマンドは動かさない。

自動で直してくれる便利さより、何も変えていないと説明できることを優先した。この制約は地味だけど、エージェントへ渡す最初の診断道具としては外せなかった。