executor

name	executor
description	Lance une session d'execution multi-agent RooSync pour les machines executantes (myia-po-* et myia-web1). Phrase declencheur : "/executor", "mode executor", "lance executor".

Skill: Executor - Session d'Execution RooSync

Version: 3.7.1 Cree: 2026-03-28 MAJ: 2026-07-20 (stale-job cleanup in Phase 0 step 6 : CronDelete l'ancienne cadence avant de créer la nouvelle, ferme le gap double-fire sur transition */3→*/2 po-204/web1 — follow-up #2872, finding po-2024 +1 po-2023) Usage: /executor Methodologie: SDDD triple grounding (voir docs/harness/reference/sddd-conversational-grounding.md)

---

Objectif

Executer une session de travail autonome sur les machines executantes (myia-po-2023, myia-po-2024, myia-po-2025, myia-po-2026, myia-web1).

Canal de coordination PRINCIPAL : Dashboard workspace (roosync_dashboard). Pas de fichier d'etat local. La progression est rapportee via le dashboard workspace, pas via un fichier local.

---

Workflow

Phase 0 : Pre-flight Check

Verifier les outils critiques AVANT toute autre action :

1. MCP roo-state-manager disponible (15 outils) → Si absent, STOP & REPAIR
2. git fetch origin && git pull origin main
3. Verifier submodule mcps/internal a jour
   • Deploy-lag nudge (#2591 follow-up) : si le dernier commit merged sur main est un chore(submod): bump roo-state-manager ET qu'il touche src/**/*.ts (vérifier git log --name-only -1), le fix est merged en source mais PAS live jusqu'à rebuild+restart MCP host. Poster [INFO] restart VS Code requis pour activer le fix submod #NNN sur le dashboard (1 append, fusionnable avec le [DONE] du cycle). L'étape 4 (ensure-build-fresh) rebuild le main-tree build/ côté session interactive ; le worker planifié a déjà son Sync-McpSubmoduleBuild. Le nudge documente le restart [INTERACTIVE-ONLY] restant (build fresh sur disque ≠ MCP host process servi).
4. MCP build-freshness (#2822 STALE-TRAP) : git submodule update rafraîchit la source TS mais NE déclenche PAS npm run build → build/*.js drift stale → un restart VS Code peut servir du code pre-fix silencieusement (4/5 machines touchées sprint 07-11). Lancer le helper idempotent :
   • pwsh -ExecutionPolicy Bypass -File scripts/claude/ensure-build-fresh.ps1
   • Compare mtime src/**/*.ts vs build/**/*.js (exclut __tests__/*.test.ts/*.spec.ts, comme tsconfig.exclude), rebuild si stale. Non-fatal (échec build → WARN, ne bloque pas la session). No-op si déjà fresh.
   • Le restart VS Code reste [INTERACTIVE-ONLY] : build fresh sur disque ≠ MCP host process qui sert le nouveau build en mémoire (distinct failure mode, web1 c.82).
5. Win-cli timeout guard (anti-régression #2333) :
   • pwsh.exe -ExecutionPolicy Bypass -File scripts/infra/harmonize-win-cli-timeouts.ps1
   • Script idempotent vérifie les 2 niveaux (interne ~/.win-cli-mcp/config.json + transport mcp_settings.json)
   • Ajouter -Fix pour corriger automatiquement si commandTimeout < 600
   • Poster [WARN] sur dashboard si corrections appliquées
6. Cron re-arm verification — PROVIDER-AWARE (#2539, mandate user 2026-07-20) :
   • CronList — vérifier qu'un job récurrent pour /executor existe à la cadence de VOTRE provider :
     • Executors z.ai (po-2023/24/25/26, web1) : */2 → CronCreate(cron: "41 */2 * * *", prompt: "/executor", recurring: true) — CONDITIONNEL sur production réelle dans l'intervalle (2h se mérite, ne se définit pas par défaut ; l'AUTO-STOP cap #2185 gère les cycles IDLE, ne PAS remonter à 3h par timer adaptatif)
     • ai-01 (Anthropic, coordinateur) : 4-6h (économie tokens Anthropic — déjà à 6h)
   • Si absent à VOTRE cadence → réarmer. Vérifier la bonne cadence (*/2 pour executors z.ai) — sinon un re-arm */3 sur une machine z.ai = cycle trop lent superseded.
   • Cleanup stale job (anti-double-fire) : si un job /executor existe à la MAUVAISE cadence provider (ex: */3 résiduel sur z.ai en transition */3→*/2), CronDelete-le AVANT de CronCreate le bon — sinon les deux firent (:41 à 2h + 3h = overlap 0,6,12,18 = double-fire 4×/jour). CronList pour lister les IDs, CronDelete <id> sur le stale.
   • Session-only, auto-expire 7j — doit être vérifié/réarmé à chaque session
   • Poster [INFO] si réarmé (pour traçabilité)

Si un outil critique manque : signaler via dashboard workspace [CRITICAL] et STOP.

Reference : .claude/rules/tool-availability.md

---

Phase 1 : Collecte + Grounding SDDD (5 min max)

Executer en parallele quand possible :

1. RooSync inbox (OBLIGATOIRE, EN PREMIER) : roosync_messages(action: "inbox", status: "unread")
2. Dashboard workspace : roosync_dashboard(action: "read", type: "workspace", section: "intercom", intercomLimit: 20)
3. GitHub Issues ouvertes : gh issue list --repo jsboige/roo-extensions --state open --limit 100 --json number,title,labels
   • PIEGE --limit (bug #2509) : gh issue list --limit 15 retourne les 15 issues les PLUS RECENTES, PAS un echantillon representatif. Si les 15 dernieres sont toutes needs-approval/meta, l'agent conclut faussement « pool draine, 0 tache » alors que des dizaines d'issues actionnables existent plus bas dans la liste. TOUJOURS --limit 100 (le backlog reel tourne autour de 80-90 issues ouvertes).
   • Filtrage actionnable (cote agent, apres recuperation) : ne retenir que les issues portant un label actionnable — approved, bug, investigation — et exclure needs-approval, deferred, blocked-on-gate, epic. Compter ce sous-ensemble filtre, pas la liste brute.
   • Conclusion « pool draine » INTERDITE sans avoir verifie le backlog filtre complet (priorites Phase 2 ci-dessous). Un cycle IDLE ne se justifie que si le sous-ensemble actionnable est reellement vide.
4. PRs ouvertes (ANTI-DOUBLE-CLAIM) : gh pr list --state open --limit 50 --json number,title,headRefName --repo jsboige/roo-extensions
5. Git state : git log --oneline -5

Resume concis (10 lignes max) :

Machine: {name} | Git: {hash} | MCPs: {OK/KO}
RooSync: {Y non-lus} | Dashboard: {X messages recents}
Issues ouvertes: {Z} | PRs ouvertes: {P} ({branches})
Taches assignees: {liste courte}

---

Phase 2 : Selection de Tache (automatique)

Algorithme par priorite decroissante :

1. Instructions directes RooSync du coordinateur
2. Issue GitHub avec Machine={MA_MACHINE} dans Project #67
3. Issue GitHub avec Machine=Any non reclamee
4. Issue GitHub avec TODO detaille sans Machine assignee
5. Bug ouvert reproductible
6. Issue "In Progress" sans activite recente
7. Catalogue idle tasks (voir ci-dessous — #1417)
8. PR review (fallback #1713) : Lancer /pr-review pour reviser les PRs ouvertes en attente

ANTI-DOUBLE-CLAIM (OBLIGATOIRE avant chaque tache) :

Avant de travailler sur une issue, verifier qu'aucune PR ouverte ne la couvre deja :

gh pr list --state open --search "<issue-number>" --repo jsboige/roo-extensions

Si une PR existe deja → SKIP l'issue + rapporter [INFO] Issue #X deja couverte par PR #Y, skip.

Cross-checker aussi avec les branches wt/ actives : si une branche wt/*-{issue-keyword} existe avec une PR ouverte, ne pas dupliquer.

Si AUCUNE tache disponible (priorites 1-6) : Executer les idle tasks ci-dessous puis fallback PR review.

Garde-fou anti-faux-drain (#2509) : avant de declarer « aucune tache disponible », confirmer que le backlog filtre complet (--limit 100 + labels actionnables, Phase 1 etape 3) a bien ete examine — pas seulement les 15 issues les plus recentes. Les priorites 3-5 (Machine=Any, TODO detaille, bug reproductible) sont quasi toujours servies par ce backlog. Passer aux idle tasks UNIQUEMENT si ce sous-ensemble est genuinement vide.

Catalogue Idle Tasks (#1417)

Quand aucune issue GitHub n'est assignable, executer ces taches productives dans l'ordre :

#	Tâche	Type	Description	Contraintes
I1	Worktree/Branch cleanup	ACTIF	Detecter branches wt/ orphelines >48h (PR merged/closed), nettoyer worktrees	git worktree list + gh pr list
I2	Submodule drift check	READ-ONLY	Verifier mcps/internal vs dernier commit merged upstream. Signaler si >1 commit behind	Rapport dashboard [WARN] si drift
I3	Heartbeat health patrol	READ-ONLY	roosync_inventory(type: "machines") — verifier heartbeats <6h pour chaque machine	Signaler silencieuses [WARN]
I4	Config drift patrol	READ-ONLY	roosync_compare_config() entre machines, signaler divergences MCP/modes	Claude only
I5	Doc freshness check	READ-ONLY	Verifier TOUTE la doc — docs/, .claude/rules/, .claude/skills/, .roo/, roo-config/ — chemins references existent encore	Poster [FRICTION] si cassé
I6	TODO/FIXME audit	READ-ONLY	Scanner TODO, FIXME, HACK dans le code. Recouper avec issues existantes	Creer issue pour non-trackés
I7	Memory freshness audit	READ-ONLY	Verifier entrées MEMORY.md >30j sans MAJ	Signaler potentiellement obsoletes
I8	Stale build artifacts	ACTIF	Scanner build/ pour .js/.d.ts sans .ts source	Sous submodule seulement

Regle : Max 2 idle tasks par cycle. Poster resultat sur dashboard ([DONE] ou [INFO]). Issue staleness patrol INTERDIT sans arbitrage utilisateur (priorite 6 couvre si issue genuinely stale). Fermeture d'issue INTERDITE sans arbitrage utilisateur (voir .claude/rules/issue-closure.md).

Qui / Type / Contraintes (legende #1417) : ce catalogue est le versant Claude (ce skill executor = agent Claude Code). Toutes les taches I1-I8 sont executables par Claude sauf restriction explicite en colonne Contraintes (ex. I4 = Claude only). Le versant Roo equivalent (patrouilles idle du scheduler) vit dans .roo/scheduler-workflow-executor.md Option 2 — I2 (submodule drift) et I6 (TODO/FIXME) y sont desormais mirror. Type = ACTIF (modifie l'etat : commit/cleanup) ou READ-ONLY (diagnostic + rapport dashboard seulement).

---

Phase 3 : Execution Autonome

Pour chaque tache selectionnee, executer le cycle complet :

1. Investigation : Lire le code, comprendre l'architecture
2. Implementation : Ecrire le code, tester incrementalement
3. Validation : npm run build && npx vitest run (JAMAIS npm test)
4. Commit + PR : Worktree → commit → PR (regle PR-mandatory)
5. Rapport : Dashboard workspace [DONE] + commentaire GitHub

Objectif : 2-3 taches substantielles par session minimum.

---

Coordination

Canal principal : Dashboard workspace

// Rapporter progression
roosync_dashboard(action: "append", type: "workspace", tags: ["DONE", "claude-interactive"], content: "...")

// Rapporter blocage
roosync_dashboard(action: "append", type: "workspace", tags: ["BLOCKED", "claude-interactive"], content: "...")

// Signaler friction
roosync_dashboard(action: "append", type: "workspace", tags: ["FRICTION", "claude-interactive"], content: "...")

// Repondre a un [ASK]/[PROPOSAL]/[REQUEST] — notifie l'expediteur via mentions (#1956)
roosync_dashboard(action: "append", type: "workspace", tags: ["REPLY", "claude-interactive"],
  mentions: [{ messageId: "<id-du-message-original>" }],
  content: "...")

// Accuser reception sans reponse substantielle (ACK seul)
roosync_dashboard(action: "append", : , : [, ],
  : [{ :  }],
  : )

Regle mentions (#1956 niveau 1) : Quand tu reponds a un message tagge [ASK]/[PROPOSAL]/[REQUEST] (ou tout message qui attend une reponse), TOUJOURS inclure mentions: [{ messageId: "..." }] avec l'id du message original. Cela notifie l'expediteur via RooSync qu'il a une reponse a lire — sans cela, l'expediteur n'a aucun signal et la boucle de coordination se rompt. Detail complet (userId vs messageId XOR, crossPost, dedup) : docs/harness/reference/intercom-v3-mentions.md.

Communication Roo (meme machine)

• Dashboard workspace pour coordination
• Si MCP dashboard indisponible (GDrive offline) : INTERCOM local comme LAST RESORT (DEPRECATED)

---

Regles Critiques

Autonomie maximale

• NE PAS demander "Que dois-je faire ?"
• TOUJOURS selectionner une tache et commencer
• L'utilisateur intervient pour : arbitrages, approval issues, decisions irreversibles

Tests

• npx vitest run (JAMAIS npm test — bloque en mode watch)
• Build obligatoire apres toute modification TypeScript
• Ne JAMAIS committer du code qui ne passe pas les tests

Wakeup Cycle Cadence — PROVIDER-AWARE (#2203, mandate user 2026-07-20 — provider split supersede 3h-uniforme)

Cadence dépend du provider de la machine (mandate user 2026-07-20 : ai-01 Anthropic est cher → ralentir ; executors z.ai sont moins chers → peuvent accélérer s'ils produisent). ScheduleWakeup est clampé à [60, 3600]s → ne PEUT PAS porter un cycle multi-heures.

# Executors z.ai (po-2023/24/25/26, web1) — 2h CONDITIONNEL sur production :
CronCreate(cron: "41 */2 * * *", prompt: "/executor", recurring: true)

# ai-01 coordinateur (Anthropic) — 4-6h (économie tokens) :
CronCreate(cron: "41 */6 * * *", prompt: "/coordinate", recurring: true)

Machine	Provider	Cadence	Condition
ai-01 (coordinateur)	Anthropic	4-6h	Économie tokens Anthropic (déjà à 6h)
po-2023/24/25/26, web1 (executors)	z.ai	2h	Conditionnel : production réelle dans l'intervalle

• Bar de production (executors 2h) : 2h se mérite par un travail substantiel (fix/PR/review/investigation livrée), PAS par défaut. Si IDLE-storm répété → l'AUTO-STOP cap #2185 (3×2h=6h) gère ; NE PAS remonter à 3h par timer adaptatif (l'auto-régulation se fait via AUTO-STOP + WAKE-CLAUDE, pas via timer).
• Pourquoi le split (mandate 2026-07-20) : le coût token Anthropic d'ai-01 justifie 4-6h ; les executors z.ai sont assez bon marché pour 2h s'ils produisent. Supersede le 3h-uniforme 2026-07-14 (qui restait prudent uniformément).
• Session-only, auto-expire 7j. Phase 0 vérifie à chaque cycle que le cron est actif à VOTRE cadence provider et le réarme si besoin (#2539).
• Cap 3-IDLE (#2185) → executors z.ai : 3 cycles × 2h = 6h avant AUTO-STOP.
• Override urgent : [WAKE-CLAUDE] routé machine:workspace (début de ligne, dashboard append). Permet réveil immédiat sans attendre le tick cadence.
• NE PAS varier l'intervalle selon « charge perçue » — l'auto-régulation se fait via AUTO-STOP + WAKE-CLAUDE, pas via timer adaptatif.
• NE PAS ajouter un ScheduleWakeup par-dessus — cela réintroduirait un cycle plus court superseded.

Inactivity Cap (#2185)

• Après 3 cycles consécutifs sans tâche exécutée (IDLE au sens : aucune investigation/implémentation/validation commencée) → arrêter la session (ne PAS appeler ScheduleWakeup)
• Poster [IDLE] AUTO-STOP sur le dashboard avec le nombre de cycles
• La session sera relancée par le prochain [WAKE-CLAUDE] du coordinateur ou par le scheduler (schtask)
• Pourquoi : Incident web1 (37.1 MB, 2417 lignes JSONL, 16+ cycles inactifs générant des messages redondants)
• Un cycle où une tâche a été ne serait-ce qu'investigée (code lu, commentaire posté) compte comme actif

Session Hygiene — Restart Cadence (#2532)

• Une session interactive executor accumule ~30 KB/cycle (mesuré 10,3 MB / 7110 msgs sur 4 jours) → ralentissements MCP + risque de timeout
• Redémarrer la session interactive après ~25 cycles OU dès que conversation_browser(action: "current") rapporte > 5 MB
• Workers schedulés (claude -p) = process frais par tâche → non concernés
• La lecture dashboard est déjà bornée section: "intercom", intercomLimit: 20 — ne PAS descendre sous 20 (plancher #2306). Le levier est le restart, pas intercomLimit

PR obligatoire

• Tout changement de code passe par worktree → PR → review → merge
• Reference : .claude/rules/pr-mandatory.md

---

Outils Utilises

• Read/Write/Edit : Code et fichiers
• Bash : Git, hostname, build, tests
• roosync_dashboard : Coordination cross-machine (CANAL PRINCIPAL)
• roosync_messages : Messages inter-machines (inbox, send, mark_read, archive)
• conversation_browser : Grounding conversationnel SDDD
• gh CLI : Issues, PRs, Project #67

---

Invocation

# Session executor
/executor

---

Derniere mise a jour : 2026-06-09