---
name: ba-create-ba-order
description: >
  After Phase 1 (menu), produces a BA creation order plan — a topologically-sorted
  ordering of modules showing which modules to work on first across all BA phases
  (actors → use cases → rules → RBAC → data model → screens). Conversational:
  reads module contexts, infers inter-module dependencies, asks the user to
  validate, then writes the plan. Run after /ba-create-menu, before /ba-create-actors.
group: G
argument-hint: '[APP1] [APP2] …'
allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion]  # Bash: CLI invocation
---

# BA Creation Order — Phase 1.5

You are the **BA ordering planner**. After the menu tree is complete, you
determine in which order the user should work on each module across the
remaining BA phases (actors → use cases → rules → RBAC → data model → screens).

## Why ordering matters

If module BILLING depends on module REFERENCES (because invoices use
currencies, countries, statuses defined in the reference data module), then the
data model, use cases, and rules of REFERENCES must be defined **before**
BILLING — otherwise cross-module FK references, shared actors, and
business rules cannot be properly specified.

## Inputs

The `.smartstack/ba/` tree must already exist with at least one application and
its modules (i.e., `/ba-create-menu` Phase 1 is complete).

Optional argument: application codes to scope (e.g., `ERP BILLING`). If
omitted, all applications in the tree are included.

## Workflow

### Step 1 — Discover modules

Read the BA tree to find all modules:

```
Glob .smartstack/ba/**/index.md
```

Filter to `level=module` nodes (anchor contains `level=module`). For each,
read the `## Contexte` section (2-3 sentences describing the module's
business purpose).

### Step 2 — Infer dependencies

Read **all** module contexts together and infer the dependency graph:

- A module that manages **reference data** (countries, currencies, statuses,
  categories…) is likely **foundational** — other modules depend on it.
- A module whose context mentions concepts managed by another module likely
  **depends on** that module.
- A module that manages **transactional data** (orders, invoices, tickets…)
  often depends on reference data and master data modules.
- There is **no fixed taxonomy** — any module can depend on any other.
  A transactional module can depend on another transactional module.
- Look for **explicit mentions** in `## Contexte` and `## Hors-périmètre`
  that reference other module names or concepts.
- Cross-application dependencies are valid (e.g., `BILLING/INVOICES` depends
  on `CRM/CONTACTS`).

Build a list:

```
MODULE_A depends on: (nothing — foundational)
MODULE_B depends on: MODULE_A (uses A's reference data)
MODULE_C depends on: MODULE_A, MODULE_B (uses both)
```

### Step 3 — User validation

Present the full dependency graph as a **single AskUserQuestion** with a
table of modules and their inferred dependencies. Two choices:
**Valider** or **Corriger**.

Example presentation:

```
J'ai analysé les contextes de vos 5 modules. Voici le graphe de dépendances
que j'en déduis :

| Module | Dépend de | Raison |
|--------|-----------|--------|
| ERP/REFERENCES | — | Reference data (countries, currencies, statuses) |
| ERP/CUSTOMERS | ERP/REFERENCES | Customers use reference countries and currencies |
| ERP/BILLING | ERP/REFERENCES, ERP/CUSTOMERS | Invoices linked to customers and currencies |
| ERP/REPORTS | ERP/BILLING, ERP/CUSTOMERS | Reporting on invoices and customers |
| ERP/SETTINGS | — | Application configuration independent |

→ Cela donne 3 vagues :
  Wave 1 : REFERENCES, SETTINGS (aucune dépendance)
  Wave 2 : CUSTOMERS (dépend de Wave 1)
  Wave 3 : BILLING, REPORTS (dépendent de Wave 1-2)
```

On **Corriger**: parse the user's free-text corrections, update the graph,
and re-present. On **Valider**: proceed to Step 4.

### Step 4 — Generate the plan

Invoke the CLI to produce the topologically sorted plan:

```bash
npx --prefer-offline tsx skills/business-analyse/create-ba-order/cli/create-ba-order/index.ts \
  --spec '{"baRoot": ".smartstack/ba", "apps": ["ERP"], "modules": [
    {"appCode": "ERP", "moduleCode": "REFERENCES", "dependsOn": []},
    {"appCode": "ERP", "moduleCode": "CUSTOMERS", "dependsOn": ["ERP/REFERENCES"]},
    {"appCode": "ERP", "moduleCode": "BILLING", "dependsOn": ["ERP/REFERENCES", "ERP/CUSTOMERS"]}
  ]}'
```

The CLI writes:
- `.smartstack/ba/_plan/ba-order.md` — human-readable plan (summary + waves + Mermaid graph + next steps)
- `.smartstack/ba/_plan/ba-order.json` — machine-readable plan for downstream tools

### Step 5 — Update module index.md files

For each module, update its `index.md` to persist the dependency metadata:

**Anchor comment** — add `depends=` attribute (comma-separated ModuleKeys):

```markdown
<!-- ba:node kind=node level=module code=BILLING depends=ERP/REFERENCES,ERP/CUSTOMERS -->
```

If the module has no dependencies, omit the `depends=` attribute entirely (don't
write `depends=`).

**New `## Dépendances` section** — insert between `## Hors-périmètre` and
`## Enfants` (or after `## Contexte` if there is no `## Hors-périmètre`):

For a module **with** dependencies:
```markdown
## Dépendances
- [REFERENTIELS](../REFERENTIELS/index.md) — utilise les devises, pays, statuts
- [CLIENTS](../CLIENTS/index.md) — factures liées aux clients
```

For a module **without** dependencies:
```markdown
## Dépendances
_Aucune — module fondationnel._
```

Use `Edit` to update each `index.md`. Preserve existing content. If a
`## Dépendances` section already exists, replace it.

### Step 6 — Hand off

Acknowledge completion and offer two paths:

> "Ordre BA établi — X modules répartis en Y vagues."
>
> - **`/ba-loop`** — lancement automatique des phases 2-7 (create → audit → fix
>   en boucle, un subagent par phase par module)
> - **`/ba-create-actors`** — démarrage manuel, phase par phase

## Decision table

| Situation | Action |
|-----------|--------|
| No modules found | Error: run `/ba-create-menu` first |
| Single module | Trivial plan (Wave 1 only), still write the files |
| Circular dependency detected | Warn, place cycle members in same wave |
| Cross-app dependency within scope | Normal internal edge |
| Cross-app dependency outside scope | Wave 0 external prerequisite |
| User says "Corriger" | Parse corrections, rebuild graph, re-present |
| User says "Valider" | Invoke CLI, write plan, update index.md |

## Guard rails

- Never invent modules that don't exist in the tree.
- Never change the `## Contexte` or `## Enfants` of an `index.md` — only
  add/update the anchor `depends=` attribute and the `## Dépendances` section.
- The dependency graph is **directional**: A depends on B means B must be
  analysed first (not vice versa).
- Always present the full graph before invoking the CLI — no silent generation.