UNPKG

paqad-ai

Version:

Spec-driven development framework — AI agents that think before they type

39 lines (28 loc) • 1.9 kB
# Journey shape verified: 2026-11-02 A journey is a claim that a real actor takes a real path to a real goal. Its value comes from being _few and important_: a handful of load-bearing journeys a newcomer can follow, not an exhaustive enumeration of every click. This reference is the shape and the discipline. ## The well-formed journey - **One actor, one goal.** A journey with two goals is two journeys. Name the actor and the single outcome it pursues. - **An entry.** Where the actor starts: a landing surface, a deep link, a command. - **Ordered steps.** Each step is a surface + an action + an expectation ("on the checkout screen, submit payment, expect the confirmation"). Every step references a surface the map already proved. - **Branches.** The meaningful forks (guest vs signed-in, valid vs declined), each pointing at existing surfaces. - **Dual ends.** Both the success end and the failure end. A journey with only a happy path is incomplete: the failure end is where real apps live. ## The cap, and why Propose at most the configured cap. The arc42 discipline is deliberate: ten journeys that carry the product's real value teach a newcomer the app; a hundred trivial ones bury the signal. When you are over the cap, drop the least load-bearing candidates and record why, do not pad. ## What matters (the signals) Let evidence decide which paths are important: a path exercised by tests, one that shows up in analytics, one the README walks a user through. A journey with no such signal is a guess; say so in its evidence, or leave it out. ## The confirmation line Every synthesized journey is `proposed`. A journey becomes `confirmed` only when a human signs off through the audited surface. Never self-confirm, never lower a status to force a journey through, and never touch the surface/transition/guard graph layers: those belong to the app-cartographer.