audit(message): make Oracle message edits durable across rebuilds

[scawful]

Goal

Define a durable Oracle of Secrets message-editor workflow instead of allowing edits that the next Asar build can overwrite.

Current ownership split

• Per-room dungeon message IDs are metadata at SNES [07:F61D,07:F86D); PR fix(dungeon): preserve header and message save metadata #86 now fences/preflights those writes.
• Expanded message bodies $18D-$1F9 live in bank $2F and are authored by Core/message.asm; direct ROM edits are not durable across rebuilds.
• Vanilla message bodies $000-$18C use the normal yaze message regions, but Core/message.asm patches $0E:EE75, which falls inside a potential secondary message-data range and needs an explicit overlap audit.

Required design decision

Choose and document one durable mode for ASM-owned expanded messages:

1. source-aware editing that updates Core/message.asm (or generated message source) and rebuilds; or
2. a declared editor-owned ROM region plus an extraction/build synchronization step.

Do not broadly exempt bank $2F from manifest protection.

Acceptance criteria

• Message editor clearly distinguishes room message-ID assignment from message body content.
• Vanilla $000-$18C writes have exact predicted ranges and protect the $0E:EE75 hook.
• Expanded $18D-$1F9 edits survive a normal Oracle build or fail closed with actionable guidance.
• Save/rebuild/reopen integration covers at least one vanilla and one expanded message.
• Canonical source ROMs are never modified by tests.

Related: #86 (room header/message-ID save stability), #87 (exact editor-managed manifest regions), scawful/Oracle-of-Secrets#110 (generator ownership fix).

[scawful]

2026-07-15 phase-1 implementation audit

Exact current behavior on the manifest stack (366c2a0d):

• MessageEditor::Save() always rewrites the 100-byte width table and the complete vanilla message streams whenever global message saving runs; there is no vanilla/expanded/font dirty split.
• If expanded messages were merely loaded, Save() also calls SaveExpandedMessages() and rewrites them even when no expanded message changed.
• There is no message-specific manifest preflight before those writes. The outer ROM transaction can restore bytes after a late conflict, but the message editor has no bank-specific retry/dirty state.
• The fixed OOS hook $0E:EE75 maps to PC 0x076E75 inside the secondary vanilla message region and is already an exact protected manifest region ($0E:EE75..$0E:EE7D). Any planned vanilla serialization crossing it must fail before the first width/message write.
• More critically, the current yaze default/manifest expanded start is SNES $2F:8000 (PC 0x178000), while the current build symbol places the first body at Oracle_MessageExpandedData = $2F:8026. $2F:8000..$2F:8025 is executable MessageExpand code. A ROM writer starting at the configured bank start can overwrite the loader itself, so direct expanded-ROM writes must remain fail-closed until the body boundary and ownership workflow are modeled explicitly.

Smallest safe phase 1:

1. Track dirty state separately for vanilla bodies, expanded bodies, and font widths; loading/navigating must not dirty a bank.
2. Pre-serialize dirty banks into immutable plans and compute exact half-open PC ranges before any write.
3. Validate all planned ranges against the project manifest before writing widths or either message bank.
4. Skip every clean bank. For OOS, reject dirty expanded bodies with actionable Core/message.asm / rebuild guidance and retain the draft plus dirty state.
5. Keep $0E:EE75..$0E:EE7D protected; do not broadly exempt bank $2F.

Required regressions:

• loading expanded messages plus saving an unrelated vanilla edit never changes bank $2F;
• a dirty expanded edit under OOS block policy fails before any width/vanilla mutation and retains retry state;
• a vanilla plan overlapping PC 0x076E75 fails before mutation;
• an allowed vanilla plan reports only its exact width/primary/secondary ranges;
• temp-ROM save/reopen/rebuild coverage leaves canonical ROM and Core/message.asm unchanged.

[scawful]

Phase 1 is now published as draft PR #95: #95

This slice makes message saves preflight-first and bank-selective:

• clean vanilla/expanded/font-width domains are not rewritten
• exact planned ranges are ROM/manifest validated before mutation
• later coordinated-save failures restore dirty state and expanded addresses
• Oracle expanded messages fail closed with Core/message.asm rebuild/reopen guidance
• vanilla editor + CLI serialization no longer confuse [W:80] with [BANK]
• truncated expanded regions fail before allocation/write

Verification on exact head 87fcda6640f18b3cc5e52c5c319712f26573efba:

• focused message suite: 15/15
• full quick editor suite: 639/639
• independent re-review: no remaining blocker/P1/P2
• pre-push validation: passed

This intentionally does not claim direct Oracle expanded-bank durability yet. The next bounded phase should make the project/ASM handoff explicit rather than writing ASM-owned bytes directly.

[scawful]

The remaining direct-CLI bypass is now closed in stacked draft PR #96: #96

At exact head 0e00177fb98653b9c790c4126f21d09da7e11bc9, expanded CLI mutation requires a matching project/ROM, loaded manifest, valid configured region, and permitted ownership policy. Oracle of Secrets block-policy writes reject with Core/message.asm rebuild guidance even if the region is mistakenly editor-exempt. Mixed bundle writes preflight before mutation and use one ROM transaction. Manifest count/range/capacity, malformed project data, oversized existing banks, global manifest restoration, and vanilla-only compatibility are covered.

