🏯

CoDD（整合性駆動開発）— コード0行・スマホだけで、設計書が腐らないOSSを作った話

2026/04/14に公開

1件

!このシリーズが初めての方はこちらから
https://zenn.dev/shio_shoppaize/articles/5fee11d03a11a1
https://github.com/yohey-w/codd-dev
シリーズ一覧:
#0 整合性駆動開発CoDD爆誕
#1 spec → 設計書 → コード
#2 コード → 設計書
#3 リバース設計書で+30%
#4 放置で93%直る自律ループ
#5 寝て起きたら73件全部直ってた

整合性駆動と名乗ってたCoDDが、実は『検知して終わり族』だった件 (Coherence Engine) ← 自己批判+改修
!📅 2026-05-05 加筆 (GW中の進化を反映): 元記事は2026-04-14時点のスナップショット。GW中に CoDD は v1.16.0 stable + Coherence Engine 等で大幅進化したため、開発記録テーブル / 主要コマンド一覧 / TODO セクションを更新しました。本文の論考自体は元のままです。

 結論から言うSDD（Spec-Driven Development）系のツールを全部調べた。

spec-kit — 87,862スター

BMAD-METHOD — 44,575スター

OpenSpec — 39,843スター

cc-sdd — 3,096スター

Kiro — AWS製、プロプラIDE
全部、設計書を作るところで止まっている。上流が変わったとき、下流の設計書を自動で追従させるツールが1個もない。 8.7万スターもらって？ マジで？
唯一の例外はAugment社のIntent。リアルタイム双方向同期。ただしプロプラ、macOS限定、サブスク必要。金を払ってベンダーロックインされたい人向け。
OSSで、CLI一本で、どのAIでも動いて、設計書の変更伝搬までやるのはCoDD（Coherence-Driven Development / 整合性駆動開発）だけだった。30日で作った。127コミット。16,101行。SWE-bench 73問100%。ソースコードは1行も書いてない。スマホから音声で指示しただけ。
これはハーネスエンジニアリングの1つの到達点だと思っている。

 2026年、SDDは爆発した2026年はSpec-Driven Developmentの年だった。
Mitchell Hashimoto（HashiCorp/Ghostty作者）が2月に「エージェントは簡単。ハーネスが難しい」と書いた。Birgitta Böckelerがmartinfowler.comでAgent = Model + Harnessのフレームワークを4月に出した。OpenAIは「1Mラインのプロダクションコードを人間のコードゼロで作った」と言い出した。
Prompt Engineering（2023年）→ Context Engineering（2025年）→ Harness Engineering（2026年）。
「AIへの頼み方」から「AIの周りに組む配管」へ。そしてその配管の中で最も注目されたのが「設計書でAIを制御する」というSDDのアプローチだった。
ツールも雨後の筍のように生えてきた。GitHubのスター数だけは立派なやつが。

 全部調べた — SDD系ツール比較

ツール
スター
何をするか
変更伝搬
既存コード対応
マルチAI


spec-kit
87,862
CLI型SDD。要件→設計→タスクを生成
なし
なし
Copilot, Claude, Gemini, Cursor

BMAD
44,575
21+のペルソナエージェントによるSDD
なし
なし
Claude, Cursor, Copilot

OpenSpec
39,843
ADDED/MODIFIED/REMOVEDのデルタマーカーで差分追跡
追跡のみ
なし
20+ツール対応

cc-sdd
3,096
Kiro風の要件→設計→タスク。TDDループ付き
なし
なし
Claude, Codex, Cursor等

Kiro
N/A
AWS製IDE。EARS記法で要件定義
なし
なし
Claude内蔵のみ

Intent
N/A
リアルタイム双方向spec-code同期
あり
あり
Augment限定(macOS)

Tessl
N/A

$125M調達。spec-as-source
探索中
不明
プロプラ

CoDD
—
依存グラフ＋AI生成＋変更伝搬＋バグ自動修正
あり
あり
任意のAI

※ 公平に言うと、spec-kitやBMADは「設計書生成フレームワーク」であり、CoDDは「設計書ライフサイクル管理ツール」だ。目的が違う。spec-kitは設計書を作ることに特化していて、それは上手にやる。ただ、作った後どうするの？ という問いに答えるツールがこの中にほとんどない、というのがこの表の要点。

 見えてくるパターン8.7万スターのspec-kitも、4.4万のBMADも、やっていることの本質は同じだ。要件を書く → 設計書を生成する → タスクに分解する → コードを書く。
