---
phase: useCases
kind: level
level: discovery
---

# Phase 1 — DISCOVERY: identify candidate use cases per section

> Scope: propose **candidate UC titles** for ONE section, let the user pick, then
> Write them as discovery-level entries. The "ONE section" is the one fixed by the
> scope-selection cascade (application → module → section) in `SKILL.md`. The write
> protocol, UC code format, authority and actors gate also live in `SKILL.md` —
> this file is the elicitation heuristic.

## Goal

For ONE section at a time, identify the 5-9 most relevant use cases. Output is
**title-only** entries (heading + primary actor + a one-line intent; flows left
as `—`) so the user gets a quick overview before diving into details.

## When to enter this phase

- The target section's `use-case.md` has no UC content (placeholder or empty), OR
- The user explicitly asks to "add use cases" / "find missing use cases" for it.

## Per-section elicitation pattern

1. **Read the section context** from its `index.md` (`## Contexte`, label, parent
   module) and glance at sibling sections so you don't duplicate their scope.
2. **Read the app actors** from `.smartstack/ba/<APP>/acteur.md` (Grep the
   `### BA-…-AC-…` headings). Identify which actors naturally interact with this
   section — often inferable from the section name.
3. **Brainstorm context-anchored use cases**, asking yourself:
   - "What does an actor accomplish here in a single sitting?"
   - "What is the core verb-object pair for this section?"
   - "Are there approval / validation / submission flows?"
   - "Which actor (from `acteur.md`) does this UC anchor on?"
4. **Optionally calibrate to industry practice.** If the domain is unfamiliar and
   you have web access, you may run a couple of searches to surface non-obvious
   standard actions and innovative directions — cite the source in the rationale.
   This is a quality boost, not a hard gate.

## Tier the candidates (challenge at four levels of ambition)

Distribute the candidates across four ambition tiers so the proposal challenges
the user instead of playing it safe:

| Tier | Test question |
|------|---------------|
| **Recommandés** (context-anchored) | "If I drop this UC, does the section lose its primary purpose?" → strict yes. Rationale MUST cite an actor / section / entity / rule that actually exists in the tree. |
| **Améliorations** (efficiency at scale) | "Would this improve usage at scale — bulk, draft, duplicate, export, advanced filter, exception handling, alternate channel?" |
| **Bonus métier** (industry standards often forgotten) | "Standard but non-obvious in this industry — notification, automation, audit trail, scheduled reminder, integration, delegation?" |
| **Élargissement-vision** (beyond initial scope) | "Innovative direction — analytics layer, AI-assisted action, predictive feature, collaborative angle?" |

If a candidate fits two tiers, place it in the **higher** (more speculative) one.
If none of the tier tests yields a clear answer, the UC is mis-named or too CRUD
— reformulate before classifying.

### Anti-pattern — collapsing everything into Recommandés (avoid)

If you classify ALL candidates as Recommandés, you are not categorising — you're
playing safe. Most non-trivial sections legitimately split across all four tiers.
Example correct distribution for a `service-calendar`: Recommandés (3) Consulter /
Planifier / Publier · Améliorations (2) Bloquer / Filtrer · Bonus métier (2)
Récurrent / Relancer · Élargissement-vision (1) Suggérer via IA.

### Target distribution

| Tier | Target | If empty |
|------|--------|----------|
| Recommandés | 2-3 | section probably doesn't justify its own UCs (read-only) — flag it |
| Améliorations | 1-2 | verify no bulk / filter / export / draft / cancel was missed |
| Bonus métier | 1-2 | every domain has standards the user forgets — push for one |
| Élargissement-vision | 1-2 | think "future of \<domain\>" |
| **Total** | **6-9** | — |

## Ask the user (AskUserQuestion)

Present the tiers in prose (group the candidates under the four headings, with a
short rationale and source for each), then ask the user to pick which ones to keep
via the **AskUserQuestion** tool (multi-select). Always reference the section by
its human-readable **label** (e.g. "Menus du jour"), never by its code. Write in
the user's language. Pre-select the obvious Recommandés.

If the user wants a candidate that isn't listed, they describe it in prose; your
next turn folds it in. Only the chosen candidates are written — unselected ones
are not persisted.

## What NOT to propose

- CRUD-flavoured titles (`Create employee`, `Edit profile`) — router-level navigation.
- UI-level actions (`Click button`, `Open page`) — too low-level.
- Cross-section UCs — every UC belongs to exactly ONE section.

## Writing the discovery result

Once the user has picked, **Write the section's `use-case.md`** (per the SKILL.md
write protocol) with one `### UC-…` heading per chosen candidate. At discovery
level each entry carries:

- the `UC-{APP}-{MOD}-{SEC}-NNN` code (numbering restarts at 001 per section — Grep
  the file for the highest taken number),
- the title,
- `Acteur principal` (a `BA-…-AC-…` code from `acteur.md`),
- a one-line intent if useful;
- the remaining Cockburn fields (`Préconditions`, `Flux principal`,
  `Postconditions`, …) left as `—`, to be filled in Phase 2.

Re-list every UC already in the file (Write overwrites). Then move to **Phase 2
(detail)** for the first UC of this section.
