Datadog Monitor 探索を Module Runner 化し chargeflow を導入

.cursor/rules/domain-dependency-direction.mdc

@@ -0,0 +1,15 @@
+---
+description: Keep domain packages independent from adapters and concrete modules
+alwaysApply: true
+---
+
+# Domain Dependency Direction
+
+Core domain packages must be depended on by adapters, not depend on adapters.
+
+- Domain packages such as `internal/coverage`, `internal/gate`, `internal/standard`, and `internal/manifest` define stable concepts and invariants.
+- Adapter/orchestration packages such as `internal/charge/*`, `cmd/hado/*`, `modules/*`, and `internal/modulerunner` may depend on domain packages.
+- Domain packages must not import module runner transport types, CLI packages, concrete module wrappers, provider implementations, or executable names.
+- Concrete module/provider registries belong in adapter/orchestration layers, not in domain packages.
+
+Example: `internal/coverage` may define `Measurement` and coverage validation, but must not know about `modulerunner.RunResult`, `modulerunner.Spec`, `hado-gobce`, or `gobce`.

.cursor/rules/hado-implementation-docs.mdc

@@ -1,25 +1,23 @@
 ---
 description: Keep docs in sync when changing HADO behavior (gates, CLI, coverage, manifest)
-globs: cmd/hado/**/*.go,internal/gate/**/*.go,internal/coverage/**/*.go,internal/manifest/**/*.go,internal/standard/**/*.go
+globs: cmd/hado/**/*.go,internal/gate/**/*.go,internal/coverage/**/*.go,internal/manifest/**/*.go,internal/standard/**/*.go,internal/charge/**/*.go,modules/**/*.go
 alwaysApply: false
 ---
 
 # 実装変更とドキュメントの同期
 
-次を編集したら、**同じ変更セット**でドキュメントを更新する。コードだけマージしない。
+**実装の詳細はコードが真実。** ドキュメントには **仕様（`docs/spec/`）と大きな設計（`docs/design/` 等）**だけを残す。
 
-1. **[docs/implementation-status.md](docs/implementation-status.md)**  
-   - 実装済みゲート、`hado evaluate` のフラグ・出力形式、coverage adapter 名、MVP との差分など、**実装の真実**をここに反映する。  
-   - 手書きでよい。更新内容が大きいときは Cursor の Skill **`hado-doc-sync`** を明示的に使ってもよい。
+次を編集したら、**同じ変更セット**で関連ドキュメントを更新する。
 
-2. **ロードマップの「現状」**  
-   - [docs/roadmap.md](docs/roadmap.md) の「このリポジトリの現状」が古くなっていたら、要約を直す（詳細は `implementation-status.md` に寄せてよい）。
+## 更新の優先順位
 
