# kinds/actor.md — one actor (role), after the fact

The playbook `/ba-change` loads for `kind: actor`. The frame is in `SKILL.md`;
this file carries what is specific to an **actor** — the WHO of the analysis,
and the seeded ROLE the platform derives from it.

Owner document: `<APP>/acteur.md` (full re-Write of the application's actor
list). Grammar: `_workflow/doc-templates.md` § acteur.md; fields in
`ba-create-actors/SKILL.md` § Actor fields; categories in
`_workflow/role-taxonomy.md`. Code: `allocation.next` — `BA-{seq}-AC-NNN`,
allocated **project-wide** (one counter for every application; a code cited by
any `rbac.md` or `use-case.md` of the project is reserved).

## 1. Analyse the request

One grouped AskUserQuestion:

| Question | Why it matters |
|---|---|
| **Who** is it — the label in the user's words (« Assistante commerciale », « Auditeur externe »), one sentence of description? | the label IS the seeded role (`role.code = slugifyRoleCode(label)`, `role.name = label`) |
| **Type** — `internal` (employees, direct access), `external` (clients, partners, candidates through a portal), `system` (a background service)? | portal vs back-office surfaces, MFA/SSO expectations |
| **Category** — does it decide for other people (`Manager`), do operational work with writes (`Contributor`), only consult (`Viewer`), administer an application (`Admin`)? Absent → `Custom` | the platform `RoleCategory` and the default row bundle of `/ba-create-rbac` |
| **Périmètre** — which applications, which modules? What data does it see: everything, its own records, its team's? | the RBAC rows to author and the data scope to materialise |

Also settle its **Origine** (conversation, code scan, user decision) — a
required traceability field.

## 2. Challenge it

- **Is it a new actor at all?** `existing.exact[]` lists any actor of ANY
  application with the same label or the same role code — actors are
  project-scoped: the change is then a `- **Périmètre**` line (or an extended
  one) in this application's `acteur.md`, **never a second code**. Two actors
  with the same role code collide at seed time (`role-code-collision`).
- **Is it a role or a permission?** « Le commercial peut aussi exporter » is
  a row for an existing actor (`/ba-change` kind=permission), not a new actor.
- **Is it a role or a data scope?** « Le commercial de l'agence de Lyon » is
  the same actor with a Portée (`équipe` / `custom`), not a new one — and
  `team`/`custom` Portées are declared expectations, not runtime restrictions
  yet (RBAC-010).
- **Does it do anything?** Which use cases will name it as primary or
  secondary actor? An actor no UC names is decorative (ACT-006).
- **Which rows?** In every module of its Périmètre, at least the section
  floor it must reach (`access` + `read`) and the actions it performs.
- **Is `Global` being asked for?** Refuse — it is platform-reserved; the
  closest authored category is `Admin`.

## 3. Author

```markdown
### <allocation.next> — <Label>
- **Type** : internal
- **Catégorie** : gestionnaire                       (optional — role-taxonomy.md labels)
- **Description** : <one sentence>.
- **Périmètre** : <APP>[ / <MODULE>]
- **Origine** : conversation (<date>)
- **Sources** : SRC-NNN §n                           (when the registry exists)
```

Then the full re-Write of `<APP>/acteur.md` (SKILL.md Step 3) and the verify
(`expectCode` = the new code, `baselineCount` = `existing.count`).

## 4. Verify

`report.verify.ok` true: found, delta +1, no duplicate code, no near-miss
`### BA-…` heading, sources cited when required.

## 5. Propagate — what a new actor drags along

1. **Use cases** — the ones it drives: new UCs (`/ba-change` kind=use-case,
   one at a time) or existing UCs whose `Acteur principal` / `Acteurs
   secondaires` change (op=modify). UC-008 errs on a UC citing an unknown
   actor.
2. **RBAC rows** — in this module first, then every module of the
   Périmètre: `/ba-change` kind=permission per row. Start with the section
   floor the actor must reach (`access`, `read`), then its actions. RBAC-004
   warns on an actor with no row; RBAC-002 on a section nobody can reach.
3. **Data scope** — rows with `les siennes` / `équipe` / `custom` need the
   materialisation the matrix documents (RBAC-006, RBAC-010).
4. **No pagespec** — permissions are paths, not actors; the rows of step 2
   are what reaches the pages.
5. **Seed parity** — when the module is developed, `derive-rbac-grants
   --mode check` (with `projectPath`) must report the new role as
   `unmatchedActors` / its grants as `missingGrants`: that IS the Phase 0
   re-entry.

## 6. Audit

`audit-ba` with dimensions `actors` (PROJECT-scoped — every `<APP>/acteur.md`),
`rbac`, `use-cases`. What an err means here: ACT-001 (missing type),
ACT-002 (duplicate label), ACT-006 (an application module nobody covers),
UC-008 (a UC cites a code that is not there), RBAC-005 (a row cites a code
that is not there).

## Modify variant (op=modify)

- A **renamed label** changes the seeded role code (`slugifyRoleCode`): the
  boot seed is additive and would create a SECOND role — the rename reaches an
  existing database only through the release-branch `derive-seed-delta`
  script (gitflow PR gate). Announce it; you never run it (red lane).
- A changed **Catégorie** changes the platform `RoleCategory` of the seeded
  role — same channel.
- A changed **Périmètre** re-opens step 2 for the modules gained (rows to
  add) — and says out loud that rows in modules lost are NOT removed here
  (deletion has no reconciler; the revocation is a delta-script matter).
- Verify expects delta **0**.