phase-build

One release phase, built in three passes — API, then UI, then infrastructure — against a plan the user saw and adjusted first. The board shows three trees (Endpoints · Components · Resources), each node coloured by what it is: new this phase, changed (exists, this phase extends it), or already built. Press Start, and the same board becomes the progress view — nodes pulse while being built and fill in as they land.

story map slice + specs + phase screens ──► plan JSON ──► board ──► user adjusts ──► Start
                                                                                         │
        done ◄── infra ◄── ui ◄── api  — one node at a time, each reported to the board ◄┘

have is read from the codebase, never from a previous plan. A plan that colours from last phase's intentions lies the first time a phase ships partial. Read the actual routes, components, migrations and infra files; stamp when you read them.

1 · Scope the phase

• Pipeline mode: phase N is phase in .vstack/pipeline.json. Its content is the phase-N slice of specs/story-map.json, the specs in artifacts.specs[], and design/phase-<n>/ if phase wireframes exist. If "specsOnly": true, this stage doesn't apply — say so and offer /vstack:start to add development setup.
• Standalone: whatever the user points at — a spec, a story list, "build this". Ask only what you can't infer.

2 · Read the codebase, then draft the plan

Walk the actual code: API routes and handlers, frontend components/pages, migrations, infra and deploy files. Then write .vstack/build/phase-<n>.json:

{
  "phase": 1,
  "readAt": "2026-07-29 14:05",
  "subjects": {
    "api":   { "mono": true, "root": { "id": "api", "kind": "API", "text": "/v1", "state": "have", "children": [] } },
    "ui":    { "root": { "id": "ui", "kind": "Frontend", "text": "<app>", "state": "have", "children": [] } },
    "infra": { "root": { "id": "in", "kind": "Infra", "text": "<envs>", "state": "have", "children": [] } }
  }
}