registrylisted

# /registry — index des fonctions par domaine Cf. `doctrine/registre.md` du socle pour le pourquoi. Ce skill décrit le geste. ## Cas 1 — construction initiale (une seule passe, à faire tôt) 1. Lister les fichiers source réels selon `registry.sources` / `registry.extensions` du manifeste. 2. **Les regrouper par domaine**, pas par dossier — le découpage doit refléter la façon dont on raisonne sur le projet (processus principal, interface, données, orchestration…), pas l'arborescence. Cinq à huit domaines est la bonne échelle ; deux, c'est trop grossier pour servir, quinze, personne ne sait où chercher. 3. Pour chaque domaine, créer `registry/<domaine>.md` avec un en-tête « Périmètre » listant les fichiers couverts, puis une section par fichier. 4. Créer l'index à la racine (`FUNCTION_REGISTRY.md`) : la liste des domaines, une ligne chacun, plus le périmètre global et sa date. 5. Lancer `node <socle>/bin/check-registry.mjs` jusqu'à ce qu'il passe. **Ne pas étaler cette passe sur plusieurs sessions.** Un registre à moitié construit n'est pas utilisable et ne sera jamais fini — c'est le seul point où le tout-ou-rien est justifié. ## Cas 2 — maintenance (à chaque fichier créé, renommé ou supprimé) Mettre à jour l'entrée **avant** de considérer la tâche terminée, au même titre que les tests. Le script rend la chose non négociable ; ce skill dit quoi écrire. ## Format d'une entrée ```markdown ### `src/domaine/fichier.ts` <Une à trois lignes : ce que fait ce