2.2 KiB
2.2 KiB
RP13-01継続の限定変更案（未承認・未適用）
対象は既存RP13-01のみ。P13-03最終修正は保存済みで新しいゲーム実装を起動しない。
- 個別修正上限2→3、使用済み2を保持し、追加1回を同一登録タスクの試験fixture修正に使う。差分案はproposed-isolated-rejection-fixture.patch。既存のAC-001重複登録で意図した負例に到達できない問題だけを直す。別fixtureプロジェクトを使い、P13-01/02拒否、回数・状態保持、提出なしを実際に検証する。Root prototype r02の当該1試験はPASS、元workerの2ファイルは未変更。
- 正式runner-unitをRP13-01だけ信頼ホスト自己試験で実行する。登録argv（python -B -m unittest discover -s tests -p test_runner.py -v）、全55件以上、SHA/clean/scope/spec、実ログ・exit、独立レビュー、統合/最終を保持。外側Runner Seatbeltだけをこの試験で外し、試験内の実Seatbeltと実装workerのSeatbeltは保持する。providerや任意コマンドへの適用は禁止。親Runnerの通常verify/processを使い、config/contract/phase/candidateへの限定ガードとprovenanceを記録する。完成前にアダプター全文と制約を独立レビューへ渡す。
正式sandbox試験は55件中4 failure/11 error、通常ホスト診断ではfixtureに起因する2 errorだけが残る。ホスト診断を正式passedへ変換しない。現在の正式失敗receiptは保存し、認証・課金・並列・500000・ゲーム30/88・製品値を変更しない。
これは権限の一般化ではなく、上記project/task/validator/候補phaseだけの正式自己試験実行環境変更。既存のHOST_SELF_TEST_PROPOSAL.mdはこの範囲について未承認と明記している。既存許可は提出復旧と資料重複削減だけで、cap増加とホスト正式試験変更は含まれない。
承認後の順序: Opus開始判断→同じSol workerの限定修正→通常submit→限定ホスト正式validate→別Opusレビュー→Runner候補の統合/最終→P13既存submitted結果から復旧→P13正式validator/18負例→exact packet容量→別Opusレビュー→統合/最終→原成果台帳。