12 lines
2.8 KiB
JSON
12 lines
2.8 KiB
JSON
{
|
|
"control_copy": "/private/tmp/the-tree-rp13-control-context-r01",
|
|
"live_runner_changed": false,
|
|
"fixed_spec_changed": false,
|
|
"contract_changed": false,
|
|
"policy_changed": false,
|
|
"source_core_sha256": "893ffa63f8ff1607815316d5e2368e272472e973462f63b8a09c931a96e62607",
|
|
"prompt_sha256": "3dfa89b4ef46104bb717edfdb965b4ca2220080f057527683873a08274969571",
|
|
"commander_job_id": "147e824141024cd5b97cfdbb2cbcf1bf",
|
|
"clarification": "判定: 実行はしない。技術的には、最新の成功runと result.json を、Runnerが記録したstdout.logの最終 item.completed agent_message をパースしたJSON、packet.txt、command.json、固定済みsource pinsと突き合わせる検証は、承認済みの「unknown/stale/tampered を拒否する限定復旧」を実装する手段です。新しい仕様変更ではないと判断します。理由は、仕様の required が既に「latest actual implementer result が exact task/base/contract で submitted」「unknown/stale/tampered は拒否」と定めており、その真正性確認の具体化に当たるためです。ただし次の制約を満たすことが条件です。(1) result.json 単独では受理しない。(2) 暗号的保証を新設しない。(3) runs行は latest implementer・service codex・status succeeded・exit 0 であること。(4) command.json の cwd が期待worktreeであること。(5) packet.txt が契約・base・spec と完全一致すること。(6) stdout.log の最終JSONが result.json と完全一致すること。(7) result の task/base が一致すること。(8) 旧runの provenance にハッシュが無い場合は、上記の複数の独立した信頼済み記録がすべて整合するときだけ受理し、不整合なコピーは拒否する。将来のrunにはハッシュを前向きに記録してよい。(9) 新task・repair追加・cap変更・state bypass はしない。(10) allowed_paths は runner/core.py と tests/test_runner.py のみ。待つ理由は、workerが blocked になった原因が『この基準が伝わっていない』ことであり、commander reason は現行packetに転送されないためです。このまま再実行しても同じ blocked になります。推奨(有限): オーナーが、上記(1)〜(10)を既存のサポートされた経路で workerに届く形にしてください。具体的には、spec への明確化として追記するか、既存の承認記録/blocked解消メカニズムがあればそれを使います。spec を変更すると spec_sha256 と source pins の扱いが変わるため、それはオーナー判断です。経路が確定し、workerのpacketに基準が含まれることを確認できた時点で、新規task・repair追加なしの既存の復旧経路から run を判断します。"
|
|
}
|