--- 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//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. **Research the industry practice (MANDATORY).** Run **at least 2** web searches calibrated to the ACTUAL business domain, at least one naming the domain explicitly ("\ \ typical user actions", "\ \ workflow steps approval", "\ \ \ required actions"). Generic queries ("dashboard best practices") are forbidden — they re-derive what you already know. Extract: concrete user actions in industry terminology, standard-but-non-obvious workflow steps, compliance must-haves, innovative features — these feed the Suggestion and Élargissement tiers with cited sources. Hard floor: **3-5 of the proposed candidates come from the research**, each citing its source in the rationale. Before the question, add a 2-3 line rationale trace ("Recherche web (\, \) — confirme : … ; ajoute : …"). Never announce research then stop — propose in the same turn. ## Tier the candidates (challenge at three levels) Distribute the candidates across the three proposal tiers so the proposal challenges the user instead of playing it safe (full method: `_workflow/proposal-method.md`): | Tier | Meaning | Test question | |---|---|---| | **Obligatoire** | Core of the scope — without it the node loses its primary purpose | "If I drop this item, does the scope lose its reason to exist?" — strict yes, rationale anchored in the client context or the existing tree | | **Suggestion** | Improves real usage at scale, or an industry standard often forgotten | "Bulk, draft, export, exception handling, notification, audit trail, automation, delegation — does one of these apply here?" | | **Élargissement** | Beyond the initial scope — the vision direction | "Analytics layer, AI-assisted action, predictive feature, collaborative angle — worth showing the client the future?" | Phase-specific reading: **Obligatoire** = "if I drop this UC, does the section lose its primary purpose?" — strict yes, and the rationale MUST cite an actor / section / entity / rule that actually exists in the tree. **Suggestion** covers both efficiency at scale (bulk, draft, duplicate, export, advanced filter, exception handling, alternate channel) AND industry standards often forgotten (notification, automation, audit trail, scheduled reminder, integration, delegation) — cite the source (tree or research). **Élargissement** = beyond the initial scope (analytics layer, AI-assisted action, predictive feature, collaborative angle) — each candidate cites its research source. 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 Obligatoire (avoid) If you classify ALL candidates as Obligatoire, you are not categorising — you're playing safe. Most non-trivial sections legitimately split across the three tiers. Example correct distribution for a `service-calendar`: Obligatoire (3) Consulter / Planifier / Publier · Suggestion (4) Bloquer / Filtrer / Récurrent / Relancer · Élargissement (1) Suggérer via IA. ### Target distribution | Tier | Target | If empty | |------|--------|----------| | Obligatoire | 2-3 | section probably doesn't justify its own UCs (read-only) — flag it | | Suggestion | 2-4 | verify no bulk / filter / export / draft / cancel was missed, and push for at least one forgotten industry standard | | Élargissement | 1-2 | think "future of \" | | **Total** | **6-9** | — | > Legacy mapping (docs authored before 2026-07): Recommandés → Obligatoire · > Améliorations + Bonus métier → Suggestion · Élargissement-vision → > Élargissement. Map on read; never write the old tier names. ## Ask the user (AskUserQuestion) Present the tiers in prose (group the candidates under the three 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 Obligatoire. 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.