ここまではいい。きれいだよね。デモ映えするよね。
問題はその後。1週間経った。要件が変わった。コードを修正した。設計書を書き直す必要がある。誰が直す？ お前が手で直すの？
spec-kitは答えない。BMADも答えない。OpenSpecはデルタマーカーで「ここが変わった」と教えてくれるけど、自分では直してくれない。「変わったよ！」って報告だけして帰る新人かよ。Kiroは設計書を一回作ったら固定。cc-sddも同じ。
Birgitta Böckelerはmartinfowler.comのSDD分析記事でこう書いている:
ほとんどのSDDツールは「spec-first only, with unclear maintenance strategies」
作ったら終わり。 8.7万スターの正体は「設計書メーカー」。メンテナンス？ 知らんがな、ってこと。
もう一つ致命的な問題がある。こいつらの大半はグリーンフィールド（新規プロジェクト）しか対応していない。 要件を書いて、設計書を生成して、ゼロからコードを書く。きれいな流れだ。カンファレンスのデモにはぴったり。
で、聞きたいんだけど、君たち1年に何回まったく新しいプロジェクトを立ち上げる？
君たちが一番時間を費やしているのは、レガシーコードの障害対応とエンハンスだろ？ 設計書なんかとっくに腐ってるか、そもそも存在しないコードベースを相手に、バグを直し、機能を足し、リファクタリングする。それが現実の開発の99%だ。
spec-kitもBMADも、既存コードから設計書を自動逆生成する機能を持っていない。テンプレートを手動で埋めれば使えなくはないが、1000ファイルのレガシーコードベースのテンプレートを手で書く？ それもう本末転倒では。既存コードへの自動対応がないSDDツールは、現場の99%で使えない。
CoDDの codd extract は既存コードベースから設計書を自動復元する。ブラウンフィールドに後から設計書を被せられる。新規も既存も両方いける。

 「SDDはMarkdownのウォーターフォール」問題Birgitta Böckelerはmartinfowler.comで、SDDがMDD（Model-Driven Development）の失敗を繰り返すリスクを指摘している——「非柔軟性と非決定性の組み合わせ」。2026年4月時点でこの懸念は業界内で繰り返し語られている。仕様を先に書いてからコードを書く——ウォーターフォールと同じ構造。マークダウンに書いたところで、仕様と実装が乖離する問題は何も解決していない、と。
この批判、半分正しい。
SDDツールの大半は設計書を「作る」フェーズにだけ注力している。作った設計書が1週間後に腐る問題を解決していない。だからウォーターフォールと同じ批判が当たる。8.7万スターのツールにこの批判が刺さるの、なかなかエグい。
でも「設計書が腐る」のは設計書が悪いんじゃなくて、腐らせない仕組みがないからだ。包丁が錆びるのは包丁のせいじゃない。研がないやつのせいだ。じゃあ自動で研ぐ仕組みを作ればいい。

 CoDDの答え — 設計書を依存グラフで繋ぐCoDDのアプローチは単純だ。
これが実際の codd scan の出力。スマホから撮った。


設計書7本、依存エッジ15本。これが「設計書の関係図」。
設計書のフロントマターに依存関係を宣言する:
---
codd:
  node_id: "design:api-design"
  depends_on:
    - id: "design:system-design"
      relation: derives_from
    - id: "req:requirements"
      relation: implements
---
codd scan で全設計書をスキャンすると、依存グラフが構築される。要件Aが変わったら codd impact が「設計書B・C・Dが影響を受ける」と教えてくれる。


要件1本変えたら設計書4本がGreen（自動更新OK）、テスト1本がAmber（人間確認）。これが変更伝搬。
codd propagate --update で下流の設計書をAIが自動更新する。
要件変更 → codd impact → 影響範囲を特定（6本中5本が影響）
         → codd propagate → AIが下流設計書を自動更新
