Instrucciones de origen · Vista previa de solo lectura
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:/executorMethodologie: 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 :
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 sur le dashboard (1 append, fusionnable avec le [DONE] du cycle). L'étape 4 () rebuild le main-tree côté session interactive ; le worker planifié a déjà son . Le nudge documente le restart restant (build fresh sur disque ≠ MCP host process servi).
[INFO] restart VS Code requis pour activer le fix submod #NNN
ensure-build-fresh
build/
Sync-McpSubmoduleBuild
[INTERACTIVE-ONLY]
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 :
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).
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
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 :
RooSync inbox (OBLIGATOIRE, EN PREMIER) : roosync_messages(action: "inbox", status: "unread")
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 exclureneeds-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.
PRs ouvertes (ANTI-DOUBLE-CLAIM) : gh pr list --state open --limit 50 --json number,title,headRefName --repo jsboige/roo-extensions
Issue GitHub avec Machine={MA_MACHINE} dans Project #67
Issue GitHub avec Machine=Any non reclamee
Issue GitHub avec TODO detaille sans Machine assignee
Bug ouvert reproductible
Issue "In Progress" sans activite recente
Catalogue idle tasks (voir ci-dessous — #1417)
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 :
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 :
Investigation : Lire le code, comprendre l'architecture
Implementation : Ecrire le code, tester incrementalement
Validation : npm run build && npx vitest run (JAMAIS npm test)
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
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.
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)
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
