blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5ee25d1ef656c9a613574596a1dc4e82facb2843
IdeA/.ideai/skills/md/86ea97df-1533-47e5-8809-dc2b02242567.md
Blomios 50e99e5ced chore(workstate): notes mémoire campagne MCP T1→T10 + état runtime 
Capitalise la mémoire projet produite pendant la campagne de tests fonctionnels
MCP (rendez-vous inter-agents, backstop no-reply, réconciliation live-state au
reboot) et synchronise l'état runtime `.ideai/` (agents, layouts, skills, index
mémoire). Inclut la mise à jour du contexte de l'agent Git.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-24 13:32:28 +02:00

5.4 KiB
Raw Blame History

Skill — Test fonctionnel du rendez-vous inter-agents MCP

Workflow ré-exécutable et évolutif pour tester de bout en bout le rendez-vous idea_ask_agent ⇄ idea_reply d'IdeA, du trivial au plus tordu. À relancer après chaque rebuild qui touche l'orchestration MCP / le backstop / la live-state. Ce plan évolue : à chaque nouveau souci rencontré, ajoute/raffine un test Tn et note le défaut dans la section « Journal des défauts ».

Principe

  • Main est le demandeur (idea_ask_agent) — test fidèle de « si je donne un message à un agent, il me répond ».
  • Doublé d'observation externe Bash :
    • ponts : ss -xp | grep idea-mcp (ESTAB) et pgrep -af mcp-server (2 process par requester = pont vivant).
    • transcripts : ~/.claude/projects/<run-dir-encodé>/*.jsonl (horodatages UTC). Reply réel = tool_use idea_reply → tool_result reply … delivered. Wedge demandeur = transcript figé sur tool_use idea_ask_agent sans tool_result. 1er tour intact = 1re ligne user parentUuid:null = [IdeA · tâche…].
    • placement : .ideai/layouts.json (agent présent = cellule visible ; absent = background / node_id None).
    • live-state : idea_workstate_read (last-writer-wins, pas temps réel).
  • Règle structurelle : binaire qui tourne = AppImage. Tout fix backend ⇒ rebuild + relance d'IdeA (tue Main). Les tests s'enchaînent SANS relance à l'intérieur d'une même version. Vérifier avant T1 : stat mtime de l'AppImage récent + git log -1 = HEAD attendu.

Setup avant T1

  1. Relancer IdeA, ouvrir le projet, Main visible (le demandeur).
  2. Garder 2 cellules visibles libres + lancer QA et DevFrontend dans des cellules visibles (cibles chaudes).
  3. Laisser Architect, DevBackend, Git ARRÊTÉS (froids) : T3 teste le réveil à froid ; T9 utilise Architect+DevBackend froids.

Méthode d'exécution

On lance dans l'ordre, on note chaque verdict avec preuve réelle. Si un défaut bloquant apparaît : stop, ouvrir le cycle de fix (Architect→Git→DevBackend→QA, ou via subagents si le rendez-vous lui-même est cassé), rebuild + relance, puis reprise depuis T1. Un défaut non bloquant est consigné au Journal et on peut continuer si l'utilisateur le décide.

Ordre des tests (trivial → tordu)

  • T1 — Visibilité outils MCP. Agent lancé par IdeA voit ses outils sans action manuelle. Vérif : pont ESTAB + 2 mcp-server par requester ; cibles froides = 0 process.
  • T2 — Cible CHAUDE + idea_reply trivial. ask(agent chaud, « pong via idea_reply »). Attendu : pong inline borné, workstate done, pas de busy fantôme.
  • T3 — Réveil à FROID + idea_reply. Cible arrêtée. Attendu : pont relancé (nouveau mcp-server), 1er tour non perdu, reply remonte.
  • T4 — Cible BACKGROUND (node_id None). Cible hors layout (sans cellule visible). Attendu : même protocole, multi-tours sans perte.
  • T5 — NO-REPLY (cible répond en prose, pas d'idea_reply). Attendu : backstop libère le demandeur en temps borné avec TargetReturnedNoReply (retryable), ET live-state de la cible purgée (pas de busy fantôme). Défaut historique #1.
  • T6 — Délégation MULTI-ÉTAPES puis idea_reply. Cible lit plusieurs fichiers / lance une cmd PUIS idea_reply. Attendu : pas de libération prématurée pendant le travail, rapport final livré. (Piège turn-watcher : backstop tirait au 1er tour interne ~3 s.)
  • T7 — Tâche LOURDE > plafond (impl + cargo test/clippy). Attendu : extension sur signe de vie OU message clair « cible active, plafond atteint » (≠ faux -32001) ; idea_reply tardif non perdu. Plafond IDEA_ASK_RENDEZVOUS_TIMEOUT_MS (défaut 600000).
  • T8 — Délégations PARALLÈLES (2 cibles en 1 tour Main). Attendu : rendez-vous multiples simultanés, multiplexage pont, 2 réponses distinctes.
  • T9 — TRANSITIVE A→B→C (Main→Architect, Architect délègue à DevBackend puis reply à Main). Attendu : rendez-vous imbriqués, 2 attentes simultanées sans deadlock.
  • T10 — INTERRUPTION/annulation + reconcile reboot. (a) Main interrompt un ask en vol → working cible purgé, pas de cascade, idea_reply tardif non-livrable proprement. (b) Au reboot, orphelins {working,waiting,blocked} & session morte → idle + STALE_AT_RESTART_MARKER (use case ReconcileLiveState).

Critère de fin

Tous les T1→T10 verts avec preuve réelle. Sinon : 1er défaut bloquant = corriger puis reprise T1.

Journal des défauts (à enrichir au fil des runs)

  • 2026-06-24, run a6ced819 (AppImage 08:15, HEAD 1efe2f1) — T1→T4 ✅. T5 partiel : backstop libère le demandeur en ~24 s (TargetReturnedNoReply retryable, wedge demandeur corrigé) MAIS la live-state de la cible n'est pas purgée : elle reste status:"working" jusqu'au prochain write réussi de la cible (re-délégation non bloquée, busy fantôme atténué mais présent → idea_workstate_read ment sur la dispo). Cause : backstop agit côté demandeur, ne réinitialise pas la live-state de la cible sur no-reply. → fix en cours.

Notes / pièges observés

  • IdeA peut placer une cible réveillée en background même quand des cellules visibles sont libres (observé T3/T4).
  • Quand le rendez-vous MCP lui-même est suspecté cassé, ne pas orchestrer le fix via idea_ask_agent (risque de blocage) : utiliser les subagents natifs de l'orchestrateur pour analyse/fix/rebuild.