flowdeck/docs/agents-skills-phase-3-custom-agents-autonomes.md

Agents & Skills pour Flowdeck — Phase 3 : Les Custom Agents deviennent autonomes

Champ	Valeur
Phase	3 sur 5 — le passage de l'assistant à l'équipe d'agents
Document parent	architecture-agents-skills-notion-flowdeck.md v1.1 — en particulier §3.3 (les Custom Agents), §10.2 et §10.5, §12.1, §12.6–12.8, §16.1–16.2
Version	1.0 — 9 octobre 2026
Auteur	Spark, pour Bruno
Statut	Prêt à implémenter après les Phases 1 et 2
Prérequis	Phase 1 (skills = pages), Phase 2 (agent_runs, RunContext, routeur)
Migration créée	41
Débloque	Phase 4 (les déclencheurs de messagerie et les écritures externes s'appuient sur ce dispatcher et ce régime de permissions)

Résultat visible à la fin de cette phase. Chaque Custom Agent a sa page en trois onglets — Chat, Activity, Settings ; il se déclenche sur horaire, événements du workspace (ligne ajoutée/modifiée/retirée, commentaire, note de réunion terminée) et mentions [[fdagent:…]], avec filtres ; il n'accède qu'aux ressources explicitement accordées (régime allowlist) ; il se partage en trois niveaux, se duplique selon des règles explicites, son historique de configuration se restaure ; il peut déléguer à d'autres agents ; il se crée aussi en décrivant le travail à l'IA, qui propose un brouillon à relire.

---

Table des matières

1. Objectif
2. Périmètre
3. État d'entrée
4. Modèle de données — migration 41
5. Tickets de travail
6. API livrée par la phase
7. Comportements détaillés
8. Tests
9. Critères d'acceptation
10. Risques spécifiques et vigilance
11. Ordre d'exécution
12. Définition de « terminé »

---

1. Objectif

Flowdeck a déjà des « agents personnalisés » (instructions, outils autorisés, déclencheurs planifiés, trigger API). Ce qui leur manque pour être des Custom Agents au sens de Notion tient en quatre blocs, qui forment cette phase :

1. Un cycle de vie complet : page dédiée en 3 onglets, partage gradué, versions de configuration, duplication, intégration dans les pages, modèles de galerie, création assistée.
2. Des déclencheurs événementiels branchés sur le bus fire_event() des automatisations — l'infrastructure existe, le câblage est le travail.
3. Le régime de permissions allowlist : en autonome, l'agent ne voit que ses accès accordés, jusqu'aux résultats de recherche. C'est le ticket de sécurité central de toute la solution.
4. La délégation entre agents, comme outil borné et comptabilisé.

2. Périmètre

2.1 Inclus

• Migration 41 : agents.kind/web_access/credit_limit_monthly/delegation_json, agent_permissions, agent_versions, extension événementielle d'agent_triggers.
• Page agent SSR /agents/{id} : onglets Chat / Activity / Settings (formulaire complet : Instructions par page liée, Triggers, Tools and access, Modèle, Avancé).
• Régime allowlist appliqué dans le Context Builder et le Tool Registry pour les runs autonomes (filtre des ressources, y compris résultats de recherche et d'index sémantique).
• Dispatcher de déclencheurs : abonnement unique à fire_event(), correspondance type/ressource/filtres, déduplication, file bornée, plafonds, marque d'acteur anti-boucle.
• Déclencheurs livrés : horaire (existant, migré), collection.row_added, collection.property_updated, collection.row_removed, page.comment_added, meeting.summarized, mention d'agent. Filtres : propriété (opérateurs des automatisations), vue de base, mots-clés.
• Mentions d'agents [[fdagent:ID]] dans les pages, propriétés de base et commentaires ; sélecteur de mention étendu.
• Partage à 3 niveaux (full / edit / interact) pour personnes et groupes ; section Agents de la sidebar alimentée par les partages ; recherche incluant les agents accessibles.
• Historique de configuration (agent_versions) : snapshot à chaque sauvegarde des Settings, restauration.
• Duplication avec les règles de reprise du document parent §3.3.
• Bloc agent_embed : intégrer le chat d'un agent dans une page, sans transfert d'accès ni lecture implicite de la page hôte.
• Délégation : outil delegate_to_agent, runs enfants (parent_run_id), plafonds de profondeur et de budget (en tokens à ce stade).
• Création assistée : description → brouillon {instructions, déclencheurs, accès proposés} → relecture → enregistrement inactif par défaut.
• Galerie de modèles de Custom Agents (les 6 modèles de l'Annexe C du parent).
• Onglet Activity complet : filtres, détail d'un run (étapes, outils, sources, skills, erreurs, coût en tokens), Re-run avec la même entrée.
• Onglet Insights minimal : compteurs de runs (statut, période), modèles utilisés, tokens — l'export CSV et les vues avancées sont en Phase 5.

2.2 Exclu

• Déclencheurs et actions de messagerie externe (message/réaction/mention dans Slack, Discord, Telegram, Teams), courriel et calendrier → Phase 4. Le dispatcher accepte dès maintenant tout event_name : la Phase 4 n'ajoutera que des émetteurs et des types de ressources.
• Écritures externes et leurs approbations fines → Phase 4 (le régime d'approbation existant couvre les écritures internes dès cette phase).
• Budgets en crédits → Phase 4 ; credit_limit_monthly est créé et affiché, son application tarifaire attend le journal d'usage (le plafond tokens du moteur, existant, borne déjà les runs).
• Restriction « qui peut créer des agents » au niveau workspace (who_can_create_agents) → créée en données en Phase 4 avec les réglages IA du workspace ; en cette phase, la création suit les droits actuels des agents.

3. État d'entrée

Élément	État
agents (instructions, scope_json, approval_mode, modèle), conversations, triggers horaires + scheduler 60 s	Existants (v7.69.8)
Bus d'événements des automatisations : fire_event(), événements page.*, collection.*, form.submitted, meeting.summarized ; action agent_trigger	Existant (§19.1 de l'architecture) — le dispatcher s'y abonne, il ne le remplace pas
agent_policies / agent_approvals, gates d'outils, HTTP 428 sur le destructif	Existants — étendus au régime allowlist
agent_runs, RunContext, Skill Router, panneau des sources	Livrés en Phase 2
Skills = pages + accès par ACL de page	Livrés en Phase 1 — un skill « accordé » à un agent = sa page dans ses accès
Jetons wiki [[fdpage:ID]], sélecteur de mentions	Existants — étendus à [[fdagent:ID]]

4. Modèle de données — migration 41

-- Migration 41 — Phase 3
ALTER TABLE agents ADD COLUMN kind TEXT NOT NULL DEFAULT 'custom';
    -- toutes les lignes existantes sont des Custom Agents ; l'Agent personnel
    -- n'est pas une ligne d'agents (Phase 2).
ALTER TABLE agents ADD COLUMN web_access INTEGER NOT NULL DEFAULT 0;
ALTER TABLE agents ADD COLUMN credit_limit_monthly INTEGER;  -- appliqué en Phase 4
ALTER TABLE agents ADD COLUMN delegation_json TEXT DEFAULT '[]';  -- agent_ids délégables
ALTER TABLE agents ADD COLUMN status TEXT NOT NULL DEFAULT 'active';
    -- 'active' | 'suspended' (suspension = aucun nouveau run autonome)

CREATE TABLE agent_permissions (
    id INTEGER PRIMARY KEY,
    agent_id INTEGER NOT NULL REFERENCES agents(id) ON DELETE CASCADE,
    user_id INTEGER REFERENCES users(id),
    group_id INTEGER REFERENCES user_groups(id),
    level TEXT NOT NULL CHECK (level IN ('full','edit','interact')),
    created_by INTEGER REFERENCES users(id),
    created_at TEXT NOT NULL,
    CHECK ((user_id IS NULL) <> (group_id IS NULL))
);
CREATE TABLE agent_versions (
    id INTEGER PRIMARY KEY,
    agent_id INTEGER NOT NULL REFERENCES agents(id) ON DELETE CASCADE,
    snapshot_json TEXT NOT NULL,
    created_by INTEGER REFERENCES users(id),
    created_at TEXT NOT NULL,
    note TEXT
);
ALTER TABLE agent_triggers ADD COLUMN trigger_kind TEXT NOT NULL DEFAULT 'schedule';
ALTER TABLE agent_triggers ADD COLUMN event_name TEXT;
ALTER TABLE agent_triggers ADD COLUMN resource_type TEXT;
ALTER TABLE agent_triggers ADD COLUMN resource_id TEXT;
ALTER TABLE agent_triggers ADD COLUMN filter_json TEXT DEFAULT '{}';
ALTER TABLE agent_triggers ADD COLUMN show_typing INTEGER DEFAULT 1;  -- utilisé en Phase 4
ALTER TABLE agent_runs ADD COLUMN trigger_id INTEGER REFERENCES agent_triggers(id);
-- Les triggers horaires existants migrent tels quels (trigger_kind='schedule').
-- agent_runs.agent_id (Phase 2, nullable) reçoit désormais les Custom Agents.

Le snapshot d'agent_versions contient : instructions (texte et instruction_page_id), modèle et politique d'approbation, scope_json, accès (liste des ressources accordées, §7.2), déclencheurs (copie complète), web_access, delegation_json. Les accès accordés vivent dans une table de liaison simple créée ici aussi :

CREATE TABLE agent_access (
    agent_id INTEGER NOT NULL REFERENCES agents(id) ON DELETE CASCADE,
    resource_type TEXT NOT NULL,   -- 'page' | 'collection' | 'skill' | 'agent' | 'workspace_shared'
    resource_id TEXT NOT NULL,     -- id, ou '*' pour workspace_shared
    access TEXT NOT NULL DEFAULT 'read',  -- 'read' | 'edit'
    PRIMARY KEY (agent_id, resource_type, resource_id)
);

5. Tickets de travail

Régime de permissions (à faire en premier — tout le reste en dépend)

P3-T01 — Migration 41 et modèle d'accès. Fichiers : app/migrations.py, nouveau app/services/agent_access.py. Travail : schéma du §4 ; service de résolution : can_access(agent, resource, mode) (lecture/écriture) combinant agent_access, l'ACL du propriétaire (PermissionManager) et les politiques du workspace — l'ordre d'évaluation est celui du document parent §16.1, et le service rend aussi le motif d'un refus (journalisable). Acceptation : la matrice du §7.1 est couverte par des tests unitaires exhaustifs (chaque cellule).

P3-T02 — Le filtre allowlist dans le contexte et les outils. Fichiers : context_builder.py, tool_registry.py, semantic_search.py (point de filtrage). Travail : quand RunContext.permission_regime == 'allowlist' : le Context Builder ne charge que les ressources accordées ; chaque outil de lecture vérifie la ressource cible ; la recherche (FTS et sémantique) reçoit un filtre de ressources avant le classement des résultats — pas un masquage après coup (un titre hors accès ne doit pas transiter par le prompt ni par les journaux visibles) ; les outils d'écriture exigent access='edit' sur la cible en plus des gates existants. Acceptation : test de fuite dédié — un agent sans accès à une page secrète ne peut ni la lire, ni la trouver par recherche, ni apprendre son titre par un résultat, ni l'atteindre par une relation depuis une page accordée (les relations sortantes vers du non-accordé sont tronquées et signalées dans le run, pas suivies).

Page agent et cycle de vie

P3-T03 — Page agent et onglet Settings. Fichiers : nouveau routeur SSR /agents/{id}, gabarits, PUT /api/agent/agents/{id}/settings. Travail : les trois onglets ; Settings en sections (Instructions — sélecteur de page liée + aperçu du cache texte ; Triggers — cartes par déclencheur avec filtres et, pour les horaires, l'aperçu du prochain passage ; Tools and access — sélecteurs de pages/collections avec niveau read/edit, skills accordés, agents délégables, interrupteur web ; Modèle ; Avancé — politique d'approbation, plafond d'itérations) ; chaque sauvegarde écrit agent_versions et une ligne d'audit. Acceptation : un agent se configure entièrement depuis cette page, sans passer par les anciens écrans ; l'ancien CRUD d'agents du panneau redirige vers elle.

P3-T04 — Onglet Chat et onglet Activity. Travail : Chat = le panneau de conversation lié à l'agent (composants de la Phase 2, identité de l'agent) ; Activity = table des agent_runs de l'agent (déclencheur libellé, statut, durée, modèle, tokens, skills), détail dépliable (étapes, lectures/écritures avec liens d'annulation existants, erreur en clair), filtres statut/déclencheur/période, bouton Re-run créant un run lié (trigger_payload_json.rerun_of). Acceptation : un run en échec se débugue et se relance depuis Activity sans quitter la page.

P3-T05 — Partage à trois niveaux. Fichiers : agent_permissions, dialogue de partage (patron des partages existants), sidebar, recherche. Travail : appliquer la matrice du §7.4 ; la section Agents de la sidebar liste les agents accessibles triés par niveau ; la recherche globale inclut les agents (résultat typé, ouvrant la page agent) ; un utilisateur sans aucun accès ne voit pas l'agent, y compris dans les listes de délégation des autres agents. Acceptation : tests par niveau (un interact ne peut ni modifier les Settings ni voir Activity au-delà de ses propres runs — décision : Activity est réservé à full, les runs manuels d'un interact lui restent visibles dans son Chat).

P3-T06 — Versions, restauration, duplication. Travail : liste des versions (auteur, date, note auto-générée résumant les sections changées) ; restauration = nouvelle version créée depuis le snapshot choisi (on ne réécrit pas l'histoire) ; duplication selon les règles du parent §3.3 : copie privée, nom suffixé, modèle et instructions repris (page d'instructions copiée), ressources et déclencheurs filtrés par les accès du duplicateur (les ressources inaccessibles sont exclues et listées dans un rapport de duplication affiché), connexions d'outils, limites et historique non repris. Acceptation : le rapport de duplication d'un agent contenant une ressource inaccessible énumère exactement ce qui a été écarté.

P3-T07 — Bloc agent_embed et mentions d'agents. Fichiers : registre des types de blocs, rendu SSR du bloc, sélecteur de mentions de l'éditeur et des commentaires, tokens. Travail : coller le lien d'un agent dans une page propose Embed → bloc agent_embed {agent_id} rendant le chat de l'agent (composant du panneau, mode embarqué) ; états explicites : pas d'accès à l'agent / agent suspendu / agent supprimé ; le bloc ne donne au modèle aucune lecture de la page hôte ; jeton [[fdagent:ID]] résolu au rendu (nom de l'agent), reconnu dans les pages, les propriétés texte des bases et les commentaires ; la sauvegarde d'un contenu contenant le jeton émet l'événement de mention (T09). Acceptation : un lecteur sans accès à l'agent voit l'état « pas d'accès », jamais le chat ; l'agent embarqué ne peut pas répondre sur la page hôte sans y avoir été accordé.

Déclencheurs

P3-T08 — Dispatcher de déclencheurs. Fichiers : nouveau app/services/agent_triggers_dispatch.py. Travail : abonnement unique à fire_event() ; correspondance (event_name, resource, filtres avec les opérateurs des automatisations) ; création du run via le même chemin que les runs manuels (mais régime allowlist et conversation journalisée dédiée à l'agent) ; déduplication par empreinte (trigger + identifiant d'événement, fenêtre glissante) ; file d'attente par workspace avec plafond de concurrence partagé avec les runs interactifs (priorité à l'interactif) ; plafond horaire par agent (réglage, défaut documenté) → au plafond, les événements suivants produisent des runs budget_exceeded visibles, pas des pertes silencieuses ; suspension d'agent (status='suspended') = dispatcher muet pour cet agent. Acceptation : déclencher 50 fois le même événement en rafale produit le nombre de runs attendu après déduplication, tous visibles dans Activity.

P3-T09 — Les déclencheurs du workspace. Travail : brancher les émetteurs : lignes de collections (ajout/mise à jour de propriété/retrait — émis par les services de collections aux mêmes points que les événements d'automations), commentaires de page, meeting.summarized (déjà émis), mentions (T07) ; filtres propriété/vue/mots-clés évalués contre le payload ; l'acteur d'une écriture faite par un run autonome est marqué agent:<id> et, par défaut, les événements dont l'acteur est l'agent lui-même ne redéclenchent pas cet agent (anti-boucle), sauf si le déclencheur l'autorise explicitement (case « se redéclencher », déconseillée et signalée). Acceptation : UC-06 de bout en bout ; le scénario de boucle (agent qui écrit dans la base qu'il surveille) s'arrête de lui-même et le signale.

P3-T10 — Déclencheurs horaires : continuité. Travail : les horaires existants basculent sur le dispatcher (même file, mêmes plafonds) sans changer leur sémantique ; l'aperçu du prochain passage est calculé par le même code que le scheduler. Acceptation : un agent planifié de la v7.69.8 continue de tourner après migration, à la même heure, avec ses runs désormais dans Activity.

Délégation et création

P3-T11 — Outil delegate_to_agent. Fichiers : registre d'outils, nouveau app/services/agent_delegation.py. Travail : visibilité conditionnée à delegation_json non vide ; le run enfant est créé avec le régime et les accès de l'enfant, le contexte transmis = tâche rédigée + artefacts attachés explicitement ; profondeur max 3 par défaut (plafonnée à 5), budget tokens prélevé sur l'enveloppe du parent ; le résultat de l'enfant (réponse + statut) revient comme résultat d'outil ; échec de l'enfant = résultat d'échec motivé, le parent décide. Acceptation : UC-07 ; un enfant ne peut pas lire une ressource du parent qui ne lui est pas accordée (test de fuite croisée) ; une délégation circulaire A→B→A est stoppée par la profondeur et journalisée.

P3-T12 — Création assistée par l'IA et galerie d'agents. Travail : /agents/new en trois cartes (document parent §7.3) ; la création assistée est un run spécial de l'Agent personnel dont la sortie structurée est un brouillon {nom, instructions proposées (texte), déclencheurs proposés, accès proposés (ressources retrouvées par recherche, à cocher)} présenté en écran de relecture — rien n'est enregistré ni activé avant validation, et l'agent créé naît sans déclencheur actif ; la galerie propose les 6 modèles de l'Annexe C du parent, chacun étant un brouillon pré-rempli passant par le même écran de relecture. Acceptation : décrire « trie les tickets de la base X » produit un brouillon dont les accès proposés sont exactement la base X (ou rien si X est introuvable/illisible — jamais un accès deviné).

P3-T13 — Insights minimal et gouvernance de création. Travail : onglet Insights de la page agent : runs par statut et par période, modèles utilisés, tokens consommés, taux d'échec ; visible au niveau full ; la création d'agents continue de suivre les droits existants (la restriction workspace arrive en Phase 4, la donnée est préparée : ne pas coder de second mécanisme). Acceptation : les compteurs d'Insights recoupent exactement agent_runs sur la même période.

6. API livrée par la phase

Route	Ticket
GET /agents/{id} (SSR, 3 onglets)	T03/T04
PUT /api/agent/agents/{id}/settings	T03
GET /api/agent/agents/{id}/activity	T04
POST /api/agent/agents/{id}/runs/{run_id}/rerun	T04
POST /api/agent/agents/{id}/duplicate (+ rapport)	T06
GET /api/agent/agents/{id}/versions · POST …/versions/{vid}/restore	T06
PUT /api/agent/agents/{id}/permissions	T05
POST /api/agent/agents/generate (brouillon)	T12
GET /api/agent/agents/{id}/insights	T13
POST /api/v2/agents/{id}/trigger (existant, renvoie run_id)	T08

7. Comportements détaillés

7.1 Matrice des régimes (normatif, extrait du parent §16.1)

Contrôle	Run manuel (Chat, trigger API par un humain)	Run autonome (déclencheur, horaire, mention)
Identité	L'utilisateur	L'agent
Lecture	ACL de l'utilisateur	agent_access ∩ ACL du propriétaire
Écriture	ACL utilisateur + gates existants	Idem + agent_access en edit + politique d'approbation de l'agent
Recherche	Filtrée ACL utilisateur	Filtrée ACL et accès accordés, avant classement
Skills utilisables	Ceux de l'utilisateur	Uniquement les skills accordés à l'agent
Délégation	Vers les agents délégables de l'agent utilisé	Idem, profondeur comptée depuis le run racine

7.2 Ce qu'« accorder » veut dire

agent_access est la seule source des accès d'un agent autonome. Lier une page dans les instructions n'accorde rien (les liens d'instructions vers du non-accordé rendent un jeton « sans accès » au moment de l'assemblage du contexte, comme dans la duplication). La ligne spéciale workspace_shared donne accès à ce qui est partagé avec tout le workspace au moment du run (évalué dynamiquement, pas photographié).

7.3 Le run autonome a une conversation

Chaque agent a une conversation journalisée permanente pour ses runs autonomes (une par agent, ou une par déclencheur si le créateur préfère — défaut : une par agent) : c'est là que Re-run, les approbations en attente et le débogage trouvent leur matière. Elle n'est visible qu'aux niveaux full/edit.

7.4 Matrice de partage

Action	full	edit	interact	aucun accès
Discuter / lancer un run manuel	✓	✓	✓	✗
Voir les Settings (lecture)	✓	✓	✓	✗
Modifier les Settings	✓	✓	✗	✗
Partager / changer les niveaux	✓	✗	✗	✗
Activity complète / Insights	✓	✗	(ses runs manuels)	✗
Dupliquer	✓	✓	✓	✗
Supprimer / suspendre	✓	✗	✗	✗

Exception héritée du modèle Notion : un utilisateur sans accès peut déclencher indirectement un agent (par exemple en ajoutant une ligne à une base surveillée) et voir ses sorties là où elles sont publiées — sans jamais voir l'agent lui-même.

7.5 Approbations en autonome

Le régime existant s'applique tel quel : une écriture couverte par require_approval suspend le run (waiting_approval, webhook) ; les approbations se décident depuis Activity ; expiration du run en attente selon le délai configuré (défaut proposé au parent : 72 h).

8. Tests

#	Niveau	Cas
T-01	Unitaire	Matrice complète de can_access (régimes × niveaux × modes)
T-02	Intégration	Fuite : recherche, lecture directe, relation, mention — aucune voie ne laisse passer une ressource non accordée (le test central de la phase)
T-03	Intégration	UC-06 : ligne ajoutée avec filtre propriété → un run, bonnes lectures, écriture dans le périmètre accordé
T-04	Intégration	Filtre non satisfait → aucun run ; événement dupliqué → un seul run
T-05	Intégration	Anti-boucle : l'agent écrit dans la base surveillée → pas de second run ; case « se redéclencher » → run fils compté et plafonné
T-06	Intégration	Plafond horaire atteint → runs budget_exceeded visibles, aucun événement perdu silencieusement
T-07	Intégration	meeting.summarized déclenche l'agent de suivi avec le résumé en payload
T-08	Intégration	Partage : chaque ligne de la matrice §7.4 testée par niveau
T-09	Intégration	Restauration de version : la configuration revient, l'historique garde la trace de la restauration
T-10	Intégration	Duplication avec ressource inaccessible : rapport exact, copie privée, aucun accès fantôme
T-11	Intégration	Délégation : périmètre de l'enfant respecté, profondeur plafonnée, coût agrégé au parent
T-12	Intégration	Création assistée : brouillon non enregistré avant validation ; accès jamais devinés
T-13	E2E	Configurer un agent de zéro (Settings), le tester dans Chat, l'activer sur déclencheur, lire son run dans Activity
T-14	E2E	Embed dans une page : chat fonctionnel pour un utilisateur partagé, état « pas d'accès » pour un autre
T-15	Non-régression	Les déclencheurs horaires et le trigger API v2 existants fonctionnent après bascule sur le dispatcher

9. Critères d'acceptation

• UC-05, UC-06 et UC-07 passent de bout en bout.
• Le test de fuite (T-02) est vert sur les quatre voies d'accès à une ressource.
• Un agent événementiel tourne une semaine en autonomie sur l'instance de test avec un Activity propre (aucun run fantôme, aucune boucle).
• Un agent se partage, se duplique et se restaure conformément aux matrices du §7.
• Aucun accès n'est accordé par un lien d'instructions, une mention ou un embed — seulement par agent_access.

10. Risques spécifiques et vigilance

Risque	Vigilance
Le filtre allowlist appliqué après classement laisse fuiter titres et extraits	T02 teste les voies une à une ; le filtrage se fait dans la requête d'index, pas dans le rendu
Le dispatcher double les automatisations existantes (une automation agent_trigger + un déclencheur d'agent sur le même événement = deux runs)	Comportement documenté et détecté : les Settings signalent les automatisations existantes qui lancent déjà cet agent sur le même événement
La file autonome affame l'interactif sur le mono-processus	Priorité stricte à l'interactif dans la file partagée ; plafond de concurrence réglable ; les runs autonomes sont interruptibles proprement
La duplication « perd » des accès sans le dire	Le rapport de duplication est un livrable du ticket, pas un log : affiché, téléchargeable
Les créateurs accordent « tout le workspace partagé » par facilité	L'interface propose par défaut un périmètre vide et nomme le risque ; l'Insights montre ce que l'agent a réellement lu (écart visible entre accordé et utilisé)

11. Ordre d'exécution

T01 ── T02 ──┬── T03 ── T04
             ├── T05 ── T06
             └── T08 ── T09 ── T10
T07 après T03 ; T11 après T02 et T08 ; T12 après T03 ; T13 en dernier.

Chemin critique : T01 → T02 → T08 → T09. Tant que le test de fuite (T02) n'est pas vert, aucun déclencheur événementiel ne doit être activable en production — c'est la porte de la phase.

12. Définition de « terminé »

Critères du §9 verts, dont le test de fuite ; une semaine de fonctionnement autonome propre sur l'instance de test ; aide in-app (page agent, déclencheurs, accès) ; document parent annoté (« Phase 3 livrée ») avec les valeurs retenues (plafonds, profondeur de délégation).

---

Document de phase 3/5 — dépend des Phases 1 et 2 ; prépare la Phase 4.