speclisted

> **Draft non éprouvé.** Écrit d'après l'état de l'art, pas récolté sur une exécution réelle — > `D-039` demande l'inverse. À confronter au premier usage ; en cas de désaccord, > `docs/methode/journal-frictions.md` prime sur ce fichier. Un **arbitrage**, pas un second diagnostic. Par construction, l'alignement a déjà eu lieu : la Discovery a établi le besoin, nommé pour qui il compte et pourquoi il compte maintenant. **Ne pas ré-interroger l'humain sur le besoin, le public ou l'urgence** — les redemander est le signal qu'il faut reposer la carte en `Discovery`, pas continuer ici. ⚠️ **C'est le binôme qui arbitre ; le document en porte la trace** (`D-053`). L'acte appartient à l'humain et à l'agent qui rédigent ensemble — la spec ne tranche rien, elle **enregistre**. Deux conséquences pratiques : ne jamais écrire un arbitrage que l'humain n'a pas prononcé, fût-il évident ; et si une option reste non tranchée, ce n'est pas la rédaction qu'il faut reprendre mais l'interrogatoire qu'il faut rouvrir. ## 1. Charger le socle Lire le document `Discovery` lié à la feature. En retenir le besoin, le pour-qui, le pourquoi-maintenant comme des **faits acquis** — ne pas les recopier dans la spec, y **renvoyer** par un lien. Complet quand : le lien vers le document Discovery est identifié, et aucune de ses trois réponses n'a été réécrite ici. ## 2. Arbitrer les options Pour chaque piste ouverte en Discovery — et toute piste apparue depuis — évaluer faisabilité et coût, légèrement : ç