Skip to content
← すべての仕様ドキュメント

リソースと能力

バージョンの適用範囲: このページは、現在の標準である DWP 7.0.0 の四つの規範文書をリリース v7.9.0 時点で要約したものです:V6_CONTEXT.md、V6_RESOURCES.md、CONFIG.md、V7_ABILITIES.md。このページとそれらのファイルが食い違う場合は、ファイルが優先されます。

状態: 安定(コンテキストとリソースは 6.0.0 から、設定と能力は 7.0.0 から)。 これらの規則は v6 系の計画(レコードレイヤー)を拘束し、v5 の標準には影響しません。キーワード MUST、MUST NOT、SHOULD、SHOULD NOT、MAY は、RFC 2119 に記述されたとおりに解釈されます。

タスクごとのコンテキストマニフェスト

各タスクの前に、エージェントは契約とジャーナル全体からコンテキストマニフェストを導出します(context_manifest.py)。これは導出されたビューであり、状態として保存されることは決してありません。同じレコードから二度導出すると同一のバイト列を生成しなければならず(MUST)、マニフェストは計画とそのリポジトリの外を読んではなりません(MUST NOT)。その形は context-manifest/v6 として公開されています。

セクション 導出元
identity 計画名、ライブの契約 id とリビジョン
authorization 同意チェックポイントを含む、承認イベントそのもの
repository_rules 契約のスコープと、現在の評価状態を伴う不変条件
acceptance タスクの基準とその閉鎖状態
touched_surface 宣言されたファイルと現在のコンテンツハッシュ。欠けているファイルは欠落として表示される
evidence ディスク上で解決される、ウィンドウ内の証拠ポインター
dead_ends 失敗したゲート、拒否、拒否された適応、識別力のないコントロール
freshness マニフェストが要約する入力のフィンガープリント
next_action 具体的なコマンドを伴う、ちょうど一つの次の手順

authorization、repository_rules、acceptance は必須です。コンテキストの刈り込みによって、受け入れや認可の境界が隠されることは決してありません。次の行動のラダーは順序が決まっており(承認、開始、権威、コントロール、証拠、完了)、通常の合格ゲートを、コントロールされた基準を閉じるものとして提示することは決してありません。

行き止まりは保持されます。 エントリーがダイジェストから外れるのは、記録上の事実が証明された場合(同じフィンガープリントが後に合格した、より新しい重複した拒否がそれを置き換えた、契約のリビジョンによって期限切れになった)に限られます。単なる変更対象面の変化でそれを落としてはなりません(MUST NOT)。鮮度は検査されます。 記録された入力フィンガープリントがもはや一致しない要約は古く、フィンガープリントのない要約は構造上古いものとされます。履歴はトリガーによってのみ読み込まれます — 記録されたハンドオフ、またはそのタスクに影響する修正です。それ以外では、マニフェストだけがタスクのコンテキストです。

四つの量による計上

指示の負荷とコストは、四つの異なる量として報告されます:静的な指示バイト数、プロバイダーのトークン数(ホストのメーターが記録した場合のみ)、金銭的コスト(記録された実レートのサンプルからのみ)、経過時間(イベントのタイムスタンプから)。欠けている量は理由とともに欠落として報告され、推定で補われることは決してありません。また、バイト数がトークン数や金額に換算されることも決してありません。

ホストの能力

ランタイムのホストは、閉じた集合 stop_agent、meter_spend、meter_tokens、meter_wall_clock、cancel_children、model_routing、subagents、telemetry から自らの能力を宣言します。未知の能力は拒否されなければならず(MUST)、宣言されていない能力は false です。最小のホスト — モデルの切り替えなし、サブエージェントなし、テレメトリーなし、停止なし — はサポートされる態勢であり、決してエラーではありません。欠けている能力を必要とするすべての上限は、欠けている能力の名前を示したうえで助言的なものに格下げされます。

能力は付与ではありません。契約における付与は権威であり、能力は環境が実際にできることです。能力を必要とするすべての態勢は、依然としてその付与も必要とします。

リソースエンベロープ

