プロジェクト全体の現在地と次の一手を素早く把握するためのガイドです。既存ドキュメントの骨格を保ちつつ、各資料の読みどころを短くまとめました。迷ったときはここから辿れば、必要な一次資料に直接到達できます。
| ドキュメント | 目的 | 参照タイミング |
|---|---|---|
| workflow-cookbook/HUB.codex.md | Day8 の変更要求を内部観測イベントへマッピングし、必要な一次資料を抽出する | 新規課題が発生した直後に参照し、影響範囲を整理するとき |
| workflow-cookbook/GUARDRAILS.md | 設計判断とレビュー基準を制約として明文化する | HUB の観測内容を踏まえ、設計方針を決めるタイミング |
| workflow-cookbook/BLUEPRINT.md | Collector→Analyzer→Reporter→Proposer のフロー/SLO/フェイルセーフを定義する | Guardrails を適用した後、要件と画面仕様・運用 SLO を整合させるとき |
| workflow-cookbook/RUNBOOK.md | 運用手順と検証ステップを決め、Day8 側の ops/quality 文書と同期する | 実装プランが固まったら運用・品質更新前に確認するとき |
| workflow-cookbook/EVALUATION.md | RUNBOOK に定義した手順が満たすべき評価指標と計測方法を整備する | Runbook を改訂した直後や品質ゲートの更新判断時 |
| workflow-cookbook/CHECKLISTS.md | RUNBOOK のアクションをレビューフローに合わせた実行チェックへブレークダウンする | Evaluation の結果を反映し、運用・レビュー実行前に順序を確認するとき |
| workflow-cookbook/TASK.codex.md | 実行タスクを分解し、Day8 の実装・テスト項目へ落とし込む | Checklists を踏まえて具体的なタスク化や Issue 起票時 |
| workflow-cookbook/SECURITY.md | セキュリティ例外や脅威対応の承認プロセスと責務を定義する | Task を起票し、リスク緩和策や例外申請を組み込むとき |
| workflow-cookbook/SAFETY.md | 倫理・安全配慮の判断基準とハンドリング動線を明文化する | Security の結論を踏まえて人・社会影響の最終確認をするとき |
- workflow-cookbook/HUB.codex.md: 変更要求を Day8 内の観測イベントへ対応付け、初動で必要な資料一覧を洗い出すときに使う。Day8 要求集約 (docs/day8/spec/01_requirements.md) と併せて参照し、観測イベントとユースケースを突き合わせる。
- workflow-cookbook/GUARDRAILS.md: HUB で得た課題を制約条件に落とし込み、設計判断やレビュー方針を確定したいタイミングで参照する。
- workflow-cookbook/BLUEPRINT.md: Collector→Analyzer→Reporter→Proposer の流れと SLO/フェイルセーフを定義し、仕様・要件・運用の整合を取る。
- workflow-cookbook/RUNBOOK.md: BLUEPRINT に沿って運用手順を更新し、リリースや運用変更の作業前に参照する。
- workflow-cookbook/EVALUATION.md: RUNBOOK の更新内容が満たすべき評価指標と測定プロセスを整理し、品質ゲートの更新や指標見直し時に参照する。
- workflow-cookbook/CHECKLISTS.md: RUNBOOK・EVALUATION の結果をチェック項目へ展開し、品質ゲートを適用するレビュー・運用の直前に順序と抜け漏れを点検する。
- workflow-cookbook/TASK.codex.md: Guardrails で確定した作業を実装タスクに分解し、Checklists の反映後に Issue 作成やスプリント計画時へ活用する。
- workflow-cookbook/SECURITY.md: タスク化した変更に潜むリスク対応や例外承認のルールを確認し、セキュリティ緩和策を手順へ織り込む。
- workflow-cookbook/SAFETY.md: Security で整理したリスクのうち倫理・安全面の追加確認が必要な項目を洗い出し、最終判断のガードを適用する。
- docs/adr/0001-collector-analyzer-reporter-pipeline.md: Collector / Analyzer / Reporter を 3 層で運用し、ログ処理の責務を分離する決定。
- docs/adr/0002-jsonl-event-contract.md: Collector が出力する JSONL スキーマと Analyzer の検証手順を規定し、
workflow-cookbook/logs/の品質を保証する。 - docs/adr/0003-propose-only-governance.md: Reporter/Proposer が propose-only を遵守し、
governance/policy.yamlの制約タグと連携する運用境界を定義する。
上記の流れで HUB → Guardrails → Blueprint → Runbook → Evaluation → Checklists → Task → Security → Safety の順に確認したら、本節の索引表と「## 2. 実装モジュールと対応仕様」へ進み、Day8 側の更新対象とトレーサビリティを確定させる。
- 索引・基準整備 — Guardrails フローでの差分承認（workflow-cookbook/GUARDRAILS.md 更新) 直後、同一 PR のレビュー完了時点で差分検知を行い、本ページと docs/day8/spec を照合する。Day8 内部の索引（workflow-cookbook/HUB.codex.md）との差異を毎スプリントで解消し、ガバナンス更新（workflow-cookbook/governance/policy.yaml）と併せて Birdseye 更新のハンドオフを確認する。入口手順はルート README の LLM-BOOTSTRAP に従い、
docs/ROADMAP_AND_SPECS.md→docs/birdseye/index.json→docs/birdseye/caps/→docs/birdseye/hot.jsonの順で参照する。差分は docs/birdseye/index.json にも反映する。Guardrails を更新したら、Step1 の一部として Birdseye 反映 4 ステップを再実行し、索引と可視化の整合を確保する。運用手順は docs/birdseye/README.md に従い、必ず「index → caps → hot」の順で更新しgenerated_atを同期させる。 - 自動化ゲートの維持 —
tools//scripts/の CI エントリポイントを見直し、workflow-cookbook/scripts/run_ci_tests.py で実行される mypy / ruff / pytest / node:test の整合を保証。チェックリスト更新時は docs/day8/quality/06_quality.md を同時改訂する。 - 実装・検証のアップデート — docs/day8/design/03_architecture.md に基づき実装やテストの差分をまとめ、docs/day8/examples/10_examples.md・docs/day8/guides/07_contributing.md を更新。Day8 固有の履歴はルート CHANGELOG.md へ追記し、上流側のトレースは workflow-cookbook/CHANGELOG.md と突き合わせる。
- リリース・承認フロー — フェーズ完了ごとに docs/day8/ops/04_ops.md と workflow-cookbook/RUNBOOK.md を突き合わせ、workflow-cookbook/governance/policy.yaml の承認記録を更新。
/healthzと MetricsRegistry の移行計画は docs/addenda/M1_Metrics_Healthz_ADR.md と docs/openapi/day8_openapi.yaml を参照し、リリース判定前にヘルスチェック・メトリクスを検証する。例外は docs/safety.md の安全審査に連携。
- BLUEPRINT を起点に制約と仕様を固める — workflow-cookbook/BLUEPRINT.md の Purpose/Scope/SLO/Guardrails を読み、docs/day8/spec/01_requirements.md / docs/day8/spec/02_spec.md と照合し、workflow-cookbook/GUARDRAILS.md の原則との齟齬を潰す。
- RUNBOOK / CHECKLISTS を同期 — workflow-cookbook/RUNBOOK.md・workflow-cookbook/CHECKLISTS.md と docs/day8/ops/04_ops.md / docs/day8/quality/06_quality.md を突き合わせ、運用動線とゲート条件を更新する。
- EVALUATION で評価指標を確定 — workflow-cookbook/EVALUATION.md と docs/day8/quality/06_quality.md の測定軸を反映し、CI/レビュー判定の調整を記録する。
- TASK seed を起票 — workflow-cookbook/TASK.codex.md と workflow-cookbook/HUB.codex.md の対応表を用いて、Issue テンプレートとチェックリストの追従タスクを作成する。
- Birdseye / ADR の整合を取る — docs/birdseye/index.json・docs/day8/design/03_architecture.md を更新し、可視化ビューと設計判断をルート CHANGELOG.md と workflow-cookbook/CHANGELOG.md の双方で同期する。
Guardrails 群を更新した場合は、必ず本 ROADMAP（
docs/ROADMAP_AND_SPECS.md）も同じ PR で同期し、差分根拠を併記すること。参照チェック（PR 本文に記載）:
- Guardrails 文書群 — workflow-cookbook/HUB.codex.md / workflow-cookbook/GUARDRAILS.md / workflow-cookbook/BLUEPRINT.md / workflow-cookbook/RUNBOOK.md / workflow-cookbook/EVALUATION.md / workflow-cookbook/CHECKLISTS.md / workflow-cookbook/TASK.codex.md / workflow-cookbook/SECURITY.md / workflow-cookbook/SAFETY.md
- Birdseye 連携 — docs/birdseye/README.md（更新順序と
generated_at同期の必須手順を参照） / docs/birdseye/index.json / docs/BIRDSEYE.md（Guardrails 参照順とedgesチェックポイントのフォールバック手順を参照）
- Day8 Guardrails サマリ — 制約とレビュー基準を Day8 の実装方針へ即時反映。docs/day8/design/03_architecture.md の責務境界と併せて確認する。
- Day8 要求・仕様インデックス —
01_requirements.mdと02_spec.mdを対で確認し、HUB で抽出した差分を反映する。 - Day8 アーキテクチャ指針 — Collector/Analyzer/Reporter/Proposer の責務境界を確定し、運用設計へ橋渡しする。参考: Day8 Architecture ASCII Map
- Day8 Ops & Quality ハンドブック — 運用承認とリリース手順の基準点。参考: workflow-cookbook/RUNBOOK.md / workflow-cookbook/CHECKLISTS.md
- Day8 Quality ゲート定義 — 計測軸とレビューゲートの同期。参考: workflow-cookbook/EVALUATION.md
- Day8 Release Checklist — ops/quality 文書と同期したリリース判定の必須項目。docs/day8/ops/04_ops.md / docs/addenda/M_Versioning_Release.md と突き合わせて更新する。
- Day8 Observability OpenAPI —
/healthzと MetricsRegistry の整合確認に利用。 - Day8 セキュリティ運用基準 — 権限設計と脅威対策の定義。参考: セキュリティ & プライバシー付録（Appendix G）
- 安全性レビュー基準 — フェイルセーフとホット更新時の安全確認ラインを整理。
- ガバナンス方針 — 優先度・承認ルールの一次情報。参考: workflow-cookbook/governance/prioritization.yaml
- Versioning & Release Operations（Appendix M） — バージョニングとリリース運用の補足資料。
- Day8 コントリビューションガイド — 実装/レビュー/テストの標準フロー。
- Day8 マイルストーン WBS — 計画策定とスプリントレビューでマイルストーン進捗を照合し、ロードマップとの差分を抽出する際に利用。
- Birdseye フォールバック手順 — 可視化更新時の確認ポイント。参考: docs/birdseye/README.md
- Birdseye 反映 4 ステップ（ロードマップ Step1 の必須作業）
- ノード追加 — docs/birdseye/index.json に該当エントリを追加・更新し、
mtimeを差分検知時刻へ合わせる。 - Capsule 更新 —
docs/birdseye/caps/配下の対象 Capsule を差分内容へ反映し、役割・保守手順を同期させる。 - hot.json 更新 — docs/birdseye/hot.json の
reasonを最新フローへ揃え、重点参照ポイントを再評価する。 - generated_at 揃え —
index.json/hot.json双方のgenerated_atを同一値へ更新し、Birdseye 再生成の履歴を同期する。
- ノード追加 — docs/birdseye/index.json に該当エントリを追加・更新し、
- フォーク同期運用ガイド
- フォーク同期 週次ログ テンプレート
- Day8 リポジトリ: LICENSE
- workflow-cookbook: workflow-cookbook/LICENSE