ARCADIA-Studio/harness/release-text-repair-save-state-20260911.md

Repair destinations and saved source state — 2026-09-11

Codex-9e8r6t /root; issue 6. The correction keeps repaired source unsaved until its current destination actually contains those bytes. It passes all 755 Windows desktop tests (zero failed, one ignored), strict Clippy, formatting and a matching GUI build. Native verification of that executable passed for missing-include repair, duplicate-alias repair and interrupted-save rollback.

Problem and correction

The GUI5478 trial opened an invalid project while retaining the prior accepted graphical model. Repairing the new source to exactly the prior saved bytes and clicking Apply all created no model change. The old destination's saved marker consequently made the app report “All changes saved,” although the new file on disk was still invalid. Native evidence preserves that contradiction; data loss on Close was not performed. Source review confirmed that the false-clean state could bypass the existing Close/New/Open guard.

Installing a repair destination now binds Document's saved marker to the raw reachable source read at that destination. It leaves the accepted model, identities, revision, Undo/Redo history and recovered-unsaved flag intact. An equal repair stays a no-op model transaction but remains unsaved relative to the invalid disk source. Valid Open and correlated successful Save retain their existing behavior.

Independent review found a related recovery case: a journal may initially leave disk equal to accepted AFTER bytes, then roll it back to different BEFORE bytes. Recovering the current or adopted destination now rebinds its fresh disk baseline. If reload fails after successful recovery, an explicit unknown baseline (None) keeps every accepted/history state unsaved until a real Save. Recovering a former Save As destination cannot alter the current saved marker. Missing first-save entries actually reload as an empty repair bundle; the separate failed-read regression injects an adapter error and is labeled as such.

Verification and provenance

Five new tests exercise duplicate/missing-include repair equal to old saved bytes across paths, actual unchanged disk before Save, closing protection, equal valid destinations, source conflict refusal, Undo/Redo save markers, actual journal rollback, missing-entry recovery, and separately injected failed reload for current versus former destinations. Root reviewed the full source and tests; independent critique accepted the final correction before execution.

Windows gates used the locked offline workspace and one Cargo build job:

• Full desktop suite: cargo test --locked --offline -p oa-desktop --bin arcadia-studio -- --test-threads=1; 755 passed, 0 failed, 1 ignored, 341.76 s execution, finished 20:37:04 UTC.
• Strict all-target desktop Clippy passed at 20:37:59 UTC; scoped rustfmt and diff checks passed. Matching development GUI build finished 20:39:08 UTC.
• All 500 input files / 9,482,855 bytes stayed unchanged across every gate. Input ZIP SHA256 213fdb39ea7c3601b4baac674c3ab3ecc863ac44db1b092d922d3e24f26887b7. Capture parent is eeeaa126 plus this three-file correction; intervening 00a21d3 changed records only, without altering any build input.
• Preserved executable: 113,206,272 bytes, SHA256 b183ef31f16b3986538b3f2aba8435eab45978635c47f99ca01be6e72b168848.

Raw correction evidence preserves 29 payloads / 2,583,613 bytes of inputs, receipts, actual streams, helpers and independent review. Manifest SHA256: cd2d4dc7f5bebd774a09ecde2e103c42cff891e6725da929384f21c5f8468bac. The separately recorded native-v4 trial confirmed repair → Apply stays unsaved, Close prompts, Cancel retains the work, and explicit Save passes complete model/source equality in all three cases, including actual journal recovery. Package/release and Linux acceptance remain outside these results.