自分のrepoなら満点で当然、ではない

Harness Babyは、README、AGENTS.md、テスト、lint、CI、秘密らしき値などを見て、コーディングエージェントへ渡す準備があるかをYAMLへ出すCLIだ。これまでは仕組みの説明を書いていたけど、実際の出力を記事に載せていなかった。

そこで2026年9月17日、Harness Babyのリポジトリを、Harness Baby自身でscanした。対象は作業中のコピーではなく、変更のないcheckout。レポートだけを一時ディレクトリへ出し、scan後にgit statusが空のままかも確認した。

自分自身をscanする
harness-baby scan . --output /tmp/self-scan.yaml

結果は9 pass、1 skip、100点

検出されたstackはPythonとGitHub Actions。repository、documentation、agent context、testing、linting、formatting、CI、security、reproducibilityの9項目がpassした。Terraform stackはなかったのでvalidationはskip。warnとfailは0だった。

skipは採点の分母から外れる。だから100点は、登録済みの適用可能なcheckが全部passしたという意味だ。Terraformを使っていないrepoへ、Terraformの設定がないという減点はしない。

2026-09-17のscan結果
Repository         PASS
Documentation      PASS
Agent Context      PASS
Testing            PASS
Linting            PASS
Formatting         PASS
Validation         SKIP
Ci                 PASS
Security           PASS
Reproducibility    PASS

Score: 100/100

何を見てpassにしたのか

数字だけでは、次に何を直せばいいか分からない。今回のYAMLでは、licenseはLICENSE、READMEはREADME.md、agent contextはAGENTS.mdを証拠として記録した。testingはpytestと4つのtest file、lintingはruffとmypy、reproducibilityはuv.lockを見つけている。

CIについてはworkflowがあるだけでなく、test stepとlint stepを検出した。securityは2つのworkflowを対象に秘密らしき値を探し、potential_hardcoded_secretsは空、secret_values_includedはfalseだった。値そのものをレポートへ出さないのもcheckの一部だ。

YAMLから抜き出した証拠
summary:
  score: 100
  passed: 9
  warned: 0
  failed: 0
  skipped: 1

checks:
  testing:
    status: pass
    evidence:
      frameworks: [pytest]
      test_files:
        - tests/test_bootstrap.py
        - tests/test_cli.py
        - tests/test_scanner.py
        - tests/test_version.py

同じscanを、もう一度やる

1回きれいなYAMLが出ても、毎回順序や時刻が変わるなら差分確認に向かない。同じcheckoutへ、出力先だけ変えてもう一度scanした。2つのreportをSHA-256で比べると、どちらも同じhashになった。

reportには生成時刻を入れず、fileやcheckを安定した順序で並べている。この確認では、同じ入力から同じbyte列が作られた。scan後のgit statusも空で、対象repoのsourceや設定は変わっていなかった。

2つのreportは同じSHA-256
8133b0513df211b5c0bfdd22364ead26f12a9b650ebc64ad1d0ad00228b6ec02  self-scan.yaml
8133b0513df211b5c0bfdd22364ead26f12a9b650ebc64ad1d0ad00228b6ec02  self-scan-second.yaml

scanは、テストを実行していない

ここは勘違いしやすい。testingがpassしたのは、pytestの設定とtest fileを見つけたからで、scanがpytestを動かしたからではない。Harness Babyは外部commandを実行しない。100点だけを見て『テスト成功』とは言えない。

今回は別の確認として、既存の.venvからpytest、ruff、mypyを実行した。pytestは25件pass、mypyは15 source filesで問題なし、ruffのcheckとformatもpassした。最初はruffがcache directoryへ一時fileを作れず止まったので、--no-cacheを付けてやり直した。これはscan結果ではなく、この日に別途実行した検証だ。

  • scan：設定とfileを観察し、証拠をreportへ残す
  • pytest：25件のtestを実際に実行する
  • ruff / mypy：format、lint、型を実際に確認する
  • git status：診断後も対象repoが無変更かを見る

100点で分からないこと

今の採点は、必要なfileや設定が存在するかを中心に見ている。READMEが初参加者に十分か、AGENTS.mdの指示が実際のarchitectureと合っているか、testが重要な事故を防いでいるかまでは深く読まない。

つまり今回の100点は、Harness Baby自身が完璧という証明ではない。現在のschema version 1で確認している範囲を満たし、reportが再現できたという観察結果だ。次に内容の質まで評価するなら、存在checkとは分けて仕様とtestを作る必要がある。

自分で使うと、境界がよく見える

作った道具を説明するだけだと、できることを大きく書きたくなる。自分のrepoへ実行すると、validationがskipになる理由も、100点と実テスト成功が別物なことも、reportのどこを読めばいいかも具体的に見えた。

次に別のrepoをscanするときも、点数だけを見て終わらせない。skipを確認し、evidenceを読み、必要なcommandはそのrepoの手順で実行する。Harness Babyは合否判定の代わりではなく、確認を始める場所を揃える道具として使う。