契約はリソースエンベロープで上限を宣言することが MAY あります。上限が強制されるのは、実際の計測ソースを指定している場合に限られます。そうでなければ助言的であり、ホスト間での強制の同等性が主張されることは決してありません。

  • カウンターのソース。 ジャーナルから観測できるカウンター(経過時間の幅、ゲートの再試行、ディスパッチの呼び出し)は、計画自身のレコードから計算されます。ホストのみのカウンター(支出、プロバイダーのトークン数)には、対応するメーターの能力と、ホストアダプターからの observed のサンプルが必要です。欠けているカウンターは無料の使用を意味しません。
  • 予備枠。 上限は reserve を宣言することが MAY あり、これにより検証、再試行、再開が通常の作業によって枯渇させられることはなくなります。消費済みと保留中の合計が上限から予備枠を引いた値を超える場合、ディスパッチは拒否されます。
  • 枯渇。 上限に達すると、未完了のチェックポイントが永続化され、LIMIT: exhausted <id>: <detail> が記録され、明示的な LIMIT: recovered <id> レコードがあるまでディスパッチが保留されます。枯渇が受け入れ基準を満たすことは決してありません。
  • キャンセルの精算。 進行中の予約は、解放または確定としてちょうど一度だけ精算されます。矛盾する二度目の精算は拒否され、調停されることは決してありません。
  • ルーティングの態勢。 既定は固定のモデルです。モデルの階層の切り替えには、model_routing の付与と同名の能力の両方が必要です。並列ディスパッチには、agent_delegation の付与と subagents の能力の両方が必要です。ルーティングの態勢は権限の表明であり、有効性の主張では決してありません。

設定ファイルとアドオンレジストリ

.dwp/config.json(リポジトリ)と ~/.dwp/config.json(ユーザー)は、dwp-config/v1 として公開されている一つの形と、一つのパーサー(config.py)を共有します。方法論は、設定ファイルもアドオンもなしで機能します。 このファイルのいかなる内容も、計画、フロー、適合性をアドオンに依存させることはできません。

  • 既定で追跡される。 リポジトリのファイルは決定事項を保持し、シークレットは決して保持しません。チームメイトと CI が同じレジストリを読めるよう追跡されます。オンボーディングは .gitignore に .dwp/* と !.dwp/config.json のルールを書き込みます。計画とベンチマークのレコードは無視されたままです。
  • 優先順位。 リポジトリのファイルがユーザーのファイルより優先され、ファイルが存在しないことはすべてが無効であることを意味します。addons キーはアドオンのキーごとに解決され、benchmark キーは全体として解決されます。
  • レジストリのキーは、パック内のアドオンのディレクトリ名です:ai-diff-reviewer、agentkit、dailybot、dependency-upgrade、design-system、devcontainer、herdr、vim。各エントリーは enabled(true のみが有効化する)、任意の version、任意の一行の note を持ちます。未知のキーは一度の警告とともに無視されます。
  • 存在しないことは有効でないことを意味する。 何かを有効にできるのは、開発者の同意を得たオンボーディング、アドオン自身のインストール手順、または人間だけです。有効にされているが検出されず、メモを持つアドオンは、延期されたものとして報告されます。
  • フェイルクローズな読み取り。 読み取れないファイルや不正な値は何も寄与せず、ちょうど一度の警告を生みます。読み取り側がフローを中断することは決してなく、破棄したものについて黙っていることも決してありません。書き込み側はアトミックに照合し、解析できないファイルの上書きを拒否します。
  • ホストの記録。 任意の host キーは、マシンが宣言した能力(閉じた集合からの真偽値)を記録します。telemetry: true には引き続き開発者の同意が必要です。
  • ベースラインは変わらない。 AI Diff Reviewer のローカルレビューは、レジストリがそれを指定しているかどうかにかかわらず、すべての Final Review の一部であり続けます。

アドオンが提供する能力

7.0.0 から、有効なアドオンは実行時に能力を追加できます。

effective abilities = host-declared abilities ∪ abilities provided by every addon that is enabled, described by a valid addon.json, detected, and on a compatible interface version

つまり、実効的な能力は、ホストが宣言した能力と、有効にされ、有効な addon.json で記述され、検出され、互換性のあるインターフェースバージョン上にあるすべてのアドオンが提供する能力の和集合です。

  • 記述子。 パック内の各アドオンは addon.json(addon-descriptor/v1)を同梱し、そのキー、提供するもの、検出方法を宣言します。
  • 検出は読み取り専用。 検出コマンドはシェルを介さず、標準入力を閉じ、10 秒のタイムアウトで実行され、出力されたものが実行されることは決してありません。報告されたインターフェースのメジャーバージョンが固定されたものと異なるプロダクトは利用不可とされ、一度の警告が出ます。
  • 有効でなければ参照されない。 無効なアドオンの記述子は開かれず、その検出コマンドも実行されません。和集合は単調です。アドオンを有効にしても、能力が増えることしかありません。
  • 永続化されない。 実効的な能力は呼び出しのたびに再計算され、計画に書き込んではなりません(MUST NOT)。計画は利用可能だったものではなく、使用したものを記録します — 委任イベントはそのトランスポートとアドオンを指定します。
  • 能力は権威ではない。 agentkit アドオンは subagents、cancel_children、model_routing を提供でき、Herdr アドオンは subagents と cancel_children を提供できます。委任には引き続き契約の agent_delegation の付与が必要です(委任)。

resources.py abilities は実効的な能力の集合と、各能力の出所を表示します。これは読み取り専用です。

関連