@atlashub/smartstack-cli 4.80.0 → 5.0.0

package/templates/skills/business-analyse/_workflow/completeAuto-discipline.md

@@ -0,0 +1,79 @@
+---
+name: completeAuto-discipline
+description: Anti-hallucination guard for "complete (auto)" coverage runs — forbids extrapolation, requires a verbatim trace in the `.smartstack/ba/` tree before proposing any item.
+phase: '*'
+kind: companion
+applies_to_modes: [completeAuto]
+section_label: 'COMPLETE AUTO — DISCIPLINE (anti-hallucination)'
+---
+
+# Complete (auto) — Anti-extrapolation discipline
+
+Apply this when the user asks you to **auto-complete / fill the gaps** of a phase
+("complète automatiquement", "qu'est-ce qui manque ?"). It overrides any
+ambiguity in the phase skill about what counts as "missing".
+
+## You invent NOTHING
+
+Auto-complete is a **coverage audit**, not a brainstorming session. A proposed
+entity / use case / rule / permission / screen MUST have a **verbatim trace** in
+the `.smartstack/ba/` tree (read it with Grep/Read). No trace = no proposal.
+
+| Acceptable trace source | Example |
+|-------------------------|---------|
+| UC code in a `use-case.md` | `UC-BUDGETS-…-001` |
+| BR code in a `règles-métier.md` | `BR-…-003` |
+| resource/section code in the tree (folder + `index.md`) | `budget`, `budget-alert` |
+| PascalCase token from a BR expression (excluding primitives) | `VatRate`, `Lead` |
+| existing entity code (to enrich a shell) | `BudgetTag [ENT-008]` |
+
+**Forbidden as a stand-alone justification:**
+
+- ❌ "domain knowledge" / "best practice" / "it would be useful"
+- ❌ web search (OK for naming/typing, NEVER to introduce an item)
+- ❌ "most systems track X" / reasoning by analogy with other apps
+
+## Mandatory two-step workflow
+
+### 1. Prose audit BEFORE any write
+
+Produce a table covering **every existing item** at the scope:
+
+```
+| Item               | Verbatim trace            | State        | Action      |
+|--------------------|---------------------------|--------------|-------------|
+| Budget             | UC-…-001 step 1, BR-…-001 | shell (vide) | enrichir    |
+| BudgetAlert        | UC-…-008 step 2           | complet      | inchangé    |
+| BudgetType (cand.) | (aucune)                  | absent       | NE PAS PROPOSER, signaler |
+```
+
+If you spot a potentially useful item without a verbatim trace, **flag the gap
+and defer to the upstream phase** that would create the trace (no UC justifies it
+→ defer to use cases; no BR → defer to rules; no resource → defer to menu). Do
+NOT propose it.
+
+### 2. Write only items that have a trace
+
+Write into the authoritative doc only items that are **existing-to-enrich**
+(shells) or **missing-but-traceable** (≥1 verbatim trace listed in step 1). No
+item whose justification is purely linguistic / domain.
+
+## Standard response when the model is complete
+
+If every existing item is complete and no missing item has a verbatim trace,
+**say there is nothing to complete**:
+
+> Le modèle actuel couvre tous les cas d'usage / règles / ressources existants.
+> Pour ajouter d'autres éléments, il faut d'abord enrichir la phase amont qui les
+> justifierait (cas d'usage ou règles).
+
+NEVER fabricate content to fill a perceived gap — "nothing to do" is the correct,
+preferable answer to a hallucination.
+
+## Why this rule exists
+
+Without an explicit front-load, auto-complete regularly invents domain-knowledge
+items (BudgetCurrency, BudgetPeriodType, BudgetAlertSeverity…) with no upstream
+anchor. Users lose trust in the coverage audit: if the tool always proposes
+something, "complete" becomes noise. This rule keeps it a **coverage check**, not
+a spec extension.

package/templates/skills/business-analyse/_workflow/context-documents.md

@@ -0,0 +1,45 @@
+---
+name: context-documents
+description: Cross-phase rules for using user-provided reference documents (specs, glossaries, schemas, screenshots). In native Claude Code these are read directly from disk with the Read tool — there is no injected summary block.
+phase: '*'
+kind: companion
+mode_pinned: true
+section_label: '_WORKFLOW — CONTEXT DOCUMENTS'
+---
+
+# Context documents (cross-phase)
+
+The user may provide reference material (specs, cahiers des charges, glossaries,
+Excel sheets, PDFs, schemas, screenshots) to ground the analysis. These are
+**authoritative source material** — never ignore them.
+
+## How you receive them
+
+The user points you at files (a path, a folder, or an attachment). **Read them
+directly with the Read tool** (it handles text, PDF, and images). If the user
+mentions a document without a path, ask where it is. There is no pre-computed
+summary block injected — you read the real content on demand.
+
+If reference docs live in the project, a good default location to check is
+`.smartstack/ba/_docs/` (Glob it at task start when the user says "use my specs").
+
+## How to use them
+
+- **Treat them as authoritative.** When a request can be answered from a
+  document, ground your reasoning in it and cite it naturally ("d'après le cahier
+  des charges…", "le schéma joint indique…") in the user's language.
+- **Quote accurately.** Because you read the real file, you may quote precisely —
+  but only what the file actually says. Do not invent figures or section numbers.
+- **Images / diagrams.** Read the image; describe what is relevant. If it is
+  illegible or ambiguous, ask the user to clarify the key elements rather than
+  guessing.
+- **Large files.** Read the relevant range (use `offset`/`limit`) rather than
+  loading an entire spreadsheet — extract what the current phase needs.
+
+## What NOT to say
+
+- ❌ Don't expose the file-reading mechanics to the user — to them it's just
+  "leurs documents".
+- ❌ Don't refuse to use a document because it feels incomplete — use what's
+  there and ask for the missing piece.
+- ❌ Don't list every document you read unless the user asks what they provided.

package/templates/skills/business-analyse/_workflow/doc-templates.md

@@ -0,0 +1,318 @@
+---
+name: doc-templates
+description: Canonical markdown skeletons for the six BA docs + index + rollup variant. The single format contract that authors (definer skills), audits, and create-prd all parse. Loaded on demand, not every turn.
+phase: '*'
+kind: reference
+section_label: '_WORKFLOW — DOC TEMPLATES'
+---
+
+# BA doc templates — the canonical file shapes
+
+Every file under `.smartstack/ba/` follows one of the skeletons below. The first
+line is always an anchor comment (`<!-- ba:… -->`); item codes are `###`
+headings so they are greppable. Write content in the user's language; keep codes
+and anchors verbatim. See `ba-files.md` for the authority matrix (which level
+authors vs rolls up each doc).
+
+---
+
+## `index.md` — every node (project / app / module / section / resource)
+
+```markdown
+<!-- ba:node kind=node level=application code=CRM -->
+# CRM — Gestion commerciale
+
+## Contexte
+Application de suivi commercial : prospects, opportunités, devis.
+
+## Hors-périmètre
+- La facturation est gérée dans BILLING.
+- La signature électronique passe par un service tiers (hors v1).
+
+## Enfants
+- [PIPELINE](./PIPELINE/index.md) — Pipeline d'opportunités
+- [CONTACTS](./CONTACTS/index.md) — Annuaire de contacts
+```
+
+`level=project` for the root `.smartstack/ba/index.md`; its `## Enfants` lists
+the applications. `out_of_scope` (the `## Hors-périmètre` bullets) cascades into
+PRD non-goals downstream — keep it accurate.
+
+### Module-level `index.md` — with optional `depends=` attribute
+
+After `/ba-create-ba-order` (Phase 1.5), module-level `index.md` files gain a
+`depends=` attribute in their anchor and a `## Dépendances` section:
+
+```markdown
+<!-- ba:node kind=node level=module code=BILLING depends=ERP/REFERENCES,ERP/CUSTOMERS -->
+# BILLING — Invoicing
+
+## Contexte
+Invoices management for customers and suppliers.
+
+## Hors-périmètre
+- No online payment v1.
+
+## Dépendances
+- [REFERENCES](../REFERENCES/index.md) — uses currencies, countries, statuses
+- [CUSTOMERS](../CUSTOMERS/index.md) — invoices linked to customers
+
+## Enfants
+- [invoices](./invoices/index.md) — Invoices
+```
+
+For a module **without** dependencies:
+
+```markdown
+## Dépendances
+_Aucune — module fondationnel._
+```
+
+`## Dépendances` is placed between `## Hors-périmètre` (or `## Contexte` if
+no out-of-scope section) and `## Enfants`. Only module-level `index.md` carries
+this section — app/section/resource levels do not.
+
+---
+
+## `acteur.md` — authoritative at Application
+
+```markdown
+<!-- ba:acteur level=application code=CRM -->
+# Acteurs — CRM
+
+### BA-001-AC-001 — Commercial
+- **Type** : internal
+- **Description** : Gère son portefeuille de prospects et opportunités.
+- **Périmètre** : CRM (toute l'application)
+- **Origine** : conversation (2026-…)
+
+### BA-001-AC-002 — Manager commercial
+- **Type** : internal
+- **Description** : Supervise l'équipe, valide les remises.
+- **Périmètre** : CRM / PIPELINE
+- **Origine** : code (rôle détecté)
+```
+
+`type` ∈ `internal | external | system`. Both `Description` and `Origine`
+(traceability) are required. Actor codes are `BA-{analysisSeq}-AC-{NNN}`.
+
+---
+
+## `use-case.md` — authoritative at Section
+
+```markdown
+<!-- ba:use-case level=section code=opportunites -->
+# Cas d'usage — CRM / PIPELINE / opportunites
+
+### UC-CRM-PIPELINE-OPPORTUNITES-001 — Créer une opportunité
+- **Acteur principal** : BA-001-AC-001 (Commercial)
+- **Acteurs secondaires** : —
+- **Préconditions** : le prospect existe.
+- **Flux principal** :
+  1. Le commercial ouvre le formulaire.
+  2. Il saisit le montant estimé et l'échéance.
+  3. Le système crée l'opportunité au statut NOUVELLE.
+- **Flux alternatifs** :
+  - ALT-1 : montant inconnu → enregistrement en brouillon.
+- **Exceptions** :
+  - EXC-1 : prospect archivé → refus avec message.
+- **Postconditions** : opportunité visible dans le pipeline.
+- **Règles liées** : BR-003
+- **Écrans liés** : SCR-CRM-PIPELINE-OPPORTUNITES-001
+- **Acceptance Criteria** :
+  - [ ] AC-01 — POST /api/opportunities avec un body valide renvoie 201 + l'identifiant créé.
+  - [ ] AC-02 — POST avec un montant négatif renvoie 400 et le code d'erreur `amount-positive`.
+  - [ ] AC-03 — La nouvelle opportunité apparaît dans GET /api/opportunities du même owner avec statut NOUVELLE.
+```
+
+UC codes are `UC-{APP}-{MOD}-{SEC}-NNN` (section code UPPERCASED in the code).
+
+AC codes are **local to the UC** : `AC-01`, `AC-02`, … numbered from 01 (zero-padded
+2 digits), sequential, no gaps. The globally unique reference is `<UC-code>#AC-NN`
+(e.g. `UC-CRM-PIPELINE-OPPORTUNITES-001#AC-02`). Each AC is a single, testable
+assertion that the test-scaffolder turns into a `[Fact]` (backend) or `test()`
+(Playwright) at code-generation time. Write at least one AC per `user-goal` UC
+(audit `UC-012`); subfunction-level UCs may legitimately have none.
+
+---
+
+## `règles-métier.md` — authoritative at the rule's deepest scope
+
+```markdown
+<!-- ba:rules level=module code=PIPELINE -->
+# Règles métier — CRM / PIPELINE
+
+### BR-001 — Remise plafonnée
+- **Type** : validation
+- **Sévérité** : err
+- **Portée** : CRM / PIPELINE
+- **Condition** : QUAND une remise > 20 % est saisie ALORS exiger l'aval manager.
+- **Expression** : `Discount <= 0.20 || Approval.ManagerId != null`
+- **Code d'erreur** : `pipeline.discount.cap`
+- **Cas valides** : remise 15 % sans aval ; remise 25 % avec aval manager.
+- **Cas invalides** : remise 25 % sans aval.
+- **Cas d'usage liés** : UC-CRM-PIPELINE-OPPORTUNITES-002 (étape 3)
+
+### BR-002 — Numéro d'opportunité
+- **Type** : numbering
+- **Sévérité** : err
+- **Portée** : CRM / PIPELINE
+- **Condition** : QUAND une opportunité est créée ALORS son numéro = `OPP-{YY}-{NNNN}` (séquence par tenant, reset annuel, gapless, immuable).
+- **Expression** : `reference = "OPP-" + fmt(year,"yy") + "-" + pad(nextSeq(scope=tenant, reset=yearly), 4)`
+- **Code d'erreur** : `pipeline.opportunity.reference.duplicate`
+- **Cas valides** : 1re de 2026 → `OPP-26-0001` ; suivante → `OPP-26-0002` ; 1re de 2027 → `OPP-27-0001`.
+- **Cas invalides** : deux créations concurrentes → jamais le même numéro ; numéro modifié après création → rejeté.
+- **Cas d'usage liés** : UC-CRM-PIPELINE-OPPORTUNITES-001 (postcondition)
+```
+
+Rules feed FluentValidation + form error messages downstream — keep the valid/
+invalid examples concrete and testable.
+
+---
+
+## `rbac.md` — authoritative at Module
+
+```markdown
+<!-- ba:rbac level=module code=PIPELINE -->
+# RBAC — CRM / PIPELINE
+
+| Acteur | Permission (`module.section[.resource].action`) | Portée |
+|--------|------------------------------------------|--------|
+| BA-001-AC-001 (Commercial) | `crm.pipeline.opportunites.read` | toutes |
+| BA-001-AC-001 (Commercial) | `crm.pipeline.opportunites.create` | les siennes |
+| BA-001-AC-002 (Manager commercial) | `crm.pipeline.opportunites.approve` | équipe |
+```
+
+Permissions are `module.section[.resource].action` within the module (3 segments
+for a section, 4 for a resource); the app prefix is added at the page/controller
+boundary, not here.
+
+---
+
+## `entité.md` — authoritative at Module
+
+```markdown
+<!-- ba:entité level=module code=PIPELINE -->
+# Modèle de données — CRM / PIPELINE
+
+### ENT-001 — Opportunity (agrégat racine)
+- **Préfixe table** : `pipeline_`
+- **Traçabilité** : UC-CRM-PIPELINE-OPPORTUNITES-001, BR-001, BR-002
+
+| Attribut | Type | Contraintes | Calculé |
+|----------|------|-------------|---------|
+| Id | Guid | PK | — |
+| Amount | decimal(18,2) | ≥ 0 | — |
+| Stage | enum | NOUVELLE/GAGNEE/PERDUE | — |
+| WeightedAmount | decimal(18,2) | — | `Amount * Probability` |
+
+- **Relations** : Opportunity *→1 Contact (FK ContactId).
+- **Index** : (Stage), (ContactId).
+- **Code pattern** : `OPP-{YY}-{NNNN}` — scope tenant, reset annuel, gapless (voir BR-002 ; allocateur ENT-002).
+
+### ENT-002 — OpportunitySequence (technical)
+- **Préfixe table** : `pipeline_`
+- **Traçabilité** : BR-002 (numérotation `OPP-{YY}-{NNNN}`)
+- **Isolation** : by-design — allocateur du compteur de référence (aucune relation métier)
+
+| Attribut | Type | Contraintes | Calculé |
+|----------|------|-------------|---------|
+| Id | Guid | PK | — |
+| Year | int | unique (par tenant) | — |
+| NextValue | int | ≥ 1 | — |
+```
+
+Entity codes are `ENT-NNN`. The role in parentheses is the classification
+(`agrégat racine` / `composant` / `lookup` / `technical`). Computed attributes
+carry a non-empty **Calculé** formula (no DB column, no setter). A `technical`
+allocator (sequence/counter/outbox) is isolated by nature — give it an
+`- **Isolation** : by-design — <raison>` line so audit DM-009 treats the absence
+of relations as intentional, not a modeling gap.
+
+---
+
+## `screen.md` — authoritative at Section / Resource
+
+```markdown
+<!-- ba:screen level=section code=opportunites -->
+# Écrans — CRM / PIPELINE / opportunites
+
+### SCR-CRM-PIPELINE-OPPORTUNITES-001 — Liste des opportunités (SmartListView)
+- **Entité** : Opportunity (ENT-001)
+- **Permission** : `crm.pipeline.opportunites.read`
+- **Cas d'usage liés** : UC-CRM-PIPELINE-OPPORTUNITES-001
+- **Colonnes** : Amount, Stage, Contact
+- **Filtres** : Stage (select), période (date-range)
+- **Actions** : create (header), edit (row), delete (row)
+```
+
+Screen codes are `SCR-{APP}-…-NNN`. The SmartComponent type (`SmartListView`,
+`SmartForm`, `SmartDashboard`, …) is named in the heading. create-prd mines
+these to build per-page specs.
+
+---
+
+## Rollup variant — non-authoritative levels
+
+At a level where a doc is a rollup (per the authority matrix), write a short
+aggregated view marked with the rollup comment, linking to the authoritative
+children. **Never hand-author content here** — regenerate it whenever the
+authoritative source changes.
+
+```markdown
+<!-- ba:acteur level=module code=PIPELINE -->
+<!-- ba:rollup auto -->
+# Acteurs — actifs sur PIPELINE
+> Vue agrégée — source faisant autorité : [../acteur.md](../acteur.md)
+
+- BA-001-AC-001 (Commercial)
+- BA-001-AC-002 (Manager commercial)
+```
+
+A placeholder (node created by create-menu, concept not yet defined) is the
+minimal form — anchor + a one-line note:
+
+```markdown
+<!-- ba:rules level=section code=opportunites -->
+_À définir lors de la phase « règles métier »._
+```
+
+---
+
+## Audit verdict — `_audit/<dimension>.md`
+
+The `/ba-audit-*` skills read the tree, apply their rule set, and write a verdict
+to an `_audit/` subfolder of the scope they audit (e.g. an app-scoped menu audit
+→ `.smartstack/ba/<APP>/_audit/menu.md`; a module-scoped data-model audit →
+`.smartstack/ba/<APP>/<MODULE>/_audit/entité.md`; a project-scoped actors audit →
+`.smartstack/ba/_audit/actors.md`). This replaces the Studio `[ACTION]{auditReport}`
+envelope — there are no i18n label codes, no `persist`, no frontend.
+
+```markdown
+<!-- ba:audit dimension=menu scope=CRM -->
+# Audit menu — CRM
+_2026-05-21 · Verdict : ⚠️ 1 warn · 0 err · 3 ok_
+
+## ✅ Conforme
+- **MENU-001** — chaque module correspond bien à son application (2 modules vérifiés).
+- **MENU-003** — aucun module ne duplique le Core SmartStack.
+- **MENU-004** — aucun module orphelin, aucune app/module vide.
+
+## ⚠️ Avertissements
+- **MENU-002** — le concept « Contacts » apparaît dans **CRM** et **SALES**.
+  - Pourquoi : risque de doublon de données et de logique.
+  - → Clarifier la frontière ou fusionner via `/ba-create-menu`.
+
+## ❌ Bloquants
+- _(aucun)_
+```
+
+- The header line carries the verdict counts; the rule codes (`MENU-001`, …) stay
+  **bold** so they remain greppable, but they are explained in business terms.
+- Findings are grouped by severity (`ok` / `warn` / `err`). For each non-`ok`
+  finding give **what's wrong** (offending codes in bold), **why it matters**, and
+  a `→` **concrete fix** naming the skill to re-run (e.g. `/ba-create-menu`).
+- The skill also prints a 3–6 line summary in the chat; the file is the durable
+  record. A downstream phase/dev gate that needs "did the audit pass?" reads the
+  `Verdict :` header (`0 err` = pass).
+

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

@@ -0,0 +1,97 @@
+---
+name: ba-audit-actors
+description: >
+  Audits the actors of a `.smartstack/ba/` project — existence, duplicate names
+  (case-insensitive), missing type (ACT-001..006). Actors are PROJECT-scoped, so
+  it reads every `<APP>/acteur.md` plus the menu tree, applies the rules, and
+  writes a verdict to `_audit/actors.md` at the project root. Run after
+  `/ba-create-actors` or as part of pre-dev readiness.
+allowed-tools: [Read, Write, Glob, Grep]
+---
+
+# ba-audit-actors — Actors audit
+
+You audit the actors 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 menu tree,
+   then `Glob .smartstack/ba/*/acteur.md` to find every application's
+   **authoritative** actor file. Read each `acteur.md` (the App level is
+   authoritative — skip rollups, marked `<!-- ba:rollup auto -->`). Each actor is
+   a `### BA-{NNN}-AC-{NNN} — <label>` heading with `**Type**`, `**Description**`,
+   `**Périmètre**`, `**Origine**` fields.
+2. **Apply** the rules ACT-001, ACT-002, ACT-006 (below) across **all** actors of
+   the project — actors are project-scoped (no application/module/section binding).
+3. **Write** the verdict to `.smartstack/ba/_audit/actors.md` (project root scope,
+   not under any app) using 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
+
+Actors are **project-wide**: collect the actors declared in every
+`.smartstack/ba/<APP>/acteur.md` and audit them as one set. The verdict file
+always lives at the project root: `.smartstack/ba/_audit/actors.md`.
+
+## Cross-phase checks moved elsewhere
+
+`ba-audit-actors` runs before use cases and permissions exist. Cross-phase checks
+therefore live in the audit of the phase that consumes the reference:
+
+- `UC-008` (in `ba-audit-use-cases`) verifies that every use case's primary actor
+  points to an existing actor.
+- `RBAC-005` (in `ba-audit-rbac`) verifies that every permission entry references
+  an existing actor.
+
+The legacy ACT-003 (unused actors), ACT-004 (actors without permissions) and
+ACT-005 (actors not linked to an application) were removed: the first two
+duplicated UC-008 / RBAC-005 with the source-of-truth on the wrong side, and
+ACT-005 referenced an actor↔application link that no longer exists in the
+project-scoped model.
+
+## Rules
+
+### ACT-001 — At least 1 actor exists
+- `err` if 0 actors across the whole project; `ok` if ≥ 1 (state the count).
+- Count distinct actor headings found across all `acteur.md` files.
+- Fix: `/ba-create-actors`.
+
+### ACT-002 — No duplicate actor names (case-insensitive)
+- `err` if two or more actors share the same label ignoring case (e.g.
+  `Manager` and `manager`); `ok` if none.
+- Compare actor labels case-insensitively across the whole project (an actor
+  appearing under the same label in two apps is still a duplicate).
+- Fix: `/ba-create-actors` — rename or merge the duplicate actors into a single
+  `BA-NNN-AC-NNN`.
+
+### ACT-006 — All actors have a type (internal/external/system)
+- `warn` if any actor is missing its `**Type**` (or it isn't one of
+  `internal | external | system`); `ok` if all are typed.
+- Fix: `/ba-create-actors`.
+
+## Output
+
+Write `.smartstack/ba/_audit/actors.md` per the doc-templates skeleton:
+- Anchor `<!-- ba:audit dimension=actors scope=project -->`.
+- Header `# Audit acteurs — projet` + `_<date> · Verdict : <emoji> N warn · M err · K ok_`.
+- `## ✅ Conforme`, `## ⚠️ Avertissements`, `## ❌ Bloquants` sections; one bullet
+  per finding. The rule codes (`ACT-001`, …) stay **bold** so they remain
+  greppable, but explain each in business terms. For every `warn`/`err`: what's
+  wrong (offending names/codes **bold**), why it matters, and a `→` fix naming
+  `/ba-create-actors`.
+- 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 actors 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 `.smartstack/ba/_audit/actors.md` as usual — the orchestrator
+reads these files.

package/templates/skills/business-analyse/audit-cross-dimension/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: ba-audit-cross-dimension
+description: >
+  Cross-dimension coherence audit of one `.smartstack/ba/` module — verifies that
+  data-model fields with state semantics have matching business rules, use cases
+  and screens, that use-case actors exist in RBAC, and that screen entity refs
+  resolve (XD-001..005). Reads the module's `entité.md`, `règles-métier.md`,
+  `use-case.md`, `rbac.md` and its section `screen.md` files together, writes a
+  verdict to `_audit/cross-dimension.md`. Run after the per-dimension audits or as
+  part of pre-dev readiness.
+allowed-tools: [Read, Write, Glob, Grep]
+---
+
+# ba-audit-cross-dimension — Cross-dimension coherence audit
+
+You audit ONE business module of a `.smartstack/ba/` project for coherence
+**between** its dimensions (data model ↔ rules ↔ use cases ↔ screens ↔ RBAC) and
+write a verdict file. The rules are unchanged from the SmartStack convention; only
+the I/O is file-based. This audit is inherently cross-doc — a single dimension in
+isolation cannot tell you whether a state field is missing its transition rule, so
+you read several docs of the module together and cross-check them.
+
+## File model — how to audit
+
+This audit is **module-scoped**: it works on one `<APP>/<MODULE>` at a time.
+
+1. **Read state**: `Glob .smartstack/ba/<APP>/<MODULE>/**/index.md` to rebuild the
+   module subtree (folders = the menu hierarchy). Then read, for that module:
+   - `entité.md` (authoritative at Module) — the MCD entities, their attributes
+     (types, enum values), relationships and traceability.
+   - `règles-métier.md` — the business rules (`BR-…`): type, condition, linked
+     entities and use cases.
+   - `rbac.md` (authoritative at Module) — the permission matrix (actor × action).
+   - every section/resource `use-case.md` under the module — the Cockburn use
+     cases (`UC-{APP}-{MOD}-{SEC}-NNN`): titles, primary actor, linked entities.
+   - every section/resource `screen.md` under the module — the screen specs
+     (`SCR-…`): SmartComponent type in the heading and the bound entity.
+   To reference a code, Grep it across the module subtree — if it is not found, it
+   does not exist (do not invent it).
+2. **Apply** the rules XD-001..005 (below) by cross-referencing those docs.
+3. **Write** the verdict to the module's `_audit/cross-dimension.md`:
+   `.smartstack/ba/<APP>/<MODULE>/_audit/cross-dimension.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 `[QUESTION]` block, no injected
+`--- CURRENT … ---` state and no i18n label codes — the `.md` verdict IS the
+record. The verdict header (`0 err` = pass) is what a downstream gate reads.
+
+## Rules
+
+State semantics, throughout: an attribute carries **state semantics** when its
+name contains `status`, `state`, `phase` or `step`, **or** its type is an `enum`
+whose values look like a lifecycle (e.g. `NOUVELLE/GAGNEE/PERDUE`,
+`DRAFT/APPROVED/REJECTED`). Identify these per entity first, then apply XD-001..003.
+
+### XD-001 — State fields have transition rules
+- `warn` if a state field is missing a transition rule; `ok` if covered.
+- Check: for each entity attribute with state semantics, verify at least one
+  business rule of type `state-transition` (or whose condition governs the
+  status/state change) references that entity. List the uncovered entities.
+- Why it matters: without a transition rule the allowed status changes are
+  undefined — FluentValidation has nothing to enforce and the UI cannot gate
+  illegal transitions.
+- Fix: `/ba-create-business-rules`.
+
+### XD-002 — State fields have corresponding use cases
+- `warn` if a state field has no use case describing its change; `ok` if covered.
+- Check: for each entity with a state field, at least one use case should describe
+  the action of changing that status — its title contains `change`, `update`,
+  `transition`, `approve`, `reject`, `validate`, `cancel`, or the entity name plus
+  a status action. List the uncovered entities.
+- Why it matters: a status that nothing in the use cases ever moves is dead state;
+  the workflow behind it was never specified.
+- Fix: `/ba-create-use-case`.
+
+### XD-003 — Workflow entities have Kanban or workflow screens
+- `warn` if a state-bearing entity has no workflow screen; `ok` if covered.
+- Check: for each entity with a state field, at least one screen of type
+  `SmartKanban` (or an equivalent workflow board) should bind that entity. List
+  the uncovered entities.
+- Why it matters: lifecycle entities are best operated on a board; otherwise users
+  have no view that surfaces the workflow.
+- Fix: `/ba-create-screen`.
+
+### XD-004 — Use-case actors exist in RBAC
+- `warn` if a use-case primary actor has no permission in the module; `ok` if all
+  matched.
+- Check: for each use case's primary actor code, verify it appears in the module's
+  `rbac.md` with at least one permission entry (or is referenced by a business
+  rule for the module). List the orphan actor codes.
+- Why it matters: an actor that performs use cases but holds no permission cannot
+  actually be authorised to do anything — the RBAC matrix is incomplete.
+- Fix: `/ba-create-rbac`.
+
+### XD-005 — Screen entity references match the data model
+- `err` on a broken reference; `ok` if all valid.
+- Check: for each screen that binds an entity, verify the referenced entity code
+  exists in the module's `entité.md`. List the broken references (screen → entity).
+- Why it matters: a screen pointing at a non-existent entity cannot be scaffolded —
+  it breaks downstream page generation.
+- Fix: `/ba-create-data-model` (add the missing entity) or `/ba-create-screen`
+  (correct the screen's binding), depending on which side is wrong.
+
+## Output
+
+Write `_audit/cross-dimension.md` per the doc-templates skeleton:
+- Header `# Audit cross-dimension — <APP> / <MODULE>` + `_<date> · Verdict :
+  <emoji> N warn · M err · K ok_`.
+- `## ✅ Conforme`, `## ⚠️ Avertissements`, `## ❌ Bloquants` sections; one bullet
+  per finding. For each `warn`/`err`: what's wrong (offending codes — entities,
+  actors, screen/entity refs — in **bold**), why it matters, and a `→` fix naming
+  the owning phase skill (`/ba-create-business-rules`, `/ba-create-use-case`,
+  `/ba-create-screen`, `/ba-create-rbac` or `/ba-create-data-model`, per the rule).
+- Rule codes (`XD-001`, …) stay **bold** so they remain greppable, but are
+  explained in business terms — no label codes, no JSON.
+- 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` (a broken screen → entity reference), state clearly that the
+module's coherence 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/cross-dimension.md` as usual — the orchestrator reads
+these files.