dev-agent-teamシリーズの9本目。 前回（人間の承認ゲートを「約束」から「仕組み」へ）で、 本体の新機能7件を取り込んだ。 機能を足し続けると、今度はドキュメント同士の綻びが溜まる。 今回はそれを、自作の検証ワークフローに掃除させた話。
- 自作の
dev-agent-team-evolveワークフローをキット自身に向けた（ドッグフーディング） - 参照ズレ・保存先ポリシー違反・記法揺れなど、計17項目の不整合を掃除
- 40項目超に肥大したCHANGELOGを整理し、v0.2.0を切ってピン留め機構を復活させた
機能を足すたびに、ドキュメントには小さな綻びが溜まっていく。 「Aにはこう書いてあるのに、Bでは違う番号を参照している」 「保存先の規約が、実装と食い違っている」—— こういう不整合は、単体では致命傷にならないぶん、放置されやすい。
今回は、この綻びを人力で探す代わりに、自作の検証ワークフローに探させた。
使ったのは dev-agent-team-evolve——
7つのサブシステムを並列で読解し、提案ごとに敵対的検証をかけるワークフローだ。
自分の道具を自分に向ける、いわゆるドッグフーディングである。
1. 検証を通過した不整合だけを直す（PR #20）
PR #20 では、 evolveが検出した候補のうち検証を通過したfix 3件＋improvement 1件を反映した。 検出されても検証で落ちたものは直さない——ここも敵対的検証の役目だ。
- 保存先ポリシー違反（検出時 severity: high） ——
/issue-to-planの計画ファイルが、Git管理領域に直接保存される設計になっていた。 これをRun単位のディレクトリ（.dev-agent-team/runs/{issue-id}/）へ移し、 ファイル名まで既存ワークフローの規約に揃えた。 - 相互参照の不整合 5箇所 —— 発火Phaseの一覧からPhase 4（ゴール定義の人間承認）が漏れていたのが代表例。 人間判断のPhaseが発火表から抜けているのは、この型では見過ごせない。
- 配布テンプレートの整合 ——
コピー先で必ず壊れる相対リンクを絶対パスに、
テンプレ変数記法（
{{issue-id}}）と実行時の値の書き分けを統一。
「3ファイル指定が21エージェントに膨張した」あの回と同じで、綻びは実際に読み合わせて初めて見える。evolveは7サブシステムを横断で読むから、1ファイルだけ見ていては気づけないズレを拾える。
2. 低優先の残バッチも一気に（PR #24）
PR #24 では、 検出済みだった低〜中優先の残り13項目をまとめて掃除した。 構成規則の追記、孤立していたドキュメントへの導線、 6つのagentへのStop Condition節の追加（内容は複製せず、対応Phaseへの参照1行に統一）などだ。
実装は下位ティア・低effortのエージェントに委譲し、差分は人間側でレビューした
（この「層別配分」自体が次回の記事のテーマになる）。
掃除の中で構造的に効いたのが manifest.sh への一本化だ。
Before
- COMMANDS/WORKFLOWS配列を
install.sh・uninstall.sh双方に記述 - 片方だけ更新して非対称化するリスク
After
- 配列を
manifest.shに一本化 - install/uninstall両方がsource
- ズレようがない構造にした
ここでも「ついでに直す」の誘惑は断った。 今回の指定対象外だった実行時パスの記法揺れ（計13箇所）はあえて残し、 「次バッチ候補」としてPR本文に明記した。スコープを広げないのも型のうちだ。
3. リリースを切る＝ピン留め機構を復活させる（PR #23）
掃除と並行して、もう一つ根の深い問題を片付けた。
CHANGELOG.md の [Unreleased] が40項目超に肥大し、
一方で version.txt は v0.1.0のままだった。
これは見た目以上に効く不具合だった。
/adopt-project のSemVer比較や、min_version によるStop Condition
（バージョンをピン留めして「この版以上でないと動かさない」を担保する機構）は、
version.txtが更新されていて初めて機能する。
リリースを切らずに機能だけ足し続けた結果、ピン留め機構が実質的に空回りしていた。
PR #23 で
[Unreleased] を [v0.2.0] に確定し、
version.txt を v0.2.0 へ上げた。
native-tooling統合・Migrationサブフロー・adopt-project本実装・新機能取り込み第1/2弾を含むので、
minor bumpが妥当という判断だ。
タグ付け（git tag v0.2.0）はマージ後の人間ステップ——リリースそのものがHuman Decision Pointだ。タグがないとCHANGELOGのcompareリンクも /adopt-project の更新動線も成立しない。ここは自動化せず、人間が切る。
4. まとめ——道具を自分に向ける
今回は新機能の回ではなく、溜まった綻びを掃除し、リリースの規律を取り戻した回だ。
- 自作の検証ワークフローを自分自身に向けると、放置していた不整合が可視化される
- 横断で読むから、1ファイルでは気づけない参照ズレ・ポリシー違反を拾える
- 検出しても検証で落ちたものは直さない——直す対象も敵対的に絞る
- 「リリースを切る」ことがバージョンピン留め機構の成立条件だった
検証ワークフローは、他人のコードをレビューするためだけのものではない。 自分の道具を自分に向けると、機能追加の裏で静かに溜まっていた負債が表に出る。 そして掃除の実装を「下位ティア・低effortのエージェント」に任せられたのは、 次回書く層別配分——判断を上流に集約する設計——があったからだ。
リポジトリはこちら: fecot/dev-agent-team