flowdeck/docs/agents-skills-phase-4-actions-externes-fichiers-credits.md

Agents & Skills pour Flowdeck — Phase 4 : Agir dehors, travailler sur fichiers, compter

Champ	Valeur
Phase	4 sur 5 — la parité complète (dernière phase de fonctionnalité)
Document parent	architecture-agents-skills-notion-flowdeck.md v1.1 — en particulier §3.2 et §3.5–3.6, §10.6–10.7, §14, §15, §16.3–16.5
Version	1.0 — 9 octobre 2026
Auteur	Spark, pour Bruno
Statut	Prêt à implémenter après la Phase 3
Prérequis	Phase 3 (dispatcher, régime allowlist, approbations en autonome)
Migrations créées	42 (modèles & usage) et 43 (fichiers des runs)
Débloque	Phase 5 (optimisations sur données réelles d'usage et de coûts)

Résultat visible à la fin de cette phase. L'Agent agit dans le monde extérieur, sous confirmation : il cherche et poste dans Slack (nouveau connecteur), rédige/envoie/archive dans Gmail, trouve un créneau entre participants avec des suggestions classées et une grille, puis réserve ; il gère l'Inbox Flowdeck par le chat ; les Custom Agents gagnent des déclencheurs messagerie/courriel/calendrier. Dans le chat, on dépose des fichiers (PDF, CSV, XLSX, DOCX, PPTX, ZIP) que l'Agent lit, analyse avec du code sandboxé, transforme en pages ou bases, et il rend des fichiers téléchargeables. Et tout est compté : modèles autorisés par surface, modèles premium activés par l'admin, allocation d'usage, crédits, limites par membre et par agent, tableaux d'usage.

---

Table des matières

1. Objectif
2. Périmètre
3. État d'entrée
4. Modèle de données — migrations 42 et 43
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

Trois chantiers indépendants mais livrés ensemble parce qu'ils partagent la même exigence — ne jamais agir ou dépenser dans l'ombre :

1. Les actions externes (écarts E8 du parent) : chaque écriture hors Flowdeck est un outil de classe EXTERNAL_WRITE, confirmé ou couvert par une politique explicite, et journalisé comme les écritures internes.
2. L'espace fichiers (écart E9 + E10) : l'Agent cesse d'être limité au texte du workspace ; il ingère, calcule et produit, en assemblant importers, sandbox Workers et exports existants.
3. La comptabilité (écart E13) : les modèles deviennent gouvernés (autorisés par surface, premium activés) et chaque run a un coût calculé depuis un journal — c'est ce qui rend les deux premiers chantiers soutenables en production.

2. Périmètre

2.1 Inclus

• Contrat « agent-ready » pour les connecteurs (sources / outils de lecture / outils d'écriture / déclencheurs / identité) appliqué à tous les connecteurs livrés dans la phase.
• Connecteur Slack natif : connexion workspace (admin) + connexion de compte (utilisateur) ; outils de l'Agent personnel (identité utilisateur) et des Custom Agents (canaux accordés) ; déclencheurs message/réaction/mention.
• Google/MS365 : second consentement pour les scopes d'écriture ; outils Gmail (brouillon, envoi, archive, étiquettes, corbeille, désabonnement) ; outils calendrier (trouver un créneau + grille, créer, préparer, déplacer si organisateur) ; dépôt d'un fichier produit dans Drive/Files.
• Outils Inbox : lire/résumer, regrouper, marquer, archiver (dont en masse avec confirmation et compte exact) ; bornes documentées (pas de décision d'approbation, pas de création de notification, pas de réglages).
• Promotion des connecteurs Discord/Telegram/Teams au contrat agent-ready (canaux comme sources, cibles d'envoi, déclencheurs).
• Déclencheurs Phase 4 dans le dispatcher de la Phase 3 : message.posted, message.reaction, message.mention (par connecteur), mail.received, calendar.event_created/updated/cancelled.
• Classe d'outils EXTERNAL_WRITE dans la gouvernance : approbation par défaut, politiques pré-approuvées bornées (outil × cible) pour les Custom Agents, envoi de courriel toujours confirmé pour l'Agent personnel.
• Espace fichiers : dépôt dans le chat (trombone + glisser-déposer), agent_run_files, extraction par les importers, profil tabulaire, outil run_code_on_data sur la sandbox Workers avec montage borné, produce_file (XLSX, PDF, DOCX, PPTX), create_collection_from_file, tableau interactif de résultats dans le chat, rétention et purge.
• Migration 42 : workspace_ai_settings (modèles autorisés par surface, premium, modèle par défaut, limites, qui peut créer des agents, accès web par défaut), ai_usage_ledger ; service usage_meter ; tarification par modèle en réglages ; allocation d'usage (fenêtre calculée depuis le journal) ; limites membre et agent appliquées au routage de modèle ; tableaux d'usage (admin) et coût par run dans Activity ; webhooks de seuil de crédits.
• Application de credit_limit_monthly (Phase 3, colonne créée) et de who_can_create_agents.

2.2 Exclu

• Le serveur MCP Flowdeck (chantier séparé déjà documenté côté Flowdeck) et le SDK d'agents externe → Phase 5 (préparation seulement).
• Les connecteurs métier nouveaux au-delà de Slack (CRM, billetterie…) : le contrat agent-ready et le client MCP les couvrent sans code dédié.
• La refacturation réelle : les crédits sont une unité de compte interne (question ouverte Q1 du parent : quotas de gouvernance ou reflet de coûts fournisseurs — le journal livré ici sert les deux, seuls les taux changent).

3. État d'entrée

Élément	État
Connecteurs natifs (gitea, github, web, google, ms365) + personnels (custom, discord, telegram, mcp) ; OAuth Google/MS365 lecture seule, refresh auto, secrets Fernet	Existants (§16.4 de l'architecture)
connectors.py (fetch gardé SSRF), oauth_connectors.py, client MCP complet	Existants
Importers (PDF, DOCX, CSV/XLSX, ZIP via pipeline) ; exports (XLSX, PDF, DOCX…)	Existants (§21)
Workers sandboxés (AST, pas de réseau/filesystem, timeout 30 s, budget journalier)	Existants (§19.2)
Service de notifications + Inbox sidebar	Existant (§19.4)
agent_approvals, webhooks agent.*, dispatcher + régime allowlist, agent_runs avec credits à 0	Livrés Phases 2–3
llm_config (23 fournisseurs, précédence 4 niveaux)	Existant — les taux par modèle s'y ajoutent

4. Modèle de données — migrations 42 et 43

-- Migration 42 — Phase 4 (gouvernance modèles & usage)
CREATE TABLE workspace_ai_settings (
    workspace_id INTEGER PRIMARY KEY REFERENCES workspaces(id),
    allowed_models_personal_json TEXT DEFAULT '[]',  -- [] = tous les modèles configurés
    allowed_models_custom_json   TEXT DEFAULT '[]',
    premium_models_json          TEXT DEFAULT '[]',  -- activés par l'admin
    default_model TEXT,
    member_credit_limit INTEGER,        -- crédits / membre / mois ; NULL = illimité
    allowance_json TEXT DEFAULT '{}',   -- {window_hours, volume} de l'allocation incluse
    who_can_create_agents TEXT DEFAULT 'everyone',  -- 'everyone' | 'admins'
    web_access_default INTEGER NOT NULL DEFAULT 0,
    updated_by INTEGER REFERENCES users(id), updated_at TEXT
);
CREATE TABLE ai_usage_ledger (
    id INTEGER PRIMARY KEY,
    workspace_id INTEGER NOT NULL,
    run_id INTEGER REFERENCES agent_runs(id),
    user_id INTEGER REFERENCES users(id),
    agent_id INTEGER REFERENCES agents(id),
    provider TEXT, model TEXT,
    tokens_in INTEGER DEFAULT 0, tokens_out INTEGER DEFAULT 0,
    credits REAL NOT NULL DEFAULT 0,
    bucket TEXT NOT NULL DEFAULT 'allowance',   -- 'allowance' | 'premium'
    created_at TEXT NOT NULL
);
-- Index : (workspace_id, created_at), (user_id, created_at), (agent_id, created_at).
-- Taux par modèle : table de correspondance dans les réglages (JSON versionné),
--   {"<provider>/<model>": {"in_per_1k": x, "out_per_1k": y, "premium": bool}}
--   le mode offline a un taux de 0 par construction.

-- Migration 43 — Phase 4 (espace fichiers)
CREATE TABLE agent_run_files (
    id INTEGER PRIMARY KEY,
    run_id INTEGER REFERENCES agent_runs(id),
    conversation_id INTEGER REFERENCES agent_conversations(id),
    direction TEXT NOT NULL,          -- 'input' | 'output'
    name TEXT NOT NULL, mime TEXT, size INTEGER,
    storage_path TEXT NOT NULL,       -- data/uploads/agent-files/<conversation_id>/…
    created_at TEXT NOT NULL,
    expires_at TEXT                   -- NULL = livrable conservé par l'utilisateur
);

Règles : le ledger est append-only (aucune correction d'écriture — un ajustement est une ligne négative motivée, créée par un admin) ; les agrégats (allocation consommée, crédits du mois) sont toujours calculés depuis le ledger ; agent_run_files ne stocke jamais le contenu en base.

5. Tickets de travail

Le contrat connecteur et Slack

P4-T01 — Contrat agent-ready et registre des capacités. Fichiers : app/services/connectors.py (extension), registre dans tool_registry.py. Travail : formaliser la déclaration de capacités du parent §14.1 (sources, read_tools, write_tools, triggers, identité) ; le sélecteur All sources (Phase 2) et le Tool Registry consomment cette déclaration au lieu de listes codées en dur ; un connecteur sans déclaration reste utilisable en lecture comme aujourd'hui (compatibilité). Acceptation : brancher un connecteur de test déclaratif suffit à le faire apparaître dans All sources et dans les outils, sans autre code.

P4-T02 — Connecteur Slack natif : connexions. Fichiers : catalogue des connecteurs natifs, flux OAuth (patron des natifs existants). Travail : connexion workspace par un admin (préalable aux agents) stockée comme les autres connecteurs workspace ; connexion compte par utilisateur pour l'Agent personnel (jeton utilisateur, Fernet) ; écran de statut distinguant les deux niveaux ; révocation indépendante. Acceptation : sans connexion workspace, les déclencheurs Slack d'agents sont refusés proprement ; sans connexion compte, l'Agent personnel signale le manque au lieu d'échouer en cours de run.

P4-T03 — Outils Slack. Travail : lecture (chercher des personnes ; lire canaux publics/privés et fils dans la visibilité du jeton utilisé ; lire les fichiers partagés récents) et écritures EXTERNAL_WRITE (poster, répondre en fil, éditer ses propres messages, réagir) ; identité utilisateur pour l'Agent personnel (les messages portent son nom), identité agent pour les Custom Agents limitée aux canaux présents dans agent_access (extension de resource_type à 'channel') ; l'outil d'édition refuse tout message non émis par la même identité. Acceptation : test de borne — avec un jeton limité à un canal, aucune lecture ni écriture hors de ce canal n'est possible, y compris par recherche.

P4-T04 — Déclencheurs Slack et messageries existantes. Travail : émission vers le bus — Slack : message.posted (filtres mots-clés, inclusion des fils), message.reaction, message.mention ; indicateur d'activité dans le canal pendant le run (show_typing du déclencheur) ; promotion de Discord/Telegram/Teams au même contrat : leurs événements existants alimentent les mêmes event_name, leurs canaux deviennent des ressources accordables et des cibles de channel_post. Acceptation : UC-05 (rapport horaire posté) et un triage sur mention fonctionnent sur Slack et sur un connecteur de messagerie préexistant, sans code de dispatcher différent.

Écritures Google / Microsoft 365 et Inbox

P4-T05 — Second consentement d'écriture et outils Gmail. Fichiers : app/services/oauth_connectors.py. Travail : demande de scopes d'écriture séparée et révocable indépendamment (l'état « lecture seule » reste le défaut et un état stable) ; outils : mail_draft, mail_send, mail_archive, mail_label, mail_trash (+ désabonnement d'expéditeur) sur Gmail et, en parité de contrat, Outlook/Graph ; l'envoi est toujours confirmé pour l'Agent personnel (carte d'approbation montrant destinataires, objet, corps complet) ; pour les Custom Agents, l'envoi exige une politique pré-approuvée explicite par boîte. Acceptation : aucun envoi ne part sans que le contenu exact envoyé soit celui qui a été approuvé (hash du contenu dans la demande d'approbation, revérifié à l'exécution).

P4-T06 — Outils calendrier d'agent. Travail : calendar_find_time (croise les disponibilités des participants sur les calendriers connectés, rend des suggestions classées avec les motifs du classement — chevauchements évités, préférences horaires — et la matière de la grille interactive rendue dans le panneau : créneaux × participants, sélection en un clic) ; calendar_create_event (organisateur = l'utilisateur ou l'agenda accordé) ; calendar_prep (assemble événement, participants, pages liées, dernière note de réunion) ; calendar_move/cancel bornés aux événements dont l'acteur est organisateur ; en multi-calendriers : calendrier par défaut, sinon question à l'utilisateur. Acceptation : UC-09 (calendrier) passe ; déplacer un événement d'un tiers est refusé avec le motif, pas tenté.

P4-T07 — Outils Inbox. Fichiers : service de notifications existant (ajout d'une API de service consommable par les outils, pas d'accès direct aux tables depuis le registre). Travail : inbox_read (résumé structuré : nouveau, à répondre, peut être effacé), inbox_group (type / statut / projet / page), inbox_mark, inbox_archive (masse comprise) ; confirmation obligatoire au-delà d'un seuil d'éléments (défaut proposé : 10) avec compte exact affiché ; bornes : les notifications d'approbation/demande d'accès sont signalées mais jamais décidées ; aucun outil de création de notification ni de modification des préférences. Acceptation : « archive tout ce qui est lu » sur une Inbox de test de 250 éléments archive exactement les éléments lus, après une confirmation affichant « 250 » — ni 249 ni 251 (test de comptage sur fixture).

P4-T08 — Classe EXTERNAL_WRITE dans la gouvernance. Fichiers : app/services/agent_policies.py, agent_approvals. Travail : quatrième classe d'outils ; par défaut approbation par action (le run passe en waiting_approval, carte dans le panneau ou dans Activity pour les runs autonomes) ; politiques pré-approuvées pour les Custom Agents : tuples (agent, outil, cible) accordés par un niveau full, révocables, expirant par défaut (durée réglable, défaut proposé : 90 jours) et affichés dans les Settings de l'agent ; toute écriture externe exécutée écrit dans agent_actions avec, quand le tiers le permet, l'action inverse (supprimer le message…) sinon la mention « non annulable ». Acceptation : il n'existe aucun chemin d'exécution d'un outil EXTERNAL_WRITE qui contourne soit l'approbation, soit une politique en vigueur (test par énumération des points d'entrée du registre).

Espace fichiers

P4-T09 — Dépôt et lecture de fichiers de conversation. Fichiers : routes de conversation (téléversement), nouveau app/services/agent_files.py, importers. Travail : dépôt par trombone et glisser-déposer ; validation (liste blanche de types alignée sur les importers, taille AGENT_FILE_MAX_MB) ; stockage sous data/uploads/agent-files/ ; outil read_uploaded_file : extraction texte (PDF/DOCX/PPTX), profil tabulaire (CSV/XLSX : colonnes, types devinés, aperçu), inventaire ZIP (pas d'extraction récursive, plafond décompressé) ; le LLM ne reçoit que résumés et aperçus, jamais le binaire. Acceptation : déposer le CSV d'UC-08 donne à l'Agent un profil fidèle (noms et types de colonnes, nombre de lignes exact).

P4-T10 — Calcul sandboxé et production de fichiers. Travail : run_code_on_data sur le moteur des Workers avec l'unique écart documenté (montage en lecture des fichiers de la conversation, répertoire de sortie en écriture, quotas renforcés) ; produce_file pour XLSX/PDF/DOCX/PPTX avec les bibliothèques d'export existantes ; cartes téléchargeables dans le message (GET …/files/{id}/download avec contrôle d'ACL de la conversation) ; create_collection_from_file via le pipeline d'import (déduplication comprise). Acceptation : UC-08 de bout en bout ; un code qui tente un accès réseau ou hors du montage est bloqué par la sandbox, et le run continue avec l'échec comme résultat d'outil.

P4-T11 — Tableau interactif de résultats dans le chat. Fichiers : panneau, outil query_collection formalisé (Annexe B du parent). Travail : quand un résultat d'outil est tabulaire (lignes × colonnes typées), le panneau le rend en tableau en lecture (tri client, ouverture de la ligne source) ; le tableau est un artefact du message, pas une collection ; plafond de lignes affichées avec mention du total. Acceptation : une question « quelles tâches en retard ? » rend le tableau sans ouvrir la base, et chaque ligne ouvre la bonne tâche.

P4-T12 — Rétention des fichiers. Travail : expires_at posé au dépôt (défaut AGENT_FILE_RETENTION_DAYS, 30 j) sauf pour les livrables que l'utilisateur épingle/conserve ; purge ajoutée au trash_purge_scheduler existant ; la suppression d'une conversation supprime ses fichiers et sa mémoire (règle du parent §16.6). Acceptation : après purge simulée, les métadonnées de run subsistent (nom, taille) mais aucun fichier expiré n'est téléchargeable.

Comptabilité et gouvernance des modèles

P4-T13 — usage_meter et journal d'usage. Fichiers : nouveau app/services/usage_meter.py, migration 42, extension de llm_config (taux par modèle). Travail : à la fin de chaque run (et, pour les runs longs, par paliers), écrire la ligne de ledger depuis agent_runs (tokens réels remontés par le client LLM) : bucket allowance si le modèle est inclus, premium sinon ; le taux zéro du mode offline est un cas de test permanent ; webhooks agent.credits.threshold aux seuils 50/80/100 % des limites concernées. Acceptation : la somme du ledger recoupe les tokens des agent_runs sur toute période de test ; aucun run terminé sans ligne (ou ligne à zéro explicitement offline).

P4-T14 — Modèles gouvernés : autorisés par surface, premium, replis. Travail : le routeur Auto (Phase 2) et les sélecteurs ne voient que les modèles autorisés pour la surface ; les premium exigent l'activation admin et puisent dans les crédits ; un modèle désactivé disparaît (grisé pendant la transition) et les agents qui l'utilisaient basculent au prochain run sur défaut/Auto (comportement annoncé dans les Settings de l'agent, pas silencieux pour son propriétaire : notification) ; à limite de crédits atteinte (membre ou agent), les modèles inclus continuent et les premium s'arrêtent avec un état explicite dans le run. Acceptation : retirer un modèle utilisé par un agent ne casse aucun run suivant et laisse une trace visible pour le propriétaire.

P4-T15 — Tableaux d'usage et réglages IA du workspace. Fichiers : page de réglages (section IA & Agents du parent §7.6). Travail : réglages de workspace_ai_settings (deux listes de modèles, premium, défaut, limites, who_can_create_agents appliqué, accès web par défaut) ; tableaux : usage par membre, par agent, par modèle (période, bucket, crédits), export CSV ; le coût (tokens + crédits) rejoint l'onglet Activity des agents et le détail d'un run du panneau. Acceptation : un admin répond en moins d'une minute, depuis l'interface, à « qui a dépensé quoi, sur quel modèle, cette semaine ? ».

6. API livrée par la phase

Route	Ticket
POST /api/agent/conversations/{id}/files · GET …/files/{fid}/download	T09/T10
GET/PUT /api/settings/ai (réglages IA du workspace, admin)	T15
GET /api/settings/ai/usage (+ ?format=csv)	T15
POST /api/agent/connectors/slack/connect (workspace et compte)	T02
Outils (pas des routes) : Slack, Gmail, calendrier, Inbox, fichiers	T03/T05/T06/T07/T09/T10
Webhooks : agent.credits.threshold ; champs credits dans agent.run.*	T13

7. Comportements détaillés

7.1 Confirmation : ce que l'utilisateur voit

Une demande d'approbation montre l'action exacte : pour un courriel, destinataires/objet/corps ; pour un message de canal, le canal et le texte ; pour une archive en masse, le compte et le critère. Approuver exécute ce contenu (hash revérifié pour le courriel) ; toute modification du contenu par l'Agent après coup exige une nouvelle approbation. Un refus laisse le run se terminer proprement avec le motif « refusé » dans la réponse.

7.2 Allocation, crédits, limites : les trois compteurs en pratique

Run démarre → modèle résolu (Phase 2/4)
  ├─ modèle inclus  → le run puise dans l'ALLOCATION (fenêtre glissante du workspace)
  │     allocation épuisée → le run est refusé proprement (« allocation épuisée,
  │     renouvellement à … »), sauf si des crédits peuvent prendre le relais (réglage)
  └─ modèle premium → le run puise dans les CRÉDITS
        limite membre ou limite agent atteinte → premium refusé, repli annoncé
        sur un modèle inclus (jamais d'arrêt sec quand un repli existe)
Fin du run → ligne de ledger (toujours), seuils vérifiés → webhooks éventuels

7.3 Identités externes — le tableau à ne jamais violer

Contexte	Jeton utilisé	Signature visible chez le tiers
Agent personnel → Slack/Gmail	Celui de l'utilisateur	L'utilisateur
Custom Agent → canaux accordés	Celui de l'app/du connecteur workspace	L'agent (nommé)
Custom Agent → Gmail	Uniquement via politique pré-approuvée par boîte	La boîte accordée
Tout agent → calendrier	Organisateur = l'utilisateur ou l'agenda accordé	L'organisateur réel

7.4 Ce que les fichiers ne sont pas

Un fichier déposé est une donnée, jamais une consigne : son contenu est délimité comme les autres contenus lus (§16.4 du parent). Un tableur contenant « envoie ce fichier à… » ne déclenche rien d'autre qu'un éventuel résultat d'outil refusé par la gouvernance.

8. Tests

#	Niveau	Cas
T-01	Intégration	Contrat connecteur : un connecteur de test déclaratif apparaît dans All sources et fournit ses outils
T-02	Intégration	Slack borné : lecture/écriture hors canal accordé impossibles (jeton restreint)
T-03	Intégration	Envoi Gmail : contenu approuvé = contenu envoyé (hash) ; refus = rien n'est parti
T-04	Intégration	calendar_find_time sur disponibilités de fixture : classement explicable, grille cohérente ; déplacement d'un événement tiers refusé
T-05	Intégration	Inbox : archive en masse au compte exact après confirmation ; notifications d'approbation jamais décidées
T-06	Intégration	Énumération des points d'entrée EXTERNAL_WRITE : aucun ne contourne approbation/politique
T-07	Intégration	UC-08 complet en mode offline (extraction et production déterministes, le calcul par un « faux » code sandboxé inclus)
T-08	Intégration	Sandbox : tentative réseau et tentative de sortie du montage bloquées
T-09	Intégration	Ledger : somme par période = somme des runs ; run offline = ligne à 0 ; allocation épuisée = refus propre
T-10	Intégration	Limite membre atteinte : premium refusé avec repli annoncé, modèles inclus toujours utilisables
T-11	Intégration	Modèle retiré : l'agent bascule, le propriétaire est notifié, Activity le montre
T-12	E2E	Déposer un CSV dans le chat, obtenir le tableau de résultats et le XLSX produit téléchargeable
T-13	E2E	Trouver un créneau à trois et réserver depuis la grille
T-14	Non-régression	Les connecteurs en lecture seule fonctionnent inchangés pour les utilisateurs sans consentement d'écriture

9. Critères d'acceptation

• UC-08, UC-09 et UC-10 passent de bout en bout.
• Aucune écriture externe sans approbation ou politique pré-approuvée en vigueur (T-06).
• Aucun run sans ligne au ledger ; les tableaux d'usage recoupent les runs.
• Un Custom Agent déclenché par une mention dans un canal accordé répond dans ce canal et nulle part ailleurs.
• La parité fonctionnelle du document parent §3 est atteinte : la Phase 5 n'a plus de fonctionnalité à ajouter, seulement à durcir.

10. Risques spécifiques et vigilance

Risque	Vigilance
Consentements OAuth d'écriture trop larges demandés d'un bloc	Le second consentement est séparé, nommé par domaine (courriel ou calendrier), et la lecture seule reste un état complet et digne
Un envoi approuvé puis modifié par une reprise de run	Hash du contenu dans l'approbation (T05) ; un run repris après refus repart d'une demande nouvelle
Explosion des coûts par un déclencheur de messagerie bavard	Les plafonds de la Phase 3 s'appliquent, plus les budgets crédits désormais réels ; l'indicateur d'activité (show_typing) est désactivable et les filtres mots-clés sont proposés par défaut
Le montage fichiers de la sandbox devient une brèche	C'est l'unique écart au modèle Workers : revue de sécurité dédiée avant T10, chemins canonisés et vérifiés sous le répertoire de la conversation, quotas bas par défaut
L'allocation « fenêtre glissante » mal comprise crée des refus surprenants	L'état courant de l'allocation est visible par l'utilisateur dans ses réglages, avec l'heure de renouvellement calculée depuis le ledger — jamais un message « réessayez plus tard » sans date
Slack change ses API/scopes	Le connecteur isole les appels derrière son service ; les tests d'intégration Slack utilisent un double d'API, les tests réels sont manuels et listés dans la grille de test

11. Ordre d'exécution

T01 ──┬── T02 ── T03 ── T04
      ├── T05 ──┐
      ├── T06   ├── T08 (gouvernance, avant toute mise en service des écritures)
      └── T07 ──┘
T09 ── T10 ── T11 ;  T12 après T10
T13 ── T14 ── T15
Les trois chantiers (externe / fichiers / comptabilité) sont parallélisables,
mais T08 et T13 sont les portes : pas d'écriture externe en production sans
gouvernance complète, pas de premium sans comptage.

12. Définition de « terminé »

Critères du §9 verts ; revue de sécurité passée sur EXTERNAL_WRITE et sur le montage fichiers ; deux semaines de fonctionnement avec le ledger en observation (écarts ledger/runs à zéro) ; document parent annoté (« Phase 4 livrée — parité atteinte ») ; aide in-app complète pour les nouveaux réglages.

---

Document de phase 4/5 — dépend des Phases 1 à 3 ; la Phase 5 ne fait que durcir et étendre.