Move the housekeeping out of the config module #48

New issue

Closed

opened 2026-08-15 18:58:45 +00:00 by rosa · 0 comments

rosa commented

2026-08-15 18:58:45 +00:00

Owner

What to build

The config module's own doc gives away that it is two things: the settings read
off the file, and the housekeeping that clears the files away again. The
housekeeping half decides what to take, asks the player about each file, and
prints the outcome, all in the same run of code — so it needs a terminal to
execute and there is no way to assert what it would have done. The case with no
test at all is the interesting one: a config too broken to parse, where the
paths fall back to the standard places.

Split it the way ADR 0003 already splits every prompt the house says, and ADR
0002 splits an engine from its UI. The housekeeping half answers with a plan —
the files it would take, in the order it would take them, each carrying what it
is and whether the config named it or it is a guess at the standard place
because the config could not be read. The crate-level ui walks that plan,
asks, and says what happened. The wording lives in the half that never touches a
terminal.

Two things resist being planned and stay as execution:

The directory sweep. Whether a directory is empty is only knowable after
the files come out, and the player may decline a deletion. It runs after
execution rather than being predetermined.
A file that vanishes between planning and removal. Still counts as already
gone, as it does today.

Ordering survives intact: the config goes last, since it is what names the other
two and a run cut short should leave the survivors findable. When the config
cannot be read it goes first instead, because it names nothing. That rule is
currently expressed as control flow around prompts; as a plan it becomes a value
a test can assert directly.

Do not name the new module discard, the verb the current code uses. In a
codebase with five card games that word is going to mean something specific at a
table, and the glossary has not claimed it yet.

Acceptance criteria

A full purge plans the save, stats, and config files, config last
A reset plans the save and stats files only, with no config and no sweep
An unreadable config plans the config first, and marks the save and stats
entries as standard-place guesses rather than paths it was given
The plan a purge produces can be asserted without driving a prompt or
owning a terminal
Declining one file still leaves the rest of the plan to run
A file that does not exist is reported as already gone rather than failing
Every line the player reads lives in the crate-level ui
Behavior at the terminal is unchanged — same questions, same order, same
outcomes
No CHANGELOG entry — this is a move, not a change

Blocked by

## What to build The config module's own doc gives away that it is two things: the settings read off the file, *and* the housekeeping that clears the files away again. The housekeeping half decides what to take, asks the player about each file, and prints the outcome, all in the same run of code — so it needs a terminal to execute and there is no way to assert what it would have done. The case with no test at all is the interesting one: a config too broken to parse, where the paths fall back to the standard places. Split it the way ADR 0003 already splits every prompt the house says, and ADR 0002 splits an engine from its UI. The housekeeping half answers with a plan — the files it would take, in the order it would take them, each carrying what it is and whether the config named it or it is a guess at the standard place because the config could not be read. The crate-level `ui` walks that plan, asks, and says what happened. The wording lives in the half that never touches a terminal. Two things resist being planned and stay as execution: - **The directory sweep.** Whether a directory is empty is only knowable after the files come out, and the player may decline a deletion. It runs after execution rather than being predetermined. - **A file that vanishes between planning and removal.** Still counts as already gone, as it does today. Ordering survives intact: the config goes last, since it is what names the other two and a run cut short should leave the survivors findable. When the config cannot be read it goes first instead, because it names nothing. That rule is currently expressed as control flow around prompts; as a plan it becomes a value a test can assert directly. Do not name the new module `discard`, the verb the current code uses. In a codebase with five card games that word is going to mean something specific at a table, and the glossary has not claimed it yet. ## Acceptance criteria - [ ] A full purge plans the save, stats, and config files, config last - [ ] A reset plans the save and stats files only, with no config and no sweep - [ ] An unreadable config plans the config first, and marks the save and stats entries as standard-place guesses rather than paths it was given - [ ] The plan a purge produces can be asserted without driving a prompt or owning a terminal - [ ] Declining one file still leaves the rest of the plan to run - [ ] A file that does not exist is reported as already gone rather than failing - [ ] Every line the player reads lives in the crate-level `ui` - [ ] Behavior at the terminal is unchanged — same questions, same order, same outcomes - [ ] No CHANGELOG entry — this is a move, not a change ## Blocked by - #45

rosa added the

ready-for-agent

label

2026-08-15 18:59:04 +00:00

rosa referenced this issue

2026-08-15 18:59:34 +00:00

Sweep the config directory even when the data directory is kept #50

rosa referenced this issue

2026-08-15 18:59:35 +00:00

Record how the casino finds its files #51

rosa added a new dependency

2026-08-15 19:01:09 +00:00