---
phase: menu
kind: level
level: resources
---

# Level 4 — Resources

> Scope strict: propose **resources** only — optional sub-menu entries under a
> section. Default is **none**. No entities/rules/screens/KPI/chart specs. The
> phase boundary, write protocol and code/label rules live in `SKILL.md`.

## Opt-in by default

A resource is an OPTIONAL sub-menu of a section, created **only** when a section
is too voluminous and a sub-division helps navigation. **Most sections need no
resource** — the default is none. Never create a resource for a UI widget, a KPI,
a chart, or a CRUD form (those are internal to the section / handled by the router).

### Not a resource

| Section type | Why | Correct |
|--------------|-----|---------|
| Dashboard (KPIs + charts) | the section IS the dashboard | no resource |
| Business listing (Employés, Commandes…) | router provides the filterable list | no resource |
| Simple form / entry | router handles CRUD | no resource |
| Calendar / kanban / org chart | specialized section, not a resource | no resource |

## When to propose a resource — 2 trigger patterns only

Permission-based splits are NOT evaluated here (that's the RBAC phase).

**Pattern 1 — Reports / Analyses section.** Trigger: the section label starts with
Rapport(s) / Report(s) / Analyse(s) / Analytics / Reporting. Each resource = ONE
coherent report telling ONE business story (a metadata anchor: code + label +
context; the KPI/chart layout comes later in screens). One report = one resource;
never one-per-KPI.

**Pattern 2 — Multi-entity sub-grouping.** Trigger: the section is a polymorphic
container (Tiers, Tenants, Contacts, Bénéficiaires…) or the user mentions several
distinct types in it. Each resource = one entity acting as a pre-filter with its
**own columns or actions** — not a mere status dropdown. If the partition doesn't
change columns/actions, don't propose it.

## How to propose

Default: emit no resource, move on. When a trigger matches: first confirm intent
(AskUserQuestion, yes/no), then if yes ask a multi-select for the concrete
resources. If the user keeps none, accept and move on. Resource labels are short
single-concept names (1-3 words), no `& / \ | < > "`; `context` is optional;
`resourceType` defaults to `Custom` at this stage.

## After validation

Write each resource under its section:
`.smartstack/ba/<APP>/<MODULE>/<section>/<resource>/index.md` (level=resource) +
the six placeholders, and add it to the section's `## Enfants`.

## End of menu architecture — hand off to actors

When the tree is complete for the project, recap it as a compact tree and ask the
user (AskUserQuestion) to **Valider** or **Corriger** — exactly two choices. Open
design questions go in prose ("à confirmer plus tard"), never in the choices.

On **Valider**: acknowledge in one line ("Structure validée — on établit l'ordre
d'analyse des modules"), make sure every node `index.md` is written, and hand off
to `/ba-create-ba-order` (phase 1.5 — BA ordering). The canonical order is fixed:
menu → **ba-order** → actors → use cases → rules → RBAC → data model → screens.
Never offer PRD/MCD/other as the next step here. On **Corriger**: parse the free
text, adjust, re-Write the affected `index.md`, re-recap, re-ask the same two
choices.

> Menu quality (duplicate/orphan/empty checks, MENU-001..005) is verified by the
> separate `/ba-audit-menu` skill, which reads the tree and writes its verdict —
> you don't emit audit findings from here.
