Remove /generate-app: app shell is now milestone 01 of the plan

The initial app is no longer generated by a separate command. /plan-milestones
now always makes milestone 01 'App Shell Generation' (target platform asked in
the single question round): theme from design tokens, one screen per blueprint
entry, routes, reusable components — no feature logic — plus Playwright setup
and the e2e/app-shell.spec.ts smoke spec. It is executed like any other
milestone via /execute-milestones (which follows platform-ui-generation for it)
or /add-feature. Milestone 02 becomes the MVP core. All workflow diagrams,
skills, docs READMEs, AGENTS.md, and README updated; docs/design README also
gains the screen-inventory.md entry.

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

.opencode/command/plan-milestones.md

@@ -24,11 +24,9 @@ opencode
   ↓
 /define-design
   ↓
-/generate-app web | flutter | winui3
-  ↓
 /plan-milestones        ← you are here
   ↓
-/execute-milestones phase1-milestones.md   (one phase file at a time)
+/execute-milestones phase1-milestones.md   (one phase file at a time; milestone 01 generates the app shell)
 ```
 
 ## Pre-Run Check
@@ -37,7 +35,7 @@ opencode
    - `docs/product-requirements.md`
    - `docs/functional-design.md`
    - `docs/architecture.md`
-2. Check whether the design files (`docs/design/ui-blueprint.json` etc.) exist. If they do not, warn the user that milestones will be planned without a design spec and suggest running `/define-design` first. Continue only if the user accepts.
+2. Check whether the design files (`docs/design/ui-blueprint.json` etc.) exist. If they do not, warn the user that milestones will be planned without a design spec — and that milestone 01 (App Shell Generation) is scaffolded from that spec — and suggest running `/define-design` first. Continue only if the user accepts.
 3. Create the milestones directory if it does not exist:
    ```bash
    mkdir -p docs/milestones
@@ -60,6 +58,7 @@ Read all of the following:
 
 If `$ARGUMENTS` does not already answer these, ask the user about the following. If the user does not provide detailed preferences, **propose a sensible default** derived from the PRD priorities and confirm it before proceeding.
 
+- **Target platform** — `web`, `flutter`, or `winui3` (propose the default from `docs/architecture.md` and `docs/design/platform-mapping.md`); milestone 01 generates the app shell for this platform
 - **Number of phases** (default: 2–3) and **milestones per phase** (default: 1–3)
 - **MVP definition** — what is the smallest product worth releasing? (phase 1 must deliver it)
 - **Priorities** — features that must come first or last
@@ -84,9 +83,10 @@ Size each feature so it can be implemented with **one `/add-feature` run**. Spli
 ### Step 4: Group Features into Milestones, and Milestones into Phases
 
 - Number milestones globally and consecutively across all phases (`01`, `02`, …).
-- **Milestone 1 is the MVP core**: the smallest set of features that forms a coherent, end-to-end usable product.
+- **Milestone 01 is always "App Shell Generation"** (there is no separate generate-app command — the shell is built as the first milestone). Following the **platform-ui-generation** skill, it scaffolds the app for the target platform from `docs/design/`: theme from `design-tokens.json`, routes/screens (one per blueprint screen) and reusable components from `ui-blueprint.json`, **no feature logic**, plus Playwright setup with the `e2e/app-shell.spec.ts` smoke spec. Its features are pre-defined in the milestone-planning skill.
+- **Milestone 02 is the MVP core**: the smallest set of features that forms a coherent, end-to-end usable product on top of the shell.
 - Later milestones build on earlier ones, ordered by priority and dependency (a feature never lands before something it depends on).
-- **Phase 1 delivers the MVP**: it contains milestone 1 (plus any milestone needed to make the MVP releasable). Later phases group the remaining milestones by theme and priority — each phase should be a meaningful release on its own.
+- **Phase 1 delivers the MVP**: it contains milestones 01 (app shell) and 02 (plus any milestone needed to make the MVP releasable). Later phases group the remaining milestones by theme and priority — each phase should be a meaningful release on its own.
 - Every feature belongs to **exactly one** milestone, and every milestone to **exactly one** phase. Explicitly park out-of-scope items in a final "Later / Icebox" section of the roadmap.
 
 ### Step 5: Create the Roadmap Overview
@@ -116,6 +116,7 @@ For each phase, create `docs/milestones/phase[N]-milestones.md` (e.g. `phase1-mi
 
 Re-read all generated files and confirm:
 
+- Milestone 01 is the App Shell milestone (target platform recorded, features per the milestone-planning skill).
 - Every P0/P1 requirement in the PRD is covered by a milestone (or explicitly parked in the icebox).
 - Every feature appears in exactly one milestone, and every milestone in exactly one phase file.
 - Milestone numbering is global and consecutive across the phase files.
@@ -137,13 +138,13 @@ Completion message:
 
 Milestone documents created:
 ✅ docs/milestones/roadmap.md            (overview + status)
-✅ docs/milestones/phase1-milestones.md  (MVP phase: milestones 01–NN)
+✅ docs/milestones/phase1-milestones.md  (MVP phase: milestone 01 = app shell, milestones 02–NN)
 ✅ docs/milestones/phase2-milestones.md  (milestones NN–NN)
 
 Next steps:
 - Review docs/milestones/ and adjust priorities if needed
 - Run /execute-milestones phase1-milestones.md to implement phase 1 (a separate steering directory is created per milestone)
-- Or go feature by feature: run /add-feature [first feature of milestone 1]
+- Or go feature by feature: run /add-feature [first feature of milestone 01 — the app shell]
 - Either way, each feature is marked complete in its phase file as it finishes
 "
 ```