コード変更 → codd fix → テスト失敗を検知 → AIが自動修正
設計書が腐らない。 上流が変わったら下流が自動で追従するから。
これが「Markdownのウォーターフォール」批判への答えだ。設計書が静的だからウォーターフォールになる。設計書を依存グラフで繋いで動的にすれば、アジャイルと共存する。

 SWE-bench — モデル単体 vs ハーネス込みSWE-bench Verifiedを知らない人に軽く説明しとく。GitHubの実プロジェクト（Django, sympy, matplotlibなど）から集めた実際のバグ報告500問をAIに渡して、「このバグ直せ」と言ってPRを作らせるベンチマーク。人間が手作業で検証済みの500問（Verified）なのでテスト品質が高く、AIコーディング能力の業界標準指標になっている。AnthropicもOpenAIもGoogleもこれでモデル性能を競っている。
SWE-bench Verifiedのリーダーボード（2026年4月）:


順位
モデル
スコア


1
Claude Mythos Preview
93.9%

2
Claude Opus 4.5
80.9%

3
Claude Opus 4.6
80.8%

4
Gemini 3.1 Pro
80.6%

これはモデル単体のスコアだ。ハーネスなし。AIにバグレポートとリポジトリを渡して「直して」と丸投げした結果。
上のリーダーボードは500問の全問ベンチマークのスコア。CoDDの73問は、信頼水準95%・許容誤差±10%で統計的に意味のあるサンプルサイズとして選んだ73問で検証した結果だ（詳細は#5）。73問のうちモデル単体で解けない難問を含み、それを100%解いている。
CoDDの73問100%は、Opus 4.6（単体80.8%）に以下を組み合わせた結果:

CoDD extract設計書 — モジュールの構造地図（#3で+30%）

テストフィードバック＋リトライ — 失敗→修正→再テスト（#4で93%）

診断推論＋Session State — 考えてから動く＋記憶（#5で100%）
モデル単体80.8%が、ハーネスを組んだら100%になった。ハーネスが20ポイント押し上げた。
LangChainも同じ現象を報告している。Terminal Bench 2.0でモデルを変えずにハーネスだけ変えたら、トップ30圏外からトップ5に入った。
ハーネスがプロダクト。モデルは部品。 ——これが2026年の結論だ。

 Harness as Code — 造語だけど聞いてくれInfrastructure as Code（Terraform）、Policy as Code（OPA）、Pipeline as Code（GitHub Actions）——「手作業でやっていたものをコードで宣言する」パターンは何度も繰り返されてきた。
2026年、Hashimotoが「ハーネスエンジニアリング」を提唱し、BöckelerがAgent = Model + Harnessのフレームワークを整備した。「AIの周りに組む配管」の重要性は認知された。でもその配管をどう表現するかは未定義のまま。
IaCは状態を宣言する。「このサーバーはこのスペックで存在すべき」と書けば、Terraformが現実を合わせに行く。
CoDDも同じ構造を持っている。設計書のフロントマター（node_id, depends_on）が状態宣言。「この設計書はこの依存関係で存在すべき」と書けば、CoDDが整合性を合わせに行く。そしてCLIコマンド群——extract → scan → impact → propagate → fix——がプロセスの宣言。組み合わせればシェルスクリプト1本でハーネスが組める。CIに載せれば自動で回る。バージョン管理できる。再現性がある。テストできる。
これをHarness as Codeと呼ぶことにした。


パラダイム
宣言するもの
ランタイム


Infrastructure as Code
インフラの状態
Terraform / Pulumi

Policy as Code
セキュリティルール
OPA / Rego

Pipeline as Code
CI/CDワークフロー
GitHub Actions

Harness as Code
AI制御の配管（依存グラフ＋プロセス）
CoDD CLI

以前の記事で「ハーネスエンジニアリング、それGit Workflowをbashで書き直してるだけでは」と書いた。hookを設定して、CLAUDE.mdにルールを書いて、linterを繋ぐ。これは「エンジニアリング」じゃなくて「セットアップ」だと。
CoDDはその先を行く。実際のパイプラインはこれだけ:
codd extract .                # 既存コードから設計書を復元
codd scan docs/               # 依存グラフを構築
codd impact --changed HEAD~1  # 直近の変更の影響範囲を特定
codd propagate --update       # 影響を受けた設計書を自動更新
codd fix                      # テスト失敗を自動修正
ただのシェルスクリプトだ。そう、それでいい。 ハーネスエンジニアリングはbashで書き直すところから始まる。でもbashスクリプトの中身が「hookの設定」と「Git Workflowの移植」で終わるなら、それはセットアップだ。CoDDのパイプラインは「設計書の依存グラフに基づいて変更を自動伝搬する」——Git Workflowに対応物がない。Terraformがインフラをコードで宣言するように、CoDDはAIハーネスをコードで宣言する。
ハーネスエンジニアリングは「何を組むか」を教えてくれる。Harness as Codeは「どう表現するか」の答えだ。
面白いことに、CoDDを作るのに使ったmulti-agent-shogun（Claude Code 5台を将軍・家老・足軽で回すマルチエージェントシステム）が、システム開発のハーネスとしてはもう要らなくなった。CoDD自体がHarness as Codeだから。CLIコマンドの組み合わせだけでハーネスが完成する。マルチエージェントの複雑なオーケストレーションは要らない。
ただしshogunが不要になったわけじゃない。AIが作るのはシステム開発だけじゃない——SEO記事、ブログ執筆、プロジェクト管理、データ分析。汎用ナレッジワークのオーケストレーションはCoDDの範囲外。CoDDは配管の設計図。shogunは配管工の組織。 仕事が違う。

 50日で23,848行 — CoDDの開発記録 (2026-05-05時点)

