P04-01: 同時発生の更新規約

2026-10-18 14:36:16 +09:00
parent befa0ef1f6
commit acab529c8d
23 changed files with 2003 additions and 186 deletions
@@ -0,0 +1,54 @@
+# REPAIR38 — superseded by REPAIR39_STATUS.md
+
+The shared-helper constraint below is historical and was explicitly resolved
+by the REPAIR39 direction: generalize `_queue` and `_reader` through one
+CASE_TABLE while preserving S5A/S5B behavior. It is no longer an open question.
+See REPAIR39_STATUS.md for the current batch status and missing source context.
+
+## Historical REPAIR38 record
+
+No implementation or acceptance is submitted by this attempt. No Python or
+GDScript source was changed. The A–F batch remains outstanding, not complete
+or admitted for native execution.
+
+The direction both freezes `_queue` and `_reader` as shared helpers and asks
+for new reservation-bearing cases with before/boundary/next/replay points.
+The existing helpers contain case-specific assertions and replay dispatch:
+
+- `s5/p04_s5_power_probe.gd::_queue` requires exactly one reserved inventory ID
+  only when `_case == "S5B_DEPENDENCY"`; every other case must have zero.
+  Using this unchanged helper for the required reservation-bearing S5C/S5F
+  queued request would fail its assertion even with correct runtime behavior.
+- `_reader` unconditionally calls `_assert_stopped` after loading boundary,
+  then replays the literal labels `held`, `recovered`, `duplicate_guard`.
+  Per-case `_labels` does not control that replay loop. New next/replay points
+  cannot be independently replayed through this loop as written.
+
+Required clarification: does “shared helpers stay unchanged” allow replacing
+these case-specific predicates/dispatch with case-table lookups while keeping
+S5A/S5B behavior and every existing assertion equivalent? Alternatively, are
+separate new-case queue/replay helpers authorized while the existing helpers
+remain exclusively the power-case implementation? No selection between these
+interpretations was silently made. This is an implementation-constraint
+question, not a request to reopen D05 or A01.
+
+Read context includes AGENTS.md, REPAIR37_STATUS.md, the existing S5 probe and
+wrapper, S5_ROOT_RUN.md, PENDING.md, D05_REMAINING_APPROVAL.json, Root's local
+q37-remaining-source-map/SOURCE_MAP.json and referenced facility and automatic
+defense sources. Root's M runtime reference is present; the worktree runtime
+is a different version and must not substitute for that reference.
+
+Only read-only source inspection and this status documentation were performed.
+No pure controls, py_compile, AST validation, probe_guard, engine, Git, Runner,
+native run, other agent, integration or /tmp operation was performed. No
+REPAIR38_STATIC_CHECKS.json claiming validation is supplied because no source
+checks were run. PENDING.md is not marked superseded: cases remain unimplemented.
+
+r35/r36 remain FAILED; Q37 remains a successful local diagnostic only. M
+c0ea009, original 30/88, formal 16/88 and P04 credit 0 remain unchanged. The
+15+EV requirements, seven domains, all six D05 decisions and A01 are unchanged.
+After clarification and completion of the entire source batch, Root's required
+order remains pure controls, check-only S1–S5 plan, focused fresh native S1–S5,
+fresh collect, full184/329 on final Q, index, --verify-only, independent review,
+and normal gates with Root join. None of these steps is authorized or claimed
+as performed by this worker status record.