---
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 / board over an existing list | an alternate **view** of that entity's list — a 2nd screen in its `*-list` section (screen phase), never its own section or a resource | no resource, no section |

## 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); if yes, run the MANDATORY research (**at least 2**
silent domain-calibrated searches — e.g. "[domain] standard reports list" for
Pattern 1 — sources cited in one line), draft + self-audit (`SKILL.md`
§ "Self-audit the draft"), then ask a multi-select for the concrete resources
grouped by the three proposal tiers (`SKILL.md` § "Proposal tiers"). 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

Persist each resource through the `menu-node` CLI (`SKILL.md` § "Writing a
node"): one `op=add level=resource` call per resource with
`parent: { app, module, section }`, `code`, `label`, a one-line `contexte` —
`check` then `write`.

## 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..008) 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.