指標
数字


開発期間
50日強（2026/3/15 → 5/5）

コミット数
183

バージョン数
27（v0.2.0a2 → v1.16.0 stable）

Pythonコード行数
23,848

コマンド数

28 (deploy / e2e-generate / fixup-drift / coverage 等を新規追加)

SWE-benchスコア
73/73 = 100% (Verified)

Zenn記事
8本（#0〜#5 + Coherence Engine + 業界マップ）

人間が書いたソースコード
0行

GW中の主要追加 (4/14以降):
v1.11.0: Filesystem-Routing Aware Drift Detection (Next.js/SvelteKit/Nuxt/Astro/Remix対応)
v1.12.0: Meta-Design Context Layer (project_lexicon.yaml)
v1.13.0: DESIGN.md統合 (Google Stitch OSS / W3C Design Tokens)
v1.14.0: codd implement Batch guard (--max-tasks/--wave)
v1.15.0: E2Eテスト自動生成 (codd e2e-generate, Playwright/Cypress対応)
v1.16.0: Coherence Engine (中央ハブ + fixup-drift + 3 Fix Strategies)
そしてなにより、オレはソースコードを1行も書いていない。
マジで0行だ。フロントマターもYAML設定もClaude Codeが書いた。キーボードで打ったコードは1行もない。
CoDDはスマホのClaude Codeアプリから作っている。通勤電車の中で音声入力して、Claudeと概念を議論して、「これやって」と指示を出す。Claudeがコードを書いて、テストを回して、コミットする。


これがCoDDの開発環境。スマホ1台。この記事もここから書いてる。
16,101行のPythonコード、127コミット、SWE-bench 73問100%。全部、概念の議論とAIへの指示だけで出来上がった。これがハーネスエンジニアリングの意味だ。コードを書く人じゃなくて、AIにコードを書かせる配管を設計する人。 それが2026年のエンジニアの仕事になる。
ソースコード0行でOSS作れました、めでたしめでたし——で終わるわけない。
30日間、順調だったわけがない。#3のSWE-bench実験で「AIの分析結果を設計書に書いて渡したら精度が上がるだろう」と思って試したら、逆に下がった。答えを教えたらAIは考えるのをやめた。「お前がそう言うならそうなんだろう」モード。3日かけて作った分析テンプレート、全部捨てた。構造地図（モジュールの関係だけ）に切り替えたら+30%。答えじゃなくて地図を渡せ——これがCoDDの設計思想の核になった。失敗しなかったら辿り着かなかった。
あとmulti-agent-shogunはClaude Max x20を2アカウント体制で回している。レートリミットに引っかかったらアカウントを切り替えて続行する。タダではない。
骨格は完成した。でも肉はまだ付いてない。これは30日の成果物であって、完成品ではない。できてないことは下のTODOに正直に書いた。
ちなみにCoDDの開発にCoDDを使っている。codd extract で自分のコードベースから設計書を逆生成し、codd scan でグラフを構築し、codd verify でテストを回す。バグが出たら codd fix が勝手に直す。自分で自分を管理できないツールは他人のプロジェクトも管理できない。

 CoDDにできること / できないこと
 できること (2026-05-05更新)

やりたいこと
コマンド


要件から設計書を自動生成
codd generate

既存コードから設計書を逆生成
codd extract

設計書の依存グラフ構築
codd scan

変更影響分析
codd impact

コード変更→設計書を自動更新

