An unreadable journey is named, never faked

[blisspixel]

Two confirmed hunt findings about the same thing: what the product says when it cannot see your progress.

The defect

A journey file that exists and cannot be read (invalid UTF-8, oversized, permission denied) came back as a default journey, which is indistinguishable from a first run. So a player whose file went bad was silently demoted: the rank fell, the veil closed on someone who had crossed it, earned trophies vanished from the tally, and because the same condition also stops the write, the identical level-up and the identical trophy were announced again on every run, forever. A trophy that arrives every time is not a trophy.

Separately, when a save was refused mid-run, the terminal warned and then celebrated anyway, printing TROPHY EARNED and LEVEL UP for progress the disk had just refused, which is the same repeat-forever loop from the other direction.

What was not wrong, now proved rather than assumed

Nothing was ever at risk of being overwritten: persist_journey_delta reads through the same fallible path and fails closed rather than replacing a file it could not read. The new gate check asserts it, reading the player's bytes back off disk after a run that could not parse them.

The fix

• Core grew the fallible read the faces needed: read_journey_file keeps a missing file as a fresh player and returns everything else as the error it is. load_journey_file stays for callers that genuinely do not speak to the player, with a doc comment saying why the distinction matters.
• The terminal says what happened once, on stderr, names the file, and states plainly that nothing will be written over it. It announces no crossing it cannot see, because the comparison would be against a journey this run never read.
• When a save is refused, the refusal is the whole story: the banners stop, with one line saying this run's earnings were not recorded.

The lock

This behavior only exists across a process boundary (an env-isolated profile, a real binary, a file that is bytes rather than text), so it is held in scripts/game-truth.py where the rest of that class lives. Mutation-verified: silencing the warning fails the gate.

Full workspace gates green through the pre-commit hook, plus the game-truth gate and its unit tests.

[Copilot]

Pull request overview

This PR fixes a persistence edge case where an existing but unreadable journey file was treated as a fresh player, which caused silent progress loss in the UI and repeated level and trophy announcements across runs. It introduces a fallible journey read API in core, updates the CLI to communicate unreadable progress clearly and avoid announcing progress it cannot validate, and adds a process-boundary regression gate in scripts/game-truth.py.

Changes:

• Add read_journey_file in core to distinguish missing journey files (fresh start) from unreadable ones (error).
• Update the CLI journey load and end-of-run announcement logic to handle unreadable journeys and failed saves without celebratory output.
• Add a game-truth gate check that asserts unreadable journeys are named on stderr and are not overwritten.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
scripts/game-truth.py	Adds an integration-style gate asserting unreadable journeys are reported and not overwritten.
faces/cli/src/main.rs	Switches CLI to fallible journey loading, improves diagnostics, and suppresses announcements when progress cannot be validated or saved.
crates/core/src/persistence.rs	Documents the semantic difference between “missing” and “unreadable”, and adds read_journey_file API.
crates/core/src/lib.rs	Re-exports the new read_journey_file API from core.
CHANGELOG.md	Documents the player-visible behavior change for unreadable journeys and failed saves.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.