v4.0 適応型ワークフローポリシー: Harness CLI は最適な開発フローをどう選ぶか¶
Quick Answer: Harness CLI v4.0 は、最初にタスクを分類してから必要なプロセスだけを選びます。質問や読み取り専用の確認は
noopまたはdirect、小さく明確な変更はguarded、複数ステップ・高リスク・委譲・再開が必要な目標はplannedです。計画の状態は別にnone、reuse、createとして扱われるため、短い確認を新しい計画として誤作成しません。
すべての依頼に同じ手順を適用すると、AI コーディングツールは重くなります。一行の調査に作業項目は不要ですが、ドキュメント、テスト、リリース証拠を含む変更は記憶だけに頼るべきではありません。v4.0 はこの境界を明示的に扱います。
4 つのワークフロールート¶
| ルート | 使う場面 | 典型的な結果 |
|---|---|---|
noop |
空入力、確認、実行可能な依頼がない場合 | リポジトリを変更しない |
direct |
質問、読み取り専用調査、状態確認 | 証拠に基づく回答 |
guarded |
小さく明確なローカル変更 | 編集ゲートと集中検証 |
planned |
複数ステップ、不明確、高リスク、委譲、再開可能な目標 | 永続化された作業項目と playbook |
ルートは適応型です。「長い依頼だから planned」「ファイルを変更するからチーム」という意味ではありません。範囲とリスクで判断します。
計画の永続化は別の判断¶
実質的な依頼では、次の二つを分けて決定します。
- どのルートで実行するか。
- 計画をどう扱うか。
計画状態は次の通りです。
none: 永続計画を作成・再利用しない。reuse: 明示的な「continue」または「resume」の後、対象となる活動中の計画を再利用する。create: 新しい planned 目標のために作業項目を作成する。
これにより、「了解」「続けて」といった短い返事を新しい目標として扱う事故を防げます。同じセッションの確認は現在の作業項目に紐づけ、クライアントをまたぐ再開では明示的な合図と必要な handoff だけを読み込みます。
planned ルートの境界¶
計画型の実行では、次の境界が残ります。
- 目標と範囲を分類して記録する。
- brainstorming、plan、TDD、systematic debugging など必要な playbook だけを選ぶ。
- ファイルを変更する前に
pre-edit-safety-gateを通す。 - 完了を宣言する前に検証証拠を保存する。
planned は必ずチームを意味しません。中断から戻る必要がある目標は solo harness で実行でき、独立した領域だけをチームに分けます。依存関係のある変更は順番に進めます。
Dry run と live readiness は違う¶
dry-run は設定、ルート、入力を確認しますが、外部モデル、ブラウザセッション、MCP サーバー、認証済みアカウントの利用可能性までは証明しません。状態表示では、設定受理、ローカル検証、外部依存、人的承認を分けて示す必要があります。これは運用にも検索・回答エンジンにも有効です。
推奨の開始手順¶
新しい checkout では、まず次を実行します。
aios init --all
aios doctor --native --verbose
現在のルート表はワークフローポリシーで確認できます。クライアント設定はクイックスタート、中断から再開する設計はSolo Harnessを参照してください。
FAQ¶
すべてのコード変更に計画が必要ですか？¶
いいえ。小さく明確な変更は guarded で十分です。依存するステップ、設計の不確実性、リスク、委譲、再開の必要性があるときに planned を使います。
planned はチーム必須ですか？¶
いいえ。planned は分類であり、単一クライアント、solo harness、チームのいずれでも実行できます。
終端状態の計画を再開できますか？¶
できません。完了または blocked の計画は活動中として暗黙に再開されません。新しい目標を作るか、対象となる非終端項目を明示的に再開します。
詳しい実装境界はどこですか？¶
アーキテクチャで CLI、ContextDB、クライアント投影、ランタイム状態の関係を確認できます。トラブルシューティングにはルートと検証の失敗例があります。
小さな仕事には少ないプロセスを、信頼性が必要な仕事には追跡できる証拠を。v4.0 の考え方はそれだけです。