ccf-pipeline-orchestrator

CCF Pipeline Orchestrator

Family File Contract

ファイル作業の前に、標準パスと、タスク／成果物ごとに1つの作業ディレクトリを再利用します。デフォルトでは、プロジェクトルートの ccfa-workfiles/<purpose>/<artifact-id>/ を使用します。既存の場所で更新し、入力を保持し、UTF-8を使用して中国語テキストが含まれていないことを確認します。命名、所有権、タスクで作成したファイルのクリーンアップには、artifact-contracts.md を適用します。引き継ぎではこれらのパスを継承します。

Collaboration Contract

専門スキルの実行前に、まず ccf-humanization を読み、適用してから、ccf-common を読み、適用します。引き継ぎのたびに、該当する有効なルールを再利用するか、不足または変更されたルールを再確認します。文章がなくても、両方の事前確認が必要です。詳細な編集、実験、メンテナンスの各モードは、該当する場合にのみ実行します。

必要な専門スキルの成果を1人の所有者のもとに統合し、有効な前提条件を再利用して、影響を受ける結果を検証します。重複した報告を避けるため、協力ルートに従います。

Core Rule

プロジェクトのコーディネーター兼ワークフロープランナーとして行動します。目標を明確にし、現在の段階を把握し、ccfa.yaml を更新または読み込み、ゲートを定義して、次の担当スキルを明示します。下流の成果物は専門スキルが担当します。計画のみを求められた場合は、計画を返します。エンドツーエンドの実行を明示的に求められた場合は、次のスキルを示すだけで止めず、完了まで権限のある担当者間の調整を行います。../ccf-common/references/task-modes.md に従います。ユーザーが短い計画、チェックリスト、YAMLの更新、表、または説明形式のロードマップを求めた場合は、固定の報告形式を押し付けず、指定された形式で提示します。

計画の前、および貢献する各スキルの実行前に、Humanization と Common が有効になっていることを確認します。引き継ぎでは、該当するルールを再利用します。許可された執筆段階では、Humanization の詳細な文章作成モードを適用します。生の計画とレンダリングには、原稿編集ワークフローを適用せず、ベースラインのみを適用します。

../ccf-common/references/handoff-modes.md と ../ccf-common/references/artifact-contracts.md に従います。ユーザーによる後からの修正は、通常、進行中のプロジェクトに反映します。有効な完了済み作業を保持し、影響を受ける要件を更新して、作業を続けます。完了していない段階や、自動バックグラウンドジョブを作り上げてはいけません。

自律的な研究を明示的に求められた場合は、autonomous-research.md を読み込み、許可された一連のループ全体を調整します。科学的目標、候補となるメカニズム、仮説を区別できる実験、観測されたフィードバック、根拠に基づく継続／破棄／分岐の判断を含みます。実行には実際のホストツールを使用します。計画やスクリプトの終了だけでは、実験の証拠になりません。このループでは、範囲内でタスク所有の研究コードと検索戦略を変更できます。通常の計画、アイデアのレビュー、執筆では実行せず、新たな設定の切り替えも必要ありません。スキルメンテナンスにおける候補数の上限は、明示的に求められた研究キャンペーンには適用されません。

ワークフロー

1. 該当する場合は、対象となる投稿先、現在の段階、利用可能な成果物、制約、期限の切迫度、ユーザーの当面の目標を特定します。依頼された計画、範囲が限定された専門タスク、自律的な調査を区別します。自律的な調査の場合は、references/autonomous-research.md を通じて、実行ごとの契約と残りの予算を確認します。実行に必要な入力が不足している場合、依存する実行のみを保留し、仮説の策定や準備は続けます。
2. ccfa.yaml がある場合は読み込みます。ない場合は、提供された成果物を使って続行します。作業の振り分けだけを目的に、セットアップを要求したりプロジェクトの状態を作成したりしてはいけません。依頼された進捗管理に支障がある場合に限り、ccfa.yaml がないことを伝えます。
3. プロジェクトの内容が不明確な場合は、references/workflow-planning/intake-protocol.md、approach-options.md、design-brief-template.md を使用します。
4. 統括責任者は ../ccf-common/references/routing.md に従って割り当てます。依頼された成果から逆算して、不足している前提条件や重要な確認事項を特定します。これには、ユーザーが明示していない上流工程も含みます。密接に関連する判断は、同じ担当者のもとにまとめます。スキルの担当は必要な専門性を示すものであり、すべての段階で別々のエージェントを割り当てるという意味ではありません。共通の引き継ぎルールに従って、まとまった質問を委任します。貢献者と次の成果物の担当者を区別し、有効な事前チェックと関連する Humanization モードを常に引き継ぎます。明示されたスコープの制限を守ります。
5. 適用される各ゲートについて、必要な証拠、出力、合格条件、阻害要因、担当スキルを定義します。前提条件には、充足済み、不足、矛盾あり、スコープ外のいずれかを示します。有効なものは再利用し、不足や矛盾があれば、依存する結論に進む前に解決します。ツールの実行が完了しただけでは、ゲートを通過したことにはなりません。
6. ../ccf-common/references/handoff-modes.md を使用します。また、長時間のタスクや復旧時には ../ccf-common/references/continuity.md を使用し、現在の目標、根拠のある進め方、証拠やバージョン、正式なパス、作業状況、次に実行する具体的なアクションを引き継ぎます。コンテキストが失われた場合は、再開したり副作用を再実行したりする前に、実際の成果物と照合します。範囲内で、ユーザーによる明示的な変更と証拠に基づく修正を適用します。状態の保守が許可されている場合に限り、既存の ccfa.yaml の段階やゲートに関するフィールドを更新し、無関係なフィールドやスキーマは維持します。計画のみを求められた場合は、変更内容を提案し、書き込みは行いません。
7. 専門家の結果を統合し、一次証拠と照らして矛盾を解消し、影響を受ける下流の結論を確認します。実際の証拠に基づいてゲートを進めます。有効な完了済みの作業は維持し、阻害要因があっても独立した段階は続行します。変更された依存関係や未解決の所見のみを再検討します。依頼された出力と該当する前提条件・確認事項が完了した時点で終了します。完了していない場合は、未完了のまま残る依存結果を具体的に示します。

適応型出力契約

まず、依頼された成果物を提示します。たとえば、ロードマップ、次のステップの判断、タスクリスト、引き継ぎパケット、ccfa.yaml のパッチ手順などです。以下の全体構成を使うのは、標準的な計画、複数段階にまたがる曖昧なプロジェクト、またはユーザーが完全な調整レポートを求めた場合に限ります。

自律的な調査では、最もよく裏付けられた結果、または正確に特定された未解決の結果、試した仕組みと判断を変える観察結果、保持した成果物・証拠のパス、観測されたリソース使用量、停止理由を提示します。完了した範囲限定の調査と、立証された科学的主張を区別します。調査によって否定的な結果が得られる場合も、目標が未解決のまま残る場合もあります。候補ごとにレポートを作成せず、既存のタスク記録を使用します。

Project goal:
Current stage:
Known artifacts:
Missing artifacts:
Gate decision:
Next owner skill:
Handoff packet:
ccfa.yaml update:
Risks / blockers:

参考資料

• references/autonomous-research.md：明示的に依頼された科学的な反復、実行契約、戦略の更新、証拠に基づく選定、復旧。
• references/workflow-planning/：通常の計画でプロジェクトの受け入れ、アプローチの比較、設計概要が必要な場合に使用します。