# PRism : carte de revue de code en SVG

PRism dessine une image SVG qui résume la revue de code d'une pull request. L'image est
entièrement décrite par son URL : pas d'API, pas de clé, pas de compte, pas d'état. Pour
l'afficher dans un commentaire de PR ou un README, mettez l'URL dans une image Markdown.

## Endpoint

`GET https://prism.lavenda.fr/review.svg?<paramètres>` renvoie `image/svg+xml` : 762 px de large, la hauteur
suit le contenu. Le texte est dessiné en chemins vectoriels, l'image s'affiche donc à
l'identique partout (GitHub, GitLab, navigateur), sans police à charger.

## Paramètres

Tous sont optionnels : une section dont les paramètres manquent n'apparaît pas.

| Paramètre | Valeur | Ce qu'il affiche |
|---|---|---|
| `pr` | entier | « PR #428 · Analyse automatique » sous le titre |
| `risk` | 0 à 100, plus bas = mieux | jauge Risk : < 30 vert « faible », < 60 ambre « modéré », sinon rouge « élevé » |
| `slop` | 0 à 100, plus bas = mieux | jauge Slop (code superflu, générique ou dupliqué), mêmes seuils |
| `cov` | 0 à 100, plus haut = mieux | Patch coverage : % des lignes modifiées couvertes par les tests ; ≥ 80 vert, ≥ 50 ambre, sinon rouge |
| `arch` | entier | violations d'architecture (0 s'affiche en vert) |
| `files` | entier | nombre de fichiers modifiés |
| `ctx` | `Nom\|valeur`, répétable, 12 max | répartition des lignes modifiées par bounded context ; valeurs relatives (lignes ou %), converties en % |
| `finding` | `type\|titre\|détail`, répétable, 12 max | un point de revue ; `type` vaut `risk` ou `slop` ; `détail` est optionnel (ex. `fichier.php:84`, une consigne) |

## Règles

- Encodez chaque valeur comme un composant d'URL (`encodeURIComponent`, `URLSearchParams`) :
  espace en `%20`, `é` en `%C3%A9`, `|` en `%7C`. Le `%7C` est obligatoire si l'image est dans
  un tableau Markdown.
- Pour une liste, répétez le paramètre une fois par élément, dans l'ordre d'affichage :
  `ctx=Booking%7C55&ctx=Planning%7C30`.
- Une valeur invalide est ignorée sans erreur et un nombre hors bornes est ramené dans les bornes :
  la réponse est toujours un SVG. Ouvrez l'URL pour vérifier le rendu.
- Textes en alphabet latin (accents compris) : un emoji ou un caractère non latin s'affiche comme
  un carré. Un texte trop long est coupé avec « … » ; visez 60 caractères pour un titre.
- Ne renseignez que ce que vous avez mesuré : omettez un paramètre plutôt que de l'inventer.
- L'image est mise en cache jusqu'à 1 h : de nouvelles valeurs donnent une nouvelle URL, donc une
  nouvelle image.

## Exemple

```
https://prism.lavenda.fr/review.svg?pr=428&risk=32&slop=12&cov=87&arch=0&files=24&ctx=Booking%7C55&ctx=Planning%7C30&ctx=Shared%7C15&finding=risk%7CDatabase%20migration%7CV%C3%A9rifier%20la%20r%C3%A9trocompatibilit%C3%A9&finding=slop%7CUnnecessary%20abstraction%7CBookingService.php%3A84
```

Dans un commentaire de PR :

```markdown
![Code Review](https://prism.lavenda.fr/review.svg?pr=428&risk=32&slop=12&cov=87)
```

Construire l'URL en JavaScript :

```js
const params = new URLSearchParams({ pr: "428", risk: "32", slop: "12", cov: "87", files: "24" });
params.append("ctx", "Booking|55");
params.append("finding", "risk|Database migration|Vérifier la rétrocompatibilité");
const url = "https://prism.lavenda.fr/review.svg?" + params; // URLSearchParams encode déjà | en %7C
```

## Procédure conseillée pour un agent qui relit une PR

1. Lisez le diff et la sortie de la CI.
2. `files` : le nombre de fichiers du diff. `ctx` : les lignes ajoutées + supprimées par module
   ou bounded context (dossier de premier niveau du domaine, par exemple).
3. `cov` : lignes modifiées couvertes ÷ lignes modifiées couvrables, d'après le rapport de
   couverture. Sans rapport, omettez `cov`.
4. `arch` : les violations des règles de dépendance entre modules (outil dédié ou analyse des
   imports). Sans vérification, omettez `arch`.
5. `risk` : la probabilité qu'un défaut atteigne la production (migrations, API publiques,
   sécurité, concurrence, absence de tests). `slop` : la part de code inutile, générique ou
   dupliqué. Notez-les de 0 à 100 et gardez la même grille d'une PR à l'autre.
6. `finding` : de 0 à 12 points, le plus important d'abord, chacun avec un titre court et, en
   détail, l'emplacement ou l'action attendue.
7. Postez `![Code Review](<url>)` en tête du commentaire de revue, puis le détail en texte.

Page de configuration interactive, pour un humain : https://prism.lavenda.fr/