# ADR 0049 : la v0.1.0 garde son périmètre intégral — `Must / Should / Could` ordonne, ne retire rien

- **Status**: Accepted (tranché par @gilmry le 2026-09-12)
- **Date**: 2026-09-12
- **Track**: Pilotage / Release
- **Authors**: @gilmry (décision) + Claude Opus 5 (rédaction)
- **Related**: `RELEASE.md` (registre d'état Foyer), `docs/BACKLOG_STRUCTURE_v0_1_0.md`,
  `docs/WBS_v0_1_0.md`, décision du 2026-09-06

## Contexte

La décision du 2026-09-06 avait mis l'intégralité des issues ouvertes au
périmètre du tag v0.1.0. Elle a été prise **avant** que le chiffrage existe.

Depuis, le backlog a été restructuré par capacité et chiffré : 10 épopées,
32 capacités, **73,25 j de wall-clock superviseur** et **293 tours**, en bornes
hautes de première passe. Le périmètre était donc engagé sur une intuition, et
rien ne l'avait réexaminé une fois le coût sur la table. Le pilote Foyer a
inscrit ce réexamen comme arbitrage 🔴 au registre d'état.

Trois modalités ont été présentées :

| Option | Périmètre | Issues | Jours | Tours |
|---|---|---:|---:|---:|
| **A** | tout | 84 | 73,25 | 293 |
| B | sans les `Could` | 45 | 39,75 | 159 |
| C | les `Must` seuls | 22 | 19,75 | 79 |

*(Le backlog a été généré à 85 issues ; #840 a été fermée le même jour. Les
jours et tours sont ceux du document généré, non recalculés.)*

## Décision

**Option A — le périmètre reste intégral.** Les 84 issues ouvertes restent au
tag v0.1.0. Aucune capacité n'est reportée en 0.2.0.

La décision du 2026-09-06 est donc **confirmée, et non plus seulement héritée** :
elle a maintenant été opposée à son coût.

## Pourquoi

**Le classement MoSCoW était déjà conçu pour ordonner, pas pour retirer.** Le
backlog l'écrit dans ses propres termes : « un `Could` ici veut dire *en
dernier*, pas *hors release* ». Sortir les `Could` reviendrait à utiliser un
instrument de séquencement comme un instrument de coupe — et à perdre
l'information que le rang portait.

**L'ordre rend le périmètre intégral tenable.** Le rang 1 à 8 place le harnais
de recette d'abord, puis ce qui expose des données, puis le noyau légal, et
laisse les `Could` en dernier. Un périmètre intégral **exécuté dans cet ordre**
n'a pas le même risque qu'un périmètre intégral exécuté à plat : si le temps
manque, ce qui reste à faire est déjà ce qui compte le moins, sans qu'aucune
décision de coupe ait eu à être prise à l'avance.

**Couper maintenant coûterait un revirement plus tard.** Les 73,25 j sont des
**bornes hautes de première passe**, que le CSI doit resserrer story après
story sur le réel observé. Retirer 39 issues sur la foi d'un chiffrage qu'on
sait non resserré serait trancher avec la donnée la plus faible dont on
disposera jamais.

## Conséquences

### Ce qui est engagé

- Les 84 issues restent étiquetées `release:0.1.0`. Le WBS et le backlog
  structuré n'ont pas à être régénérés : ils décrivaient déjà ce périmètre.
- L'ordre des rangs 1 à 8 devient la séquence d'exécution de la release, et
  non une suggestion.

### Ce qui reste ouvert

- **Le backlog n'est toujours pas « Agent IA Ready ».** 7 issues sur 84 portent
  les huit éléments (`scripts/backlog-pret.py`) ; 25 portent les quatre classes
  de tests. Le livrable BMAD porte `etat: NON SIGNÉ`. Trancher le périmètre ne
  prépare pas les stories : l'étape 4 de la phase A reste due.
- **Le socle n'est pas vert.** `e2e` est 🔴 (#872). La phase B du parcours exige
  un vert connu avant d'empiler la release ; le périmètre intégral ne change pas
  cette précédence, il l'aggrave.

### Ce qui rouvrirait cette décision

Le resserrement du chiffrage par le CSI. Si le réel observé écarte
significativement les bornes hautes, la question du périmètre se repose — avec,
cette fois, une donnée solide. Cette ADR n'interdit pas ce réexamen : elle
enregistre qu'à la date du 2026-09-12, avec les bornes hautes pour seule
information, la coupe n'était pas justifiée.

---

*Arbitrage conduit selon `.foyer/pilote/arbitrage.md` : l'agent a assemblé la
preuve et présenté les modalités, l'humain a tranché.*