Mission Guardian

Statut

Direction produit principale pour les garde-fous d’exécution agentique.

Champ	Valeur
Routes serveur	`mission-guardian`
Use-cases	`core/use-cases/mission-guardian`
Maturité	beta
Pack first-party actif	`deck-guardian` — `draft_for_validation` (au 2026-05-27, lot P0-2)

Statut Deck Guardian

Deck Guardian passe les checks de cohésion runtime étendus au chargement :

validator structurel (validateGuardianPackDefinition incluant xrefs event-policy et runtime-role) ;
findOrphanPackTools(toolPolicy, runtimeExposedTools) retourne [] ;
findUnsupportedPackRoleEntries(toolPolicy) retourne [] ;
un diagnostic stderr est émis par FsGuardianPackCatalog si un pack futur échoue l’un des deux checks ; le diagnostic est aussi exposé via FsGuardianPackCatalog.getLastCohesionDiagnostic(packId).

Le passage à validated est gelé jusqu’au prochain lot CapabilityRegistry. Quelques actions de gouvernance référencées par le pack (notamment mission_guardian.assess_impact, mission_guardian.request_audit, mission_guardian.reference_existing_concept, mission_guardian.request_run_validation) vivent dans tool_policy.pending_capabilities.future_capabilities_for_capability_registry et ne sont pas injectées aux agents tant que le registry n’est pas implémenté. Les actions de validation humaine (validate_concept, validate_run, validate_cloture_*) sont délibérément routées par les cards et le backend POST /api/projects/:id/agent-action-cards/:cardId/select, pas par tool_policy.mode_tools.

Rôle

Mission Guardian couvre les décisions de gate liées aux missions, au leader, à la QA et aux transitions d’orchestration. Il rend les blocages explicites, traçables et actionnables avant qu’un agent ou un leader ne poursuive une mission.

Mission Control est la vue exposée au runtime agent : elle synthétise la flowmap active, le mode courant, les blocages et les prochains documents attendus. Mission Guardian reste l’autorité de gate ; Mission Control est la surface de lecture opérationnelle.

Mission Control s’injecte dans toute session agent visible. En solo, l’agent reçoit gates/events/flowmap sans squad ni orchestration. En mode équipe, le leader reçoit les tools d’orchestration audités ; les workers, QA et observateurs reçoivent le même cadre de gates/events/flowmap, mais sans droit de dispatch.

Le droit de dispatch n’est pas seulement un prompt : les tools d’orchestration write sont liés à la session et refusés côté système si l’agent courant n’est pas le leader de la squad active. Le MCP projet générique arka_runtime ne publie pas ces commands write.

Surfaces

Surface	Détail
Routes serveur	`mission-guardian` (groupes de routes Fastify)
Use-cases core	`core/use-cases/mission-guardian`
Prompts runtime	Bundle local Mission Control installé dans Cortex Lite ; alimentation depuis Cortex Public prévue en phase 2
MCP runtime	`mission_guardian_explain_events`, `mission_control_read_flowmap`, tools ArkaDoc/squad/tasks via `arka_runtime` selon rôle
Intégrations	`squad-leader` via les guards de transition, `squad-orchestration` via le pipeline mission
Vue UI	`GuardianPackAdminView` (Mission Control, administration du guardian pack, flowmap et règles)
Event Lab	Registry, stream projet, inspector de bindings, validateur de pack et scénarios dry-run pour les events modules
Runtime compiler	`guardian-runtime-compiler` compile les artefacts actifs en packet d’injection agent

Event Lab

Event Lab est une surface de contrôle pré-gouvernance dans Mission Guardian. Elle liste les events déclarés par les modules, affiche les events observés pour un projet, explique comment le guardian pack actif les matche, et simule des scénarios sans modifier l’état runtime.

La V1 couvre les catalogues d’events déclarés pour ArkaDoc, mémoire, workers, providers, connecteurs projet/MCP et cards d’action. Les producteurs réels raccordés au bus module sont les changements de statut ArkaDoc, les notes/rollups mémoire, les validations de cards d’action, les changements de statut MCP projet, les runs workers terminés/échoués et les échecs provider rattachés à une session projet. Routes HTTP locales :