Verification: focused CLI policy 11/11, quick core 145/145, native z3ed build, pre-push validation, and strict review with no blocker/P1/P2.

The paired Oracle workflow correction is draft scawful/Oracle-of-Secrets#111: scawful/Oracle-of-Secrets#111. It keeps $18D+ / bank $2F ASM-owned and documents Core/message.asm -> rebuild -> reopen instead of direct ROM writes.

This issue remains open for the durable editor-to-ASM project workflow; these PRs make current unsafe paths fail closed rather than claiming that handoff is complete.

[scawful]

Final phase-1 stack validation is now green.\n\n- PR #95 exact head 87fcda6640f18b3cc5e52c5c319712f26573efba: full cross-platform CI succeeded in run 29487012259.\n- PR #96 final exact head 0a94258e6122669d6a5718d7e3b75a13f267520e: hosted checks and full cross-platform CI succeeded in run 29516667114, including Windows full-stack coverage. No review blockers or unresolved inline threads remain.\n\nThe issue intentionally remains open: these slices make editor/CLI paths bank-selective and fail-closed, but the durable editor-to-Core/message.asm handoff is still future work. Oracle workflow draft scawful/Oracle-of-Secrets#111 remains the paired documentation/policy change.

[scawful]

Dungeon parity update:

• Draft fix(dungeon): match archery curtain draw parity #101 fixes subtype-1 object 0xB5 (archery-game curtains) against USDASM: size + 1 adjacent horizontal 2x4 stamps, exact eight-word column-major tile order, and selected-layer-only rendering.
• Selection, ObjectGeometry, and legacy dimensions now match the rendered 2 * (size + 1) by 4 footprint.
• Local validation: exact unit target build plus 121 focused registry/rendering/geometry/layer tests; pre-commit and pre-push checks passed.
• Full CI for fix(dungeon): match vertical jump ledge draw parity #98 completed green on exact head 967cfdebf5938a02a688db9ac752ac728aa69318 (run 29526357744). Full CI for fix(dungeon): match light beam draw parity #99 is now running on exact head 3d51c730f859fa4c37ea31375d10c7ea4781cc19 (run 29533303419); later stack layers remain gated behind it.

No release tag or ROM mutation was performed.

[scawful]

Dungeon parity update:

• Draft fix(dungeon): gate big light beam by attic state #102 implements exact state behavior for subtype-3 object 0xFF1 (big light beam): it reads the persisted bombed-floor state for fixed room 0x065 (RMFLG065 & $0100), emits no tile writes while clear, and uses the existing 64-word / 8x8 selected-layer floor-light grid while active.
• The implementation intentionally does not use the current room ID. State-free selector/geometry previews remain visible; a dedicated East Attic Open / Blind Light preview control exposes the cross-room relationship.
• Exact review commit: 0f29c7428c9d27ed89de7546f7129591028597e7.
• Local validation: unit target build, focused FF1/floor-light/geometry tests 4/4, broader draw/geometry/dimension/mapping/layer suites 122/122, pre-commit, pre-push smoke 5/5, and independent read-only review with no blockers.
• Full CI for fix(dungeon): match light beam draw parity #99 completed green on exact head 3d51c730f859fa4c37ea31375d10c7ea4781cc19 (run 29533303419). Full CI for fix(dungeon): match unconditional floor light parity #100 is in progress on exact head 07045903ee87a3096454d6c6a66607aaeecec9a9 (run 29552450231); fix(dungeon): match archery curtain draw parity #101 remains gated behind it. fix(dungeon): gate big light beam by attic state #102 hosted Claude/WASM checks have started.
• Release PR [release] Prepare yaze 0.7.2 metadata #69 remains draft/CLEAN at 24a2504c6be22f3321e44a01805f52127925c3ce; no v0.7.2 tag or release was created. Packaged Windows open/save/reopen validation remains the release blocker.

No ROM was opened or mutated. Canonical OOS ROM, manifest, and project hashes remain unchanged.

[scawful]

Phase-1 message safety is now on master.

• PR fix(message): preflight dirty message banks #95: exact head 9181b2d68fc4c4474e62e0b8ab96aeac3ef5eca0, merge c3c0ded4f665f4862cc5bbbd8042776b5ad9ab8c.
• PR fix(message): gate expanded CLI writes by project #96: exact head 1724e6ec88983973e6e4a30f3d2010d9ef98574a, merge 1230d0c64caebd72e6abd7a5766e6ed64a373e22.
• fix(message): gate expanded CLI writes by project #96 completed the required Linux/macOS/Windows core matrix plus attached Claude/WASM checks with zero unresolved review threads. The dispatch-only Windows full-stack tail was canceled after merge; it was not a pull-request gate.

The editor and CLI now skip clean message domains, preflight exact ranges, preserve retry state, and fail closed for ASM-owned Oracle expanded messages. This issue intentionally remains open: a durable editor-to-Core/message.asm source handoff and rebuild/reopen integration are still required before expanded Oracle message editing is a complete daily-driver workflow.