Plan: add M10 save slots (multi-file), renumber polish to M11

tool/disk_save already indexes every call by entry, so multiple save files
cost almost nothing on the storage side — KISSAT00.SAV, KISSAT01.SAV, and
DiskSave_Check/Delete/GetFreeEntries already exist per entry. The work is
the boot-time slot screen, which is why it sits late: it is easier to
design once there is real save content to display.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

projects/kissaten_yugure/docs/DESIGN.md

@@ -20,7 +20,7 @@ Platform: MSX2 · Library: MSXgl (C) · ROM: ASCII16 MegaROM
 >   brewed, so her visits skip it — `SCRIPT.md` §8.
 >
 > Build order and per-stage requirements live in `PLAN.md`, which supersedes
-> the scope ladder in §8 below with a finer ten-milestone breakdown.
+> the scope ladder in §8 below with a finer eleven-milestone breakdown.
 
 ## 1. Concept
 

projects/kissaten_yugure/docs/PLAN.md

@@ -81,10 +81,11 @@ and disk persistence all working. Verified by playing a day, cold-booting, and
 resuming at day 2 with the served count intact.
 
 **Pacing dial, revisited at the end.** `CUSTOMERS_PER_DAY` in `kissaten.c` is
-the only number that sets day length. Worth reconsidering at M10 as a
-player-facing choice — offered once at first boot ("how long should a day
-be?"), or as a shelf option alongside the records. A game with no fail states
-can afford to let the player set its own tempo, and it costs one saved byte.
+the only number that sets day length. Worth reconsidering at **M10** as a
+player-facing choice — the slot screen is already a boot-time front-end, so
+"how long should a day be?" has a natural home there, asked once when a new
+shop is started. A game with no fail states can afford to let the player set
+its own tempo, and it costs one saved byte.
 Not worth building before the content exists: the right default only becomes
 obvious once days have stories in them.
 
@@ -267,7 +268,44 @@ every generated track. Money finally gates something.
 **Exit:** Music changes with time-of-day and weather; the player can choose a
 record.
 
-### M10 — Ending, polish, hardware
+### M10 — Save slots (multi-file)
+
+Several shops on one disk. `tool/disk_save` is already built for this: every
+call takes an `entry` index, so slots become `KISSAT00.SAV`, `KISSAT01.SAV`
+and so on with no change to the save format. `DiskSave_Check(entry)` reports
+each slot's state, `DiskSave_GetFreeEntries()` counts the free ones, and
+`DiskSave_Delete(entry)` removes one. **The storage side is nearly free.**
+
+The actual work is front-end: a slot screen at boot showing what's in each
+one, and a confirm step before overwriting or deleting. That is also why this
+milestone sits late — it touches the boot flow, and it is much easier to
+design once there is real save content to display.
+
+Worth framing in-fiction rather than as a file manager. A slot is not "Save
+1", it is a shop with days behind it — *"Day 34 · 210 cups"* tells the player
+which one is theirs better than a filename does.
+
+**Requires — from you:**
+- **How many slots.** Three is conventional and the disk has room for far
+  more; the constraint is screen space, not storage.
+- **Whether slots are named.** A proprietor's name per shop is charming, but
+  it means building text entry on a machine with no line editor. My
+  recommendation: skip it, and let day count plus cups served identify a slot.
+- **What the deletion guard is.** No fail states applies to the save screen
+  too — an accidental delete is the one genuinely unrecoverable action in a
+  game that otherwise has none. I would make it a two-step confirm.
+
+**Requires — in place:** M2's save layer (done). Nothing else technically —
+this could be built any time, and is late only because the design benefits
+from real content.
+
+**Produces:** slot selection screen, per-slot summary, delete with confirm,
+`SAVE_ENTRY` becoming a runtime value rather than the `#define` it is now.
+
+**Exit:** Three shops can be run in parallel from one disk, each resuming to
+its own day and cast state, and no single keypress can destroy one.
+
+### M11 — Ending, polish, hardware
 
 One quiet ending (see §6). Real-hardware verification, 50/60Hz check, timing
 pass on the brew minigame.
@@ -496,7 +534,8 @@ milestone that consumes them.
 | 13 | M7 | Number of palette sets | Fewer, art-directed well |
 | 14 | M8 | How overt Nakajima's reveal gets | Never stated by anyone but her |
 | 15 | M9 | Sound chip: PSG / FM / retarget | PSG-only via your existing lVGM pipeline |
-| 16 | M10 | Hardware access + 50/60Hz target | — |
+| 16 | M10 | Number of save slots, and whether they're named | 3 slots, unnamed — day count and cups served identify them without needing text entry |
+| 17 | M11 | Hardware access + 50/60Hz target | — |
 
 Items 1–3 are small and I can proceed on my recommendations if you'd rather
 not think about them. Items 4 and 8 are the two that genuinely shape the