---
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`.

## Research before proposing (MANDATORY)

Run **at least 2** silent web searches calibrated to the module's domain
("[domain] [module] software sections", "[domain] [module] typical screens"),
at least one naming the domain explicitly — generic queries are forbidden.
Then draft the FULL section list, self-audit it (`SKILL.md` § "Self-audit the
draft" — including the same-subject pairwise test below) and propose it
grouped by the three proposal tiers (Obligatoire / Suggestion /
Élargissement — `SKILL.md` § "Proposal tiers"), sources cited in one line.
Never announce research then stop — propose in the same turn.

## 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'`.

A section groups the sub-set of the module that deals with **ONE subject**;
two sibling sections about the same subject is an illogical split. Canonical
example — module Facturation: `factures` ✅ and `avoirs` ✅ are two distinct
subjects; `factures-editees` ❌ is a STATE of `factures` (a router filter, or
at best a resource under `factures`). This pairwise test is step 3 of the
MANDATORY self-audit (`SKILL.md` § "Self-audit the draft") and is enforced on
disk by the sections audit rule **SEC-008**.

## 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` |

> A **kanban / board / pipeline / calendar is NOT a section** — it is a
> *representation* (a layout) of an entity, with no business meaning of its own.
> A section must denote a **business** workspace. A kanban is authored as a
> **second screen** inside the entity's `*-list` section at `/ba-create-screen`
> (same entity, same permission, ONE route `/…/list` — the board renders as the
> list page's kanban viewMode, folded at the PRD) — never a
> `-board`/`-workflow`/`-pipeline` section. The cross-dimension audit XD-006 flags
> a kanban modeled as its own section.

`-detail`/`-edit`/`-create`/`-form` are NOT valid section codes (they're actions);
`-board`/`-workflow`/`-pipeline` are NOT valid section codes either (a board is a
*view* of an entity's list — author it as a second screen in the `*-list` section,
never a sibling section). 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

Persist each section through the `menu-node` CLI (`SKILL.md` § "Writing a
node"): one `op=add level=section` call per section with
`parent: { app, module }`, `code`, `label`, `contexte`, optional
`horsPerimetre` and `sources` — `check` (a verb/representation suffix, a
`settings` section or a code equal to the module's is refused) then `write`.
Acknowledge in one line and ask (AskUserQuestion) whether to add resources to a
voluminous section, move to another module, or finish the menu.