---
phase: permissions
kind: level
level: detail
---

# Phase 2: DETAIL — refine permissions per section

> Follow this file when the decision table in `SKILL.md` routes here. The action
> vocabulary, scopes and authority rules live in `SKILL.md`.

## Goal

Refine the module matrix to **section level** with specific actions and condition
scopes. Walk through each section of module M that has use cases or business
rules.

## Before proposing (for each section S) — read the tree

1. Read `<APP>/<MODULE>/<section>/use-case.md` (or the module `use-case.md`
   filtered to S) — extract the main-flow steps.
2. For each UC in S, identify the primary actor + the main-flow actions using the
   verb mapping below.
3. Read `<APP>/<MODULE>/règles-métier.md` — note any rule whose scope implies an
   access permission on S.
4. Read the module's `rbac.md` — what is already refined for S?

## UC verb → permission action mapping

Read the main-flow step descriptions and fold each verb into one action:

| UC verb pattern | Action |
|-----------------|--------|
| "views", "consults", "searches", "browses" | `read` |
| "creates", "submits", "adds", "registers" | `create` |
| "edits", "modifies", "updates", "changes" | `update` |
| "deletes", "removes", "archives", "cancels" | `delete` |
| "exports", "downloads", "generates report" | `export` |
| "imports", "uploads", "bulk loads" | `import` |
| "approves", "validates", "confirms" | `approve` |
| "rejects", "refuses", "declines" | `reject` |
| "assigns", "delegates", "transfers" | `assign` |
| "triggers", "executes", "runs", "activates" | `execute` |

For each UC, the **primary actor** must receive at minimum the actions implied by
its main flow (plus prerequisites — see the action hierarchy in `SKILL.md`). In
your prose, anchor each line to the UC code that justifies it. Never map a UC
verb onto `lookup`: lookup rows are DERIVED by the `derive-lookup-grants` CLI
from the data model's FKs, not authored from use cases.

## Business-rules cross-reference

Scan `règles-métier.md` for rules targeting S. A rule that gates access (e.g. "a
remise > 20 % requires manager approval") implies the corresponding actor needs
the `approve` action on S — reference the `BR-…` code in your prose.

## Scope defaults per actor type (the Portée column)

| Actor type | Default scope | Rationale |
|------------|---------------|-----------|
| Internal admin-type | `all` / toutes | Full visibility on all records |
| Internal contributor-type | `own` for create/update, `all` for read | Sees own work, reads everything |
| Operator/agent-type (works a queue) | `assigned` for read/update, `own` for create | Processes records routed to them, not the whole backlog |
| Manager-type | `team` for read, `own` for create | Sees the team's work, creates own |
| External actors | `own` ALWAYS | External users only see their own data |

These are **defaults** — override from the UC context or the user's request, and
ask the user (via AskUserQuestion) to confirm any non-obvious scope choice.
Remember the materialization rule (SKILL.md): in a module where any actor's read
is `own`/`assigned`, every actor whose read is `toutes` also gets the
`… .read.all` line. The `team` scope stays DESCRIPTIVE for now (materialization
lands with the HR application) — keep it in the Portée cell, and never grant a
producer `read` as a workaround.

## Propose — section by section

Describe the refined lines in prose (actor, actions, scope, justifying UC/rule),
then ask the user to validate via **AskUserQuestion** (one multi-select per
section, or one confirmation if the inference is unambiguous).

## After the user validates → Write the matrix

1. Acknowledge briefly (one sentence).
2. **Write** `<APP>/<MODULE>/rbac.md` with the section-level lines added, using
   permissions `module.section[.resource].action` — 3 segments for a section
   (e.g. `pipeline.opportunites.create`), 4 for a resource (e.g.
   `pipeline.opportunites.devis.create`). Re-list every line that must survive — the
   Write overwrites the file, including the Phase 1 module lines you keep.
3. Announce the next section, or the transition to Phase 3 (review).

## Transition (Phase 2 → Phase 3)

When every section of M that has use cases is refined, move to Phase 3 (follow
`levels/review.md`) for the module-level completeness review.