paqad-ai
Version:
Spec-driven development framework — AI agents that think before they type
39 lines (28 loc) • 1.9 kB
Markdown
# 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.