ObsiGate/docs/features/fusion-panneau-spark-218.md

#218 — Fusion : panneau Spark intégré (agent commun)

Contexte. Le programme Fusion a livré le service d'agents commun (agent-commun : conversation LLM, lectures/écritures des quatre applications via approbations, sous-agents, missions longues). Trois applications affichaient déjà son panneau partagé (TikTak, Flowdeck, Kanbante) ; ObsiGate, pourtant émettrice de l'identité draco_session, gardait le message d'attente « arrive en phase 4 » sur le bouton Spark de sa barre commune (#215).

Livraison.

• Assets vendangés à l'identique des autres applications : frontend/draco-panneau.js et frontend/draco-panneau.css, à la racine de frontend/ comme les autres assets draco (servis par le montage /static, Cache-Control: no-cache déjà en place — aucun mécanisme de versionnage à ajouter, index.html n'est pas un gabarit Jinja).
• frontend/index.html : lien CSS après celui de la barre, script différé après draco-liens.js, action spark de DRACO_BAR_CONFIG.onAction branchée sur window.DRACO_PANNEAU.toggle() avec repli explicite si l'asset ne charge pas.
• CSP (backend/main.py, SecurityHeadersMiddleware) : https://agent.dracodev.net ajouté à connect-src — le panneau appelle le service en fetch avec le cookie de session ; aucun autre hôte n'est ouvert (précédent : Flowdeck, même exception).

Vérifications. Tests tests/test_draco_barre.py étendus (présence et références des assets, branche spark, hôte CSP) ; vérification visuelle et E2E à confirmer après redéploiement Docker (le panneau, z-index: 400, cohabite avec des surfaces ObsiGate à z-index plus élevé — à observer en réel).

Hors périmètre. Les textes du panneau vivent dans l'asset partagé du programme (français, identique dans les quatre applications) ; ils ne passent pas par les locales FR/EN d'ObsiGate — écart assumé au niveau du programme, pas de cette fiche.