A corrupt audio-settings.json is silently replaced with defaults at shutdown

[ErwanLegrand]

What happens

An audio-settings.json that failed to parse is silently replaced with defaults when the
application exits. Observed on the reference machine during FR-UI-070's manual run (2026-08-27),
step 9: garbage was written into the file, the app started on defaults with the expected
app.settings.unreadable warning, and after shutdown the file held a valid default document.

Cause

crates/namir-app/src/app.rs:486 unconditionally persists the negotiated settings on exit, which is
FR-IO-080's intent — "persist whatever was actually negotiated … so the next launch starts from what
worked this time". Applied to a file the user may have been in the middle of hand-editing, it
destroys the edit.

The notice says "using defaults". It does not say the file will be overwritten.

Why it is worth a decision rather than a shrug

FR-STATE-040 makes hand-editability an explicit goal for the state document; a settings file with a
typo is the ordinary way a user discovers they got the syntax wrong, and today they lose the file
rather than getting a chance to fix it. That shutdown save is also the one report in the program that
cannot become a notice, by design, because the window is already closed
(crates/namir-app/src/app.rs:481) — so if it fails, nothing on screen ever says so.

Options

• Keep a .bak of an unreadable settings file before the first overwrite.
• Or skip the shutdown save when the load failed, until the user changes something.
• Or say so in the notice, so at least the behaviour is announced.

Evidence

docs/manual-tests/fr-ui-070-non-modal-error-notices.md, executed run, "Observations outside
FR-UI-070's own clauses".

[ErwanLegrand]

FIXED — before #145, at M14 (0a993da). The first option was taken, with a variation worth noting.

settings::load now distinguishes the two failure modes (crates/namir-app/src/settings.rs:122):

• Unreadable (the std::fs::read failed) — there is nothing to preserve, because nothing could be read, and the file is left exactly where it is.
• Unparseable — the file is renamed aside to preserved_path(path) before defaults are returned, so the shutdown save at app.rs:575 writes a fresh file rather than overwriting the user's edit.

The variation: it moves the file aside rather than keeping a .bak copy, and the notice detail names where it went — "{path}: {e}; the unreadable file was kept as {preserved}". If the rename itself fails, the detail says so instead — "it could not be moved aside ({move_error}), so closing Namir will overwrite it" — rather than making a promise about a file that is not there. the_unreadable_remedy_names_the_preserved_file and the neighbouring "the unreadable file must be kept, not overwritten" assertion cover both arms.

The issue's related observation is also addressed: the shutdown save is still the one report that cannot become a notice (the window is closed), but it is no longer let _ = — a failure is now written through crate::diagnostics::record (app.rs:575-577), which is exactly the "why did it forget my device again?" report FR-ERR-010's log exists to answer.

FR-IO-080's unconditional persist at exit is unchanged, and correctly so — the destructive case it had was the hand-edited file, and that file is no longer there to destroy.

---

Generated by Claude Code