@atlashub/smartstack-cli 4.80.0 → 5.0.0

package/templates/skills/business-analyse/audit-rbac/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: ba-audit-rbac
+description: >
+  Audits the RBAC permission matrix of a `.smartstack/ba/` module — minimum
+  permissions, segregation of duties, actor coverage and reference integrity
+  (RBAC-001..005). Reads the module `rbac.md`, the app `acteur.md` and the
+  section `use-case.md`, writes a verdict to `_audit/rbac.md`. Run after
+  `/ba-create-rbac` or as part of pre-dev readiness.
+allowed-tools: [Read, Write, Glob, Grep]
+---
+
+# ba-audit-rbac — RBAC permissions audit
+
+You audit the RBAC permission matrix of a `.smartstack/ba/` module against the
+rules below and write a verdict file. The rules are unchanged from the SmartStack
+convention; only the I/O is file-based.
+
+## File model — how to audit
+
+1. **Read state**: `Glob .smartstack/ba/**/index.md` to rebuild the tree, then
+   read the module's `rbac.md` (the permission matrix — actor ×
+   `module.section[.resource].action` × scope), the parent app's `acteur.md` (the
+   authoritative actor list, codes `BA-…-AC-…`), and each section's `use-case.md`
+   under the module (the actions the use cases imply, for coverage). Permissions
+   are `module.section[.resource].action` within the module (3 segments for a
+   section, 4 for a resource); the app prefix is added downstream, not here.
+2. **Apply** the rules RBAC-001..005 (below) to every permission in the module.
+3. **Write** the verdict to `_audit/rbac.md` under the audited module:
+   `.smartstack/ba/<APP>/<MODULE>/_audit/rbac.md` (use the audit-verdict skeleton
+   from `_workflow/doc-templates.md`). Then print a 3–6 line business summary in chat.
+
+There is no database, no `[ACTION]` envelope, no i18n label codes — the `.md`
+verdict IS the record. The verdict header (`0 err` = pass) is what a downstream
+gate reads.
+
+## Scope
+
+- **Module scope** (default): audit one module — apply RBAC-001..005 to its
+  matrix. RBAC-004 only checks actors that have at least one permission entry in
+  this application's modules; do NOT flag actors from other applications as
+  missing permissions in this module.
+- The verdict file lives at the audited module's `_audit/rbac.md`.
+
+## Rules
+
+### RBAC-001 — At least 1 permission exists per module
+- **Severity**: err (if 0), ok (if >= 1)
+- **ok**: the module's matrix has at least one permission entry (state the count).
+- **err**: the module has zero permissions — name the module.
+- Fix: `/ba-create-rbac`.
+
+### RBAC-002 — Every section has minimum permissions (access + read) for at least 1 actor
+- **Severity**: err (if missing), ok (if all have)
+- Check: for each section, at least 1 actor must have both `access` and `read` actions.
+- **err**: list the sections lacking the minimum (access + read) for any actor.
+- Fix: `/ba-create-rbac`.
+
+### RBAC-003 — No segregation of duties violations
+- **Severity**: warn (if found), ok (if none)
+- **Toxic pairs** (same actor, same target must NOT have both):
+  - `create` + `approve` (creator should not approve their own work)
+  - `delete` + `restore` (prevents abuse)
+- **warn**: list the offending actor × target × pair violations.
+- Fix: `/ba-create-rbac`.
+
+### RBAC-004 — All defined actors have at least 1 permission in the module
+- **Severity**: warn (if orphan actors), ok (if all have)
+- **warn**: list the actors (of this application) with no permission entry in the module.
+- Fix: `/ba-create-rbac`.
+
+### RBAC-005 — All permission actor references point to existing actors
+- **Severity**: err (if unknown actor IDs), ok (if all valid)
+- Check: every `BA-…-AC-…` referenced in the matrix is authored in the app's `acteur.md`.
+- **err**: list the unknown actor IDs.
+- Fix: `/ba-create-rbac`.
+
+## Output
+
+Write `_audit/rbac.md` per the doc-templates skeleton:
+- Header `# Audit rbac — <APP> / <MODULE>` + `_<date> · Verdict : <emoji> N warn · M err · K ok_`.
+- `## ✅ Conforme`, `## ⚠️ Avertissements`, `## ❌ Bloquants` sections; one bullet
+  per finding. For `warn`/`err`: what's wrong (offending actor/permission/section
+  codes **bold**), why it matters, and a `→` fix naming `/ba-create-rbac`. Include
+  the concrete offending permission/actor/section names so the fix is actionable.
+- Re-Write the whole file each run (overwrite — it's a fresh verdict).
+
+Then a 3–6 line chat summary in the user's language — business terms, not rule
+codes. If any `err`, state clearly that the permissions must be fixed before moving on.
+
+## Used by the readiness orchestrator
+
+`/ba-audit-pre-dev` runs every dimension and aggregates the verdicts. When invoked
+by it, still write `_audit/rbac.md` as usual — the orchestrator reads these files.

package/templates/skills/business-analyse/audit-rules/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: ba-audit-rules
+description: >
+  Audits the business rules of a `.smartstack/ba/` module — completeness,
+  conflicts, redundancy, example quality, entity/UC references, per-ruleType
+  edge-case coverage (BR-001..010). Reads `règles-métier.md` plus the module's
+  `use-case.md` and `entité.md`, writes a verdict to `_audit/règles-métier.md`.
+  Run after `/ba-create-business-rules` or as part of pre-dev readiness.
+allowed-tools: [Read, Write, Glob, Grep]
+---
+
+# ba-audit-rules — Business Rules audit
+
+You audit the business rules of a `.smartstack/ba/` module against the rules
+below and write a verdict file. The rule set is unchanged from the SmartStack
+convention; only the I/O is file-based.
+
+## File model — how to audit
+
+1. **Read state**: `Glob .smartstack/ba/**/index.md` to locate the module in
+   scope. Read `.smartstack/ba/<APP>/<MODULE>[/<section>]/règles-métier.md` for
+   the rules (codes, type, severity, condition, expression, error code, valid/
+   invalid examples, linked use cases). Also read the module's `use-case.md`
+   (to validate UC references and the upstream detail gate) and `entité.md` (to
+   validate entity references). To check a UC or entity code exists, Grep it
+   across the tree — if it's not found, it does not exist.
+2. **Apply** the rules BR-001..009 (below) at the requested scope.
+3. **Write** the verdict to `_audit/règles-métier.md` under the audited module:
+   `.smartstack/ba/<APP>/<MODULE>/_audit/règles-métier.md` (keep the accented
+   filename; use the audit-verdict skeleton from `_workflow/doc-templates.md`).
+   Then print a 3–6 line business summary in chat.
+
+There is no database, no `[ACTION]` envelope, no i18n label codes — the `.md`
+verdict IS the record. The verdict header (`0 err` = pass) is what a downstream
+gate reads.
+
+## Gate dependencies
+
+- **Upstream**: the use-cases phase must be ready before rules can be considered
+  complete. If any UC in scope lacks a detailed main flow, this phase cannot
+  complete — BR-009 emits `err` regardless of rule count.
+- **Downstream**: the RBAC phase depends on this phase being ready (rules
+  materialise access/ownership permissions).
+
+## Scope
+
+- **Module scope** (default): audit rules whose scope belongs to the target
+  module. UCs are audited for UC → rule coverage within the same module.
+- **Section scope**: restrict every check (BR-001..009) to rules whose section
+  matches the selected section. BR-001 becomes "at least 1 rule for the selected
+  section"; BR-007 becomes "every UC in the selected section has ≥1 linked rule".
+  Read only the section's `règles-métier.md` and `use-case.md`.
+- **Application / project scope**: rules from all descendant modules apply.
+- Rules outside the active scope are out of scope. The verdict file lives at the
+  audited module's `_audit/règles-métier.md`.
+
+## Rules
+
+### BR-001 — At least 1 business rule exists per module
+- `err` if 0; `ok` if ≥ 1.
+- Fix: `/ba-create-business-rules`.
+
+### BR-002 — Rules carry complete examples (Level 2)
+- `err` if any rule with examples is incomplete; `warn` if no examples at all on
+  ≥1 rule; `ok` if all complete.
+- **What to check**:
+  1. Rules with no examples → `warn` — rule still at Level 1 shell stage.
+  2. Rules with ≥1 example must have **≥1 valid + ≥1 invalid** → `err` if missing
+     either side.
+  3. Every example must have a non-empty given, when, then → `err` if any field
+     blank.
+  4. **Enforcement rules only** (rule has a populated error code or error
+     message): invalid examples must have an expected error code OR expected
+     error message → `err` if both missing. **Filter/visibility rules** (rule
+     has no error code AND no error message, e.g. soft-delete guards,
+     anonymisation filters, scope isolation) describe observable absence —
+     invalid examples legitimately leave the expected error code and message
+     empty. Do NOT flag these.
+- Fix: `/ba-create-business-rules`.
+
+### BR-003 — No conflicting rules (same condition, different outcomes)
+- `err` if conflicts found; `ok` if none.
+- Check: normalize conditions (lowercase, trim). Group by condition. If the same
+  condition has different expressions → conflict.
+- Fix: `/ba-create-business-rules`.
+
+### BR-004 — No redundant rules (same condition AND same expression)
+- `warn` if found; `ok` if none.
+- Fix: `/ba-create-business-rules`.
+
+### BR-005 — (relocated to DM-010 in `/ba-audit-data-model`)
+Entity-reference validation moved to the data-model audit where the entity
+catalogue is authoritative. No check here.
+
+### BR-006 — All rules are linked to at least 1 use case
+- `warn` if unlinked; `ok` if all linked.
+- Direction: rule → UC. Complement of BR-007.
+- Fix: `/ba-create-business-rules`.
+
+### BR-007 — Every use case in scope is covered by ≥1 business rule
+- `err` if UCs without rules; `ok` if every UC has ≥1 linked rule.
+- Direction: UC → rule. Complement of BR-006.
+- Check: for each UC in scope, count rules whose linked use cases contain the UC
+  code. If 0 → UC is uncovered.
+- Why `err` (not `warn`): a UC without rules cannot be vibecoded — the generated
+  code would have no invariants, no validation, no failure paths. Downstream code
+  generation breaks.
+- Fix: `/ba-create-business-rules`.
+
+### BR-008 — Examples cover the edge cases expected for the ruleType
+- `warn` if obvious edge cases are missing for the ruleType; `ok` if covered.
+- Reference: `create-business-rules` edge-case checklist by ruleType.
+- Check per ruleType (minimum expected coverage — at least one example hitting each):
+
+  | ruleType | Required edge cases (pick ≥2 of) |
+  |----------|----------------------------------|
+  | `validation` | null/empty, boundary (min/max length), format mismatch, case-insensitive dup |
+  | `calculation` | zero, negative, rounding boundary, division by zero when applicable |
+  | `state-transition` | illegal skip, reverse transition, terminal-state exit |
+  | `ownership` | owner allowed, non-owner denied, manager/admin bypass |
+  | `constraint` | at-limit boundary, just-above/below, null-vs-zero |
+  | `derivation` | missing input (null component), recompute-on-update |
+  | `workflow` | threshold boundary, delegation, timeout |
+  | `integrity` | soft-deleted parent, cascade, orphaned child |
+  | `cross-cutting` | batch operation, system/service account, retry |
+  | `compliance` | retention expiry, retroactive policy change |
+  | `access` | actor with permission, actor without permission |
+  | `numbering` | sequence progression, per-tenant isolation, reset boundary, concurrent allocation (no duplicate) |
+
+- How to detect coverage: scan each example's label, given, when, then for
+  keywords from the expected list (case-insensitive). If fewer than 2 of the
+  expected edge-case themes are matched → `warn`.
+- Fix: `/ba-create-business-rules`.
+
+### BR-009 — Upstream gate: every UC in scope must be detailed
+- `err` if any UC in scope is not detailed; `ok` if all detailed.
+- **Why**: per the gate chain `actors → UCs → rules → permissions`, rules cannot
+  be considered complete while use cases are still in progress. Without detailed
+  main flows, rules have nothing concrete to constrain and any downstream code
+  generation would produce empty validation paths.
+- **Check**: a UC is "detailed" when it has ≥1 main-flow step. Read the module's
+  `use-case.md` and collect every UC code in scope (module or section) whose main
+  flow is empty.
+- Fix: `/ba-create-business-rules` (and re-run `/ba-create-use-case` for the
+  undetailed UCs).
+
+### BR-010 — Numbering rules are fully specified
+- `err` if a `numbering` rule misses its generation spec; `ok` if all complete or
+  no `numbering` rule in scope.
+- **Why**: a `numbering` rule drives a code/sequence allocator. Without a complete
+  spec the generated numbering is ambiguous (wrong scope = collisions across
+  tenants; missing reset = ever-growing counter; unknown gapless = wrong storage).
+- **What to check**: for each rule with `Type: numbering`, its Condition/Expression
+  must state all four — a **format** template (with at least one token), a
+  **sequence scope** (`tenant` / `global` / `parent:<Entity>`), a **reset** period
+  (`none` / `yearly` / `monthly` / `daily`), and whether it is **gapless**. A reset
+  period MUST match a date token in the format (yearly ⇒ `{YY}`/`{YYYY}`). Examples
+  must include ≥1 valid showing the sequence **progressing** and ≥1 invalid showing
+  the **no-duplicate** (concurrency / cross-tenant) or **immutability** guarantee.
+- Skip when the module has no `numbering` rule.
+- Fix: `/ba-create-business-rules`.
+
+## Output
+
+Write `_audit/règles-métier.md` per the doc-templates skeleton:
+- Header `# Audit règles métier — <APP> / <MODULE>` + `_<date> · Verdict :
+  <emoji> N warn · M err · K ok_`.
+- `## ✅ Conforme`, `## ⚠️ Avertissements`, `## ❌ Bloquants` sections; one bullet
+  per finding. Keep rule codes (`BR-001`, …) **bold** so they stay greppable, but
+  explain each in business terms. For `warn`/`err`: what's wrong (offending rule
+  / UC codes **bold**), why it matters, and a `→` fix naming
+  `/ba-create-business-rules`.
+- Re-Write the whole file each run (overwrite — it's a fresh verdict).
+
+Then a 3–6 line chat summary in the user's language — business terms, not rule
+codes. If any `err`, state clearly that the rules must be fixed before moving on.
+
+## Used by the readiness orchestrator
+
+`/ba-audit-pre-dev` runs every dimension and aggregates the verdicts. When invoked
+by it, still write `_audit/règles-métier.md` as usual — the orchestrator reads
+these files.

package/templates/skills/business-analyse/audit-screens/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: ba-audit-screens
+description: >
+  Audits the screen specs of a `.smartstack/ba/` section — coverage, entity refs,
+  SmartComponent coherence, navigation integrity, related-tabs, home-page
+  hierarchy, UC traceability, custom-actions structure (SCR-001..013). Reads the
+  section `screen.md` plus the module `entité.md`/`rbac.md` and the section
+  `use-case.md`, writes a verdict to `_audit/screen.md`. Run after
+  `/ba-create-screen` or as part of pre-dev readiness.
+allowed-tools: [Read, Write, Glob, Grep]
+---
+
+# ba-audit-screens — Screen specifications audit
+
+You audit the screen specs of a `.smartstack/ba/` project against the rules below
+and write a verdict file. The rules are unchanged from the SmartStack convention;
+only the I/O is file-based. The thirteen rules cover the full SmartComponent type
+set: `SmartListView`, `SmartForm`, `SmartDashboard`, `SmartKanban`, `SmartCard`,
+`SmartAppHome`, `SmartModuleHome`, `SmartSectionHome`. The legacy `SmartFilter`
+type is forbidden (covered by SCR-010), and the **custom-actions metadata**
+introduced by ba-create-screen (SCR-011/012/013) is verified end-to-end so the
+downstream pipeline never silently drops a non-CRUD button.
+
+## File model — how to audit
+
+1. **Read state**: `Glob .smartstack/ba/**/index.md` to rebuild the tree. For each
+   section in scope, Read its `screen.md`
+   (`.smartstack/ba/<APP>/<MODULE>/<section>[/<resource>]/screen.md`). To validate
+   refs, also Read the parent module's `entité.md` (entity codes/names) and
+   `rbac.md` (permissions), and the section's `use-case.md` (UC codes). The
+   `index.md` files give you the application → module → section counts (for the
+   home-page rules) and the navigation targets resolve against `SCR-…` codes
+   Grepped across the tree's `screen.md` files.
+2. **Apply** the rules SCR-001..013 (below) at the requested scope.
+3. **Write** the verdict to `_audit/screen.md` under the audited section:
+   `.smartstack/ba/<APP>/<MODULE>/<section>/_audit/screen.md` (use the audit-verdict
+   skeleton from `_workflow/doc-templates.md`). Then print a 3–6 line business
+   summary in chat.
+
+There is no database, no envelope, no i18n label codes — the `.md` verdict IS the
+record. The verdict header (`0 err` = pass) is what a downstream gate reads.
+
+## Scope
+
+- **Section scope** (default): audit one section — apply SCR-001..010 to its
+  screens, resolving refs against the parent module's `entité.md`/`rbac.md` and
+  the section's `use-case.md`. Navigation targets (SCR-008) resolve against every
+  `SCR-…` code in the analysis.
+- **Module scope**: apply the rules to every section under the module; the
+  module-level rules (SCR-001, SCR-007) and the app-level rule (SCR-006) span the
+  whole subtree.
+- The verdict file lives at the audited section's `_audit/screen.md`.
+
+## Rules
+
+### SCR-001 — At least 1 screen exists per module
+- **Severity**: err (if 0), ok (if >= 1)
+- Count the `SCR-…` screens across the module's sections.
+- Fix: `/ba-create-screen`.
+
+### SCR-002 — Every section has at least 1 screen
+- **Severity**: warn (if uncovered sections), ok (if all covered)
+- Fix: `/ba-create-screen`.
+
+### SCR-003 — Screen entity references point to existing entities
+- **Severity**: err (if broken refs), ok (if all valid)
+- Check: screen's entityRef matches an entity code OR entity name in the data model
+- Skip when `entityRef` is null AND screen type is `SmartDashboard`/`SmartAppHome`/`SmartModuleHome`/`SmartSectionHome` (these aggregate via widgets)
+- Fix: `/ba-create-screen`.
+
+### SCR-004 — Entity-bound screens have an entity reference
+- **Severity**: warn (if missing), ok (if all have)
+- Check: screenType ∈ {`SmartListView`, `SmartForm`, `SmartCard`} → entityRef must be non-empty
+- `SmartKanban` SHOULD have entityRef (workflow entity with status)
+- `SmartDashboard`/`SmartAppHome`/`SmartModuleHome`/`SmartSectionHome` do NOT need entityRef on the screen (they aggregate through widgets)
+- Fix: `/ba-create-screen`.
+
+### SCR-005 — All screens are linked to at least 1 use case
+- **Severity**: warn (if unlinked), ok (if all linked)
+- Fix: `/ba-create-screen`.
+
+### SCR-006 — Application landing page (SmartAppHome) exists when ≥2 modules
+- **Severity**: warn (if missing), ok (if all multi-module apps have one)
+- Check: for each application with ≥2 modules, at least one screen of type `SmartAppHome` exists with that `applicationCode`
+- Fix: `/ba-create-screen`.
+
+### SCR-007 — Module landing page (SmartModuleHome) exists when ≥2 sections
+- **Severity**: warn (if missing), ok (if all multi-section modules have one)
+- Check: for each module with ≥2 sections, at least one screen of type `SmartModuleHome` exists with that `applicationCode`/`moduleCode`
+- Fix: `/ba-create-screen`.
+
+### SCR-008 — Navigation targets reference existing screens
+- **Severity**: err (if any broken target), ok (if all valid)
+- Check every navigation field for an existing screen `code` in this analysis:
+  - `SmartListView.config.rowClickTarget`
+  - `SmartCard.config.clickTarget`
+  - `SmartKanban.config.rowClickTarget`
+  - `SmartForm.config.relatedTabs[].screenTarget`
+  - `SmartAppHome.config.quickLinks[].screenTarget`
+  - `SmartModuleHome.config.quickLinks[].screenTarget`
+  - `SmartSectionHome.config.quickLinks[].screenTarget`
+- Fix: `/ba-create-screen`.
+
+### SCR-009 — Detail forms expose related collections via relatedTabs
+- **Severity**: warn (if missing on candidate forms), ok otherwise
+- Check: for each `SmartForm` in `mode: "edit"` or `mode: "detail"` whose entity has ≥1 incoming 1:N FK in the data model, `config.relatedTabs[]` should be non-empty
+- Skip portal/read-only modules where related navigation is intentionally suppressed
+- Fix: `/ba-create-screen`.
+
+### SCR-010 — No legacy SmartFilter screens remain
+- **Severity**: err (if any present), ok (if none)
+- Check: no screen has `screenType === "SmartFilter"`. The type is removed; filters live inside `SmartListView.config.filters`.
+- Fix: `/ba-create-screen`.
+- **migration hint**: for each affected section, fold the SmartFilter into the matching SmartTable/SmartListView (move `config.fields[]` into `SmartListView.config.filters.fields[]`) and re-emit a single `SmartListView` screen.
+
+### SCR-011 — Custom actions carry the mandatory metadata
+- **Severity**: err (if any custom action is missing a required field), ok
+- Check: for every `- **Actions personnalisées** :` sub-bullet of every screen,
+  all of `code`, `kind`, `scope`, `permission`, `label` are present and
+  well-formed. The `code` regex is camelCase `^[a-z][a-zA-Z0-9]*$`; the
+  `permission` regex accepts 3 segments (section) or 4 segments (resource):
+  `^[a-z][a-z0-9-]*\.[a-z][a-z0-9-]*(\.[a-z][a-z0-9-]*)?\.[a-z][a-z0-9-]*$`.
+- Then branch on `kind`:
+  - `kind: api` requires `endpoint` (kebab `^[a-z][a-z0-9-]*$`) +
+    `httpMethod` ∈ {GET,POST,PUT,PATCH,DELETE} + `UC: UC-…`. When `endpoint`
+    is absent the default is `kebab(code)` — the audit accepts the absence
+    but still verifies kebab-ness once the default is applied.
+  - `kind: navigate` requires `targetScreen: SCR-…` OR a `targetRoute`
+    string, and MUST NOT carry `endpoint` / `httpMethod` / `payloadDto`.
+- This is the gate that catches free-text custom actions silently dropped by
+  `ba-create-prd`.
+- Fix: `/ba-create-screen`.
+
+### SCR-012 — Custom action endpoints are unique per entity
+- **Severity**: err (if any duplicate endpoint within one entity's screens), ok
+- Check: across every screen `bound` to the same entity (`entityRef` match) of
+  the audited module, no two custom actions of `kind: api` share the
+  `(httpMethod, scope, endpoint)` triplet. A duplicate would emit a duplicate
+  `[HttpVerb("<endpoint>")]` on the controller (compile error) or two service
+  methods of the same name (TypeScript collision).
+- Fix: `/ba-create-screen`.
+
+### SCR-013 — Navigate targets resolve to an existing screen
+- **Severity**: err (any broken `targetScreen`), ok otherwise
+- Check: every custom action with `kind: navigate` AND `targetScreen: SCR-…`
+  references a screen code present in this audit's analysis (any module of
+  the same application). Reuses the resolution table built for SCR-008.
+- Custom actions using `targetRoute` (free-text route helper) are skipped by
+  this rule — they are validated later by the per-page contract audit
+  (`/ba-audit-prd`, PRD-100) once the route resolution is wired by
+  `ba-create-prd`.
+- Fix: `/ba-create-screen`.
+
+## Output
+
+Write `_audit/screen.md` per the doc-templates skeleton:
+- Header `# Audit screen — <APP> / <MODULE> / <section>` + `_<date> · Verdict : <emoji> N warn · M err · K ok_`.
+- `## ✅ Conforme`, `## ⚠️ Avertissements`, `## ❌ Bloquants` sections; one bullet
+  per finding. For `warn`/`err`: what's wrong (offending codes **bold**), why it
+  matters, and a `→` fix naming `/ba-create-screen`.
+- Re-Write the whole file each run (overwrite — it's a fresh verdict).
+
+Then a 3–6 line chat summary in the user's language — business terms, not rule
+codes. If any `err`, state clearly that the screens must be fixed before moving on.
+
+## Used by the readiness orchestrator
+
+`/ba-audit-pre-dev` runs every dimension and aggregates the verdicts. When invoked
+by it, still write `_audit/screen.md` as usual — the orchestrator reads these files.

package/templates/skills/business-analyse/audit-sections/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: ba-audit-sections
+description: >
+  Audits the menu sections of a `.smartstack/ba/` project — module-section
+  coverage, duplicate/ambiguous/empty sections, cross-module and cross-app
+  duplication (SEC-001..006, XAPP-001..003). Reads the section nodes under a
+  module, writes a verdict to `_audit/sections.md`. Run after `/ba-create-menu`
+  or as part of pre-dev readiness.
+allowed-tools: [Read, Write, Glob, Grep]
+---
+
+# ba-audit-sections — Menu sections audit
+
+You audit the sections of a `.smartstack/ba/` project against the rules below and
+write a verdict file. The rules are unchanged from the SmartStack convention; only
+the I/O is file-based.
+
+## File model — how to audit
+
+1. **Read state**: `Glob .smartstack/ba/**/index.md` to rebuild the tree. Sections
+   are the folders directly under a module
+   (`.smartstack/ba/<APP>/<MODULE>/<section>/index.md`). Read each section's
+   `index.md` (label, `## Contexte`, `## Enfants` — the children listed there are
+   the section's resources). The module folder's own `index.md` `## Enfants` lists
+   the sections.
+2. **Apply** the rules SEC-001..006 (and XAPP-001..003 at the wider scopes, below)
+   at the requested scope.
+3. **Write** the verdict to the audited module's `_audit/sections.md`:
+   `.smartstack/ba/<APP>/<MODULE>/_audit/sections.md` (use the audit-verdict
+   skeleton from `_workflow/doc-templates.md`). Then print a 3–6 line business
+   summary in chat.
+
+There is no database, no envelope, no i18n label codes — the `.md` verdict IS the
+record. The verdict header (`0 err` = pass) is what a downstream gate reads.
+
+## Scope
+
+- **Module scope** (default): audit one module — apply SEC-001, SEC-002, SEC-005,
+  SEC-006 to its sections (the module-internal rules). Skip SEC-003, SEC-004 and
+  the XAPP rules — cross-module / cross-app duplication isn't a single-module
+  concern. The verdict lives at `.smartstack/ba/<APP>/<MODULE>/_audit/sections.md`.
+- **App scope**: apply SEC-001, SEC-002, SEC-005, SEC-006 to every module under the
+  app, **plus** SEC-003 (cross-module duplicate names) and the XAPP rules
+  (cross-app). Write one `_audit/sections.md` per module audited.
+- **Project scope**: as app scope, and also apply SEC-004 (duplicate names across
+  other applications / analyses in the tree). Decide every cross-cutting rule from
+  the menu tree only — section labels/codes and business semantics; never reach
+  into downstream phases (actors, use cases, data model), which are blocked while
+  the menu is being audited.
+
+## Rules
+
+### SEC-001 — Module must have at least 1 section
+- **Severity**: err (if 0 sections), ok (if >= 1)
+- **ok**: the module exposes at least one section (state how many).
+- **err**: the module has zero sections — it can't expose any UI, which blocks
+  downstream phases.
+- **fix**: `/ba-create-menu`
+
+### SEC-002 — No duplicate section codes within the module
+- **Severity**: err (if duplicates found), ok (if none)
+- Check: count occurrences of each section code (folder name + `index.md` anchor
+  code) within one module.
+- **err**: two or more sections share the same code (list the offending codes).
+- **fix**: `/ba-create-menu`
+
+### SEC-003 — No section names duplicated across other modules (same analysis)
+- **Severity**: warn (if true functional duplicate found), ok (if no duplicates or contextually different)
+- Check: compare section labels (case-insensitive) across ALL modules in the analysis
+- **Contextual analysis REQUIRED**: When two sections share the same name across
+  different modules, you MUST determine whether they represent:
+  - **True duplicate** (same business function, same data, same purpose — should be
+    consolidated or renamed) → flag as `warn`
+  - **Contextually different** (same generic name but different business domain,
+    different data, different actors — each is legitimate in its own module) → `ok`
+- Use ONLY the menu tree hierarchy (application code/label + module code/label
+  + section codes/labels) and business semantics to decide. Downstream phases
+  (actors, use cases, data model) are BLOCKED while menu is being audited and
+  MUST NOT be referenced here. Examples:
+  - "Pipeline" in CRM (sales opportunities) vs "Pipeline" in HR/Recrutement
+    (candidatures) → contextually different → ok
+  - "Dashboard" in Module A vs "Dashboard" in Module B → each module's dashboard
+    is contextual → ok
+  - "Reports" in Sales and "Reports" in Marketing within the same app, both doing
+    the same KPI exports → true duplicate → warn
+- Do NOT use a hardcoded whitelist. Analyze the business semantics.
+- **warn**: name the duplicated sections with their module context.
+- **fix**: `/ba-create-menu`
+
+### SEC-004 — No section names duplicated across other active analyses
+- **Severity**: warn (if found), ok (if none)
+- Check: if the tree includes more than one analysis / application, compare section
+  labels across them and report functional duplicates.
+- **warn**: list the duplicated section names across applications.
+- **fix**: `/ba-create-menu`
+
+### SEC-005 — No ambiguous section names
+- **Severity**: warn (if found), ok (if none)
+- **Ambiguous names** (case-insensitive): `settings`, `options`, `configuration`, `config`,
+  `parametres`, `utilities`, `tools`, `outils`, `misc`, `other`, `divers`, `autre`
+- **warn**: list the sections whose label is one of the ambiguous names.
+- **fix**: `/ba-create-menu`
+
+### SEC-006 — No empty sections (0 resources)
+- **Severity**: warn (if found)
+- Check: sections with zero resources — no children listed under `## Enfants` and
+  no resource sub-folders.
+- **warn**: list the empty sections.
+- **fix**: `/ba-create-menu`
+
+### SEC-007 — Sections referenced in downstream docs still exist in the menu
+- **Severity**: err (if any orphan reference is found), ok (otherwise)
+- **Why**: when a section is removed from the menu (`/ba-create-menu`) after
+  downstream content was generated, the UC/SCR/BR/RBAC codes that carry the
+  deleted section in their (APP,MOD,SEC) triplet become orphans. The downstream
+  files (`use-case.md`, `screen.md`, `règles-métier.md`, `rbac.md`) silently
+  keep those blocks — `/ba-develop` then crashes on invalid section codes
+  during scaffolding.
+- **Check**: for each code matching
+  `(UC|SCR|BR|RBAC)-{APP}-{MOD}-{SEC}-NNN` extracted via Grep from every
+  `**/use-case.md`, `**/screen.md`, `**/règles-métier.md`, `**/rbac.md` under
+  the audited scope, the triplet `(APP, MOD, SEC)` MUST correspond to an
+  existing `<APP>/<MOD>/<sec-folder>/index.md` in the tree (section code
+  derived from the kebab folder name via uppercase + `-` → `_`).
+- **err**: list each orphan code with its file path verbatim.
+- **fix**: `/ba-reconcile-menu` (preflight that renames or deletes orphans
+  with user validation), then re-run `/ba-loop`.
+
+## Cross-Application Patterns (reported in the sections verdict)
+
+**Gate**: Only apply XAPP rules when audit scope = project or application.
+When scope = module, skip all XAPP rules — emit zero XAPP findings.
+
+### XAPP-001 — Duplicate section/module pattern across applications
+- **Severity**: warn
+- Check: section or module names like "Rapports", "Reports", "Parametrage", "Settings",
+  "Portail", "Portal" that appear in 2+ different applications.
+- Report: the repeated pattern and the applications it appears in.
+- **fix**: `/ba-create-menu`
+
+### XAPP-002 — Missing standard application for the business domain
+- **Severity**: warn
+- Based on the applications defined, identify commonly expected but absent apps:
+  - Enterprise suite → Finance/Accounting, Administration/Backoffice, GED/Documents
+  - SaaS platform → Billing, Admin Console
+  - HR-heavy → Payroll, Talent Management
+- Report: the missing application and why it is commonly expected.
+- **fix**: `/ba-create-menu`
+
+### XAPP-003 — Functional overlap between modules in different apps
+- **Severity**: warn
+- Check: modules in different apps that cover the same business function
+  (e.g., "Competences" in HR and "Training" in Academy both manage skills).
+- Report: the two overlapping modules (app.module) and a description of the overlap.
+- **fix**: `/ba-create-menu`
+
+## Output
+
+Write `_audit/sections.md` per the doc-templates skeleton:
+- Header `# Audit sections — <MODULE>` + `_<date> · Verdict : <emoji> N warn · M err · K ok_`.
+- `## ✅ Conforme`, `## ⚠️ Avertissements`, `## ❌ Bloquants` sections; one bullet
+  per finding. For `warn`/`err`: what's wrong (offending codes **bold**), why it
+  matters, and a `→` fix naming `/ba-create-menu` (sections are authored there).
+- Keep the rule codes (`SEC-001`, `XAPP-001`, …) **bold** so they stay greppable,
+  but explain them in business terms.
+- Re-Write the whole file each run (overwrite — it's a fresh verdict).
+
+Then a 3–6 line chat summary in the user's language — business terms, no rule
+codes. If any `err`, state clearly that the sections must be fixed before moving on.
+
+## Used by the readiness orchestrator
+
+`/ba-audit-pre-dev` runs every dimension and aggregates the verdicts. When invoked
+by it, still write `_audit/sections.md` as usual — the orchestrator reads these files.