aep-watch

Watch

自動で継続的に作業を発見します。/aep-watch は継続的またはスケジュール実行されるモニターです。設定されたソース（バグトラッカー、エラーストリーム、テレメトリ）からデータを取得し、各検出項目を /aep-reflect と同じ分類器で分類し、バックログと照合して重複を除外したうえで、新しいバグや改善のストーリーを product-context.yaml に書き込みます。これらは /aep-dispatch に渡されるか、自動操縦によって取り込まれます。これにより、人が手動で /aep-envision や /aep-reflect を実行しなくても、システムが継続的に作業を発見するループが実現します。

sources → [ /aep-watch: pull → classify → dedupe → write stories ] → product-context.yaml
                                                                          │
                                                                          ▼
                                                          /aep-dispatch  (or /aep-autopilot)

/aep-reflect は、リリース後に実行する人間が介在する分類器です。/aep-watch は、その常時稼働する姉妹機能です。同じロジックを使いながら、検出項目ごとに人がプロンプトを入力する必要はなく、ループを_継続的_に保つ役割を担います。/aep-dispatch が読み取る同じ stories セクションにデータを渡すため、発見された作業は /aep-envision → /aep-map → /aep-dispatch → … → /aep-wrap → /aep-reflect のサイクルに再び取り込まれます。

セッション： メインワークスペースのみ（/aep-autopilot と同様）。オーケストレーターの境界を遵守します。
実行方法： /loop <interval>（Claude Code）、または codex exec の cron／launchd（Codex）。
入力： topology.routing.watch で設定されたソース。
出力： product-context.yaml の stories セクションに追加される新しい bug／refinement ストーリー（または、確認用の提案として提示されます。Config を参照）。

---

オーケストレーターの境界

/aep-watch はメインワークスペースのみで実行され、実行者ではなくオーケストレーターとして機能します。/aep-autopilot で定められたオーケストレーターの境界が、ここでもそのまま適用されます。読み取るのは次のものだけです。

• 設定されたソース（API／フィード経由。Step 1 を参照）
• product-context.yaml（重複を除外し、ストーリーを書き込むため）

検出項目の調査にコードの確認が必要な場合、その作業はストーリーのディスパッチ後にワークスペースエージェント内で行われます。

# Main workspace guard
pwd | grep -q '.feature-workspaces' && echo "ABORT: Run /aep-watch from main workspace only" && exit 1
[ -f product-context.yaml ] || echo "ABORT: Run /aep-envision and /aep-map first"

/aep-watch が起動するワーカー（バッチの取得と分類を行う低コストの CHECK デリゲートなど）は、Claude Code 上では**native-bg-subagentとして実行し、/aep-executor に従って標準の起動後の稼働確認プローブ**（scripts/spawn-liveness-probe.sh <name> <agent_id>）を適用します。プローブが失敗した場合は、起動したプロセスを終了して一度だけ再試行します。再試行も失敗した場合は、そのティックでは監視セッション内で取得と分類をインライン実行します（機能は制限されますが、シグナルのみを扱います）。監視セッション自体がワークスペースのコードを読み取ることはありません。

---

設定

Watch は product-context.yaml の topology.routing.watch によって完全に制御されます。各 sources[] エントリーにはソースの type を指定します（アダプターと検出項目の形式は references/telemetry-ingestion.md にあり、そこでタイプが定義されています）。

topology:
  routing:
    full_auto: false # master switch (see below)
    watch:
      sources: # source types + adapters: references/telemetry-ingestion.md
        - type: bug_tracker # github_issues | linear | jira | sentry | datadog | log_stream
          query: "is:open label:bug"
        - type: error_stream
          dsn: "<sentry/rollbar/...>"
        - type: telemetry
          metric: "error_rate"
          threshold: 0.02
        - type: dogfood_report # dogfood findings (local / post-deploy / standalone)
          glob: ".dev-workflow/dogfood-*.md" # default; see telemetry-ingestion.md adapter
        - type: distillation # layer distillations (proposal-only synthesis from /aep-wrap)
          glob: "lessons-learned/distillations/*.yaml" # default; see telemetry-ingestion.md adapter
      interval: 30m # poll cadence for the /loop or cron driver
      auto_create: false # write stories directly vs. surface proposals
      since: null # high-water mark — last ingested timestamp (watch maintains this)

確認ポリシー（デフォルトは慎重）： full_auto: true（マスタースイッチ）または watch.auto_create: true（個別の Watch でのオプトイン。マスタースイッチより適用範囲が狭い）の場合に限り、ストーリーを自動作成します。それ以外の場合は提案として提示します。ストーリーオブジェクトを topology.routing.watch の watch_proposals ブロックに書き込み、表示します。人が（/aep-reflect またはインラインで）承認するまで、stories セクションには追加されません。full_auto: true の場合、Watch はストーリーを直接 stories に書き込み、次のティックで /aep-dispatch／/aep-autopilot が取り込みます。