GET /api/event-lab/catalogs
GET /api/projects/:projectId/event-lab/stream
POST /api/projects/:projectId/event-lab/inspect
POST /api/projects/:projectId/event-lab/scenarios/dry-run
GET /api/projects/:projectId/event-lab/pack-validator
GET /api/projects/:projectId/event-lab/scenarios
POST /api/projects/:projectId/event-lab/scenarios

L’UI expose cinq onglets : Registry, Stream, Inspector, Validator et Scenarios. Un dry-run peut être enregistré comme scénario projet, puis rejoué plus tard pour vérifier un guardian pack après modification. L’inspector remonte aussi les bindings invalides du pack même lorsque l’event inspecté ne les matche pas, afin de rendre visibles les fautes de type d’event, de facets ou d’opérateurs de predicate avant runtime.

Le registry d’events s’appuie sur un contrat d’auto-déclaration : chaque module ou addon peut fournir un ModuleEventCatalogProvider qui expose ses catalogues d’events, sans modifier Event Lab. Le validateur de pack relit le guardian pack actif depuis Cortex Lite, contrôle tous ses bindings contre ces catalogues déclarés, affiche les providers déclarants, les effets prêts, les erreurs bloquantes et les fautes de schéma avant qu’un event réel ne déclenche une card ou une transition.

Les scénarios dry-run forcent payload.synthetic = true et ne publient rien dans l’EventBus runtime, ne créent pas de card et ne changent pas de mode. Si aucun guardian pack n’est actif dans Cortex Lite, Event Lab reste utilisable pour lire le registry/stream et retourne GUARDIAN_PACK_UNAVAILABLE sur les inspections dépendantes du pack.

Injection runtime

L’injection Mission Guardian passe par guardian-runtime-compiler. Le runtime construit d’abord un packet Mission Control déterministe (mode courant, rôle, flowmap, obligations, events et tools autorisés), puis le compiler assemble les couches dues depuis les artefacts du pack actif.

La preview GET /api/projects/:projectId/mission-control/runtime-packet-preview permet de contrôler le packet compilé pour un rôle donné (solo_agent, team_leader, team_worker, team_qa, team_observer) sans lancer de session agent.

Le garde CI npm run guardian:runtime:check vérifie que les textes longs des guardian packs JSON ne sont pas recopiés dans le code runtime. Les règles et prompts vivent dans les packs ; le système les lit, les compile et les applique.

Formulation publique recommandée

“Mission Guardian applique les garde-fous mission et rend les refus visibles.”
Ne pas promettre un Mission Control autonome complet embarqué dans arka-deck — Mission Guardian couvre les gates mission, pas toutes les policies opérationnelles.

Limites

L’intégration CR automatique est encore en chantier.
Les preuves consommées et leurs schémas sont définis par les use-cases ; les addons consommateurs ne doivent pas créer de routes parallèles.
Les gates de dispatch exigent les ids de documents ArkaDoc task. Un task_id métier stocké dans le payload d’une task n’est qu’un alias et ne doit pas servir d’id de dispatch.
dispatch_ready existe comme capacité dérivée d’une ou plusieurs tasks dispatchables. Ce n’est plus un modeId global : le mode reste tasking, et le dispatch démarre seulement quand le runtime accepte le scope demandé.
Cortex Lite est la source de vérité des artifacts du guardian pack actif. arka-deck ne porte plus de pack de base hardcodé dans le runtime core ; chaque pack de gouvernance contient son registre de modes, transitions, tools, règles complètes, mini-rules, règles par mode, flowmap, event policy, templates de cards UI, couches d’injection et exigences documentaires.
Les packets runtime du guardian pack s’appliquent à tous les rôles : solo_agent, team_leader, team_worker, team_qa et team_observer.
Un projet peut fonctionner avec zéro ou un guardian pack. Les packs métier fournissent leur guardian pack dédié au lieu d’overrider un pack de base partagé.
Event Lab n’est pas un moteur de gouvernance. Il observe et simule ; Mission Guardian et le guardian pack actif restent l’autorité runtime.

Pour aller plus loin

Squad Orchestration : ./squad-orchestration