---
phase: menu
kind: level
level: applications
---

# Level 1 — Applications

> Scope strict: propose **applications only**. No modules/sections/resources/
> entities/rules/screens. The phase boundary in `SKILL.md` applies verbatim.
> The write protocol (scaffold node folder + `index.md` + placeholders) and the
> code/label rules also live in `SKILL.md` — this file is the proposal heuristic.

## Exploration (first message, empty tree) — run in parallel before proposing

1. **Read SmartStack config**: open `.smartstack/config.json` if present —
   `baseNamespace` (project name), `dbContext`, `tablePrefix`. Absent → "not a
   SmartStack project", continue anyway.
2. **Read the current tree**: `Glob .smartstack/ba/**/index.md` — empty or
   populated?
3. **Scan existing code** (if a SmartStack project): controllers
   (`src/*.Api/Controllers/**/*.cs`, `[NavRoute("app.module")]`), entities
   (`src/*.Domain/Entities/**`), React pages (`web/*/src/pages/**` — folders =
   modules). Extract real app/module names rather than inventing them. NOTE: this
   scan sees CLIENT code only — the built-in platform apps ship inside the package
   and are invisible here (next step covers them).
4. **Match against the built-in platform apps** (`SKILL.md` § "Built-in platform
   apps"): does the requested domain resolve to `administration`, `support`, `hr`,
   `api` or `myspace`? If yes (e.g. RH → `hr`), the verdict is **EXTEND the
   built-in app** — propose the client's NEW modules under it, never a new
   application. This is the check that stops a duplicate HR app.
5. **Present a short exploration summary** (project, prefix, current tree,
   existing code, built-in matches, verdict: new / **extend built-in** / extend
   client / fill gaps).

## Research before proposing (MANDATORY)

Even at application level, ground the split in actual industry practice: run
**at least 2** silent web searches calibrated to the domain ("[domain]
software suite applications", "[domain] ERP applications overview"), at least
one naming the domain explicitly — generic queries are forbidden. Use the
results to confirm/extend the candidate apps and to feed the Élargissement
tier; cite the sources in one line inside the proposal. Research is NOT a
calibration question — the HARD CAP below still allows only 1 question. Never
announce research then stop — propose in the same turn.

## Calibration — HARD CAP 1 question, then propose

The same domain (e.g. HR) yields different apps by industry. Ask **at most one**
calibration question via AskUserQuestion, then propose. Skip it entirely if the
user's prompt already answers it.

- **Whitelist** (the only topics you may ask): industry/sector · application-level
  scope (which high-level areas the app covers) · org size/volume.
- **Blacklist** (defer, never ask here): payment/billing models, access models,
  workflow steps, schedules, field-level details, permission matrices, form
  structures, dashboard contents. These belong to later phases.

If you catch yourself drafting a 2nd calibration question, STOP — propose with
your best inference plus a one-line caveat ("on affinera au tour suivant").

## Application guidelines

- **Autonomy**: each application is an autonomous business scope with its own
  settings. NEVER a cross-cutting `SETTINGS`/`ADMIN` application — configuration
  is a MODULE inside the relevant app.
- **Infer** 1-3 apps from the requirement + context; **check** against the
  built-in platform apps (`SKILL.md` § "Built-in platform apps" — a match ⇒ extend
  the existing app, never a new one); **challenge** (>8 potential modules → split;
  similar scope → merge); **verify** each app is autonomous.
- **Draft, self-audit, then propose in tiers**: run the checklist of `SKILL.md`
  § "Self-audit the draft" on the full draft, then present the candidates
  grouped by the three proposal tiers (Obligatoire / Suggestion /
  Élargissement — `SKILL.md` § "Proposal tiers").
- **Naming**: short business-scope names (1-2 words). No `& / \ | < > "` (split or
  pick an umbrella concept).
- Optional in `index.md`: a one-line rationale and an `## Hors-périmètre` whenever
  the user signalled exclusions.

## Out-of-scope checkpoint (turn 1 only)

On the very first turn of a brand-new project, before proposing apps, you MAY ask
one multi-select AskUserQuestion: "are there areas you explicitly do NOT want
covered?" (billing, payroll, client portal, consolidated reporting, none). Record
any picks as the `## Hors-périmètre` of the project root `.smartstack/ba/index.md`
and/or the relevant app. One scope question per project, turn 1 only.

## First message with an existing tree

Present what exists ("{N} apps, {M} modules, sections: yes/no"), then ask via
AskUserQuestion how to proceed (continue with sections / modify / add a new app).
Never auto-jump to the next level.

## Edge cases

| Situation | Action |
|-----------|--------|
| User refuses all | Ask to rephrase, re-propose |
| Matches a built-in platform app (e.g. RH → `hr`) | Switch to the EXTEND path — announce the built-in + its modules, propose client modules UNDER the existing app, never a new app |
| Duplicates a cross-cutting Core feature (Auth, Notifications…) | Explain the built-in, suggest an alternative |
| Single app for everything | Accept; warn if >8 modules |
| Two apps, similar scope | Suggest merging |

## After validation

Persist each application through the `menu-node` CLI (`SKILL.md` § "Writing a
node"): one `op=add level=application` call per app — `code`, `label`,
`contexte` (3-5 sentences), `horsPerimetre` (the picks of the out-of-scope
checkpoint, or `[]`), `sources`; on an empty tree pass `project` so the root
`index.md` is created with its own Hors-périmètre. `check` first (a built-in
platform match is refused unless `extension: true` + the Contexte sentence),
then `write`. Then acknowledge in one line and ask (AskUserQuestion)
whether to define modules for an app, add another app, or pause — per the
checkpoint rule in `SKILL.md`. Do not auto-propose modules.