20 lines
7.2 KiB
JSON
20 lines
7.2 KiB
JSON
{
|
|
"job_id": "06ad915f6e1c458c998772ecb6c8167e",
|
|
"state": "succeeded",
|
|
"project": "the-tree-runner-p13-recovery",
|
|
"task_id": "RP13-01",
|
|
"operation": "commander",
|
|
"created": 1791848656.547595,
|
|
"pid": 71216,
|
|
"started": 1791848656.639148,
|
|
"exit_code": 0,
|
|
"result": {
|
|
"action": "request-repair",
|
|
"task_id": "RP13-01",
|
|
"reason": "【判断】repair2(最終・repairs=1→2、上限2内)を、許可2ファイル(runner/core.py, tests/test_runner.py)のみで実施する。ただし正式validateは、下記のホスト実行についてオーナー承認が出るまで再実行しない。\n\n【修復範囲(境界付き)】\n1. 対象status互換: 実測のP13 runs行は status=finished, exit_code=0, service=codex, role=implementer(旧プロセス規約)。この形をsucceeded相当として、recovery対象のimplementer結果判定でのみ受理する。それ以外のstatus(failed、running、不明)は引き続き拒否する。他の認可ガードはすべて維持する: scope_violation起因、exact task/base/contract、active run/operation無し、HEAD一致、spec不変、check_scope通過、stale/tampered拒否。\n2. P13-03限定: recoveryの対象をP13-03のみにする。P13-01/P13-02は拒否する。\n3. 記録済みsource pin: recovery_source_pinsがCONTROLの`git show c88e2...:docs/spec/RP13-01.json`に依存する点を除く。本番CのCONTROLにはこのパスが無く、隔離Sにしか無い。そのため配備に依存しない、記録済みpin(spec SHA、base、contract digest。workflow_hash_noteどおりgit stdout.strip UTF8の表現を明記)で検証する。CONTROLへのcommit追加はしない。\n4. 回帰fixture: 実provider、実state、実DBを使わない。含めるケースは次の5つ。(a) finished/0/codex/implementerの正例、(b) 旧status以外の拒否、(c) P13-01/P13-02の拒否、(d) CONTROLにspecパスが無い状態でも記録pinで通ること、(e) pin不一致の拒否。git showをmockして欠陥を隠すテストは作らない。実gitのtmp repoで、パスの無いCONTROLを再現する。repairs不変と下流ゲート(submit、validate、独立review、integration)を引き続きassertする。\n\n【禁止事項の維持】policy、sandbox、caps、検証バイパス、DB直接修復、再登録、上限変更は行わない。受入分母(1)、500000ガード、P24 marker filteringも変更しない。\n\n【正式unitの扱い(別問題)】\n- 失敗はtests内の実sandbox_apply呼び出しが入れ子OSで Operation not permitted になる環境要因。mock化やskipは境界受入の代替にならないため、コード修復では解決しない。\n- 外部の54 PASS(19.700s, exit0)は診断のみで、正式receiptではない。そのまま保持する。\n- 必要なのは、信頼ホストでの正式self-test実行(workerの必須outer sandboxと実54ケースを維持)。これは検証環境と受入証跡の扱いを変えるため、別途オーナーの人間承認が必要。現在のRP13-01の認可(P13限定復旧と文書dedup)には含まれない。承認が出るまで、validateとreviewは保留する。\n\n【手順】\n1. この完全なコンテキストを渡した後で、repair2のworkerを1回だけ起動する。\n2. worker完了後は、自動のvalidateではなくwaitにする。\n3. オーナーが信頼ホスト実行を承認し、有効な正式receiptが得られた後に、validate→独立review→prepare-integrationへ進む。\n4. 有効な正式receiptが出るまでは、既知の正式失敗の再実行も、reviewも行わない。\n\n【次のオーナー判断】信頼ホストでの正式runner-unit実行の可否と、その実行主体・手順。"
|
|
},
|
|
"finished": 1791848677.241099,
|
|
"stdout_tail": "{\n \"action\": \"request-repair\",\n \"task_id\": \"RP13-01\",\n \"reason\": \"【判断】repair2(最終・repairs=1→2、上限2内)を、許可2ファイル(runner/core.py, tests/test_runner.py)のみで実施する。ただし正式validateは、下記のホスト実行についてオーナー承認が出るまで再実行しない。\\n\\n【修復範囲(境界付き)】\\n1. 対象status互換: 実測のP13 runs行は status=finished, exit_code=0, service=codex, role=implementer(旧プロセス規約)。この形をsucceeded相当として、recovery対象のimplementer結果判定でのみ受理する。それ以外のstatus(failed、running、不明)は引き続き拒否する。他の認可ガードはすべて維持する: scope_violation起因、exact task/base/contract、active run/operation無し、HEAD一致、spec不変、check_scope通過、stale/tampered拒否。\\n2. P13-03限定: recoveryの対象をP13-03のみにする。P13-01/P13-02は拒否する。\\n3. 記録済みsource pin: recovery_source_pinsがCONTROLの`git show c88e2...:docs/spec/RP13-01.json`に依存する点を除く。本番CのCONTROLにはこのパスが無く、隔離Sにしか無い。そのため配備に依存しない、記録済みpin(spec SHA、base、contract digest。workflow_hash_noteどおりgit stdout.strip UTF8の表現を明記)で検証する。CONTROLへのcommit追加はしない。\\n4. 回帰fixture: 実provider、実state、実DBを使わない。含めるケースは次の5つ。(a) finished/0/codex/implementerの正例、(b) 旧status以外の拒否、(c) P13-01/P13-02の拒否、(d) CONTROLにspecパスが無い状態でも記録pinで通ること、(e) pin不一致の拒否。git showをmockして欠陥を隠すテストは作らない。実gitのtmp repoで、パスの無いCONTROLを再現する。repairs不変と下流ゲート(submit、validate、独立review、integration)を引き続きassertする。\\n\\n【禁止事項の維持】policy、sandbox、caps、検証バイパス、DB直接修復、再登録、上限変更は行わない。受入分母(1)、500000ガード、P24 marker filteringも変更しない。\\n\\n【正式unitの扱い(別問題)】\\n- 失敗はtests内の実sandbox_apply呼び出しが入れ子OSで Operation not permitted になる環境要因。mock化やskipは境界受入の代替にならないため、コード修復では解決しない。\\n- 外部の54 PASS(19.700s, exit0)は診断のみで、正式receiptではない。そのまま保持する。\\n- 必要なのは、信頼ホストでの正式self-test実行(workerの必須outer sandboxと実54ケースを維持)。これは検証環境と受入証跡の扱いを変えるため、別途オーナーの人間承認が必要。現在のRP13-01の認可(P13限定復旧と文書dedup)には含まれない。承認が出るまで、validateとreviewは保留する。\\n\\n【手順】\\n1. この完全なコンテキストを渡した後で、repair2のworkerを1回だけ起動する。\\n2. worker完了後は、自動のvalidateではなくwaitにする。\\n3. オーナーが信頼ホスト実行を承認し、有効な正式receiptが得られた後に、validate→独立review→prepare-integrationへ進む。\\n4. 有効な正式receiptが出るまでは、既知の正式失敗の再実行も、reviewも行わない。\\n\\n【次のオーナー判断】信頼ホストでの正式runner-unit実行の可否と、その実行主体・手順。\"\n}\n",
|
|
"stderr_tail": ""
|
|
}
|