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