codd propagate (v1.16.0で --coherence 追加)

設計書からコード自動生成

codd implement (v1.14.0で batch guard 追加)


DESIGN.md統合 (W3C Design Tokens)

codd validate --design-tokens (v1.13.0新規)

E2Eテスト自動生成

codd e2e-generate (Playwright/Cypress, v1.15.0新規)


drift検知 → 自動修復 (整合性駆動の核)

codd fixup-drift (v1.16.0新規)


デプロイ (VPS/Azure等)

codd deploy (v1.17.0新規)

全体カバレッジゲート (E2E/design-token/lexicon)

codd coverage (v1.16.0新規)

テスト/ビルド失敗の自動修正

codd fix (v1.16.0で Coherence-mode追加)

プロジェクト健全性スコア
codd measure

CI連携（GitHub Action）
yohey-w/codd-dev@main


 正直にまだ足りないこと — TODO (2026-05-05更新)GW中の進化で消化したものに ✅ を付け、残るTODOを再掲。
⏳ 生成ドキュメントの精度向上: AI出力の品質はモデル次第。特にLLMがMarkdownの見出し構造を崩すことがある
⏳ もっと乱雑なブラウンフィールド対応: codd extract は動くが、設計書18本のプロジェクトが最大。100モジュール規模は未検証
⏳ 変更頻度ベースの優先抽出: 障害が多いモジュール・変更が多いファイルから優先的に extract する仕組み
✅ UI/画面設計レイヤー → v1.13.0 で DESIGN.md統合 (W3C Design Tokens spec) 完了。codd extract --layer routes で screen-flow.md 自動生成、codd validate --design-tokens で UI 整合性チェック可
⏳ 増分更新: コード変更時に変更されたモジュールの近傍だけ再抽出する仕組み
✅ implementerの柔軟化 → v1.14.0 で codd implement --max-tasks/--wave 追加、部分適用しやすくなった
✅ 依存グラフの可視化 → codd extract --layer routes --format mermaid で Mermaid出力対応
⏳ 要件の逆推定: 構造事実から「このシステムは何のために作られたか」を AI に推定させる
✅ E2Eテスト自動生成 (元記事執筆時には未存在のTODO) → v1.15.0 で codd e2e-generate 完成
✅ drift検知 → 自動修復の配管 → v1.16.0 で Coherence Engine + codd fixup-drift 完成 (詳細)
✅ デプロイ統合 → v1.17.0 で codd deploy 追加
⏳ 本番運用実証: LMSをCoDDだけで本番Azure稼働させる実証実験 進行中 (記事化予定)

 ここからの問い — 3つCoDDの骨格は完成した。次に解くべき問いが見えている。

 1. ブラウンフィールドはどこまで汚くても通るのかcodd extract は設計書18本のプロジェクトで動いた。じゃあ設計書なし・テストなし・ドキュメントなし、ファイル数1000のカオスなレガシーコードベースでは？ 骨格があるなら、そこに一番汚い肉を載せてみるのが次の実験だ。

 2. SWE-bench 500問全問で何%出るか73問100%はサブセット。全500問を回せば、ハーネスの限界が見える。CoDDが解けない問題の共通パターンがわかれば、次のハーネス改善の方向が決まる。金はかかるが、やらないと説得力が頭打ちになる。

 3. Harness as Codeは他のドメインに拡張できるかCoDDはソフトウェア設計書のハーネスだ。でも「依存グラフで状態を宣言し、変更を自動伝搬する」構造は、設計書以外にも使えるかもしれない。法務ドキュメント、API仕様、インフラ構成図——上流が変わったら下流を自動で直す需要は設計書だけじゃない。

 で、あなたの設計書はまだ生きてる？spec-kitで作った設計書、先週の要件変更に追従してますか。BMADで生成した設計、今日のコードと一致してますか。
