レコードレイヤー
バージョンの適用範囲: このページは、現在の標準である DWP 7.0.0 が土台とする規範的な v6 レコードレイヤーを要約したものです。リリース
v7.9.0における正規の情報源はV6_CONTRACT.mdとV6_LIFECYCLE.mdです。このページとそれらのファイルが食い違う場合は、ファイルが優先されます。v5 計画は 計画の状態 レイヤーを維持し、暗黙のうちに移行されることは決してありません。
バージョン 6.0.0、7.0.0 で拡張。状態: 安定。 レコードレイヤーは、物語的な完了報告をレコードで置き換えます。契約が権威であり、ジャーナルが記憶であり、ヘルパーが書き込みを行い、生成されるすべてのファイルは投影です。キーワード MUST、MUST NOT、SHOULD、SHOULD NOT、MAY は、RFC 2119 に記述されたとおりに解釈されます。
一行で表すモデル
計画は、人が書く二つの成果物と、ガードされた一つのシーケンスです。計画の Markdown（README.md とタスクファイル）は、何を行うかを述べます。アウトカム契約（contract.json）は、何をもって完了とみなし、計画に何が許されるかを述べます。ジャーナル（journal.ndjson）は、実際に何が起きたかを記録します。state.json と views/ はジャーナルから再生成され、手で編集してはなりません（MUST NOT）。生成されたファイルとジャーナルが食い違う場合はジャーナルが優先され、ファイルが再生成されます。
世代の検出
計画フォルダーが v6 系の計画であるのは、contract ポインターが解決される manifest.json、contract.json、または contracts/ のリビジョンチェーンのいずれかを持つ場合であり、かつその場合に限ります。検出はこれらの成果物を用いなければならず（MUST）、インストール済みのパックのバージョンを用いてはなりません。現在のパックが v5 計画を抱えていることも、古いパックが v6 計画に出会うこともあるためです。
契約の schema URL がその世代を示し、マニフェストとすべてのジャーナルイベントはそれを反映します。
| 世代 | 契約 | ジャーナルイベント | マニフェスト | 追加されるもの |
|---|---|---|---|---|
| v6 | plan-contract/v6 |
journal-event/v6 |
plan-manifest/v6 |
— |
| v7 | plan-contract/v7 |
journal-event/v7 |
plan-manifest/v7 |
parallel_safe と delegation イベント（委任） |
7.x パックが作成する新しい計画は既定で v7 です。明示的に v6 を要求すれば、引き続き v6 の契約がマテリアライズされます。計画が世代を変えることは決してなく、世代が混在したジャーナルは拒否されなければなりません（MUST）。どちらの世代も同じ plan-snapshot/v6 の形へ投影されます。
アウトカム契約
契約は計画ごとに一つで、その世代のスキーマに準拠します。契約は、アウトカムの記述と成功の定義、受け入れ基準、前提条件・変更対象面・ゲートの意図を伴うタスク、計画スコープの不変条件、スコープ（許可されたパス、コマンドのクラス、禁止された操作）、リソースエンベロープ、スケジューリングの上限、権限、そして認可の記録を保持します。
- 識別子。
contract_idは、id フィールドを除いた契約の正規化バイト列の SHA-256 です。その契約のもとで生成されるすべてのレコードはこれを引用します。 - 不変性。 実行が始まった後、契約を変更してはなりません（MUST NOT）。変更された契約は
contracts/配下の新しいリビジョンであり、親を引用し、連続したリビジョン番号と、新たに記録された権威を持ちます。 - 安定した id。 基準（
AC-*）、不変条件（INV-*）、タスク（T-*）は一意でなければならず（MUST）、レコードはリスト上の位置ではなく id を引用します。タスクグラフは非巡回でなければならず（MUST）、すべてのゲートの意図は宣言された基準を参照しなければなりません（MUST）。 - 権限。 付与された能力と付与されていない能力は、閉じた集合
gate_command_exec、fs_write_plan_scope、fs_write_repo_scope、git_operations、network_access、host_adapter_metering、agent_delegation、context_exportの互いに素な部分集合でなければなりません（MUST）。 - 認可。 仕組みは厳密に
plan_authorship（実行前に人間が計画を作成またはレビューした）かpre_authorization（トラストモードのように、エンベロープが明示された常設の付与）のいずれかです。どちらも同じようにゲートし、異なるのは記録される権威だけです。 - 閉じられること。 すべての基準は閉じられるものでなければなりません（MUST）。タスクがゲートする基準は、受け入れる証拠クラスに応じて、そのゲートからの
observedの証拠か、assertedの人間によるサインオフによって閉じられます。どちらも受け入れない草案の基準は拒否されます。
マテリアライゼーション
計画は、同梱のヘルパー（ledger.py materialize）によってマテリアライズされ、手作業で行われることは決してありません。手順は厳密に次の順序で、各手順は冪等かつ再開可能です。
- 契約ポインターを持つ
manifest.json。マテリアライゼーションが中断されても計画の世代を発見できるよう、最初に書き込まれます。 - 検証され、コンテンツアドレス化された
contract.json。 - 契約 id と計画 Markdown のダイジェストを引用する
approvalジャーナルイベント。
タスク開始のゲートを開くのは、この approval イベントだけです。これを伴わない手でコピーされた契約はタスク開始時に拒否され、ポインターがマテリアライズ中の契約と一致しないマニフェストは、書き換えられるのではなく拒否されます。
ジャーナル
journal.ndjson は追記専用です。一行につき一つの閉じた JSON オブジェクトで、編集も削除もされません。訂正は後続のイベントとして行います。すべてのイベントは、スキーマ、種類、厳密に増加する seq、タイムスタンプ、計画、contract_id、そしてアクター（helper、agent、host_adapter、human）を持ちます。イベントカタログは、タスク開始、承認、ゲート実行、観測、適応、修正、介入、リソースのサンプル、コントロールペア、スケジューラーの選択、拒否、ビューのレンダリング、照合、ジャーナルの修復を網羅し、v7 は委任イベントを追加します。すべての拒否はそれ自体が記録されます。
証拠クラス
証拠を伴うイベントは信頼ラベルを記録します。
- observed — 同梱のヘルパー自身が、宣言された作業ディレクトリ、環境、タイムアウトのもとでチェックを実行し、出力を取得したもの。observed のゲート証拠を生み出すのはゲートランナー（
ledger.py gate）だけです。報告された結果を書き留めるだけのエージェントには生み出せません。 - imported — 来歴を伴って、一致する外部ソースから取り込まれたもの。たとえば、証拠ポインターが解決される、移行済みの v5 ゲートレコードです。
- asserted — 独立した裏付けなしに述べられたもの。
各基準はどのクラスを受け入れるかを宣言するため、observed のみを受け入れる基準が主張だけで閉じることは決してありません。チェックサムはバイトの同一性を立証するものであり、意味上の真実を立証するものではありません。レコードレイヤーは構造と来歴を検査し、プロダクトの意味を証明するものではありません。
人間によるサインオフ
人間が判断しなければならない基準は、ledger.py signoff --criterion <AC> --evidence-path <artifact> --authority <who> によって閉じられます。サインオフは asserted として記録され、根拠となる成果物を引用し、宣言したタスクの証拠ウィンドウ内でのみ有効であり、asserted を受け入れる基準だけを閉じます。エージェントが人間の代わりにサインオフすることは決してありません。マテリアライゼーションの外で書かれる人間アクターのレコードは、明示的な権威マーカー（人間が書き、パスとダイジェストで記録されたメモ、または対話的な確認）を持ちます。台帳は人物を認証できないため、このマーカーは主張を observed にするのではなく、監査可能にします。
コントロールされた基準
回帰コントロールまたは識別コントロールとして宣言された基準は、識別力のあるコントロールペアによってのみ閉じられます。すなわち、チェックが開始リビジョンでは失敗し、新しいリビジョンでは合格することです。両方の脚で合格するペアは識別力がないものとして記録され、切り上げられることは決してありません。開始時のツリーが汚れている場合や古い脚が利用できない場合は、コントロール利用不可として記録され、合成されることは決してありません。
実行と完了
ディスパッチは決定的なスケジューラー（scheduler.py ready）から行われ、ledger.py start は前提条件が未完了のタスクを拒否します。各タスクの開始時には作業ツリーのフィンガープリントが記録され、証拠は、同等のフィンガープリント上の同じタスクと基準に対してのみ再利用されます。
不変条件は計画スコープです。 宣言された各不変条件は計画全体を通じて成り立ち、あらゆる境界で観測（INV-<id>: pass または INV-<id>: fail: <reason>）として評価されます。一部のタスクだけが満たすべき性質は、それらのタスクの受け入れ基準であり、不変条件ではありません。
完了は導出されるもので、宣言されるものではありません。 いずれかの基準にウィンドウ内の受け入れ可能な証拠がない間、またはいずれかの不変条件に新しい合格の評価がない間、ledger.py complete は拒否し、その拒否を記録します。スナップショットは、レコードが裏付けるときに限りタスクを完了として表示します。
適応と修正
実行中の変更はスケジューラーへの提案であり、閉じた集合 split、reorder、insert、change_strategy、retry に限られます。適応は、要件を削除すること、受け入れを弱めたり差し替えたりすること、スコープや権限を広げること、エンベロープを超えて消費すること、未実行のシナリオを完了とすることをしてはなりません（MUST NOT）。
スコープ、受け入れ基準、権限、エンベロープの変更は契約の修正です。ledger.py amend は改訂された契約を次のリビジョンとして準備し、以前の証拠を無効にする基準とともに修正を記録し、人間の権威マーカーを伴う新たな承認を求め、その後で初めてライブの契約を切り替えます。中断された修正は最初の欠けた手順から再開されます。計画の作成者であることがリビジョンへ引き継がれることは決してありません。
レシート、ビュー、エクスポート
outcomes.py receipt はレコードから計画のアウトカムを再計算するため、レコードが変われば結果も変わります。手書きされることは決してありません。views.py render は人間が読めるビューを再生成します。人間が編集したビューは報告され、黙って上書きされることは決してなく、その照合自体も記録されます。.dwp/ は gitignore されているため、ledger.py export --dest <dir> はジャーナル、スナップショット、契約チェーン、引用されたすべての証拠成果物をまとめ、永続化や別のホストでの利用に備えます。
読み取り専用のサーフェスと再開
status と verify は v6 系の計画に書き込むことは決してありません。純粋なコマンドと生成された投影を通じて報告します。再開するホストは決まった順序（検査、検証、投影、記録された権威によるレンダリング）で復旧し、古くなったフィンガープリントを、再利用可能な結果ではなく、再実行すべき無効化された証拠として扱います。ジャーナルが会話のコンテキストとして再生されることは決してありません。作業は、タスクごとの コンテキストマニフェスト を伴う実行ループを通じて再開されます。
共存と移行
v5 計画と v6 系の計画は一つの .dwp/plans/ に共存することが MAY あり、それぞれがその全期間にわたって自らの世代のもとで実行されます。v5 から v6 への唯一の経路は、検証済みのバックアップとロールバックを伴う、明示的でプレビュー付きのマイグレーション（refine を通じて実行される migrate_v6.py）です。移行された v5 の履歴は、証拠が解決される場合は imported、そうでなければ asserted となり、observed になることは決してありません。逆方向の移行は存在しません。