---

Watch のループ

各ティックでは、同じ 4 ステップの処理を実行します。冪等性があります。新しいソースデータがない状態で再実行しても、新しいストーリーは作成されません（重複排除と since の高水位マークによって保証されます）。

⓪ PRECHECK  → verify the /aep-map telemetry binding is complete (coverage_check)
① PULL      → fetch new findings from each configured source (since high-water mark)
② CLASSIFY  → run each finding through the /aep-reflect Step 2 classifier
③ DEDUPE    → drop findings that already map to an existing story
④ WRITE     → create bug/refinement stories (or surface proposals)

ステップ 0：前提条件 — マップのバインドを確認する

/aep-watch はテレメトリソースを消費するため、最初に /aep-map が実際にそれらを バインドしたことを確認してください。そうすれば、対象が何もない監視でも、そのことが示されます。監視に必要なシグナルに対して、 coverage_check()（references/telemetry-ingestion.md §1.5 のヘルパー）を実行してください。 各 topology.routing.watch.sources[] エントリー（および依存する metric／error_stream）が、 metric_map を持つ配線済みの topology.routing.telemetry_sources エントリーに 解決される必要があります。

• カバー済み → ステップ 1 に進みます。
• 未カバー（ソースが空、または参照先のメトリクスに metric_map がない） → カバー範囲ではなく不足を報告します。次のメッセージを提示してください。 "telemetry binding incomplete for <missing> — run /aep-map (Telemetry Binding step) before /aep-watch can ingest it"。未カバーのソースはスキップし、カバー済みのものが何もなければ、そのメッセージを表示してティックを停止します。バインドの欠落は処理をブロックします。何もせずに終了することはありません。

事後条件： カバーされた各ソースは、metric_map を持つ配線済みの telemetry_sources エントリーに解決されます（ファイルグロブソースの dogfood_report／distillation は自己記述型のため対象外です）。または、ティックでバインド未完了のメッセージが提示されています。

ステップ 1：ソースから取得する

watch.sources の各エントリーについて、watch.since 以降に作成または更新された検出事項を取得し、 それぞれを検出事項レコードに変換してください。references/telemetry-ingestion.md のソース別アダプター（→ /aep-watch の検出事項 レコード、Dogfood-report アダプター、Distillation アダプター）を使用します。これらのアダプターが検出事項の 形式を定義します。watch.since は、ティックが正常に完了した後に限り、最新の last_seen まで進めてください（ティックに失敗した場合は、検出事項を取りこぼさないよう再取得します）。

• **ファイルグロブソース（dogfood_report、distillation）**には項目ごとの タイムスタンプがないため、watch.since は進めません。各ティックでグロブを 再スキャンしても問題ありません。ステップ 3 で、各アダプターの安定した external_id（dogfood:<report>:<hash>／distillation:<layer>:<hash>）を使って重複を排除します。 自己記述型であるため、どちらもステップ 0 の coverage_check の対象外です。
• distillation の追加ルール： process（skill_amendments）にマッピングされた項目は、 ストーリーとして自動作成されることはありません。full_auto／auto_create の設定にかかわらず、 提案された修正として人間に提示されます。

事後条件： 設定済みの各ソースから、0 件以上の検出事項レコードが取得されています。 ティックが正常に完了するまでは、watch.since は変更されません。

ステップ 2：各検出事項を分類する

すべての検出事項を、/aep-reflect のステップ 2 とまったく同じ分類器（バグ／改善／発見／機会の変化／プロセス）で分類します。/aep-reflect の「各観察事項を分類する」（標準となる 5 カテゴリーのロジック）を適用してください。変更がある場合は、そちらで変更されます。

Watch が自律的に処理するのは、安全に作業へ変換できる2 つのカテゴリーのみです。バグ → バグストーリー（ステップ 4）、改善 → 次のレイヤーの改善ストーリー（ステップ 4）です。発見、機会の変化、キャリブレーション、プロセスに該当する検出事項は、full_auto の設定にかかわらず自動作成されません。これらはプロダクトの意図やワークフローを変えるため、常に人間に提示されます（/aep-reflect 経由。機会の変化は賭けの内容を変えるためエスカレーションされます）。

ステップ 3：既存のストーリーとの重複を排除する

新しい項目を作成する前に、product-context.yaml の現在の stories セクション （および既存の watch_proposals）を確認し、検出結果と照合します。次の場合は検出結果をスキップします。

