Feature cards

One page per MVP feature, written before its code (decision A13). A card is done when a builder — a person or an AI — can work from it without guessing.

Card template

# <Mx> — <feature name>

Status: draft | agreed · Last session: <date>

## Who and the job
Who uses it, and the one job it does for them.

## Value
Why it exists. What breaks or gets worse without it.

## Placement
Where it sits on mobile, tablet and web — and why there.

## Journey and existing system
Entry route and previous screen; user role, permissions and initial state.
Primary action, edit/save transitions, cancel/back, errors/recovery and next screen.
Link current route/components, older screenshots and previous designs.
Mark neighboring screens as existing, changed or outside scope.

## Reference evidence
Source/date/revision; observations; keep/change/avoid; unavailable evidence.
Include relevant competitor journeys without treating hypotheses as validation.

## Approved HTML design
Link responsive HTML design, reviewer view, screen/state anchors and approved commit.
Record simulation boundaries outside product copy. State draft or approved explicitly.
Founder phone review required for changed user journeys (D8).
For non-UI work, provide the contract and examples instead.

## Responsive behavior
Mobile (390), tablet (768), web (1440 CSS px); narrow-width check (320).
Describe navigation, columns, sidebar/sheet, sticky controls and overflow.
List performed checks and outstanding checks; do not infer device testing.

## States
Empty · loading · error · long content · missing data (e.g. no photo).

## Rules and edge cases
The domain rules this feature must respect, with the reason for each.

## Decided
- ...

## TBD (decide by <date>)
- ...

## Backlog (after launch)
- ...

## Acceptance checks
Observable checks, including required manual testing and review.

## Tasks
Founder-assigned team task IDs, owner, reviewer and dependencies.
Each task brief links this card, design/reviewer view, exact approved revision,
relevant screen/state, responsive expectations and acceptance checks.
Link originating tickets; team records, not historical tasks.md, assign work.