Files
TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p13-03-resume-20261015/ACCEPTED_REVIEW.json
T

24 lines
6.6 KiB
JSON

{
"task_id": "P13-03",
"commit": "bd3a97ec741ddb2346d0c2b2e0472c978927ce82",
"status": "pass",
"summary": "I reviewed candidate bd3a97e against the unchanged spec, all eight required outcomes and the single acceptance item P13-03. It passes as a records-only P13-03 delivery. This is not a content-completion, P13-package or game acceptance.\n\n**Evidence and scope**\n- I read the full diff, the checker, the ledger, the receipt and the registered validation material (stdout, command and receipt).\n- Runner validation passed: exit 0, using the registered command `python3.12 -B tools/check_p13_content_difference.py --verify-only` in the sandbox. Record integrity passed, 33 negative cases were rejected and the alternate-input case was verified read-only.\n- All changes are inside allowed_paths: the checker plus the `p13-03/**` folder. No game, asset, value, spec, Runner or policy files were changed.\n\n**Outcome-by-outcome check, verified against the sources**\n1. **Seven facilities.** `original_facility_mapping.json` has exactly 7 facilities in §10.4/§10.6: 風俗個室 (adult_private_room), 高級ソープ, SM拷問室, 闇市場 (black_market), 覗き部屋, 地下牢 and マナ炉. Five of these have `definition_id` null. The ledger keeps all seven under `original_facility_NN` IDs. The current mapping was re-searched in the catalog and in every `data/facilities/*.tres`, not assumed from the old null. A search of `scripts/` and `scenes/` for these names finds no definition (only the generic dungeon tileset). The checker raises an error if mana_control_room is used as a proxy, and the proxy_mapping negative case confirms this.\n2. **Connection observations.** Each facility records normal_entry, runtime, event_state, save and test separately, with the actual path, SHA, search tokens and full matching lines. All are status=unverified with accepted=false. I checked the notes against the code:\n - `facility_catalog.gd`: adult_private_room is in FACILITY_PATHS. black_market is in EXPANSION_FACILITY_PATHS only. ORIGINAL_FACILITY_PATHS is cleaning_room, chapel, premium_room and staff_dormitory under `expansion/`.\n - `simulation_runtime.gd` on main (blob 4696df…): line 437 loads FACILITY + INFRA + RESCUE + ORIGINAL only.\n - `main.gd` on main: line 53 has adult_private_room.\n - Outside tests, nothing calls load_expansion, load_available or by_id. So the statement that black_market is not loaded at runtime holds.\n3. **Media usage slots.** `facility_usage_slots.json` has exactly 84 matching `facility_name` records. All 84 slot_ids are in the ledger and receipt with a source path and SHA, status unverified_required_slot and approved_asset=null. Each facility's actual asset count is null/unknown, and pixel_tower_art is described as a search lead only.\n4. **Non-facility differences.** Six categories are recorded: event, overlay, history, story, voice and scene. content_ids and quantity are null/unknown and D08/D09 are unknown, never zero. Only neutral metadata is recorded; no scenes are created or described.\n5. **Three-way separation.** Technical observations, completed_asset_acceptance and original_content_completion are kept apart. accounting stays at 30/88 with no partial credit. package_completion_inferred is false and original_views_edited is false.\n6. **Ledger and receipt.** The readable ledger, the machine ledger and validation.json all exist. Each source is labelled current_checkout, base_git_blob (work_packages at e1a1651) or main_git_blob (the two Runtime/preview files at 57131ec). The receipt gives a reason why runtime, native, Windows, engine and full-regression tests do not apply.\n7. **Checker.** It is stdlib only and never writes files. It always enforces the spec hashes, the source pins, the frozen work_packages blob, a duplicate-JSON-key ban, duplicate slot rejection, an exact 7-facility count, and full equality of the ledger, receipt and readable ledger against expanded content. Negative cases cover omission, stale pins, false completion, technical work promoted to content, unknown turned into zero, tampering with shared references, stale or corrupt source bytes in both frozen and merged modes, and Git errors. There is no unconditional failure, and pending fields do not count as a pass.\n8. **Integration gate.** Integration still requires the Runner validator and this separate review. The ledger does not claim the review itself.\n\n**Prior medium finding (current-main applicability)**\nThis is now resolved in code. The two changed sources are re-observed from immutable main blobs and labelled as such. Real Git ancestry decides whether the working bytes must equal the base or the main version, and any drift or Git error fails closed. Both modes are exercised by negative cases.\n\n**Not verified here, left to the normal gate**\nI could not run git or the checker in this review. So I did not personally confirm the Root statement that every other current_checkout pin is the same on base and on main 57131ec. The normal integration and final gate must confirm this on a real merged (descendant) checkout.",
"acceptance_ids": [
"P13-03"
],
"findings": [
{
"severity": "low",
"message": "Integration is tied to a fixed main commit. In merged mode, the checker requires the working simulation_runtime.gd and main.gd to equal the blobs at 57131ec. All other current_checkout sources must equal the pinned SHAs. If main has moved past 57131ec and changed these files before P13-03 integrates, the gate will fail closed, which is correct. The fix would then be a regenerated record, not a hash relabel. This could not be checked on a merged checkout during review (no git or execution available). The normal integration and final gate must confirm it."
},
{
"severity": "low",
"message": "Each connection view uses one shared note for all seven facilities. For example, the normal_entry note for 地下牢 mentions adult_private_room and black_market. Per-facility differences show only in the evidence matches, and the readable ledger simply says to see the machine ledger. This is not a false claim, since everything stays unverified, but it makes the readable ledger less useful per facility."
},
{
"severity": "low",
"message": "The deliverable folder also holds root-supplied context files: P13_ORDER_FINAL_REPAIR_INPUT.md (with its old caps, marked superseded) and P13_SPEC_HASH_CONTEXT.md. They are inside allowed_paths and say they are not deliverables, but they are history, not records. The checker also embeds an in-memory unittest.mock negative suite, and its outcome is pinned to fixed commits. Once main moves, the tool will become a version-bound proof that fails rather than a general one."
}
]
}