• すでに source と external_id が一致するストーリーがある（watch は作成したすべてのストーリーに watch_origin: { source, external_id } を記録します）、または
• 未完了のストーリーの title／説明が、同じ問題を明確に扱っている （同じエラーシグネチャ、同じエンドポイント、同じメトリック）。

一致するストーリーが completed／closed で、問題が再発している場合（completed_at 以降に新たな 発生がある場合）は、注記を追加し、人の注意を促すためリグレッションとして提示します。再発は 過去の作業についての新しい情報であり、新しい作業ではありません。

事後条件： 残ったすべての検出結果に、一致する未完了のストーリーがなく、 過去に watch_origin.{source, external_id} が記録されていません。

ステップ 4：ストーリーを作成する（または提案として提示する）

残ったバグ／リファインメントの検出結果ごとに、ストーリーを作成します。

- id: "watch-<source>-<external_id>"
  title: "<finding title>"
  description: "<finding detail> (auto-discovered by /aep-watch from <source>)"
  type: bug # or refinement
  status: pending
  priority: high # bugs: high; tune by count/severity (see below)
  layer: <active_layer> # bug → current layer; refinement → next layer
  module: <best-effort or unset> # leave unset if the source doesn't localize it
  watch_origin:
    source: "<source>"
    external_id: "<external_id>"
    discovered_at: "<ISO8601>"

優先度／レイヤーのルール（/aep-reflect に準拠）：

• バグ → priority: high、status: pending、現在／アクティブなレイヤーに設定します （count または重大度が高い場合は critical に引き上げます。例：多くのユーザーに影響するクラッシュ／ しきい値を超える error_rate）。
• リファインメント → 次のレイヤーで status: pending に設定します。
• ソースから module／files_affected を特定できない場合は未設定のままにします。 dispatch の準備状況スコアにより、これらは最初に /aep-design に振り分けられます。

次に、確認ポリシー（Config）に従います：

• 自動作成（full_auto: true または watch.auto_create: true）：ストーリーを stories セクションに追加します。 通常の保留中ストーリーとして /aep-dispatch がスコアを算出し、次のティックで /aep-autopilot が取り込みます。
• 提示（デフォルト）：ストーリーオブジェクトを topology.routing.watch.watch_proposals に追加して出力します。人が /aep-reflect を実行する （またはインラインで確認する）と、提案が stories に昇格されます。

検証してコミットする（reflect／dispatch と同じガードレールを適用します。検証コマンドは references/yaml-guardrails.md を参照してください）：

npx js-yaml product-context.yaml > /dev/null && echo "YAML OK"
# Resolve $BASE (integration branch) per /aep-git-ref "Integration Branch".
git pull --ff-only origin "$BASE"
git add product-context.yaml
git commit -m "chore: watch — auto-discovered N stories from <sources>"
git push origin "$BASE"

検出結果の取り込み、分類、重複排除、作成と提案の件数をまとめた changelog エントリ （type: watch）を追加します。事後条件： npx js-yaml product-context.yaml が終了コード 0 で終了し、コミットが $BASE にプッシュされています。

---

ドライバー

/aep-watch は /aep-autopilot と同じドライバーマトリックスに基づく継続的／スケジュール実行のモニターです。 executor の detect() と /aep-executor の references/backends.md にあるドライバー × バックエンドの マトリックスを使ってホストのドライバーを特定し、間隔には watch.interval を使用します。

• Claude Code — /loop <interval>（長時間実行、セッション内）：/loop 30m /aep-watch tick。 セッションは維持されるため、起動された CHECK デリゲートはセッションに紐づく native-bg-subagent になります。
• Codex — codex exec cron／launchd（短時間実行、OS スケジュール）：外部で /aep-watch tick をスケジュールします（launchd の StartInterval、cron、または while … sleep ループ）。OS に紐づくワーカー（codex-exec）で、各ティックにつき軽量な ワンショットを 1 回実行します。AEP はスニペットを出力しますが、スケジューラーはインストールしません。

/aep-watch tick は 4 ステップのループを 1 回実行して終了します。/aep-watch stop はドライバーを 停止します（/loop のキャンセル、または cron／launchd ジョブの削除）。

---

相互参照

• /aep-reflect — ステップ 2 の分類器（bug／refinement／discovery／…）をここで再利用します。 watch に対応する human-in-the-loop の機能です。
• references/telemetry-ingestion.md — ステップ 1 で使用する検出結果のレコードとソースごとのアダプター （/aep-reflect のステップ 1 と共有）。
• /aep-dispatch — watch が作成したストーリーを取り込みます（スコアリング、準備状況、WIP）。
• /aep-autopilot — watch が踏襲するオーケストレーターのパターン、ドライバーマトリックス、稼働確認、 メインワークスペースの境界を定義します。watch が作成したストーリーを次のティックで取り込みます。