@atlashub/smartstack-cli 4.80.0 → 5.0.0

package/templates/skills/business-analyse/create-data-model/levels/attributes.md

@@ -0,0 +1,130 @@
+---
+phase: dataModel
+kind: level
+level: attributes
+---
+
+# Aspect — ATTRIBUTES (incl. computed formulas)
+
+For each entity, define its `tablePrefix`, `tenantMode`, business attributes
+(type, length, required, unique), computed formulas, indexes and an optional code
+pattern. You auto-deduce attributes from the module's `use-case.md` and
+`règles-métier.md` and present the complete result for review — you do NOT ask
+the user field by field.
+
+## How to deduce attributes (closed sources only)
+
+- **Business rules** — `salary >= minimumWage` → `Salary` (decimal); `when
+  status = 'active'` → `Status` (enum); "email unique per tenant" → `Email`
+  (string, unique).
+- **Use cases** — "fills in their leave dates" → `StartDate`, `EndDate`; "enters
+  an approval note" → `ApprovalNote` (text); "the system calculates the total" →
+  a **computed** attribute (see below).
+
+**NEVER from domain knowledge or web search.** "Standard" fields (`FirstName`,
+`Email`, `Status`, `TotalExclTax`…) are not a source: if no module UC/BR mentions
+the field, do not add it — surface the gap and defer. For a `person: mandatory`
+entity, identity fields (`FirstName`, `LastName`, `Email`) come from `auth_Users`
+— never redeclare them.
+
+## tablePrefix (functional domain, not module location)
+
+| Prefix | Domain | Prefix | Domain |
+|--------|--------|--------|--------|
+| `hr_` | Employee, Department, Timesheet | `crm_` | Customer, Lead, Opportunity |
+| `ops_` | Project, Task, Resource | `fin_` | Invoice, Payment, Budget |
+| `inv_` | Product, Warehouse, StockMovement | `cfg_` | tenant lookups |
+
+Invent 2-5 lowercase letters + `_` for new domains (`edu_`, `med_`…). Match the
+prefix of the module's existing entities when in doubt. Reserved prefixes are
+blocked — see SKILL.md § Collision detection.
+
+## tenantMode
+
+| Mode | Use for |
+|------|---------|
+| `strict` (default) | tenant-isolated business data (employees, orders, invoices) |
+| `optional` | shared resources with per-tenant overrides (email templates) |
+| `scoped` | tri-level visibility (tenant + shared catalog + platform) |
+| `none` | platform lookups single-set for all tenants (`Language`, `Country`) |
+
+Default `strict`. Use AskUserQuestion only when tenancy is genuinely ambiguous.
+
+## Types & lengths — stick to these
+
+**Strings:** 50 (codes), 100 (names/labels), 200 (titles), 256 (email/URL),
+500/1000/2000 (descriptions), 4000 (JSON), `text` (unbounded). Never arbitrary
+lengths — round to the nearest standard.
+
+**Decimals:** money `decimal(18,8)`; percentages `decimal(5,4)`; quantities
+`decimal(18,4)`; coordinates `decimal(9,6)`. Never `float`/`double` for money.
+
+**Palette:** `string text int long short decimal float double bool datetime date
+time guid enum json binary`.
+
+## Computed attributes (the `Calculé` column)
+
+When a value is **deterministically derived from other attributes of the SAME
+entity** (line total, consumption rate, age from a birth date), declare it as a
+normal attribute and put the **C# formula** in the `Calculé` column of
+`entité.md`. The dev cascade picks it up: DTO projection, repository LINQ
+`.Select(…)` (single query, no N+1), read-only React column.
+
+**Rules (load-bearing — they cascade to the dev pipeline):**
+- The formula is a C# expression referencing **PascalCase properties of the same
+  entity** (`Amount`, `Probability`, `BirthDate`).
+- **Cross-entity references are forbidden** (the audit rejects them). A value
+  needing data from a related entity stays a backend service / business rule.
+- Side-effect-free, EF-translatable (pure arithmetic / string concat). No method
+  calls EF can't translate. Max ~1000 chars.
+- A computed attribute has **no DB column and no setter** — it is read-only.
+
+| Use case | Type | Formula |
+|---|---|---|
+| Weighted amount of an opportunity | decimal | `Amount * Probability` |
+| Line total of an invoice item | decimal | `Quantity * UnitPrice * (1 + VatRate)` |
+| Full name of a contact | string | `FirstName + " " + LastName` |
+| Consumption rate of a budget | decimal | `(InitialAmount - CurrentBalance) / InitialAmount` |
+
+**When NOT computed:** the value is stored & user-editable; or it needs a related
+entity; or it's non-deterministic (random, time-now without an input attribute) →
+omit the formula (`—` in the column).
+
+## Framework fields — DO NOT list
+
+`Id`, `CreatedAt`, `UpdatedAt`, `CreatedBy`, `UpdatedBy`, `DeletedAt`, `TenantId`,
+`Scope` are implicit (base classes add them). Show only `Id Guid PK` in the table
+for readability; never the others.
+
+## Indexes & code patterns
+
+- **Indexes** — only those a UC/BR query pattern justifies. Unique for business
+  uniqueness ("no two users share an email" → `(Email) unique`); composite for
+  frequent filters (`(Status, CreatedAt)`). No need to index FK columns (EF
+  auto-indexes them). In `entité.md`, list as `(Field)` / `(Field) unique`.
+- **Code pattern** — only for entities users refer to by number (Order, Invoice,
+  Ticket, Employee matricule, Product). A `codePattern` is the data-model side of a
+  `numbering` business rule (`/ba-create-business-rules`) and carries:
+  - **format** — template with tokens (`AFF-{YY}-{SEQ:4}` → prefix + 2-digit year
+    + 4-digit zero-padded counter) ;
+  - **scope** — `tenant` (default, tenant-isolated data) / `global` (platform-wide)
+    / `parent:<Entity>` ; **must be consistent with `tenantMode`** ;
+  - **reset** — `none` / `yearly` / `monthly` / `daily`, aligned with a date token
+    in the format (yearly ⇒ `{YY}`) ;
+  - **gapless** — `true` (legal/accounting, no gaps) / `false` (gaps tolerated).
+
+  Strategy shorthands still apply: `sequential` (default), `year-sequential`
+  (invoices), `timestamp-daily` (high daily volume), `uuid-short` (tokens).
+  Reference the `numbering` rule code (`BR-…`) in the entity's **Traçabilité**.
+  When the pattern is **gapless + tenant-scoped**, also model the counter as a
+  `technical` allocator entity (see `identify.md`) so the per-tenant sequence is
+  explicit in the MCD. Lookups, junctions and audit logs get no code pattern.
+
+## Quality checks (per entity)
+
+- `tablePrefix` matches `^[a-z]{2,5}_$`, not reserved; `tenantMode` set.
+- ≥1 attribute; every string has a length, every decimal precision/scale, every
+  enum non-empty values.
+- Computed attributes reference only same-entity PascalCase props (no
+  cross-entity).
+- No framework field listed. Then continue to relationships (`./relationships.md`).

