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](#1-objectif)
2. [Périmètre](#2-périmètre)
3. [État d'entrée](#3-état-dentrée)
4. [Modèle de données — migration 41](#4-modèle-de-données--migration-41)
5. [Tickets de travail](#5-tickets-de-travail)
6. [API livrée par la phase](#6-api-livrée-par-la-phase)
7. [Comportements détaillés](#7-comportements-détaillés)
8. [Tests](#8-tests)
9. [Critères d'acceptation](#9-critères-dacceptation)
10. [Risques spécifiques et vigilance](#10-risques-spécifiques-et-vigilance)
11. [Ordre d'exécution](#11-ordre-dexécution)
12. [Définition de « terminé »](#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

```sql
-- 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 :

```sql
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

```text
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.*