msd-core/gsd-core/references/planner-mvp-mode.md

# Planner — MVP Mode (Vertical Slice Strategy)

> Loaded by `gsd-planner` only when `MVP_MODE=true`. Standard horizontal-layer planning rules continue to apply for all other phases.

## Core Rule

**Decompose by feature slice, not by technical layer.** Every task must move the user-facing capability forward. After each task, a real user can click through more of the feature than they could before.

**Forbidden** in MVP mode:
- "Create the database schema" as a standalone task
- "Build the API layer" as a standalone task
- "Wire up the UI" as a final integration task

**Required** in MVP mode:
- The first non-test task produces a working end-to-end path. Stubs are allowed for non-critical branches; the happy path must be real.
- Each subsequent task either adds a new slice OR refines an existing slice (validation, error states, edge cases).
- The phase goal is framed as a user story: "**As a** [user], **I want to** [do X], **so that** [Y]."

## Task Order Pattern

For a feature `F`:

1. **Failing end-to-end test** for the happy path of `F`.
2. **Thinnest viable slice** — UI form → API endpoint → DB read/write — that makes the test pass. Hard-coded values, missing validation, no error states are fine here.
3. **Real data layer** — replace any stubs from Task 2 with real queries.
4. **Validation + error states** — invalid input, network failure, empty states.
5. **Production polish** — loading indicators, edge cases, accessibility checks.

Tasks 3-5 are not always all needed; gate by the phase's acceptance criteria.

## Walking Skeleton Mode (`WALKING_SKELETON=true`)

When the orchestrator sets `WALKING_SKELETON=true` (Phase 1 of a new project under `--mvp`), the plan changes shape:

- The "feature" is the application itself. Pick the smallest meaningful capability that proves the full stack works (e.g., "user can sign up and see their name on a dashboard").
- The plan **must include**:
  - Project scaffold (framework init, routing, build, lint)
  - One real DB read/write
  - One real UI interaction wired to the API
  - Deployment to a dev environment (or a documented local-run command that exercises the full stack)
- The plan **must produce** `SKELETON.md` in the phase directory alongside `PLAN.md`. Use the template at `@~/.claude/gsd-core/references/skeleton-template.md`. `SKELETON.md` records the architectural decisions that subsequent phases will build on (chosen framework, DB, deployment target, auth approach, directory layout).

`SKELETON.md` is the architectural backbone for every later vertical slice; treat it as a contract, not a scratchpad.

## Anti-Patterns to Reject

- **Layer cake disguised as slices.** Three "vertical" tasks where Task 1 is "all the schemas", Task 2 is "all the endpoints", Task 3 is "all the UI" — that is horizontal planning with new labels. Reject.
- **Skeleton bloat.** Walking Skeleton is the *thinnest* working stack, not "Phase 1 of a normal app." If Skeleton has more than ~5 tasks, you are not skeletonizing.
- **Premature SPIDR splitting.** SPIDR splitting is the `mvp-phase` command's job (Phase 2 of the PRD), not the planner's. If the phase scope feels too large, surface it via the verification loop, do not split silently.

## Acceptance Test for Your Plan

Before emitting the plan, ask: **after Task N completes, can a real user *do* something they could not do after Task N-1?** If the answer is "no, but the foundation is laid", you have a horizontal task disguised as a slice. Restructure.