---
phase: menu
kind: level
level: sections
---

# Level 3 — Sections

> Scope strict: propose **sections** for one or more modules. No resources/
> entities/rules/screens. Section code + label + context only. The phase
> boundary, write protocol and code/label rules live in `SKILL.md`.

## What a section is

A section is an **autonomous workspace** in the menu — a distinct activity the
user performs in a module, with its own entry point, its own functionality, and
potentially its own permissions. Each section answers: "what distinct activity
does the user do here?"

## A section is a NOUN, never a VERB (one exception)

A section is **where** the user works; an action is **what** they do. Actions are
buttons or nested routes, never sibling sections. Test: translate the code and
read it — if it's a verb, it's not a section.

| Pattern | Verdict |
|---------|---------|
| Noun — `factures`, `enveloppes`, `mouvements`, `directory` | ✅ Section |
| Exception — `list` / `liste` | ✅ Section (maps to a list view) |
| `create`, `edit`, `detail`, `close`, `emettre`, `valider`, `archiver`, … | ❌ Action — button/route |
| `parametres`, `settings` | ❌ This is a MODULE, not a section |

## A section is a DISTINCT ENTITY, never a STATE FILTER of a sibling

Two sections in the same module must describe **different entities or workflows**,
not the same entity at different lifecycle stages. A "history"/"archive"/"closed"
view of an existing list belongs INSIDE that list (a router filter or status tab),
or as a Step-4 resource if it has its own columns/actions — never as a sibling.

Test: does candidate Y share its primary entity with a sibling X, filtering only
a subset (status/period/state)? If yes → Y is a filter, not a section. **Default
when unsure = filter.** A section is justified only by its own columns, actions,
or permissions — not by a `WHERE status='closed'`.

## Code → screen type (downstream impact)

The kebab-case `code` you choose drives the SmartComponent that `/ba-create-screen`
generates later. Pick the suffix on purpose:

| Section code ends with | Screen type later |
|------------------------|-------------------|
| `-home`, `-overview`, `-dashboard` | `SmartSectionHome` / `SmartDashboard` |
| `list`, `liste`, `-list`, `-grid`, `-search` | `SmartListView` |
| `-board`, `-workflow`, `-pipeline` | `SmartKanban` |

`-detail`/`-edit`/`-create`/`-form` are NOT valid section codes (they're actions).
A section code must not equal its parent module's code; default to `list` for a
list or `dashboard` for an aggregate view.

## Naming

- Short single-concept phrases (1-4 words); no `& / \ | < > "`.
- "X et Y": same activity → one umbrella label; two distinct activities → two
  sections with distinct codes.
- Always pick BOTH a kebab-case `code` and a clear user-language `label` — never
  echo the raw code as the label.

## Edge cases

| Situation | Action |
|-----------|--------|
| User proposes a verb as a section | Explain noun=section, action=button; re-propose with the entity noun |
| Module has only 1 section | Acceptable if simple |
| No section justifies the module | Propose merging the module |
| User wants a "Settings" section | Explain it's a module |

## After validation

Write each section under its module: `.smartstack/ba/<APP>/<MODULE>/<section>/index.md`
(level=section) + the six placeholders, and add it to the module's `## Enfants`.
Acknowledge in one line and ask (AskUserQuestion) whether to add resources to a
voluminous section, move to another module, or finish the menu.