package/templates/skills/business-analyse/create-data-model/levels/identify.md

@@ -0,0 +1,100 @@
+---
+phase: dataModel
+kind: level
+level: identify
+---
+
+# Aspect — IDENTIFY entities
+
+Discover **all entities** the current module needs, from its `use-case.md` and
+`règles-métier.md` only. You do NOT ask the user which entities to keep — you
+deduce them and present them for review. **Every entity needs a verbatim trace**
+to ≥1 UC/BR of this module; non-traceable entities are forbidden.
+
+## Read first (the only entity sources)
+
+| Source | What to extract |
+|--------|-----------------|
+| `index.md` (module) | scope + `## Hors-périmètre` — all work is limited to this module |
+| `use-case.md` | nouns in main/alternative flows + pre/postconditions → candidate entities; verbs and actors are NOT entities |
+| `règles-métier.md` | the rule's target concept → entity; PascalCase tokens in the expression (skip primitives) → referenced entities |
+| `entité.md` (if present) | existing entities — enrich alongside, don't duplicate |
+
+Web search, "domain knowledge", "best practices" and analogy with other apps are
+**NOT sources**. If a candidate has no verbatim trace in this module's UC/BR,
+defer to `/ba-create-use-case` or `/ba-create-business-rules` — never invent.
+
+## Deduction rules
+
+**From use cases** — for each step of the main flow, identify the nouns (objects
+acted upon) → entities; ignore verbs (rules/steps) and UI words (button, page,
+dialog). Each precondition/postcondition that asserts a thing exists ("the order
+exists" → Order; "the audit log has an entry" → AuditLog). A UC's primary actor
+often has a domain counterpart entity (`Employee` for an EMPLOYEE actor) — model
+the counterpart, not the actor.
+
+**From business rules** — the rule's target concept is the entity it constrains;
+its condition hints at which attributes matter; PascalCase tokens in its
+expression name referenced entities. If a rule expression references an entity
+you didn't list, add it with a trace to that rule.
+
+**Junctions, lookups, snapshots** — admissible **only when an upstream reference
+forces them**:
+- N:M junction → only when a UC/BR explicitly implies the cardinality.
+- Lookup (`ContractType`, `Country`) → only when a UC/BR references it. A rule
+  "contract types: CDI, CDD, STAGE" forces a `ContractType` lookup; absent any
+  reference, do NOT invent it.
+- Historical snapshot / audit log → only when a UC/BR requires the trace.
+
+Each is forbidden until an upstream reference exists. Surface the gap and defer.
+
+## Scoring grid → classification (drives the `(role)` label)
+
+Score each entity 0-3 on five criteria (total 0-15):
+
+| Criterion | 0 | 1 | 2 | 3 |
+|-----------|---|---|---|---|
+| Lifecycle (states) | static | simple CRUD | CRUD + 1-3 states | full lifecycle |
+| Actors (who interacts) | admin only | 1 role | 2-3 roles | 4+ / public |
+| Relations (FK count) | 0-1 | 1-3 | 3-5 | 5+ |
+| Volume (rows) | < 50 | 50-500 | 500-5 000 | 5 000+ |
+| Autonomy | no sense alone | context-dependent | stands alone | independent domain |
+
+| Total | Classification | Role hint for the `entité.md` heading |
+|-------|----------------|----------------------------------------|
+| 0-3 | `lookup` | `lookup` — admin-managed reference table |
+| 4-6 | `component` | `composant` — sub-entity managed inside a parent |
+| 7-10 | `lightweight-module` | own list section |
+| 11-15 | `full-module` | `agrégat racine` — rich lifecycle, own section tree |
+
+The classification drives downstream UI decisions (a `lookup` needs only an admin
+page; a `full-module` deserves its own section tree).
+
+**`technical` (special, score 0-3).** When a 0-3 entity is an infrastructure
+allocator — a sequence/counter handing out reference numbers (e.g. a
+`DemandeSequence` issuing `AFF-YY-NNNN`), an outbox, or an audit-only log —
+rather than admin-managed business reference data, label it `technical` (not
+`lookup`). It is isolated by nature (no business relationship), so add an
+`- **Isolation** : by-design — <reason>` line to its `entité.md` heading block:
+that records the intent in the model and exempts it from audit DM-009. It gets
+no list/admin UI by default.
+
+A `technical` allocator is the table backing a **gapless** per-tenant
+`codePattern` (see `attributes.md` § Code pattern): one counter row per scope
+(e.g. keyed `{tenantId, year}`) with a `nextValue:int`. Declare it whenever a
+`numbering` rule requires no gaps; for a non-gapless pattern the `codePattern`
+metadata alone is enough (the runtime allocator the Studio provides handles it).
+
+## Quality checks (per entity, before proposing)
+
+- Has a business identity (a user would refer to it by name)?
+- Persistent (survives across sessions)?
+- **Traceable** verbatim to ≥1 UC step / pre-postcondition or BR target /
+  expression token **of this module**? *(blocking — cross-module refs become
+  plain `Guid` FK attributes instead)*
+- Classification consistent with its score?
+- `person` mode unambiguous (mandatory / optional / none — see SKILL.md)?
+- Description understandable by a developer with no context?
+
+If any answer is "no" → drop the candidate or surface the gap and defer to the
+upstream phase. Then move on to attributes (`./attributes.md`).

package/templates/skills/business-analyse/create-data-model/levels/relationships.md

@@ -0,0 +1,97 @@
+---
+phase: dataModel
+kind: level
+level: relationships
+---
+
+# Aspect — RELATIONSHIPS
+
+Connect the entities with foreign keys and cardinalities. For each relationship
+between **two entities of the SAME module**, define: cardinality
+(`1:1`/`1:N`/`N:1`/`N:M`), FK name (PascalCase, usually `{Target}Id`), required
+(nullable?), and cascade (`restrict`/`cascade`/`set-null`/`no-action`). You
+auto-deduce relationships from entity attributes, use cases and rules — never
+from domain knowledge — and present the complete map for review.
+
+## How to deduce (closed sources only)
+
+- **Names/attributes** — `OrderLine` belongs to `Order` → N:1, FK `OrderId`; a
+  "department" concept on Employee → N:1 to Department.
+- **Use cases** — "the manager approves the leave request" → LeaveRequest N:1
+  Employee (approver); "the order contains multiple lines" → Order 1:N OrderLine.
+- **Business rules** — "cannot delete a department with employees" → `restrict`
+  on Department→Employee; "when an order is cancelled, lines are soft-deleted" →
+  `cascade` on Order→OrderLine; "if a ticket has no assignee, route to pool" →
+  nullable assignee, `set-null`.
+
+**NEVER from domain knowledge.** Hierarchical-tree, "manager-of", "category-of",
+"type-of" reflexes are not sources: if no module UC/BR names the relationship,
+defer to the upstream phase. Pick `restrict` only when a BR says deletion is
+blocked; otherwise surface the gap.
+
+## Cardinality
+
+| Cardinality | Meaning | FK lives on |
+|-------------|---------|-------------|
+| `1:1` | each A ↔ exactly one B | the dependent side |
+| `1:N` | each A has many B; each B one A | on B (`AId`) |
+| `N:1` | each A has one B; each B many A | on A (`BId`) |
+| `N:M` | each A many B and vice-versa | junction table (composite key) |
+
+Declare the **owning side** (the one with the FK column); the inverse navigation
+is auto-created. An `N:M` without payload (a pure tag cloud, e.g. Employee↔Skill)
+is declared on one side; the junction table is generated automatically. If the
+junction carries business meaning (e.g. `Enrollment` between Student and Course
+with a grade and a completedAt), model it as a **separate entity** with two `N:1`
+relationships instead of an `N:M`.
+
+## Required & cascade
+
+- **required** — `true` when a BR says "must exist" / "cannot be null"; else
+  `false`. Self-references are usually `false` (root nodes exist).
+- **cascade** — `cascade` when children can't exist without the parent
+  (`Order`→`OrderLine`); `restrict` when a BR blocks deletion
+  (`Department`→`Employee`); `set-null` to detach (requires nullable FK,
+  `Ticket`→`Assignee`); `no-action` for self-references (SQL can't cascade a
+  cycle). **Default `restrict`.** A self-referencing hierarchy (org chart,
+  category tree) uses `N:1` self-ref, FK `{Role}Id` nullable, cascade
+  `no-action`.
+
+## Cross-module relationships — DESIGN RULE (load-bearing)
+
+The MCD is **scoped to ONE module** (`entité.md` per module). The EF Core
+generation pipeline does **not navigate across module boundaries** — cross-module
+FKs are reconciled via `ICoreDataService`-style lookups, with no navigation
+property. Therefore:
+
+- **Same-module FK** → declared as a **relationship** (cardinality + cascade
+  matter for code generation).
+- **Another module of the same app, another app's module, or SmartStack Core**
+  (`auth_Users`, `nav_*`, `tnt_*`, …) → model the FK as a **plain `Guid`
+  attribute**, declare NO relationship.
+
+| Target lives in… | Use |
+|------------------|-----|
+| Same module | declared `relationship` |
+| Another module of the same app | **plain `Guid` attribute** — no relationship |
+| Another app's module | **plain `Guid` attribute** — no relationship |
+| SmartStack Core | **plain `Guid` attribute** — no relationship |
+
+Naming for the plain FK attribute: `{TargetName}Id` (`ContactId`, `OwnerUserId`).
+Always give it a description naming the foreign module/entity, e.g.
+`ContactId (Guid) — FK cross-module vers CRM/CONTACTS.Contact`. In `entité.md`,
+such a FK appears as a normal row in the attribute table (type `Guid`), NOT in
+the `Relations` line.
+
+## Quality checks (per entity)
+
+- Every relationship targets an entity **of the same module**.
+- No relationship targets another module or Core — those are plain `Guid`
+  attributes.
+- No duplicate relationship name within an entity.
+- `required: true` is consistent with the FK being non-nullable (cannot pair
+  `required: true` with `set-null`).
+- Self-references use `no-action`.
+- `N:M` is either payload-free or already promoted to a separate junction entity.
+
+After relationships, Write `entité.md`.

package/templates/skills/business-analyse/create-menu/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: ba-create-menu
+description: >
+  Phase 1 of business analysis. Builds the Application → Module → Section →
+  Resource menu hierarchy for a project as a folder tree of `index.md` files
+  under `.smartstack/ba/`. Conversational: reads the current tree, proposes the
+  next level, asks the user to validate, then writes the files. Run this first,
+  before defining actors, use cases, rules, RBAC, data model, or screens.
+allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion]
+---
+
+# ba-create-menu — 4-layer menu architecture
+
+You are a business analyst defining the **menu architecture** of a project
+through conversation. Your entire output for this phase is a tree of
+**Application → Module → Section → Resource**. Nothing else.
+
+## File model — state & persistence (read this first, every turn)
+
+State lives in the `.smartstack/ba/` directory of the current project — there is
+no database and no action blocks. On every turn:
+
+1. **Read the current tree**: `Glob .smartstack/ba/**/index.md`. Each folder is a
+   node named by its **code**; each `index.md` holds its label, context and
+   out-of-scope. If `.smartstack/ba/` does not exist, this is a brand-new
+   project — you will create it.
+2. **Propose** the next level in prose (list every code + label you propose so
+   the user sees it).
+3. **Ask** the user to validate with the **AskUserQuestion** tool (closed
+   choices). Open questions (sector, scope) go in normal prose.
+4. **Write** the result with the **Write** tool once validated (see "Writing a
+   node" below). A Write overwrites the whole file — re-list every item that
+   must survive.
+
+Closed choices use AskUserQuestion (never a numbered list in prose). Confirm any
+deletion before writing.
+
+### Codes & labels (enforced)
+
+| Level | Folder = code format | Example code | Example label |
+|-------|----------------------|--------------|---------------|
+| Application | `^[A-Z][A-Z0-9_]*$` | `CRM` | CRM |
+| Module | `^[A-Z][A-Z0-9_]*$` | `PIPELINE` | Pipeline |
+| Section | `^[a-z][a-z0-9-]*$` | `opportunites` | Opportunités |
+| Resource | `^[a-z][a-z0-9-]*$` | `devis` | Devis |
+
+Codes are ASCII (no accents); labels keep the user's language and accents. The
+folder name IS the code (`Opportunités` → folder `opportunites`).
+**Forbidden in any label**: `& / \ | < > "` — they signal a label bundling two
+concepts; split into two nodes or pick a single unifying name.
+
+## ⛔ Phase boundary — menu only
+
+Your output captures node **names + business context** only. Defer everything
+else to its phase — acknowledge in one line and move on, never preview the spec:
+
+| Forbidden in this phase | Owner phase |
+|-------------------------|-------------|
+| Entities, attributes, fields, FK/PK, tables, schema | data model (`/ba-create-data-model`) |
+| Business rules, validations, "si X alors Y" | rules (`/ba-create-business-rules`) |
+| Routes, URLs, permissions, roles, `.access` codes | RBAC (`/ba-create-rbac`) |
+| Screens, wireframes, KPIs, SmartComponents | screens (`/ba-create-screen`) |
+| Use cases, actor flows, scenarios | use cases (`/ba-create-use-case`) |
+| Actors / roles | actors (`/ba-create-actors`) |
+
+### Familiar-domain trap — HARD GATE
+
+Well-known domains (HR, CRM, stock, billing) tempt you to emit a complete spec
+in one shot. Before every Write, check these bounds:
+
+- applications ≤ 4 per project · modules ≤ 8 per app · sections ≤ 6 per module ·
+  resources ≤ 8 per section
+
+If a bound is exceeded → STOP and propose a split across turns. If you catch
+yourself writing "Entités principales", "Règles métier", "Routes" — STOP and
+rewrite as menu-only.
+
+### Calibration restraint — HARD CAP
+
+For a NEW application you may ask **AT MOST 1** calibration question (via
+AskUserQuestion) before proposing — targeting industry/sector, scope, or org
+size, nothing else. If the user's prompt already answers it, skip the question
+and propose directly. A 2nd calibration question is the #1 way this phase drifts.
+
+## The 4 levels & decision table
+
+```
+Application → Module → Section → Resource
+```
+
+Read the current tree, match the row, follow the level file. Re-read the tree
+after every Write and re-enter this table.
+
+| Tree state (for the focus app X) | Follow |
+|----------------------------------|--------|
+| `.smartstack/ba/` empty / first message | `./levels/applications.md` |
+| App X has no modules | `./levels/modules.md` |
+| X has modules, modules lack sections | `./levels/sections.md` |
+| All X's modules have sections | `./levels/resources.md` |
+| Complete tree for X | hand off to `/ba-create-actors` |
+| User asks to merge two modules | `./levels/modules.md` § "Fusion" |
+| User asks to modify/rename an element | adjust + re-Write the affected `index.md` |
+| Informational question, no change | answer in prose, no Write |
+
+The workflow is **per-app**: each app goes through applications → modules →
+sections → resources independently.
+
+## Writing a node (the persist step)
+
+When the user validates, write the node(s) with the **Write** tool. Each node is
+a folder named by its code under its parent, containing an `index.md` plus six
+placeholder docs so the structure is uniform from creation.
+
+### `index.md` shape (every node)
+
+```markdown
+<!-- ba:node kind=node level=application code=CRM -->
+# CRM — Gestion commerciale
+
+## Contexte
+{2-3 sentences: the business WHY of this node.}
+
+## Hors-périmètre
+- {explicit exclusion — "not in v1", "covered by BILLING", a refused behaviour}
+
+## Enfants
+- [PIPELINE](./PIPELINE/index.md) — Pipeline d'opportunités
+```
+
+- `level` ∈ `project | application | module | section | resource`.
+- `## Contexte` is REQUIRED (apps/modules/sections); 2-3 sentences. Resources may
+  have a one-line context.
+- `## Hors-périmètre` is optional but **strongly encouraged** whenever the user
+  signalled exclusions ("pas X", "plus tard", "ça c'est ailleurs") — the
+  downstream PRD reads it to stay in scope. Empty only when no exclusion exists.
+- `## Enfants` lists child nodes with relative links; refresh it whenever you add
+  a child. The root `.smartstack/ba/index.md` (`level=project`) lists the apps.
+
+### Scaffold the six placeholder docs
+
+When you create a NEW node folder, also create the six concept docs as
+placeholders so later phases fill them in place:
+
+```markdown
+<!-- ba:acteur level=application code=CRM -->
+_À définir lors de la phase « acteurs » (/ba-create-actors)._
+```
+
+Create one per concept with the right anchor: `acteur.md`, `entité.md`,
+`use-case.md`, `règles-métier.md`, `rbac.md`, `screen.md`. (Keep these French,
+accented filenames verbatim.) Later phases replace the placeholder with real
+content at the authoritative level and write rollups elsewhere — that is their
+job, not yours.
+
+### Modifying & deleting
+
+- **Rename / re-context**: read the node's `index.md`, edit the heading/sections,
+  Write it back. Update the parent's `## Enfants` link/label.
+- **Delete a node**: confirm with AskUserQuestion, then remove the node's folder
+  (and its descendants) and drop it from the parent's `## Enfants`. Use the Bash
+  `rm`/`Remove-Item` only after explicit confirmation, or tell the user which
+  folder to delete if you lack a remove tool.
+- **Merge two modules** (fusion): re-parent the source module's children under
+  the target, merge their `## Contexte`, delete the source folder, and fix every
+  `## Enfants` list. See `./levels/modules.md` § "Fusion".
+
+## After writing a level → checkpoint, don't auto-drill
+
+After writing applications (or modules, …), acknowledge in **one line** and ask
+the user — via AskUserQuestion — whether to continue to the next level, add a
+sibling, or pause. Do NOT auto-jump into proposing modules before the user opts
+in. Never list "what phase next?" — the order is fixed (menu → actors → …).
+
+## Absolute prohibitions
+
+1. **Sections are nouns**, never verbs/actions (`factures`, not `create`/`emettre`).
+   Sole exception: `list`/`liste` (maps to a list view). Actions are buttons, not sections.
+2. **Never a `Settings` section** — settings are a MODULE.
+3. **Never a `SETTINGS` application** — each app owns its settings.
+4. **Never duplicate SmartStack Core**: Ticketing/Support, Authentication/SSO,
+   Administration (permissions, audit logs), Notifications, Workflows, Data export.
+5. **Never "CORE" terminology** — use Fundamental / Recommended / Advanced.
+6. Sections are autonomous workspaces (Dashboard, Pipeline, Calendar, List), not
+   transient CRUD operations.
+
+## Per-level guidance
+
+Load the level file that matches the decision table for the detailed proposal
+heuristics: `./levels/applications.md`, `./levels/modules.md`,
+`./levels/sections.md`, `./levels/resources.md`. They carry the exploration
+checklist, two-axis (manager/portal) pattern, naming rules, and edge cases.

package/templates/skills/business-analyse/create-menu/levels/applications.md

@@ -0,0 +1,85 @@
+---
+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.
+4. **Present a short exploration summary** (project, prefix, current tree,
+   existing code, verdict: new / extend / fill gaps).
+
+## 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 SmartStack
+  Core (never duplicate built-ins); **challenge** (>8 potential modules → split;
+  similar scope → merge); **verify** each app is autonomous.
+- **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 |
+| Duplicates SmartStack Core | Explain the built-in, suggest an alternative |
+| Single app for everything | Accept; warn if >8 modules |
+| Two apps, similar scope | Suggest merging |
+
+## After validation
+
+Write each application: create `.smartstack/ba/<CODE>/index.md` (level=application)
++ the six placeholder docs, and add the app to the project root
+`index.md` `## Enfants`. 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.