Anatomie d'une mission agentic-dbm

Détail de l'étape

agentic-dbm est un plan de contrôle pour bases de données piloté par des agents LLM — avec une règle dure : un agent propose, seul un humain confirme, et l'exécution est du code déterministe. Ce diagramme rejoue une mission réelle de bout en bout : « une base PostgreSQL 17 pour une équipe, avec backup ».

▶ Simuler déroule les 41 étapes : chaque flèche passe au vert quand elle est faite, et la simulation s'arrête d'elle-même au human gate — comme le vrai système. Cliquez n'importe quelle flèche pour voir ce qui se passe, quel fichier/fonction du dépôt porte la logique, et qui décide.

Trois réponses à retenir :

1 · Une mission est une ligne en base (table missions), jamais un fichier — plan et score voyagent en jsonb sur cette ligne.
2 · Le LLM n'intervient qu'à 3 moments : décomposer, traduire une étape en commande, scorer. Tout le reste — conteneur, écritures, audit — est du Python déterministe.
3 · Aucune écriture sans humain : chaque action d'infra naît comme une proposition avec token et expiration ; la confirmation exécute handler + audit dans la même transaction.

espace lecture/pause · ←→ pas à pas · clic sur une étape = s'y positionner

humain LLM décide code déterministe données fait

Architecture — qu'est-ce qui tourne où

Sur le poste : Claude Code (la session qui lit le protocole mission.md) et le CLI dbm, un client HTTP pur.

Dans Docker (démarré une fois) : le control-plane FastAPI, sa base Postgres (missions, pending_actions, audit_log), Prometheus, Grafana.

Créées dynamiquement : les instances Postgres de flotte — par le control-plane lui-même via le SDK Docker, jamais déclarées dans compose, réseau interne, zéro port publié.

Seul appel réseau externe : l'appel au modèle de langage (Anthropic ou tout endpoint OpenAI-compatible via runners/). Le serveur, lui, ne sait même pas qu'un LLM existe.