してないでしょ。 してるわけない。みんなそう。設計書は書いた日が命日。8.7万スターのツールで作ろうが、手書きだろうが、腐るスピードは同じ。
CoDDは設計書を生き返らせるためのツールだ。書いた日だけじゃなく、変わった日にも意味を持つ設計書。依存グラフで下流を自動追従する設計書。AIが読んでバグを直す材料になる設計書。
「SDDはMarkdownのウォーターフォール」？ 設計書が静的ならそうなる。動的にすればいい。 それがCoDDの答えだ。
GitHub
https://github.com/yohey-w/multi-agent-shogun
CoDD
https://github.com/yohey-w/codd-dev
30日、127コミット、16,101行、ソースコード0行。SWE-bench 73問100%。設計書を作るだけのツールは8.7万スターもらえる。設計書を維持するツールはまだ誰も作っていなかった。だからスマホから作った。骨格は完成した。次は500問全問と、一番汚いレガシーコードベースで試す。
ところで。
Harness as Codeって要するに「自分の頭の中にある配管設計を、AIが読めるテキストに落とす」作業だ。フロントマター書くのも、プロンプト設計するのも、禁止ルール並べるのも、全部「考えてることを構造化して言語化する」行為。
コード書かなくていい時代になると、思考を言語化する能力が一番効いてくる。AIへの指示の精度 = 自分の思考の精度、そのまま。
その辺の話を体系的に書いた本があるので、興味あれば。
https://zenn.dev/shio_shoppaize/books/ai-mentoring-thinking

ツール	スター	何をするか	変更伝搬	既存コード対応	マルチAI
spec-kit	87,862	CLI型SDD。要件→設計→タスクを生成	なし	なし	Copilot, Claude, Gemini, Cursor
BMAD	44,575	21+のペルソナエージェントによるSDD	なし	なし	Claude, Cursor, Copilot
OpenSpec	39,843	ADDED/MODIFIED/REMOVEDのデルタマーカーで差分追跡	追跡のみ	なし	20+ツール対応
cc-sdd	3,096	Kiro風の要件→設計→タスク。TDDループ付き	なし	なし	Claude, Codex, Cursor等
Kiro	N/A	AWS製IDE。EARS記法で要件定義	なし	なし	Claude内蔵のみ
Intent	N/A	リアルタイム双方向spec-code同期	あり	あり	Augment限定(macOS)
Tessl	N/A	$125M調達。spec-as-source	探索中	不明	プロプラ
CoDD	—	依存グラフ＋AI生成＋変更伝搬＋バグ自動修正	あり	あり	任意のAI

順位	モデル	スコア
1	Claude Mythos Preview	93.9%
2	Claude Opus 4.5	80.9%
3	Claude Opus 4.6	80.8%
4	Gemini 3.1 Pro	80.6%

パラダイム	宣言するもの	ランタイム
Infrastructure as Code	インフラの状態	Terraform / Pulumi
Policy as Code	セキュリティルール	OPA / Rego
Pipeline as Code	CI/CDワークフロー	GitHub Actions
Harness as Code	AI制御の配管（依存グラフ＋プロセス）	CoDD CLI

指標	数字
開発期間	50日強（2026/3/15 → 5/5）
コミット数	183
バージョン数	27（v0.2.0a2 → v1.16.0 stable）
Pythonコード行数	23,848
コマンド数	28 (deploy / e2e-generate / fixup-drift / coverage 等を新規追加)
SWE-benchスコア	73/73 = 100% (Verified)
Zenn記事	8本（#0〜#5 + Coherence Engine + 業界マップ）
人間が書いたソースコード	0行

やりたいこと	コマンド
要件から設計書を自動生成	`codd generate`
既存コードから設計書を逆生成	`codd extract`
設計書の依存グラフ構築	`codd scan`
変更影響分析	`codd impact`
コード変更→設計書を自動更新	`codd propagate` (v1.16.0で `--coherence` 追加)
設計書からコード自動生成	`codd implement` (v1.14.0で batch guard 追加)
DESIGN.md統合 (W3C Design Tokens)	`codd validate --design-tokens` (v1.13.0新規)
E2Eテスト自動生成	`codd e2e-generate` (Playwright/Cypress, v1.15.0新規)
drift検知 → 自動修復 (整合性駆動の核)	`codd fixup-drift` (v1.16.0新規)
デプロイ (VPS/Azure等)	`codd deploy` (v1.17.0新規)
全体カバレッジゲート (E2E/design-token/lexicon)	`codd coverage` (v1.16.0新規)
テスト/ビルド失敗の自動修正	`codd fix` (v1.16.0で Coherence-mode追加)
プロジェクト健全性スコア	`codd measure`
CI連携（GitHub Action）	`yohey-w/codd-dev@main`

Discussion

ゆーけ

Gemini CLIでCoDDコマンドを実行したいのですが、対応可能でしょうか？こいつだけヘッドレスモードの文化が違うようなので…