# Règles (vetos + décisions)

Ce dossier contient la configuration "métier" pour piloter le moteur qualité.

## Fichiers

- `base.yaml` : socle commun (règles activées par défaut).
- `enabled.yaml` : choisit les overlays à activer (site/spécialité).
- `specialties/*.yaml` : overrides par spécialité.
- `sites/*.yaml` : overrides par établissement.

## Principe

- Une règle **non listée** est considérée **activée**.
  - Ça évite de casser le comportement historique lors d'une montée de version.
- Une règle listée peut être :
  - `enabled: false` → désactivée
  - (VETO) `force_severity: "HARD"|"MEDIUM"|"LOW"` → force la sévérité

## Exemple d'override

Créer `config/rules/sites/chu_poitiers.yaml` :

```yaml
version: 1
rules:
  VETO-12:
    enabled: false
  VETO-09:
    force_severity: "HARD"
```

Puis activer dans `enabled.yaml` :

```yaml
active:
  site: "chu_poitiers"
  specialty: ""
  extra: []
```


## Routage automatique (router.yaml)

Le fichier `router.yaml` permet d’activer automatiquement des **packs** de règles en fonction des signaux du dossier (codes, biologie, extraits). Concrètement :

- Par défaut, seuls les packs listés dans `defaults.enabled_packs` sont actifs.
- Quand un trigger match, on ajoute ses `enable_packs`.
- Le routage est appliqué **par dossier** (et re-appliqué sur la version fusionnée).

### Mode strict

Quand `mode: strict`, une règle *non listée* dans `base.yaml` est considérée **désactivée** dès que le routage runtime est actif.

Ça force une approche “catalogue explicite” : tout ce qui tourne en prod est visible et gouvernable.

### Exemple

Activer les règles ionogramme uniquement si un code `E87.*` est détecté ou si la biologie mentionne Sodium/Potassium :

```yaml
triggers:
  - id: TRG-ELECTROLYTES
    enable_packs: [bio_electrolytes]
    when_any:
      codes_prefix: ["E87."]
      lab_tests: ["sodium", "potassium"]
```