Files

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

3.9 KiB

Raw Blame History

name, description, metadata

name

description

metadata

mcp-e2e-findings-reply-wedge-phantom-busy

memory note mcp-e2e-findings-reply-wedge-phantom-busy

type
project

Findings validation MCP e2e (live, AppImage 0.3.0) — 2026-06-22

Contexte : validation réelle du parcours inter-agents (cf. resume-after-appimage-rebuild-mcp-e2e). Méthode = Main observe en externe (Bash sur ss -xp + transcripts ~/.claude/projects/<run-dir-encodé>/*.jsonl), l'utilisateur déclenche dans l'UI ; on ne valide PAS via idea_ask_agent.

Scénario 1 — délégation vers agent FROID + cycle complet : VERDICT

✅ Réveil à froid : déléguer vers un agent arrêté relance son pont (mcp-server --requester <id> réapparaît, socket ESTAB recompte).
✅ 1er tour non perdu : tâche livrée intacte = 1er user [IdeA · tâche de <agent> · ticket <uuid>] ….
✅ Chemin positif idea_reply : quand l'agent cible appelle idea_reply(ticket,result), le bridge répond reply ... delivered, le demandeur reçoit le tool_result et reprend la main (vérifié : DevBackend reçoit pong puis continue).
✅ Purge live-state : dès l'idea_reply, idea_workstate repasse le cible de working → done, intent vidé.

➡️ Transport + protocole de rendez-vous = SAINS. Bugs historiques 3/4/5 OK sur ce chemin.

LE défaut restant (racine unique) — wedge sans `idea_reply`

Si l'agent délégué termine son tour sans appeler idea_reply (ex. tâche triviale « réponds pong » → il répond pong en prose et s'arrête) :

le demandeur wedge indéfiniment dans idea_ask_agent (transcript demandeur figé sur le tool_use idea_ask_agent, aucun tool_result) ;
la cible reste working sur le ticket périmé dans la live-state ;
aucun timeout ni récupération côté serveur. Une interruption utilisateur du ask libère le demandeur mais ne purge pas le working de la cible (purge seulement à l'idea_reply).

➡️ Le « Busy fantôme » n'est PAS un bug d'état indépendant : c'est la conséquence de l'absence d'idea_reply. Une seule cause à traiter.

Pistes correctif (à arbitrer Architect)

Durcir contextes agents : « toute tâche déléguée se termine IMPÉRATIVEMENT par idea_reply, même triviale » (cheap, attaque la cause comportementale).
Garde-fou serveur (rendez-vous) : timeout sur l'attente idea_ask_agent → renvoyer au demandeur un résultat d'échec/relance explicite + purger le working de la cible (idempotent). Touche le contrat rendez-vous + cycle de vie live-state = domaine Architect. Voir idea-program-surface-separation-and-livestate, mcp-bridge-and-delegation-runtime-notes.

Diagnostic / repro (rappels)

Ponts : pgrep -af 'mcp-server --endpoint' (1 requester = 2 process) ; ss -xp | grep -c idea-mcp.
Reply réel = tool_use idea_reply dans le transcript cible → tool_result reply ... delivered (⚠️ ne pas confondre avec les mentions idea_reply du CLAUDE.md injecté via attachments).
Wedge demandeur = transcript demandeur s'arrête sur tool_use idea_ask_agent sans tool_result.
⚠️ Horodatages transcripts = UTC ; ls %H:%M:%S masque la date → comparer avec date + mtime réel (ls -t).

Restant à tester (scénarios e2e suivants)

Délégation vers agent BACKGROUND (node_id None) — même protocole, vérifier pas de 1er tour perdu.
ask sans réponse ne wedge pas durablement la CONNEXION du demandeur (vs juste l'appel) — Bug 5 côté transport.
Profils Claude/Codex utilisent MCP par défaut ; fallback fichier+prose cohérent.
Observabilité UI des délégations/replies (aujourd'hui opaque) — sujet UX.

3.9 KiB Raw Blame History