成果物カタログ: data-flow
- project-id:
prj-0001 - ドメイン:
data-flow
1. 全体構成
| local-id | 成果物名 | 種別 | 根拠 | 概要 |
|---|---|---|---|---|
cdfd-overview | 概念データフロー図（全体概要） | work | - | SpecDojo を活用したプロジェクト運営について、PDCA サイクルに沿った 14 のプロセス領域と六つのプロセスグループ、データストア、グループとデータストアの間の情報・実行要求の流れを可視化し定義する |
cdfd-overview の完了条件:
- Onboarding・Plan・Do・Check・Action・Orchestrator の六つのプロセスグループに属する 14 のプロセス領域と、グループとデータストアの間の情報・実行要求の流れが表と図で確認できること
- 対象とするプロセス領域、および独立した業務フローに含めない補助操作の境界を承認できること
- 各領域の起点イベントと、プロセスグループ単位の主要入力・主要出力・データストアが識別でき、概念データフローのエッジと相互に対応し、プロセスグループ別 CDFD の構成方針として参照できること
- プロセスグループ別 CDFD とユースケース別 CDFD への分割に重複または欠落がないことを、詳細 CDFD 一覧と各領域の対応で確認できること
2. プロジェクト推進
| local-id | 成果物名 | 種別 | 根拠 | 概要 |
|---|---|---|---|---|
cdfd-init | 概念データフロー図（初期セットアップ） | work | cdfd-overview | config・register・catalog・実行補助設定を初期化し、プロジェクトの計画と実行を開始できる状態にする流れを可視化し定義する |
cdfd-register-operation | 概念データフロー図（登録簿運用） | work | cdfd-init | 廃止済み。内容は cdfd-register-lifecycle へ移行した（id-and-file-naming-standard.md 9.2 経路B）。Schedule に記録済みの過去タスクIDとの参照整合性を保つためエントリを維持する。 |
cdfd-register-lifecycle | 概念データフロー図（登録簿ライフサイクル） | work | cdfd-init | 立ち上げ時の未整理事項と運用中の計画外事項を個票へ登録し、判断・実行・待機・レビュー・承認・終了・再開、派生ビュー生成・履歴確認と例外復旧まで継続管理する流れを可視化し定義する |
cdfd-catalog-planning | 概念データフロー図（カタログ〜計画展開） | work | cdfd-init | 成果物カタログとスケジュール戦略を検証し、Scheduleと実行状態・Ready・CPM・timelineへ展開する流れを可視化し定義する |
cdfd-task-execution | 概念データフロー図（タスク実行ライフサイクル） | work | cdfd-catalog-planning | Readyタスクの選択・claimからhuman/agentによる実行、レビュー・ready確定、完了記録、中断・訂正・再実行までの流れを可視化し定義する |
cdfd-init の完了条件:
- config init・register scaffold・catalog scaffoldと、必要に応じたexec scaffoldの起動条件・入力・生成物が表と図で確認できること
- 必須の初期化と任意のprovider・実行補助設定の境界を承認できること
- 初期化対象ごとの正本ファイル、生成先、後続プロセスへの引き渡しが識別できること
- 既存ファイルがある場合、設定が不足する場合、生成に失敗した場合の分岐が確認できること
cdfd-register-operation の完了条件:
- todo・question・risk・issue・change-request・decision・noteの登録判断と、scheduleで管理する計画済み作業との境界が表と図で確認できること
- 個票Frontmatterを正本としてopen・in-progress・waiting・review・done/decided・rejected・deferredを遷移し、登録日・完了日・結論、生成一覧・派生ビューおよびregister historyへ反映する流れが識別できること
- agent実行の成功時・失敗時の遷移、個票の重複IDまたはファイル名と文書IDの不整合の検出、renumberによる個票・参照・実行記録の復旧、およびworktreeの同期・統合失敗時の例外経路が確認できること
- type別の承認者とreviewからclose・reject・defer・waitへの遷移、commit承認とPR承認の適用境界、および留保・却下・延期・再開の判断に必要な情報が識別できること
cdfd-register-lifecycle の完了条件:
- todo・question・risk・issue・change-request・decision・noteの登録判断と、scheduleで管理する計画済み作業との境界が表と図で確認できること
- 個票Frontmatterを正本としてopen・in-progress・waiting・review・done/decided・rejected・deferredを遷移し、登録日・完了日・結論、生成一覧・派生ビューおよびregister historyへ反映する流れが識別できること
- agent実行の成功時・失敗時の遷移、個票の重複IDまたはファイル名と文書IDの不整合の検出、renumberによる個票・参照・実行記録の復旧、およびworktreeの同期・統合失敗時の例外経路が確認できること
- type別の承認者とreviewからclose・reject・defer・waitへの遷移、commit承認とPR承認の適用境界、および留保・却下・延期・再開の判断に必要な情報が識別できること
cdfd-catalog-planning の完了条件:
- カタログと戦略の準備からcatalog validate・schedule build・exec refreshを経て計画情報を利用可能にする流れが表と図で確認できること
- dct・strategy・schedule・eventからstate・Ready・CPM・timelineへ至る入力、出力、依存関係が識別できること
- カタログ検証失敗・戦略不足・依存解決失敗により計画展開を停止するゲートが判定可能な形で確認できること
cdfd-task-execution の完了条件:
- Ready選択・claim・plan/result生成・実行・レビュー・finalize・completeの正常経路が、担当と入出力を含めて表と図で確認できること
- human/agent、in-place/worktree、単発/自動/並列の実行経路、登録済みnicknameによるagent選択と、各経路で更新される成果物・event・resultが識別できること
- project実行中のskip/wait/fail、blockedからのunblock/release、todoからのcancel、doneからのreopen、レートリミット後のresume --due、worktreeの依存導入・統合失敗の分岐が確認できること
- ready確定、差し戻し、前提不足時のPJR登録とPO判断に必要な情報が識別できること
3. オペレーション推進
| local-id | 成果物名 | 種別 | 根拠 | 概要 |
|---|---|---|---|---|
cdfd-routine | 概念データフロー図（定期処理） | work | cdfd-register-lifecycle, cdfd-task-execution | routine定義とdue判定に基づき、既存の登録項目・Scheduleタスク、順次実行cycle、またはJobから生成した実行単位を起動し結果を反映する流れを可視化し定義する |
cdfd-multi-project | 概念データフロー図（複数プロジェクト・ブランチ並行処理） | work | cdfd-init | project develop・feature・execの各ブランチとworktreeを用いて複数プロジェクト・タスクを分離し、同期・統合する流れを可視化し定義する |
cdfd-agent-config-operation | 概念データフロー図（agent・provider構成の運用変更） | work | cdfd-task-execution | 作業要件と実行結果に応じてagent・provider・phaseの構成を評価し、承認・変更・検証する流れを可視化し定義する |
cdfd-derived-content | 概念データフロー図（成果物・派生ビュー・索引生成） | work | cdfd-register-lifecycle, cdfd-catalog-planning, cdfd-task-execution | カタログ・登録簿・実行状態などの正本から、成果物本体・表示ビュー・YAML表示ページ・文書索引を生成し同期する流れを可視化し定義する |
cdfd-reporting | 概念データフロー図（進捗監視・報告・ログ管理） | work | cdfd-register-lifecycle, cdfd-task-execution, cdfd-derived-content | 実行状態・CPM・マイルストーン・登録簿を監視し、遅延や滞留を検知して進捗報告・議事録・管理ログへ反映する流れを可視化し定義する |
cdfd-deprecation | 概念データフロー図（非推奨化・保管） | work | cdfd-init | 役割を終えた、または新IDへ引き継がれた文書を非推奨化し、id・Schedule taskIDを維持したまま誤参照を防ぐ保管場所へ移す流れを可視化し定義する |
cdfd-routine の完了条件:
- routine定義の選択・due判定・register/schedule実行への委譲、resumeから状態再計算・autoへ進むexec-cycleに加え、Job Run生成を伴う反復作業との境界・実行結果更新の流れが表と図で確認できること
- rtn-*.yamlのaction kind・filter・interval・limit、個票Frontmatterを正本とするregister対象選択、exec-cycleのstrategy・parallel・loop、Job連携時のcron・timezone・missed/overlap policyと、委譲先へ渡す入力および返却される結果が識別できること
- projectがbusyの場合、対象なし・利用制限・cycleのstep別失敗・再開時刻待ち・重複Job Run・取りこぼしの場合に、last_run・last_resultと次回判定がどのように記録されるか確認できること
cdfd-multi-project の完了条件:
- project develop・feature・execの作成、作業、同期、統合、後片付けの各プロセスと担当が表と図で確認できること
- 各ブランチ・worktreeが読み書きするプロジェクト成果物、実行記録、commitと統合方向が識別できること
- ID競合・merge競合・同期失敗・未commit変更がある場合の停止条件と復旧経路が確認できること
cdfd-agent-config-operation の完了条件:
- 作業要件または実行上の問題を起点として、構成案作成・権限確認・承認・設定変更・検証へ進む流れが表と図で確認できること
- pm-members.yaml・exec-defaults.yaml・provider設定・sch-strategyの変更責務と相互参照が識別できること
- agent・providerの権限範囲、認証情報を設定文書から分離する境界、プロンプトインジェクション対策を承認できること
- capability不足・provider利用不能・設定不整合・権限超過を検知した場合の差し戻し経路が確認できること
cdfd-derived-content の完了条件:
- deliverable scaffold・catalog build・register build・exec refresh・yaml-pages build・index buildと一括build/watchの役割および起動関係が表と図で確認できること
- 個票Frontmatterから生成する登録項目一覧・状態別・優先度別・担当者別ビューを含め、各正本と生成先の対応、直接編集してはならない派生成果物、再生成時の上書き境界が識別できること
- 正本不足・検証失敗・部分生成失敗・生成物の陳腐化を検知した場合の停止条件と再実行経路が確認できること
cdfd-reporting の完了条件:
- Ready・CPM・マイルストーン・blocked/doing・登録項目を確認し、遅延や滞留への対応と報告へつなげる流れが表と図で確認できること
- 遅延・滞留の検知条件、エスカレーション先、進捗報告・議事録を作成する契機が計画運用に使える粒度で定義されていること
- 人が作成する進捗報告・議事録と、register buildで生成する登録項目一覧・課題・リスク・変更要求・決定ログ、およびregister historyで再構成する監査履歴の入力と更新責務が識別できること
- 更新漏れ・古い生成ビュー・未報告の遅延・未転記の決定事項を検知する確認経路が識別できること
cdfd-deprecation の完了条件:
- 非推奨化の判断から、id移行経路（ファイル名のみ変更・新IDへの切替）の使い分け、trashディレクトリへの物理移動までの流れが表と図で確認できること
- local_idとSchedule task IDを変更せず、成果物カタログのpathフィールドだけを更新して
docs/ja/product/trash/またはdocs/ja/projects/<project-id>/trash/へ配置する対応関係が識別できること - 移動先が既に存在する場合、対象文書またはcatalogエントリが見つからない場合の停止条件が確認できること
- 非推奨化の承認境界と、恒久的な削除・復元の方針が本領域の対象外として未定義のままであることを承認できること
4. プロセスグループ別 CDFD
| local-id | 成果物名 | 種別 | 根拠 | 概要 |
|---|---|---|---|---|
cdfd-onboarding | 概念データフロー図（Onboarding） | work | cdfd-overview | SpecDojo を導入して Kata を配置し、その雛形から稼働構成の初期状態を整える Onboarding グループ（P-01）の領域内プロセス、起点イベント、例外・復旧、データストアの読み書きを定義する |
cdfd-plan | 概念データフロー図（Plan） | work | cdfd-overview | 登録簿定義、成果物カタログ定義、スケジュール計画展開、定期実行定義、ジョブ定義からなる Plan グループ（P-02〜P-06）の領域内プロセス、起点イベント、例外・復旧、データストアの読み書きを定義する |
cdfd-do | 概念データフロー図（Do） | work | cdfd-overview | 実行計画に基づいて人または AI Agent が Kata を参照してタスクを実行し、成果物と実行記録を残す Do グループ（P-07）の領域内プロセス、起点イベント、例外・復旧、データストアの読み書きを定義する。定期実行・ジョブ・並行実行はタスク実行の実行形態として扱う |
cdfd-check | 概念データフロー図（Check） | work | cdfd-overview | 成果物評価、進捗可視化報告、派生生成閲覧提供からなる Check グループ（P-08〜P-10）の領域内プロセス、起点イベント、例外・復旧、データストアの読み書きを定義する |
cdfd-action | 概念データフロー図（Action） | work | cdfd-overview | タスク完了、稼働構成管理、非推奨化保管からなる Action グループ（P-11〜P-13）の領域内プロセス、起点イベント、例外・復旧、データストアの読み書きを定義する |
cdfd-orchestrator | 概念データフロー図（Orchestrator） | work | cdfd-plan, cdfd-do, cdfd-check, cdfd-action | Plan・Do・Check・Action へ要求を発行して PDCA を回す Orchestrator グループ（P-14）の領域内プロセス、起点イベント、例外・復旧、データストアの読み書きを定義する。参加者の意図に基づく対話型の運転と、定期実行定義に基づく自動運転を含む |
cdfd-onboarding の完了条件:
- 全体概要の P-01 の主要入力・主要出力・データストアが「プロセス領域」章で矛盾なく詳細化され、Kata の配置と稼働構成の初期化がプロセス単位で確認できること
- 各プロセスの起動条件、読み書きするデータストア（Kata、稼働構成）、生成先が識別でき、後続の Plan への引き渡しがグループ外委譲として示されていること
- 既存設定の検出、雛形の不足、権限不足など、成果の採否を変える主要例外の検出条件と再開条件が判定できること
cdfd-plan の完了条件:
- 全体概要の P-02〜P-06 の主要入力・主要出力・データストアが「プロセス領域」章で領域ごとに矛盾なく詳細化されていること
- 登録簿、成果物カタログ、スケジュール戦略、Schedule（track）、実行計画、定期実行定義、ジョブ定義への読み書きがプロセス単位で識別でき、名称が全体概要の「データストア」と一致していること
- 登録項目の状態の定義と遷移を本書で再定義せず、STSD への参照に留めていること
- カタログ検証の失敗、依存の循環、strategy と Kata grade の不整合など、後続起動を変える主要例外の検出条件と再開条件が判定できること
cdfd-do の完了条件:
- 全体概要の P-07 の主要入力・主要出力・データストアが「プロセス領域」章で矛盾なく詳細化され、Schedule task・登録項目・Job のいずれを対象にしても同じプロセスで説明できること
- 実行計画、Kata、稼働構成、成果物、登録簿、実行記録への読み書きがプロセス単位で識別でき、worktree 隔離と統合ブランチへの merge が並行実行の形態として示されていること
- 利用制限、保護対象の変更、検証失敗、統合失敗など、成果の採否と再開位置を変える主要例外の検出条件と再開条件が判定できること
- 人間が担う判断（承認、完了確定）を AI Agent の自動処理として表していないこと
cdfd-check の完了条件:
- 全体概要の P-08〜P-10 の主要入力・主要出力・データストアが「プロセス領域」章で領域ごとに矛盾なく詳細化されていること
- 評価結果、進捗報告、派生ビュー・索引の生成先と、成果物・実行記録・登録簿・Schedule（track）からの参照がプロセス単位で識別できること
- 評価対象の変更検知、評価の失敗、生成物の不整合など、Action への引き渡しを変える主要例外の検出条件と再開条件が判定できること
cdfd-action の完了条件:
- 全体概要の P-11〜P-13 の主要入力・主要出力・データストアが「プロセス領域」章で領域ごとに矛盾なく詳細化されていること
- 完了記録、稼働構成、Kata のバージョン、成果物カタログ、保管庫への更新がプロセス単位で識別でき、Plan への再計画要求がグループ外委譲として示されていること
- 完了確定、構成変更の承認、非推奨化の判断が人間の判断として表され、承認境界が承認できること
cdfd-orchestrator の完了条件:
- 全体概要の P-14 の主要入力・主要出力・データストアが「プロセス領域」章で矛盾なく詳細化され、対話型運転と自動運転が同じ要求発行のプロセスで説明できること
- 稼働構成、成果物カタログ、スケジュール戦略、定期実行定義、実行計画、実行記録への読み書きと、Plan・Do・Check・Action への要求がグループ外委譲として識別できること
- 実行ロックの競合、定期実行の取りこぼし、要求先の失敗など、サイクルの継続を変える主要例外の検出条件と再開条件が判定できること
5. ユースケース別 CDFD
| local-id | 成果物名 | 種別 | 根拠 | 概要 |
|---|---|---|---|---|
cdfd-uc-register | 概念データフロー図（登録簿起票から完了まで） | work | cdfd-plan, cdfd-do, cdfd-check, cdfd-action | 登録項目の起票から、対応、評価、完了記録までの Plan → Do → Check → Action の順序と引き渡し条件を定義する。グループ内部のプロセスは再掲しない |
cdfd-uc-deliverable | 概念データフロー図（成果物の作成から完了まで） | work | cdfd-plan, cdfd-do, cdfd-check, cdfd-action | 成果物カタログの定義からタスク展開、実行、評価、完了記録までの Plan → Do → Check → Action の順序と引き渡し条件を定義する。グループ内部のプロセスは再掲しない |
cdfd-uc-register の完了条件:
- 起票から完了記録までの各引き渡しについて、送り元グループ、受け側グループ、引き渡す情報、引き渡し条件、戻す条件が表で確認できること
- 引き渡し条件を満たさない場合の戻り先がグループ単位で示され、グループ内部の例外を扱っていないこと
- 完了記録を人間が確定する境界が承認できること
cdfd-uc-deliverable の完了条件:
- カタログ定義から完了記録までの各引き渡しについて、送り元グループ、受け側グループ、引き渡す情報、引き渡し条件、戻す条件が表で確認できること
- 引き渡し条件を満たさない場合の戻り先がグループ単位で示され、グループ内部の例外を扱っていないこと
- レビューによる確定と grade による評価の責務分担が引き渡し条件として区別できること