Skip to content
Deep Work Plan が本日 Product Hunt に登場 応援する
← すべての仕様ドキュメント

Lite 計画

バージョン 5.0.0。状態: 安定。 この文書は、DWP 仕様 と並んで導入された Lite 計画の表現形式を規定します。小〜中規模の境界づけられた作業のための計画フォーマットであり、非実行可能なドラフト段階を経ることなく直接マテリアライズされます。キーワード MUST、MUST NOT、SHOULD、SHOULD NOT、MAY は、RFC 2119 に記述されたとおりに解釈されます。

表現形式とライフサイクル

計画は次の二つの表現形式のいずれかでなければならず(MUST)、manifest.jsonplan_format として一度だけ記録されます。Full<n>.task_<slug>.md の下にタスクごとに一つのファイルを保存します。Lite はコンパクトで実行可能なタスクレコードを README.md にインラインで保存し、各レコードは安定した {#task-N} アンカーの背後にあります。Lite 計画は部分的な、あるいは非公式な Full 計画ではありません。すべてのタスクレコードは、タスク構造 が Full について定義するのと同じ規範的な形で、目標、変更対象面、受け入れ基準、検証ゲート、そして完了ログを引き続き持たなければなりません(MUST)。

計画の状態は四つの軸で記述され、混同せず独立して追跡されなければなりません(MUST)。

意味
形式 litefull タスクレコードがどこにあるか
マテリアライゼーション materializingreadypromoting 計画フォルダーが書き込み中か、完了しているか、昇格の途中か
承認 pendingapprovedpre_approved 人間が計画をレビューしたか、trust モードが事前承認したか
実行 pendingin_progressblockedcompleted タスクごとおよび全体の進行状況

ガイド付き create は レビュー可能な保留中の提案 を書き出します — Lite であれ Full であれ、それはすでに本物の計画であり、使い捨てのドラフトでは決してありません。trust は 準備完了で事前承認済み の計画を直接マテリアライズし、即座に制御を返します。create と昇格は製品作業を決して実行しません。明示的な execute または resume のリクエストは計画の現在の準備完了スコープを承認するものであり、作業開始前にその承認を記録しなければなりません(MUST)。そのリクエストなしでは、pending の提案は実行できません。未解決の昇格が進行中の計画は、製品作業の前に必ず回復されなければなりません(MUST)。

作成と形式選択

/dwp-create は、大規模な作業だけでなく、あらゆる規模の計画意図に応えます。規模が小さく境界づけられた作業 — 単一の関心事、おおよそ一回の作業、調整不要 — は Lite 計画の対象です。実際のスコープを持つ複数ステップの作業は、比例したリゴー に従いデフォルトで Full になります。直接の編集、説明、状態確認、再開、あるいは明示的な計画不要の要求は、それぞれ独自の経路を保ち、計画になることは決してありません。

litefull形式の希望 です。trustauto はそれとは別の 対話オプション であり、どちらの種類のオプションも、リクエストのどちらの端に、どの順序で現れても構いません(MAY)。

/dwp-create trust fix the label
/dwp-create lite trust fix the label
/dwp-create fix the label trust lite
/dwp-create fix the migration full trust

同じオプションを繰り返すのは冪等です。litefull を同時に要求するのはエラーです。-- はオプション解析を終了します。

形式の希望が指定されない場合、create は一つを推奨し、その理由を説明します。明示的な Full の要求は常に優先されます。明示的な Lite の要求は、その作業の要件や検証ゲートがコンパクトなインラインレコードに収まらない場合を除いて尊重されます — その場合、create はなぜ代わりに Full が必要かを記録します。この選択は、観察されたスコープ、依存関係、必要な指示の詳細度、そして未知の要素を、選択の背後にある根拠として記録しなければなりません(MUST) — これは監査可能な判断であって、あらゆるモデルやエージェントを通じて成り立つ保証ではありません。

Lite は、Full と同じ方法で並列化の決定を保持します: Execution: sequential — {rationale} の行、または Team Agents Configuration セクションを用い、タスクごとの Team Agents Metadata は、別のタスクファイルではなく、アンカーされたタスクレコードに直接添付されます。この決定は Lite においても決して暗黙のままにはなりません — Lite 計画は、Full 計画とまったく同じようにそれを明記します。

昇格と互換性

Lite 計画は、/dwp-refine promote {plan_name} を介して、いつでも Full へ 昇格 しても構いません(MAY)(dwp-refine を参照)。昇格は 表現形式のみ に関わるものです。それは意図を記録し、移行先のタスクファイルを書き込み、Lite レコードが持っていたすべての要件とゲートが引き続きカバーされていることを検証し、権威あるコピーをインラインの README レコードからタスクファイルへ切り替え、それから進行中マーカーを消去します。昇格マーカーが設定されたままの間、executeresume は続行を拒否しなければなりません(MUST)。すでに記録されたタスク ID と完了の証拠は、昇格によって書き換えられてはなりません(MUST NOT)。昇格の途中で発見された新しいスコープは、代わりに refine を通過し、それが影響する証拠のみを無効化します。

昇格が自動的に逆方向へ進むことは決してありません。Full 計画が静かに Lite へ折り畳まれることはありません。より前の仕様バージョンのもとで書かれた計画 — plan_format フィールドをまったく持たない v1 の Full 計画を含む — は、その記録された形をそのまま保持し、適合したままです。refine セッションが意図的にそれを移行することは MAY ありますが、暗黙のうちにそうする仕組みは何もありません。

manifest.jsonplan_format は一度書き込まれると不変です。昇格は state.jsonformat を変更し、その promotion マーカーを消去しますが、マニフェストを書き換えることは決してありません。正確な plan_formatformatmaterializationapprovalpromotionlocator の各フィールドとその v2 スキーマ URL については、計画の状態 を参照してください。