create-cmp-cli 0.7.1 → 0.9.0

package/template/specs/home.spec.md

@@ -8,11 +8,14 @@
 - **HOME-02** — Given the repository returns items, When loading completes, Then the items are
   listed with their title and subtitle, and no error is shown.
 - **HOME-03** — Given the repository fails, When loading completes, Then a human-readable
-  error message is shown (`home_error`) and no items are visible.
+  error message is shown (`home_error`) and no items are visible — the copy is mapped in
+  presentation from the failure's `DomainError` kind, never a raw exception message.
 - **HOME-04** — Given a load has failed, When the data source recovers and the user triggers a
-  reload, Then the error clears and the items render.
+  reload (`home_retry`), Then the error clears and the items render.
 - **HOME-05** — Given items are listed, When the user taps an item, Then the app navigates to
   that item's detail.
 - **HOME-06** — Given the Home screen renders, When its structure is inspected, Then the
-  screen matches its committed golden tree (`qa/golden/home.json`) — structural regressions
-  are intentional, declared changes only.
+  screen matches its committed golden tree (`qa/golden/home.json`) — structural change must
+  be intentional and declared.
+- **HOME-07** — Given the repository succeeds with zero items, When loading completes, Then
+  the empty state is shown (`home_empty`) and neither items nor an error are visible.

package/template/specs/intent.md

@@ -0,0 +1,50 @@
+# Intent brief
+
+> The root artifact everything else traces to (GENESIS-FLOW-DESIGN.md §0, conversation 0 of
+> the genesis walk). This is prose, not a clause spec — no `// SPEC:` tags apply here, and
+> `specCoverage` never scans this file (it only scans `specs/*.spec.md`). The `cmp-new`
+> interview fills in the sections below before the design-language, architecture, components,
+> and exemplar-feature conversations begin; each of those is expressed in the vocabulary this
+> brief establishes.
+
+## Purpose
+
+_not yet captured — filled by the cmp-new interview._ What is this app, in one or two
+sentences? What problem does it solve, and for whom?
+
+## Audience
+
+_not yet captured — filled by the cmp-new interview._ Who uses this app? One primary
+audience beats a vague list — name them.
+
+## Platforms
+
+_not yet captured — filled by the cmp-new interview._ Android, iOS, or both? Any platform-
+specific constraints (e.g. iOS-only feature, Android-first launch)?
+
+## Brand feel
+
+_not yet captured — filled by the cmp-new interview._ Two or three adjectives for how this
+app should feel (e.g. "calm, trustworthy, minimal" vs. "playful, bold, energetic"). This
+seeds conversation 1 (design language) — the candidates it proposes react to what's written
+here.
+
+## Reference apps
+
+_not yet captured — filled by the cmp-new interview._ One to three apps whose look, feel, or
+interaction patterns this app should be judged against ("closer to X than Y").
+
+## First screens
+
+_not yet captured — filled by the cmp-new interview._ What are the first 2–4 screens you see
+in your head? This grounds conversation 4 — the exemplar feature is the user's *actual* first
+feature, not a generic placeholder.
+
+## Glossary
+
+_not yet captured — filled by the cmp-new interview._ The domain nouns specific to this app —
+one line each, in the app's own vocabulary, not generic template terms (e.g. "**Trip** — a
+single planned outing with an itinerary and companions", not "**Item**"). Usually falls out of
+the Purpose/First screens answers above; confirm the list with the human rather than guessing.
+This section is lifted verbatim into `docs/ARCHITECTURE.md` §8 — write it in the form you want
+published: a Markdown bullet list, `**Term** — definition` per line.