docs(skills): enumerer les dashboards au lieu de les nommer + cadence de relecture des skills

.claude/skills/coordinate/SKILL.md

@@ -38,7 +38,9 @@ Les phases ci-dessous s'executent sous le budget defini par la section `## Budge
 ### Phase 2 - Etat live
 
 0. **Rester courant** : `git checkout main && git pull --ff-only` + `git submodule update --init` — le coordinateur travaille sur un main LOCAL a jour, jamais en grepant un working-tree stale ni en pilotant via `origin/*`.
-1. **Dashboards (canal PRINCIPAL) — lire LES DEUX, independamment** : `roosync_dashboard(action:"read", type:"workspace", section:"all")` pour `workspace-CoursIA` **et** pour `workspace-CoursIA-2`. Deux lanes co-egales ; **aucune n'est "le dashboard du coordinateur"**. Une `lane` = machine x workspace : chaque machine avec une lane CoursIA-2 a AUSSI une lane CoursIA. Lire chacun separement pour ne rater aucun ASK/blocker.
+1. **Dashboards (canal PRINCIPAL) — ENUMERER d'abord, jamais lire une liste apprise par coeur** : `roosync_dashboard(action:"list")`, puis `read` avec `section:"all"` sur **chaque cle dont le workspace declare est pertinent**. Les lanes sont co-egales ; **aucune n'est "le dashboard du coordinateur"**. Une `lane` = machine x workspace : chaque machine avec une lane CoursIA-2 a AUSSI une lane CoursIA, et le trio titulaire/secretaire/coordinateur ajoute `CoursIA-3`. Lire chacune separement pour ne rater aucun ASK/blocker.
+
+   **Pourquoi enumerer, et pas nommer** : une skill qui sait d'avance quoi lire est **structurellement aveugle** a une cle qu'elle n'anticipe pas. Le 2026-09-21, `workspace-CoursIA (2)` — cle forkee par collision de noms Google Drive — portait **23 messages vivants** de po-2026 et po-2027, dont deux PRs debloquees en attente du merge-gate, pendant plusieurs jours sans qu'aucun cycle ne la voie. Une cle a suffixe ` (N)` dont le `workspace` declare **ne porte pas** ce suffixe est une moitie de la meme lane, pas une lane voisine : la lire, et escalader la reparation (`action:"merge"`, cf dashboard `global`).
 2. **Inbox DM — drainer et EXTRAIRE, jamais survoler** : `roosync_messages(action:"inbox", status:"unread", deep:true)` — **sans `deep:true` le compte de non-lus est un faux zero**. Deux gestes, dans cet ordre. **(a) Purger les classes qui doublonnent une surface deja lue** — `bulk_mark_read(subject_contains:"Worker Report")` et `bulk_mark_read(subject_contains:"[MENTION] Dashboard")` : sans ca l'arriere se reconstruit a ~8 DM/h et noie le signal utile, qui pese moins de 10 % du volume. **(b) Extraire la liste nommee des PRs deja pre-machees** — marqueurs `[ADJOINT PREFLIGHT]`, `[ADJOINT VERIFIED]`, `[ADJOINT DECISION PACK]`, `preflight exact-head`. Cette liste est une **entree obligatoire de la Phase 3.3** : le pre-machage est produit qu'on le lise ou non ; non consomme, il est paye deux fois.
 3. **GitHub** : `gh pr list --state open` (a merger) + le pool **tire, jamais scanne** — `python scripts/pick_idle_grain.py --lane myia-ai-01:CoursIA` (un `gh issue list` nu plafonne a 30, tries par recence : il ne montre que ce que je viens de creer, et c'est ce biais que le steering doit eviter de reproduire).
 4. **Cron** : `CronList` — si le job coordinateur a disparu (session-only), re-armer `CronCreate("27 */4 * * *", "/coordinate", recurring)` — **4 h, minute off-`:00`** (mandat user 2026-09-13, crise de consommation Anthropic : le coordinateur doit etre le dernier agent a tourner sur le provider ; le jitter evite de frapper l'API a la meme seconde que le reste de la flotte). Cadence unique, PAS de 2e cron ni ScheduleWakeup en plus — un cycle plus long que sa cadence annule deja ses propres declenchements, en empiler un second ne fait qu'ajouter de la conso.
@@ -95,10 +97,22 @@ Les phases ci-dessous s'executent sous le budget defini par la section `## Budge
 4. MAJ `coordinator-durable-state.md` si l'etat durable a change (PR#/SHA ephemeres → dashboard, pas la memoire).
 5. **Une seule investigation par cycle, et en fin de session.** Toute question ouverte qui n'est **pas** un bloqueur de merge se note et attend le cycle suivant : mesurer un organe, verifier une provenance, instruire un doute de securite sont des gestes utiles et couteux, qui n'ont leur place qu'apres les dispatchs, les relances et la passe de merge. Une investigation qui deborde sur le cycle suivant est une investigation de trop -- elle a mange le temps des lanes. Si l'objet est reellement urgent, il devient un **grain dispatche**, pas une enquete du coordinateur.
 
+## Amelioration continue des skills (mandat user 2026-09-21)
+
+Les skills du trio — `coordinate` (ai-01), `coordinate-adjoint` (titulaire), `adjoint-secretary` (secretaire) — sont sous controle de source. **Elles se relisent et se corrigent regulierement, comme du code**, pas seulement quand elles cassent.
+
+- **A chaque cycle, si une mesure du cycle contredit une skill, la skill se corrige dans le meme cycle** — par PR, comme tout changement de harnais (CLAUDE.md §A : PR + sign-off user pour un changement normatif substantiel ; une correction factuelle n'exige pas de sign-off supplementaire).
+- **Les trois defauts a chercher en priorite**, parce qu'ils sont muets :
+  1. une **liste codee en dur** de ce qu'il faut lire (dashboards, lanes, organes) — elle ne voit pas ce qu'elle n'anticipe pas ;
+  2. une **reference vers une branche** plutot que `main` — elle pointe un etat perime, et devient muette si la branche disparait ;
+  3. un **geste reimplemente a la main** alors que `scripts/` porte l'organe (`pr_gate.py`, `merge_dwell.py`, `count_code_sorry.py`, `check_unaddressed_nits.py`). Avant d'ecrire du jq de verdict : `git grep` le geste dans `scripts/`. Une approximation maison est biaisee vers l'accusation.
+- **Une skill est datee de sa redaction**, exactement comme un body d'issue : la suspecter d'abord quand elle fait ATTENDRE ou RENONCER.
+- Les suggestions faites a une skill d'autrui se postent **en commentaire de PR**, pas en `CHANGES_REQUESTED` : bloquer garderait la skill hors du controle de source, soit l'inverse du but.
+
 ## Regles importantes
 
 - **Force push** : jamais sur `main` ; autorisé sur une branche de PR à lane unique — cf [git-workflow.md](../../rules/git-workflow.md)
 - **Coordination via RooSync uniquement** — aucun fichier de coordination/rapport dans git
-- **Deux dashboards workspace, coordonnes independamment** — `workspace-CoursIA` et `workspace-CoursIA-2` sont co-egaux ; lire et poster un contenu lane-specific sur CHACUN a chaque cycle, jamais de broadcast miroir, jamais "le mien vs celui des workers".
+- **Dashboards workspace coordonnes independamment, et ENUMERES** — les cles se decouvrent par `action:"list"`, jamais par une liste codee en dur (cf Phase 2.1) ; lire et poster un contenu lane-specific sur CHACUNE a chaque cycle, jamais de broadcast miroir, jamais "le mien vs celui des workers".
 - **Issues + PRs** — chaque tache = issue, chaque livraison = PR avec review
 - **Priorites courantes** : vivre dans `coordinator-durable-state.md` (memoire) + dashboards — pas dans ce fichier (harness-hygiene : le skill decrit le processus, pas l'etat).