-3. **`internal/manifest/types.go` の型を変えた場合**  
-   - [`internal/manifest/field_docs.go`](internal/manifest/field_docs.go) に **YAML パスごとの説明**を追加・更新する（`TestManifestYAMLDocComplete` が不足・余剰キーで失敗する）。  
-   - [`docs/hado.manifest.reference.yaml`](docs/hado.manifest.reference.yaml) を `make gen-manifest-doc` で再生成して同じ PR に含める。
+1. **ドメイン / 横断仕様** — [docs/spec/](docs/spec/) の該当ファイル（例: Observability → `spec/observability.md`、Coverage → `spec/coverage.md`、CLI → `spec/cli.md`、fire 判定 → `spec/evaluation.md`）
+2. **Manifest スキーマ** — `field_docs.go` + **`make gen-manifest-doc`**
+3. **横断 doc** — overview / README / **design/** は **リンク修正のみ**（仕様本文をコピペしない）。`design/` は検討ドラフト。確定した振る舞いは `spec/` へ
 
-4. **README / アーキテクチャ**  
-   - 利用者向けの CLI 説明（ルート [README.md](README.md) や [docs/architecture.md](docs/architecture.md)）が実装と矛盾していたら合わせる。
+## やらないこと
 
-ゲートを `internal/gate/evaluate.go` に追加したら、**必ず** `implementation-status.md` の実装済みゲート一覧と、必要なら `roadmap.md` の Phase 3 記述を更新する。
+- 複数 doc に同じ仕様段落を貼る
+
+Skill **`hado-doc-sync`** を参照。

.cursor/rules/internal-go-packages.mdc

@@ -32,7 +32,7 @@ Prefer **one main concern per file**. If a file grows large, split on boundaries
 
 - `internal/gate` — `types.go`, `evaluate.go`
 - `internal/standard` — `types.go`, `load.go`, `validate.go`
-- `internal/coverage` — `types.go`, `profile.go`, `parse.go`, `specs.go`, `validate.go`
+- `internal/coverage` — `types.go`, `metrics.go`, `validate.go`; pure coverage domain model and validation only
 - `internal/manifest` — `types.go`, `io.go`, `validate.go`, `path.go`, `scaffold.go`, `coverage.go`, `operations.go`, `observability.go`, `infra.go`, `release.go`; reference YAML in `refdoc/`
 - `internal/manifest/refdoc` — `field_docs.go`, `paths.go`, `generate.go` (`Write` for commented reference YAML)
 
@@ -42,4 +42,4 @@ Prefer **one main concern per file**. If a file grows large, split on boundaries
 - Repeat the package comment in multiple `.go` files; keep it in `doc.go` only.
 - Put methods on evidence types in `types.go`; use the matching `<domain>.go` file even when the helper is small.
 
-`internal/integration` may stay **doc-only** if it is intentionally a contract marker with no implementation.
+Domain packages should stay adapter-free; see `domain-dependency-direction.mdc`.

.cursor/skills/hado-doc-sync/SKILL.md

@@ -1,51 +1,39 @@
 ---
 name: hado-doc-sync
 description: >-
-  HADO の実装（gates, CLI, coverage adapters, manifest）を変えたあと、
-  docs/implementation-status.md と関連ドキュメントを実装に合わせて更新する。
-  cmd/hado、internal/gate、internal/coverage、internal/manifest、internal/standard を触ったときに使う。
+  HADO の仕様（docs/spec/*）と manifest スキーマを変えたあと、
+  field_docs / 参考 YAML を実装に合わせて更新する。
+  cmd/hado、internal/gate、internal/charge、internal/manifest、modules を触ったときに使う。
 ---
 
-# HADO 実装とドキュメントの同期
+# HADO 仕様とドキュメントの同期
 
-## いつ使うか
+## 方針
 
-- `cmd/hado`（サブコマンド、フラグ、終了コード、出力形式）
-- `internal/gate`（評価する gate id、`Evaluate` の分岐）
-- `internal/coverage`（adapter 名、`ParseAdapterInput` の分岐）
-- `internal/manifest`（読み込む evidence の形）
-- `internal/standard`（gate id 定数やバリデーション）
+- **コード** = CLI フラグ、パッケージ、module レジストリの真実
+- **docs/spec/** = 振る舞い・契約の真実（ドメイン + 横断仕様を同一フォルダ）
+- **field_docs.go + hado.manifest.reference.yaml** = manifest スキーマの真実
 
-のいずれかを変更したあと、**同じタスク内**でドキュメントを直す。
+## spec/ の構成
 
-## 手順
-
-1. **真実のソースはコード**  
-   実装を読み、実際にサポートしている gate id・adapter 名・CLI フラグを確定する。
-
-2. **`docs/implementation-status.md` を更新**  
-   - 実装済みゲートの箇条書き（`internal/gate/evaluate.go` の `switch` と一致）  
-   - coverage adapter 一覧（`internal/coverage/parse.go` の `Format*` 定数と一致）  
-   - `hado target` / `charge` / `fire` / `manifest doc` のフラグ・`--output` の取りうる値・終了コードの説明（`cmd/hado` と一致）  
-   - MVP / 未実装として追いたい項目があれば表や箇条書きで維持（ロードマップの [docs/roadmap.md](docs/roadmap.md) と矛盾させない）
+| ファイル | 内容 |
+| --- | --- |
+| `spec/cli.md` | target / charge / fire |
+| `spec/evaluation.md` | 終了コード、severity |
+| `spec/coverage.md` | coverage gate、manifest、**gobce** |
+| `spec/observability.md` | observability gate、Datadog discovery |
 
-3. **`docs/hado.manifest.reference.yaml`**  
-   - `internal/manifest/types.go` または `field_docs.go` を変えたら **`make gen-manifest-doc`** で再生成し、同じ変更セットに含める。
-
-4. **`docs/roadmap.md`**  
-   「このリポジトリの現状」の要約が古ければ 2〜3 文だけ直す。詳細は `implementation-status.md` に任せる。
-
-5. **利用者向け**  
-   ルート `README.md` の CLI 例やフラグ説明がずれていたら合わせる。
+## 手順
 
-6. **push / PR 前**  
-   `docs/` や `README.md` を触れたら `make lint`（少なくとも `make lint-markdown`）を通す。pre-push を使うなら `make setup-hooks`（[docs/local-development.md](docs/local-development.md)）。
+1. **どの spec か特定**して 1 ファイルだけ更新（executable 名・パスは書かない）
+2. **Manifest 型を変えたら** `field_docs.go` + `make gen-manifest-doc`
+3. **README / overview 等** — リンクずれの修正のみ
+4. **`make lint-markdown`**
 
 ## やらないこと
 
-- `make docstatus` のような別コマンドは**ない**。Manifest の参考 YAML（コメント付き）は **`make gen-manifest-doc`**（`hado manifest doc`）で生成し、それ以外は手書き＋この Skill。
-- 実装と無関係な長いロードマップの書き換えは、ユーザーが求めた範囲に留める。
+- 削除済みの旧 doc パスに内容を復活させる
 
 ## 参照
 
-- プロジェクトルール: [.cursor/rules/hado-implementation-docs.mdc](.cursor/rules/hado-implementation-docs.mdc)
+- [.cursor/rules/hado-implementation-docs.mdc](.cursor/rules/hado-implementation-docs.mdc)

Makefile

@@ -10,6 +10,7 @@ GO_BOOTSTRAP_VERSION ?= 1.22.12
 GO_FILES := $(shell git ls-files '*.go' | while read f; do test -f "$$f" && printf '%s\n' "$$f"; done)
 BINARY := bin/hado
 HADO_GOBCE_BINARY := bin/hado-gobce
+HADO_DATADOG_BINARY := bin/hado-datadog-pup
 GO_BIN = $(shell $(GO_CMD) env GOPATH 2>/dev/null)/bin
 GOBCE = $(GO_BIN)/gobce
 GOBCE_PACKAGE ?= github.com/keyskey/gobce/cmd/gobce@latest
@@ -85,6 +86,7 @@ build: ensure-go
 	@mkdir -p bin
 	$(GO_CMD) build -o "$(BINARY)" ./cmd/hado
 	$(GO_CMD) build -o "$(HADO_GOBCE_BINARY)" ./modules/gobce/cmd/hado-gobce
+	$(GO_CMD) build -o "$(HADO_DATADOG_BINARY)" ./modules/datadog/cmd/hado-datadog-pup
 
 gen-manifest-doc: ensure-go
 	@mkdir -p bin
@@ -135,6 +137,7 @@ readiness-check: ensure-go
 	$(GO_CMD) test ./... -coverprofile="$(COVERPROFILE)"
 	@mkdir -p bin
 	$(GO_CMD) build -o "$(HADO_GOBCE_BINARY)" ./modules/gobce/cmd/hado-gobce
+	$(GO_CMD) build -o "$(HADO_DATADOG_BINARY)" ./modules/datadog/cmd/hado-datadog-pup
 	@tmpdir="$$(mktemp -d)"; \
 		trap 'rm -rf "$$tmpdir"' EXIT; \
 		cp "$(READINESS_MANIFEST)" "$$tmpdir/hado.yaml"; \

README.md

@@ -21,9 +21,9 @@ HADO という名前は「波動砲」から来ています。波動砲は、日
 ## Docs
 
 - [Project HADO ドキュメント](docs/README.md)
-- [実装状況（手保守; Cursor Skill `hado-doc-sync`）](docs/implementation-status.md)
-- [HADO Manifest 参考（型から生成するコメント付き YAML）](docs/hado.manifest.reference.yaml)（`make gen-manifest-doc` で再生成）
-- [ローカル開発コマンド](docs/local-development.md)
+- [仕様（spec）](docs/spec/)
+- [HADO Manifest 参考（型から生成）](docs/hado.manifest.reference.yaml)（`make gen-manifest-doc`）
+- [ローカル開発](docs/local-development.md)
 
 ## Build and run
 
@@ -35,7 +35,7 @@ make build
 ./bin/hado
 ```
 
-`make build` は HADO CLI に加えて coverage module wrapper の `bin/hado-gobce` もビルドします。
+`make build` は HADO CLI に加えて bundled module wrapper の `bin/hado-gobce` と `bin/hado-datadog-pup` もビルドします。
 
 ## Target manifest（service / standard）
 
@@ -54,22 +54,12 @@ TTY で実行すると、現在の manifest の値をデフォルトにしなが
 `hado` は `target` / `charge` / `fire` の 3 コマンドで運用します。
 
 - `hado target`: service / standard と evidence のひな形を manifest に書く
-- `hado charge`: coverage module を実行して `evidence.coverage.metrics` を manifest に書き戻す。任意で **`--datadog-discover`** により Datadog Monitor を API から特定し **`evidence.observability.monitor.refs`** に `discovery_type: auto` を upsert する（`DD_API_KEY` / `DD_APP_KEY`、詳細は [docs/observability-readiness.md](docs/observability-readiness.md)）
-- `hado fire`: manifest に揃った evidence を Readiness Standard の gate と照合して判定する
+- `hado charge`: evidence を module / discovery で充填（[spec/](docs/spec/)）
+- `hado fire`: manifest を Readiness Standard の gate と照合して判定する
 
 `hado fire` の終了コードは `0`（ready）、`1`（blocked）、`2`（error）です。`BLOCKED` のときは CI で扱いやすいように 1 で終了します。
 
-HADO core は、特定の runtime、tool、SaaS、infrastructure provider の
-フォーマットに直接依存しません。Coverage、Operation、Observability、
-Infrastructure、Application、Security などの readiness domain は、
-module が evidence を正規化し、standard の gate が判定します。
-
-現在の evaluator は、coverage・operations・observability・release（rollback と
-自動リリース用 `workflow_refs` の宣言）・infra（deployment 参照）の各 evidence を
-Manifest から読み、対応する existence 系 gate を評価できます（詳細は
-[docs/implementation-status.md](docs/implementation-status.md)）。
-Coverage tool 固有の出力は coverage module が `test.c0_coverage` / `test.c1_coverage` に正規化し、`hado charge` が manifest に保存します。
-`module: gobce` は HADO 同梱の `hado-gobce` wrapper を起動し、内部で `gobce analyze` を実行します。
+HADO core は、特定の runtime や SaaS の出力形式に直接依存しない。各 readiness domain は module が evidence を正規化し、Readiness Standard の gate が判定する。仕様は [docs/spec/](docs/spec/)、Manifest スキーマは [docs/hado.manifest.reference.yaml](docs/hado.manifest.reference.yaml) を参照。
 
 ```bash
 cat > hado.yaml <<'YAML'
@@ -102,4 +92,4 @@ evidence:
       c1: 68.4
 ```
 
-必要なら `hado charge --coverage-module gobce` で manifest の `evidence.coverage.module` を補助的に指定できます。`--datadog-discover` を付けたときは、`evidence.observability.monitor.discovery.datadog` が必須で、失敗時（0 件・複数件・認証エラーなど）は exit 2 としその時点の manifest ファイルは更新されません。
+Coverage module は manifest の `evidence.coverage.module` で宣言します（[spec/coverage.md](docs/spec/coverage.md)）。