frame-app

Restate each requirement as an observable outcome, sort fragments into nodes, artifacts, cross-cutting concerns, and gates, then draw setup-dependency edges between outcomes. Only slices whose checks can go RED today and GREEN when built become nodes; the current buildable frontier is handed off first.

A vertical slice is one observable end-to-end outcome owning its DB, API, and UI, such as a user signing up. A layer like 'build the API' has no standalone observable outcome, so it cannot be tested RED-to-GREEN and must be re-cut or routed as infrastructure.

They become obligation invariants, not nodes. Each downstream slice adds a fresh RED check on its own new surface, such as a 403 check per new endpoint, because a passing existing suite cannot catch an unguarded new route.

Fold adjacent outcomes when they share the same needs and RED setup, such as a lifecycle chain like create-edit-share. Split them when a downstream node reads state a verb produces, or when one node accumulates axes with divergent RED setups, signaling a god-node.

Yes. A user-facing tier and a headless ingestion pipeline are separate walking skeletons, each seated with its own first observable outcome. They converge at the first node whose setup needs both, and the frontier may start with multiple roots.

Subjective design goals, human-workflow timings, and population-level SLOs are not falsifiable on a single build, so they become design or observer gates rather than nodes. The decomposition is also a hypothesis that downstream check-authoring may falsify, requiring re-slicing.