Record Opus semantic review recommendation before final P08 regression

docs/plans/original-completion-2026-10-02/execution/p08-03/CURRENT_ACCEPTANCE_STATUS.json

@@ -16,5 +16,7 @@
   "denominator_units": 88,
   "completed_delta": 0,
   "formal_validator": "passed:1c1e23a695664c0999a6924211108c00-validation.json",
-  "next_action": "required final175 then independent semantic acceptance; capacity approval requested for2closed regenerated caches"
+  "next_action": "Opus recommends independent all5-condition semantic review before costly final175 to decide green preview followed by domain refusal; final175 and final acceptance still mandatory",
+  "semantic_triage": "OPUS_PRE_FULL_SEMANTIC_TRIAGE_7E2368F5.json (read-only, no acceptance)",
+  "capacity": "two closed generated cache deletion approval pending; no deletion performed; used Codex log excluded from compression"
 }

docs/plans/original-completion-2026-10-02/execution/p08-03/OPUS_PRE_FULL_SEMANTIC_TRIAGE_7E2368F5.json

@@ -0,0 +1,7 @@
+{
+  "action": "wait",
+  "task_id": "P08-03",
+  "reason": "WAIT (as the owner requested). This is a read-only semantic triage; I give no acceptance. Candidate 7e2368f5 passes the registered validator, but this only means the checker passed.\n\n1) What happened (confirmed in source)\n- The preview comes from world_preview.gd:201-218. It is ConstructionService.validate_placement plus _build_connection_report. It does not include the stair-landing rule.\n- The stair-landing rule exists only as a Runtime command gate, in autoload/simulation_runtime.gd:7599-7600 (`guest_stairs/service_stairs` with no path at origin+(0,-1,0) → STAIR_LANDING_MISSING). This gate predates the task and is outside allowed_paths. The spec's initial_forbidden list bans Runtime/service/construction changes.\n- The sequence: main.gd:1428-1432 shows the hover status \"配置可能 … クリックで建設\". On click, main.gd:1391-1414 sends build_facility and displays _command_failure_message(result).\n- The checker requires exactly this design. check_p08_normal_placement_evidence.py:607-609 requires status == '操作に失敗しました: '+result['message'] and report.can_build == true ('connection refusal did not reach Runtime'). Lines 581-583 require VALIDATION_FAILED/reason == STAIR_LANDING_MISSING and preserve() (whole typed state; only the command envelope may grow). The fixture is placement.gd:124-125 and 229.\n\n2) What the contract requires\n- support_connection: \"支持・接続を満たさない拒否例を実操作し、同一セルの実判定を確認する\". This asks for the actual judgment at the same cell. It does not ask for the preview to agree.\n- invalid_position_reason: \"範囲外・重複等の不正位置…表示理由と実判定コードが一致\". Those cases (boundary/overlap) are preview refusals and can_build=false under REASONS (lines 562-566). missing_connection is not one of them.\n- Overall acceptance: \"拒否理由と実判定が一致\". The rejection reason shown after the action is the Runtime reason itself, and state is preserved.\n\nSo the contract does not necessarily require a product fix. No text says the hover preview must predict every Runtime command gate. The only in-scope way to make the preview red would be to copy the Runtime stair rule into WorldPreview. That copies domain logic, which runs against production_scope (\"use existing domain refusals; do not duplicate … domain logic\"). A real fix would sit in Runtime/ConstructionService, which is forbidden and owner territory. One thing remains a real semantic question: is showing \"配置可能\" (green) before a domain refusal a mismatch between the displayed reason and the actual judgment under \"拒否理由と実判定が一致\"? I have not decided this. It needs the independent final semantic judgment.\n\n3) Recommendation and scope\n- Before the costly final175, run the independent Opus semantic review (all 5 conditions) on the R09 original evidence and candidate 7e2368f5. Name this item explicitly in that review.\n  (a) Is the green preview followed by a STAIR_LANDING_MISSING refusal acceptable under the support_connection and acceptance wording?\n  (b) Does the post-click status equal the Runtime message, and is the whole typed state preserved?\n  (c) Do the lower_stair/upper_stair positives and refused_demolition (STAIR_LANDING_IN_USE) each match their own real results? Judge them separately; do not relabel them as this case.\n- If the reviewer finds a mismatch, that is not an in-scope implementation fix. The commander should report it to the owner as a Runtime/ConstructionService preview-coverage proposal outside allowed_paths. Do not add duplicated logic to WorldPreview, and do not relax the checker or change the expected values.\n- If the reviewer accepts it, Root's final175 follows.\n\nStill pending:\n- Root R09 positive hash re-check\n- Root final full175\n- Independent Opus review of all 5 conditions\n- Integration, current final verification and ledger\n- These items stay open: the preview/runtime stair difference, coordinator runtime acceptance=false, and Windows same-distribution/device (no Mac substitution)\n- P23 manual held inputs stay deferred\n\nNo spec, denominator, value, budget or cap changes are made or proposed.",
+  "codex_model": "gpt-6.1-sol",
+  "codex_model_reason": "This is a wait: no Codex run and no repair is requested. If a run is needed later, the default gpt-6.1-sol is enough. The open point is a semantic judgment for the independent Opus reviewer, not a hard implementation problem, so gpt-6-astra's extra time and usage aren't justified."
+}