Decompose

X2 Decompose (D-000)

The one place where the model's whole-solution-space view beats the human's slice-by-slice view, and the decisions a slice cannot cheaply reverse. Everything else stays reversible and waits.

The five-lens session

Decompose the story set under five imposed lenses, one pass each, no code: data flow, failure domain, change frequency, team boundary, trust boundary. Look at what disagrees between the five decompositions; the disagreements are where the real shape decision lives. Choose a shape. Record the choice and the four rejected shapes with reasons as D-000-decomposition.md in docs/decisions/.

D-000 also records:

• The story set from gate 1. D-000 is the source of truth for it; there is no separate requirements document (the pilot's turn 8b defect was creating one).
• The recorded product decisions from ideation.
• The persistent schema decisions. Schema is the second stays-ahead asset; approving it is a human turn, and every later migration is an unconditional human turn, every time.
• The slice-one definition: the smallest slice that ships real user-visible value end to end. Build scope and design scope are separate rulings: the build is slice-first, the design is whole-product (MET-03); record both.

The launch and exposure pre-flight

Applies when the product will ship to a public audience; rule each concern IN or OUT now, so none of it arrives as ad-hoc directives at the end (record: NS-2, NS-3):

• The estate question: does this greenfield app land inside an existing brand estate (styles, domains, policies, analytics) that is not greenfield?
• Exposure values: serving domain, sender addresses, public identifiers, entry points. These are ruled before first use, never assumed; an assumed value propagates into green artifacts and surfaces late.
• Launch concerns: brand chrome and legal pages, discoverability (robots, sitemaps, social and AI-readability), analytics, abuse pricing, and edge hardening.

Also read the cross-project churn table in the method's record/negative-space.md: it names the decision types history says will churn. Pre-decide the pre-decidable ones here; budget the iteration-inherent ones (story refinement, model selection, content voice) instead of fighting them. For the marked chronic churn types, record a confidence and a "wrong-if" line on the decision so reality can trip it later.

The deltas file

Start deltas.md: how this project differs from the edition it was seeded from, which the kernel-provenance row names. It grows as the build surfaces differences; it never restates what that edition already says.

Human-turn contract

• Human turns here: the shape choice, schema approval, slice-scope ruling. These are stays-ahead decisions and are not counted in the per-slice metric.
• Anything presented for a ruling is put in plain language, the owner's own words; method vocabulary rides alongside, never instead. A ruling made on a summary the owner cannot parse on first read is no ruling at all (P3).
• No MET-07 gate of its own; gate 2 belongs to the design step that follows.

What this skill must NOT produce

• No screens, no prototype, no acceptance criteria, no tests, no code.
• No detailed per-module design; a single-service module is legal and the shape decision is the module boundary, not the internals.

Next

design, carrying D-000 and the behaviour spec.