Use this file to discover all available pages before exploring further.
Objectif : Construire un Hub de connecteurs alimenté par l’IA — Autonome (assistant de portail), Copilote (intégré au système hôte), Hub (orchestration centrale inter-systèmes).Principes : Agnostique des fournisseurs (pas de verrouillage des fournisseurs), abstraction minimale, protocole en premier, connecteur en premier (l’intégration est la valeur fondamentale).
FIM One est un Hub de Connecteurs IA qui propose trois modes progressifs :
Standalone → Votre propre assistant IA (Portal)Copilot → IA intégrée dans un système hôte (iframe / widget / embed)Hub → Orchestration centrale inter-systèmes (Portal / API)
Le mode Hub est le différenciateur clé. Les clients entreprise disposent de systèmes hérités — ERP, CRM, OA, finance, HR — qui doivent communiquer entre eux via l’IA :Stratégie GTM : Land and Expand
Étape
Mode
Ce qui se passe
Land
Copilot
Intégrer dans un système, prouver la valeur dans leur interface utilisateur
Bugs tracés qui sont reproductibles en production mais pas encore corrigés. Chaque entrée nomme le symptôme, la zone de surface suspecte et la solution de contournement (le cas échéant). Les éléments passent à une section de version une fois qu’un correctif est défini et planifié.
L’éditeur d’agent affiche un avertissement de modifications non enregistrées sans aucune modification. L’ouverture d’un agent existant via /agents/[id] et le clic immédiat sur le bouton retour déclenchent la boîte de dialogue « Modifications non enregistrées » même si aucun champ n’a été touché. La vérification de modification compare 20+ champs par rapport à la charge utile de l’agent chargée, donc une asymétrie de défaut entre l’initialisation d’état et la comparaison de modification suffit à causer une discordance fantôme — la suspicion actuelle porte sur l’un des champs imbriqués model_config_json / notification / approbation-routage, possiblement à partir de la normalisation undefined vs null vs "". Se reproduit particulièrement sur les agents à portée organisationnelle. Solution de contournement : ignorer la boîte de dialogue (Discard and leave) — aucune perte de données puisque rien n’a réellement changé. Une tentative de correction (cb40c86a) a supprimé un scintillement de badge orphelin connexe sur les sélecteurs de ressources mais n’a pas résolu ce problème.
L’enregistrement d’une modification d’agent peut échouer avec Input should be 'initiator', 'agent_owner' or 'org_members'. Pydantic rejette le champ confirmation_approver_scope à la limite PUT /api/agents/{id} même si chaque valeur stockée dans la base de données est l’un des trois littéraux valides. Suspicion : le cast frontend as "initiator" | "agent_owner" | "org_members" est une promesse au moment de la compilation uniquement, donc une chaîne héritée ou inattendue au moment de l’exécution (possiblement à partir d’un modèle, d’une importation ou d’une migration plus ancienne) peut passer par setConfirmationApproverScope et être renvoyée textuellement. Solution de contournement : resélectionner explicitement une valeur dans la liste déroulante Approbation → Portée de l’approbateur avant d’enregistrer.
L’arrêt et la nouvelle tentative du terrain de jeu affichent des artefacts visuels transitoires qu’une actualisation de page efface toujours. Trois sources de rendu concurrentes — activeConversation.messages (snapshot DB), le flux SSE messages et l’espace réservé optimiste pendingQuery — ne sont pas réduites à un seul état dérivé, donc entre le clic sur « Retry » et l’arrivée de la réponse de l’assistant appairée, l’interface utilisateur peut (a) brièvement afficher la même requête deux fois dans la fenêtre pré-flux, (b) supprimer les bulles utilisateur orphelines antérieures de l’historique de nouvelle tentative tandis que hasLiveMessages est vrai et avant le rechargement de l’instantané, et (c) scintiller dans la fenêtre étroite entre l’événement SSE « done » et l’actualisation selectConversation suivante. Les données ne sont jamais perdues — chaque message utilisateur (y compris les tentatives abandonnées) est conservé dans conversation.messages, porté dans l’appel LLM suivant via normalize_alternating_messages et rendu correctement après actualisation via HistoryTurn.orphanUserContents introduit dans le correctif de rendu 48ba08c6. Pour le contexte, l’interface Web propre de Claude présente une classe analogue de bug — l’arrêt au milieu d’une réponse et l’envoi immédiat d’une requête de suivi crée parfois la requête de suivi comme une branche d’édition sœur de la première requête plutôt que de l’ajouter comme un nouveau tour — c’est donc un problème connu difficile dans les conceptions optimiste-UI + SSE + historique-persisté, pas un défaut spécifique à FIM One. Un correctif approprié nécessite de réduire les trois sources de rendu à un seul état dérivé ; reporté jusqu’à une refonte plus large de la machine d’état du terrain de jeu.
Détection automatique OAuth depuis window.location
Support de la réflexion étendue / raisonnement (LLM_REASONING_EFFORT, LLM_REASONING_BUDGET_TOKENS) pour OpenAI série o, Gemini 2.5+, Claude
Activation/désactivation par outil administrateur (outils désactivés exclus du chat à l’exécution)
Gestion des serveurs MCP déplacée vers la page Connecteurs
Support de base de données double : SQLite (par défaut sans configuration) + PostgreSQL (production) ; Docker Compose provisionne automatiquement PostgreSQL
Page de documentation de configuration des modèles avec configuration de la réflexion étendue par fournisseur
Protocole SSE v2 : diffusion de réponses en temps réel avec champs delta_reasoning, usage, et événements done/suggestions/title/end séparés ; taille du pool SQLite 5 -> 20
Expansion AI Builder : 7 nouveaux outils de construction (GetSettings, TestConnection, ImportOpenAPI pour connecteurs ; ListConnectors, AddConnector, RemoveConnector, SetModel pour agents), drapeau is_builder sur les agents, actualisation automatique du prompt du constructeur, protection SSRF
Frontend SSE v2 : curseur à point pulsant en continu, snapshots de re-plan DAG sous forme de cartes réductibles, mise en page DAG découplée des états d’étape
Page de documentation du concept AI Builder avec guides de construction de connecteurs et d’agents
Système d’organisation : CRUD complet avec adhésion basée sur les rôles (propriétaire/administrateur/membre), interface de gestion administrateur
Visibilité des ressources à trois niveaux (personnel/org/global) pour les agents, connecteurs, bases de connaissances, serveurs MCP
API Publier/Dépublier pour tous les types de ressources ; délégation de propriétaire pour les agents publiés
Point de terminaison administrateur set-visibility (remplace clone-to-global) ; assistant de requête build_visibility_filter() unifié
Connecteurs de base de données (Phase 1-3) : accès SQL direct à PG/MySQL/Oracle/SQL Server + BD héritées chinoises ; introspection de schéma, annotation IA, exécution de requête en lecture seule, identifiants chiffrés, 3 outils par connecteur (list_tables, describe_table, query)
Centre d’évaluation : évaluation quantitative de la qualité des agents — CRUD d’ensemble de test (prompt + comportement attendu + assertions), exécutions d’éval (exécution parallèle + évaluateur LLM + résultats par cas réussi/échoué/latence/jeton), visionneuse de résultats avec interrogation automatique ; migration r8t0v2x4z567
Trois rôles de modèle (Général/Rapide/Raisonnement) avec isolation de configuration env par niveau ; le modèle rapide n’hérite plus des paramètres du modèle principal
Classe de données StepOutput remplaçant les résultats d’étape en chaîne simple pour les données structurées et la transmission d’artefacts
Cache d’outil pour l’exécution DAG — appels d’outil identiques mis en cache par exécution avec prévention du verrouillage asynchrone stampede (DAG_TOOL_CACHE)
Vérification LLM par étape avec 1 nouvelle tentative en cas d’échec (DAG_STEP_VERIFICATION)
Routage automatique : LLM rapide classe les requêtes comme ReAct ou DAG ; point de terminaison /api/auto ; basculement de mode 3 voies frontend (AUTO_ROUTING)
Organisation du marché fantôme + Abonnements aux ressources : Organisation du marché intégré (fantôme, pas d’adhésion automatique) remplace l’organisation de plateforme ; ressources découvertes via navigation sur le marché et explicitement souscrites (modèle pull) ; API de marché pour s’abonner aux ressources partagées ; la publication sur le marché nécessite toujours un examen ; tableau des abonnements aux ressources ; partage de ressources basé sur l’organisation remplaçant la visibilité globale
Découverte automatique d’agent et liaison de sous-agent : drapeau discoverable sur les agents ; liste blanche sub_agent_ids ; CallAgentTool pour déléguer des tâches à des agents spécialisés
Identifiants du serveur MCP + Remplacement par utilisateur : tableau mcp_server_credentials ; point de terminaison PUT /api/mcp-servers/{id}/my-credentials ; drapeau allow_fallback pour le comportement de secours des identifiants
Basculement connecteur/KB : POST /api/connectors/{id}/toggle et POST /api/knowledge-bases/{id}/toggle pour suspendre/reprendre les ressources
Conversations KB autonomes : champ kb_ids sur les conversations pour le chat KB direct sans liaison d’agent
v0.8 (2026-03-20) — Configuration déclarative des connecteurs + Divulgation progressive
Connecteurs de base de données: accès SQL direct (PostgreSQL, MySQL, Oracle) (livré en v0.7.x — Phase 1-3)
RBAC: contrôle d’accès aux connecteurs par utilisateur/rôle (livré en v0.7.x — système org + visibilité à trois niveaux)
Chiffrement des identifiants de connecteur + remplacement par utilisateur: table connector_credentials, chiffrement Fernet via CREDENTIAL_ENCRYPTION_KEY, drapeau allow_fallback, points de terminaison GET/PUT/DELETE /my-credentials, résolution des identifiants par utilisateur dans le chargement des outils de chat
Interface d’examen de publication: système d’examen de publication au niveau de l’organisation — basculement d’examen par organisation, ReviewsSheet avec flux d’approbation/rejet, badges de statut sur les cartes de ressources, avis d’examen dans la boîte de dialogue de publication, renvoi pour les ressources rejetées
Divulgation progressive des connecteurs (Phase 1-2): un seul ConnectorMetaTool remplace les outils par action; le message système reçoit uniquement des stubs légers (nom + description d’une ligne, ~30 tokens/connecteur vs ~250 tokens/action); l’agent appelle discover(connector) pour charger le schéma d’action complet à la demande — le schéma ne se charge que lorsque le modèle sélectionne un connecteur, maintenant le préfixe du message stable pour la mise en cache. Suit le modèle de chargement d’outils différé courant dans les frameworks d’agents modernes. Sous-commande execute; drapeau de fonctionnalité pour la compatibilité rétroactive.
Système de compétences d’agent + Instructions compactes: Chargement à la demande des instructions de compétences pour les agents — modèle Skill (nom, contenu/SOP, scripts optionnels) attaché aux agents; référencé dans le message système par nom uniquement (~10 tokens/compétence); l’agent appelle read_skill(name) pour charger le contenu complet à la demande. Réduit le coût des tokens d’instruction par conversation d’environ 80% tout en permettant des bibliothèques SOP plus riches. Homologue de la divulgation progressive de ConnectorMetaTool appliquée au niveau des instructions. Active la différenciation de l’histoire “指令 + 工具 + 技能”. Ajoute également le champ compact_instructions au modèle Agent — liste de priorités de compression par agent injectée dans ContextGuard lors de la compression (par exemple, “préserver les ID de commande et les montants, supprimer les réponses API brutes”), remplaçant l’invite générique statique actuelle. Suit la convention des instructions compactes largement adoptée dans les frameworks d’agents modernes.
Import/export de connecteurs: partage de modèles de connecteurs
Fork de connecteur: cloner et personnaliser les connecteurs existants
Nœuds de phase 2 du flux de travail: Iterator, Loop, VariableAggregator, ParameterExtractor, ListOperation, Transform, DocumentExtractor, QuestionUnderstanding, HumanIntervention — 9 types de nœuds avancés avec frontend + backend complets + 150 nouveaux tests (275 au total). Nouvelle tentative de nœud avec backoff exponentiel, évaluation d’expression sécurisée. Panneau de statistiques avec barre de taux de réussite. 12 modèles intégrés. Menu contextuel du volet (Coller, Sélectionner tout, Ajuster la vue, Disposition automatique).
Nœuds de phase 3 du flux de travail: SubWorkflow + ENV — 2 nouveaux types de nœuds (25 nœuds au total), 14 nouveaux tests (306 au total), 14 modèles intégrés. SubWorkflow: exécuteur de flux de travail imbriqué complet avec support de base de données, sélection de flux de travail cible, mappage de variables et limite de profondeur configurable pour éviter la récursion infinie. ENV: lit les variables d’environnement chiffrées avec sélecteur de clé et valeurs par défaut de secours. Frontend complet (composants de nœud, panneaux de configuration, entrées de palette, couleurs de minimap). Panneau de statistiques d’exécution par nœud (taux de réussite, durées, comptages d’échecs triés du pire au premier). Client API getNodeStats + type NodeStatEntry. Boîte de dialogue des raccourcis clavier (touche ?).
Déclencheurs planifiés du flux de travail: Configuration cron par flux de travail avec fuseau horaire, entrées par défaut et calcul de la prochaine exécution. Boutons cron prédéfinis, 30 tests de déclenchement.
Déclencheurs API du flux de travail: Clés API publiques par flux de travail (préfixe wf_) pour l’exécution externe sans authentification utilisateur, avec limitation de débit. Boîte de dialogue de gestion des clés API avec génération/régénération/révocation, URL de déclenchement et exemples cURL/JS.
Exécution par lot du flux de travail: POST /batch-run avec jusqu’à 100 ensembles d’entrée, parallélisme configurable (1-10), résultats par élément réductibles, export JSON. 14 tests d’exécution par lot.
Visionneuse du journal d’exécution du flux de travail: Flux d’événements SSE chronologique en temps réel dans le panneau d’exécution avec horodatages, badges codés par couleur et bascules de filtre par type d’événement.
Statistiques d’exécution du flux de travail: Le backend récupère par lot les comptages d’exécution et les taux de réussite via la sous-requête GROUP BY; le frontend affiche les statistiques sur les cartes de flux de travail avec des indicateurs de taux de réussite codés par couleur.
Démon du planificateur de flux de travail: Service asynchrone en arrière-plan interrogeant tous les 60 secondes les flux de travail basés sur cron dus. Support du fuseau horaire Croniter, concurrence par sémaphore, suivi de last_scheduled_at, livraison de webhook. 14 tests.
Résolveur de conflits d’import de flux de travail: Détecte les références d’agent/connecteur/KB/MCP non résolues lors de l’import. Requêtes DB par lot avec filtrage de visibilité, avertissements toast frontend. 17 tests.
Exécution de nœud de test du flux de travail: Test isolé de nœud unique avec variables fictives, intégré dans l’éditeur (bouton Test du panneau de configuration + menu contextuel). 23 tests.
Diff de version du flux de travail: Comparaison de blueprint côte à côte avec détection de changement de nœud/arête, indicateurs codés par couleur (ajouté/supprimé/modifié).
Gestion des exécutions du flux de travail: Supprimer les exécutions individuelles (DELETE /runs/{run_id}) et effacer toutes les exécutions terminées (DELETE /runs), avec boîtes de dialogue de confirmation frontend.
Superposition de relecture d’exécution du flux de travail: Bouton “Afficher sur le canevas” dans l’historique d’exécution pour superposer les résultats d’exécution passés sur le canevas, affichant le statut et la sortie par nœud sans réexécution.
Favoris/épinglage du flux de travail: Étoile/épingle des flux de travail en haut de la liste avec persistance localStorage.
Export de l’historique d’exécution du flux de travail: Exporter l’historique d’exécution en tant que téléchargement de fichier JSON avec métadonnées d’exécution complètes et résultats par nœud.
Gestion des flux de travail administrateur: Onglet du panneau administrateur pour gérer tous les flux de travail entre les utilisateurs — lister, basculer actif/inactif, supprimer avec confirmation. Points de terminaison par lot pour supprimer, basculer et publier avec journalisation d’audit.
Système de modèles de flux de travail: Modèle ORM WorkflowTemplate avec CRUD administrateur, API de listing/clone public et 5 modèles de semences insérés automatiquement au premier démarrage.
Badges de validation en ligne du flux de travail: ValidationBadge en temps réel par nœud sur le canevas avec info-bulles d’erreur/avertissement pour un retour visuel immédiat lors de l’édition.
Visionneuse de trace d’exécution du flux de travail: Visionneuse de trace basée sur la chronologie avec paramètre trace_level du moteur et snapshots de variables par nœud pour le débogage pas à pas.
Limitation de débit et délai d’expiration du flux de travail: WorkflowRateLimiter par utilisateur (fenêtre glissante 10 exécutions/min, 3 concurrentes) et délai d’expiration global par défaut de 10 minutes.
Système de blueprint de flux de travail: Éditeur de flux de travail visuel pour concevoir et exécuter des blueprints d’automatisation multi-étapes — modèles ORM Workflow / WorkflowRun, CRUD complet + API d’exécution SSE, import/export, duplication, point de terminaison de validation de blueprint, WorkflowEngine avec tri topologique + concurrence basée sur sémaphore + branchement conditionnel et 12 types de nœuds (Start, End, LLM, ConditionBranch, QuestionClassifier, Agent, KnowledgeRetrieval, Connector, HTTPRequest, VariableAssign, TemplateTransform, CodeExecution), VariableStore avec interpolation {{node_id.output}} et espace de noms env.*, stratégies d’erreur par nœud (STOP_WORKFLOW / CONTINUE / FAIL_BRANCH) avec délai d’expiration par nœud et interface de configuration avancée, éditeur visuel React Flow v12 avec palette glisser-déposer + panneau de configuration de nœud + combobox de sélecteur de variable + ajouter-nœud-sur-arête + disposition automatique (ELK.js) + feuille d’historique d’exécution, conception de nœud compact de style Dify avec statut d’exécution basé sur anneau et transitions d’arête animées, 4 modèles de démarrage intégrés (Chaîne LLM simple, Routeur conditionnel, QA augmenté par connaissance, Pipeline API HTTP) avec boîte de dialogue de sélecteur de modèle et API GET /templates + POST /from-template, point de terminaison de statistiques, paramètre URL ?run=true ouverture automatique, exécution de code basée sur subprocess pour la sécurité, suite de tests 105 (modèles, aplatissement d’espace de noms eval, avertissements de validation de blueprint, suppression de nœud/arête, import/export/duplication, détection d’impasse, branchement multi-condition)
Audit opérationnel: journalisation détaillée de qui a fait quoi — onglet d’examen du journal d’audit administrateur ajouté (piste d’examen de publication par organisation/ressource)
Annotations de schéma sémantique: étendre les champs de schéma de connecteur avec semantic_tag, description et drapeaux pii; annotations affichées dans les descriptions d’outils LLM afin que l’agent comprenne l’intention du champ sans deviner à partir des noms de colonnes
v0.8.1 (2026-03-29) — Divulgation Progressive de la Maturité + Durcissement ReAct
Divulgation progressive pour les connecteurs de base de données (DatabaseMetaTool), les serveurs MCP (MCPServerMetaTool), et le chargement d’outils à la demande (request_tools meta-tool)
Révision de la qualité du DAG (5 améliorations : mise à niveau du modèle, découverte automatique des compétences, vérificateur de citations, préservation du contenu structuré, routage conscient du domaine)
Escalade du modèle de domaine dans ReAct (les domaines spécialisés s’escaladent automatiquement vers le modèle de raisonnement)
Basculement d’appel de fonction native par modèle (tool_choice_enabled)
Détection de cycle ReAct (prévention déterministe des appels d’outils en double)
Liste de contrôle d’achèvement ReAct (vérification pré-réponse lorsque des outils ont été utilisés)
Phase 1 de la fourche de ressources (points de terminaison de fourche du serveur MCP + compétence avec suivi de la lignée)
Abonnement automatique des dépendances de connexion de flux de travail (résolution récursive des dépendances de sous-flux de travail)
Modèles de solutions préconstruites (8 solutions verticales ensemencées au Marché lors de la première inscription)
Améliorations des notifications d’administration (conscientes du fuseau horaire, commutateur maître, Réponse SMTP)
Disjoncteur de budget de jetons par tour (REACT_MAX_TURN_TOKENS)
Troncature d’outils centralisée, budgétisation dynamique des invites système
Téléchargement de pièces jointes, correction de la soumission de messages en double
v0.8.2 (2026-04-10) — Durcissement du noyau d’agent + Documents avec vision
Phase 0 du noyau d’agent — Prompt compact amélioré au format structuré en 9 sections ; protection des résultats d’outils vides (message descriptif au lieu de (no output)) ; prompt anti-boucle + seuil de détection de cycle abaissé à 2 ; classificateur de domaine + résolution de configuration DB en vol parallélisée (400–1100 ms économisés par requête) ; événement SSE end envoyé immédiatement après la réponse, avec titre/suggestions déplacés aux tâches en arrière-plan
Phase 1 du noyau d’agent (Anti-encombrement du contexte) — Nettoyage basé sur règles MicroCompact des anciens résultats d’outils (conservation des 6 derniers) ; plafond agrégé REACT_TOOL_RESULT_BUDGET=40000 ; compactage réactif au débordement de contexte (auto-compactage à 50% du budget et nouvelle tentative au lieu de crash)
Phase 2 du noyau d’agent (Vitesse) — Présélection d’outils basée sur mots-clés (ignore l’appel LLM sur les correspondances évidentes, 200–500 ms économisés) ; mise en pool de connexions LLM SharedHttpClient ; vérification d’achèvement ignorée pour les réponses >200 tokens ; FallbackLLM enveloppe le primaire+rapide avec basculement automatique sur erreurs 429/503/529/connexion
Traitement intelligent des documents (Vision-Aware) — Gestion adaptative des documents : pages PDF rendues en images via PyMuPDF pour les modèles compatibles vision (GPT-4o, Claude 3/4, Gemini), secours texte uniquement via pdfplumber. Drapeau supports_vision par modèle. Modes via DOCUMENT_PROCESSING_MODE, DOCUMENT_VISION_DPI, DOCUMENT_VISION_MAX_PAGES. Extraction d’images intégrées DOCX/PPTX. Persistance vision multi-tours entre les tours de conversation. Traitement PDF intelligent (pages riches en texte extraient texte + images ; pages numérisées rendues en PNG pleine page). Image sandbox pré-construite (Dockerfile.sandbox) avec packages data-science courants pour exécution de code --network=none
Achèvement de la fourche de ressources — Points de terminaison de fourche Agent / Connecteur / Workflow ajoutés, complétant le suivi de lignée de cinq types (fourche KB supprimée — intrinsèquement locale à l’utilisateur)
Garde-fou d’intégrité de fichier — Règle du prompt système empêche l’agent de substituer des contenus de fichiers non liés lorsqu’un fichier cible est illisible ; les fichiers téléchargés incluent désormais file_id dans le contexte du message pour accès direct read_uploaded_file
v0.8.3 (2026-04-16) — Conversion universelle de documents + Phase 3 du cœur de l’agent
Conversion universelle de documents (convert_to_markdown + OCR) — Outil d’agent intégré enveloppant Microsoft MarkItDown ; convertit PDF, Word, Excel, PowerPoint, HTML, JSON, CSV, XML, ZIP, EPUB, Outlook .msg, images, audio, URLs YouTube en Markdown. LiteLLMOpenAIShim active l’OCR via n’importe quel LLM capable de vision (Claude, Gemini, Bedrock, Azure). Ingestion RAG sensible à la vision avec repli sans régression pour texte uniquement. Variable d’environnement LLM_SUPPORTS_VISION pour refuser
Phase 3 du cœur de l’agent (Durcissement des invariants d’exécution) — Récupération de conversation (réparation automatique de tool_use en suspens) ; carte de travail compacte structurée (WorkCard fusion typée sur les tours de compaction) ; profileur au niveau des tours (REACT_TURN_PROFILE_ENABLED) ; limitation de débit par utilisateur (LLM_RATE_LIMIT_PER_USER) ; message d’assistant avec contenu vide et tool_calls ne sont plus supprimés
v0.8.4 (2026-04-17) — Cache de prompts + Correction du raisonnement
Registre de section de prompts système avec points d’arrêt de cache — PromptRegistry mémoïsée divise les prompts système en préfixe stable + suffixe dynamique ; les fournisseurs compatibles avec le cache (Claude, Bedrock Anthropic, Vertex Claude) reçoivent cache_control: {"type": "ephemeral"} sur le préfixe pour ~60-80% d’économies de tokens d’entrée par tour. Les fournisseurs sans cache reçoivent un seul message concaténé (zéro changement de comportement)
Observabilité du cache de prompts — cache_read_input_tokens et cache_creation_input_tokens suivis via UsageSummary → TurnProfiler → champ done_payload.cache. Ligne de journal turn_cache structurée par tour. Sert également de sonde de vérification d’honnêteté du cache relais
MVP de récupération de conversation — Les lignes tool_result synthétiques persistent après les tours interrompus ; POST /chat/resume rejoue les événements SSE en cache à partir d’un curseur monotone ; hook frontend useSseResume se reconnecte automatiquement avec backoff exponentiel (300ms → 1s → 3s, max 3 tentatives) et indicateur « Reconnexion en cours… »
Persistance des blocs de raisonnement avec signature — reasoning_content + signature Anthropic persistés dans metadata_["thinking"] et rejoués aux tours suivants ; corrige l’erreur HTTP 400 de non-concordance de signature sur les conversations multi-tours Claude 4
Politique de relecture du raisonnement consciente du fournisseur — reasoning_replay_policy() centralisée dans core/prompt/reasoning.py contrôle la sérialisation par famille de fournisseur : Claude rejoue les blocs de raisonnement avec signature ; DeepSeek-R1/Qwen-QwQ/Gemini-thinking/o-series suppriment reasoning_content en sortie (précédemment fui, cassant les caches KV des fournisseurs et violant la documentation API)
v0.8.5 (2026-04-23) — Intégration de canal + Système de hooks + i18n pour contributeurs
Canal Feishu (sous-ensemble Phase 1) — Ressource Channel à portée organisationnelle avec identifiants chiffrés par Fernet ; FeishuChannel supporte l’envoi de cartes interactives + callback (vérification de signature + défi URL) ; UI de gestion Paramètres → Canaux (liste, créer/modifier avec protection d’état modifié, détails avec URL de callback copiable, envoi de test) ; API CRUD (/api/channels) et endpoint de callback d’événement (/api/channels/{id}/callback). Livré en avant-première pour la roadshow du 2026-04-24
Système de hooks d’agent (actif dans les runtimes ReAct + DAG) — Abstraction PreToolUseHook / PostToolUseHook dans src/fim_one/core/hooks/ ; les agents déclarant hooks.class_hooks dans model_config_json ont des hooks instanciés et enregistrés par session de chat. Premier consommateur FeishuGateHook publie une carte Approuver/Rejeter au groupe Feishu lié quand un agent appelle un outil avec requires_confirmation=True, bloque l’exécution, et reprend ou abandonne selon le verdict
Portail de confirmation configurable (en ligne OU canal) — Chaque agent obtient une section Approbation avec trois modes de routage (Auto / En ligne uniquement / Canal uniquement), sélecteur de portée approbateur (initiateur / propriétaire / n’importe qui dans l’org), override par outil, et sélecteur de canal d’approbation explicite. Le mode Auto bascule gracieusement vers une carte d’approbation en ligne quand aucun canal n’est lié. POST /api/confirmations/{id}/respond partage un chemin unique d’enregistrement de décision avec le webhook Feishu
Notifications de fin de tâche par agent — Les agents ReAct ou DAG longue durée peuvent envoyer une carte de synthèse au canal de l’org quand une tâche se termine. Premier consommateur du modèle de notification sortante générique
Playground d’approbation par hook — La feuille de détails des canaux a une action « Tester le flux d’approbation » qui exerce le chemin de production complet (ligne ConfirmationRequest authentique, vrai callback Feishu, transitions d’état) — le même chemin de code qu’un hook de production utilise
Fallback CI i18n convivial pour contributeurs — .github/workflows/i18n-sync.yml traduit EN → ZH/JA/KO/DE/FR sur master après fusion de PR et auto-commit avec [skip ci] ; les contributeurs n’ont plus besoin de LLM_API_KEY localement. Garde de pré-commit refusant les modifications manuelles aux fichiers de locale générés (ALLOW_LOCALE_EDIT=1 override pour les corrections de traduction légitimes). Vérifié de bout en bout via push de test de fumée
Docs d’intégration Exa — Section Intégrations dédiée avec une première page Exa couvrant la surface de recherche Exa complète (neural / fast / deep-reasoning / instant), filtrage, récupération de contenu, et trois présets ajustés
Support de base de données Xinchuang (信创) — Le connecteur de base de données liste maintenant KingbaseES (人大金仓), HighGo (瀚高), et DM8 (达梦) aux côtés de PostgreSQL/MySQL. Les pilotes compatibles PG réutilisent asyncpg ; DM8 utilise dmPython. scripts/test_xinchuang_dbs.py vérifie la connectivité en direct depuis la CLI
Docs d’architecture Canaux + Système de hooks — docs/architecture/hook-system.mdx explique les trois points de hook et parcourt FeishuGateHook de bout en bout ; les pages d’architecture existantes font des renvois croisés ; README liste les canaux de messagerie comme une capacité de première classe
Durcissement — Les clics de callback Feishu dupliqués produisent une carte de remplacement au lieu d’une double décision ; les clics de callback concurrents résolus via vérification de compteur de lignes UPDATE ... WHERE status='pending' conditionnel ; les approbations en attente expirent automatiquement après CHANNEL_CONFIRMATION_TTL_MINUTES (24h par défaut) via balayeur en arrière-plan ; Paramètres → Canaux respecte le rôle org (les membres voient l’UI en lecture seule) ; l’agrégateur d’appels d’outils parallèles gère les fournisseurs qui réutilisent index=0 pour chaque delta ; la redirection d’expiration de session préserve la chaîne de requête
Goal: Close loose ends from the v0.8.5 Channel + Hook rollout before the v0.9 production-hardening wave lands. Scope is intentionally narrow — polish, not new capability.
Per-hook config pass-through — class_hooks entries today are bare strings; to override FeishuGateHook.timeout_seconds, poll_interval_seconds, or callback_base_url per-agent, the schema needs to accept {"name": "feishu_gate", "config": {...}} objects that get forwarded as kwargs to the hook factory. Low-risk follow-up; current defaults (120s timeout / 1.5s poll / env-var callback URL) are acceptable in the meantime.
DAG tools_used accuracy — the completion notification card currently derives tools_used from plan.steps[*].tool_hint (the planner’s suggestion), not the real tool names the per-step ReAct loops chose. Plumb the actual chosen tool names out of the DAG executor’s step-completion callback so notification cards reflect what was actually run.
Hook inheritance policy for delegated sub-agents and Workflow AGENT nodes — today CallAgentTool children and Workflow AGENT nodes create fresh ReActAgents that do not inherit the parent’s hook registry, so a sensitive tool call reached via delegation silently bypasses feishu_gate. Decide and document: do child agents inherit (default-secure, prevents gate bypass) or isolate (lets teams delegate non-approval-gated work to a child agent)? Eval Center runs stay opt-out by design (automation cannot block on human approval).
Playground follow-up suggestions restored, opt-in per agent — the v0.8.5 post-processing refactor moved suggestion generation into a fire-and-forget background task and dropped the post_processing / suggestions SSE events, so the chip row beneath an answer never appeared. Suggestions now stream inline between done and end and are gated by a new per-agent suggest_followups toggle (default off) — task-style agents stay quiet, conversational agents that explicitly opt in pay the one fast-model round-trip and get the chips back.
Everything here is additive and behind existing abstractions — no schema changes, no breaking API changes, safe to land piecewise between v0.8.5 and v0.9.
v0.9 — Observabilité + Durcissement de la Production
Objectif : Opérations, débogage et surveillance de qualité production. Introduit le Système de Hooks — une couche d’application déterministe qui se situe sous les instructions de l’agent et ne peut pas être contournée par le LLM.
Divulgation Progressive des Connecteurs (Phase 3-4) : interface ConnectorExecutor unifiée (API/DB/MCP derrière une abstraction unique) ; validation des paramètres d’action avec jsonschema ; découverte/exécution agnostique au protocole
Configuration des connecteurs YAML/JSON : la plateforme génère automatiquement le serveur MCP
Connecteurs de Base de Données Phase 4 : pilotes d’entreprise — Oracle (oracledb), SQL Server (aioodbc), [x] 达梦 DM8 (natif dmPython), [x] 人大金仓 KingbaseES + 瀚高 HighGo (compatible PG, réutiliser asyncpg), 南大通用 GBase (aioodbc + GBase ODBC)
Intégration des Canaux IM (Bidirectionnelle) : Phase 1 — Push sortant : actions de notification Lark, WeCom, Slack, Email, Teams à partir des résultats de l’Agent/Workflow. Phase 2 — Déclenchement entrant : les utilisateurs @mentionnent l’Agent dans les chats de groupe IM pour déclencher des tâches sans ouvrir le Portal ; récepteur webhook par canal ; chaque canal IM modélisé comme un Connecteur avec actions bidirectionnelles (envoi + réception). Fonctionnalité phare du mode Hub
Canal Feishu (sous-ensemble Phase 1) — Ressource Channel à portée organisationnelle avec identifiants chiffrés Fernet ; implémentation FeishuChannel supportant l’envoi de cartes interactives + rappel (vérification de signature + défi URL) ; s’intègre avec la porte de confirmation afin que les approbations d’opérations d’écriture arrivent sous forme de cartes Approuver/Rejeter dans le chat de groupe Feishu configuré ; UI de gestion des Canaux dans Paramètres. Livré en avance pour la feuille de route du 2026-04-24. Restant : WeCom, Slack, Email, Teams sortant + déclencheurs entrants Phase 2.
Modèles de notification sortants (génériques, réutilisables entre les types de canaux) : L’abstraction BaseChannel identique supporte un catalogue de cas d’usage sortants au-delà du contrôle d’approbation. Chaque modèle est implémenté une fois par rapport à BaseChannel et fonctionne automatiquement pour chaque canal concret (Feishu aujourd’hui ; Slack/WeCom/Teams/Email à mesure qu’ils arrivent).
Notification d’achèvement de tâche : lorsqu’un DAG/Workflow/agent planifié de longue durée se termine, publiez une carte récapitulative sur le canal organisationnel (ou un canal choisi par l’utilisateur) avec un extrait de résultat + liens d’artefacts. Le produit « Canal sortant » minimum viable — premier consommateur après FeishuGateHook
Alertes d’exception/défaillance : l’inférence de l’agent échoue, un fournisseur LLM génère une erreur, un connecteur lève une 5xx, un DAG épuise le budget de re-planification → poussez une carte de diagnostic vers le canal ops avec l’ID de trace et l’affordance de nouvelle tentative
Avertissements de coût/budget : le budget de token/requête par utilisateur ou par agent atteint les seuils 80 % / 100 % → poussez vers le canal admin (ou @-mentionnez le propriétaire de l’agent) avec l’utilisation actuelle par rapport au plafond
Résumés planifiés : les agents ou workflows émettent des cartes récapitulatives périodiques (quotidiennes/hebdomadaires) — cumul des KPI, triage des tickets ouverts, liste de renouvellement de contrats — directement dans le canal sans obliger les utilisateurs à ouvrir le Portal
Escalade sur agent bloqué : l’agent n’a fait aucun progrès observable pendant N itérations consécutives (cycle détecté, ou max_iterations dépassé) → publiez une carte demandant à un opérateur humain de prendre le relais, avec le contexte actuel et l’action « reprendre avec votre note »
Reçus d’audit pour les appels d’outils sensibles : indépendamment de la porte d’approbation — chaque appel à un outil marqué audit=true émet une carte de reçu en lecture seule vers le canal de conformité (qui/quoi/quand/args), fournissant une piste d’audit durable en dehors de la base de données
Escalade d’approbation : si une carte d’approbation feishu_gate ne reçoit aucune réponse dans N minutes, @-mentionnez automatiquement le propriétaire du groupe ou transférez la carte vers un canal de niveau supérieur ; configurable par outil/connecteur
Couches d’autorisation des connecteurs (RBAC au niveau des données)
Les contrôles RBAC existants gèrent la visibilité des ressources (qui peut voir un connecteur), non l’autorisation au moment de l’exécution (ce que l’appelant peut faire via celui-ci). Quand un administrateur configure une BD/API avec une credential haute-privilège, chaque membre de l’organisation utilisant ce connecteur hérite du rayon d’explosion de l’administrateur. Cette sous-section comble l’écart sur trois niveaux de capacité en amont distincts :
Tier 1 — Mode BD (full-admin + basic/legacy) : l’administrateur fournit une seule credential BD (root ou un compte de service least-privileged) car la plupart des systèmes legacy ne peuvent pas émettre de comptes BD par utilisateur. L’application se fait au-dessus de la connexion via ConnectorScopeGuard — un hook PreToolUse qui filtre les appels query / execute par identité d’appelant. Capacités : bloquer les verbes destructeurs (DROP, TRUNCATE, DELETE/UPDATE non-scoped) ; listes allow/deny au niveau table ; redaction de colonne pilotée par annotations sémantiques pii=true ; injection automatique de prédicats de scope (p. ex., ajouter AND dept_id = :caller_dept à chaque SELECT). La config est un champ JSON scope_rules sur le connecteur avec correspondance basée sur les rôles ; par défaut deny-if-ambiguous.
Tier 2 — Mode Open API (clé API par utilisateur) : le chemin préféré. Les utilisateurs apportent leur propre clé API (livrée en v0.8 — connector_credentials + allow_fallback=false) ; l’authz natif du système en amont applique le scope naturellement. Travail restant : UI d’administrateur par connecteur pour exiger des credentials par utilisateur (désactiver le fallback-admin globalement) et un tableau de bord de santé montrant quels membres de l’organisation n’ont pas encore lié leur propre clé.
Tier 3 — Tier intermédiaire (échange de ticket de connexion) : pour les systèmes frontend/backend-split sans clé API scoped-utilisateur. Appeler l’endpoint de connexion du système avec des credentials fournis par l’utilisateur, mettre en cache le ticket courte-durée retourné, auto-refresh à l’expiration. Nouveau type LoginTicketCredential aux côtés de clé API / OAuth ; la spec du connecteur déclare auth_type: login_ticket avec login_endpoint, ticket_field, et refresh_strategy. La couche adaptateur convertit le ticket dans l’en-tête auth sortant par requête.
Auditabilité cross-tier : chaque appel d’outil estampillé avec caller_user_id, effective_credential_source (user / admin-fallback / ticket), et scope_rules_applied dans ConnectorCallLog, afin que les ops puissent répondre « qui a vraiment exécuté quoi en tant que qui » après un incident.
Aujourd’hui, Feishu est câblé en tant que paire Canal + Connecteur — tuyau de livraison et surface API. Les déploiements en entreprise nécessitent un troisième rôle : Intégration (la même liaison tierce fournit également SSO et la synchronisation du graphe organisationnel). Arrivée en v0.9 car la liaison Feishu existante couvre déjà 3 des 4 facettes requises, et l’histoire d’identité déverrouille l’autorisation de niveau 2 ci-dessus (les utilisateurs peuvent obtenir leur propre token en amont à la connexion au lieu de provisionner manuellement les clés API).
Modèle Canal → Intégration : promouvoir Channel de « livraison sortante uniquement » en parent ThirdPartyIntegration avec trois sous-capacités optionnelles — (a) Livraison (comportement Canal existant : envoyer des cartes, valider les confirmations) ; (b) Connexion (OIDC / SSO personnalisé ; « Se connecter avec Feishu » génère à la fois une session FIM et le token de la plateforme en amont) ; (c) Synchronisation du graphe organisationnel (refléter les départements/membres en amont dans la structure organisationnelle FIM ; pilotée par planification ou webhook). Les administrateurs basculent chaque capacité par liaison.
Feishu SSO en tant que capacité d’intégration : réutiliser la liaison d’application Feishu existante (app_id/secret déjà sur le Canal) pour exposer « Se connecter avec Feishu » à chaque utilisateur dont le locataire Feishu est lié à une organisation. Le token obtenu à la connexion devient la credential par défaut de l’utilisateur pour le Connecteur Feishu — supprimant la friction « allez obtenir votre propre clé API » pour l’application de niveau 2.
Synchronisation du graphe organisationnel (Feishu → FIM org) : extraire les départements + membres Feishu dans FIM ; mapper les rôles administrateur de locataire Feishu / chef de département / membre aux rôles propriétaire/administrateur/membre FIM. Fondation pour WeCom et DingTalk ensuite, et pour les adaptateurs Kingdee / Yonyou / SAP ERP-OA en v1.0.
Phase 1 (déployée) : middleware d’authentification par clé API, support des portées, spécification OpenAPI curée, référence API Mintlify avec terrain de jeu interactif.
Limitation de débit par clé — Limites configurables de requêtes/minute et requêtes/jour par clé API ; réponses 429 Too Many Requests avec en-têtes X-RateLimit-*
Quota d’utilisation par clé — Budgets mensuels de jetons/requêtes avec tableau de bord administrateur et alertes de seuil
Application des portées par endpoint — Dépendance require_scope("chat") sur tous les endpoints protégés ; les clés avec scopes=chat ne peuvent accéder qu’aux APIs liées au chat
Versioning d’API (/v1/...) — Contrat d’API versionné stable ; en-têtes de dépréciation pour les endpoints supprimés
Callbacks webhook — Enregistrer les URLs webhook par clé API ; recevoir des notifications POST pour la fin de conversation, les erreurs d’agent et les résultats de tâches asynchrones
Génération de SDK — SDKs clients Python et TypeScript générés automatiquement à partir de la spécification OpenAPI ; publiés sur PyPI et npm
Portail développeur — Panneaux interactifs « Essayer » dans la documentation Mintlify ; analyses d’utilisation visibles aux propriétaires de clés
Rotation de clé API — Rotation de clé en un clic avec période de grâce (ancienne clé valide pendant 24h après rotation)
API batch / asynchrone — POST /api/batch acceptant jusqu’à 100 requêtes ; retourne un batch_id pour interroger les résultats ; utile pour les requêtes KB en masse ou l’orchestration multi-agent
Disjoncteur par dépendance externe — Prévenir les défaillances en cascade quand les fournisseurs LLM en aval ou les connecteurs ne sont pas disponibles ; basculement automatique et récupération
Agent Trace Layer (Observabilité++): Hiérarchie run/trace/thread au niveau application pour le débogage d’agent — chaque conversation → Trace, chaque appel LLM / appel d’outil / étape DAG → Span avec input/output/tokens/timing. Visionneuse de trace frontend avec timeline et payloads d’appel LLM extensibles. Cela va au-delà d’OTel (niveau infrastructure) pour fournir un débogage de boucle d’agent exploitable pour les développeurs et clients d’entreprise. Export OpenTelemetry comme option de puits de données. Modélisé d’après les concepts run/trace/thread de LangSmith — le pattern validé par l’industrie pour l’observabilité d’agent.
Tableau de bord des métriques: latence, taux de succès, utilisation des tokens, analytique des appels de connecteur — par agent, par utilisateur, par org
Disjoncteur: machine à trois états (closed/open/half-open) avec suivi des défaillances par connecteur, détection 5xx et endpoints de monitoring(livré en avance — implémenté en v0.8)
Nettoyage de rétention des exécutions de workflow: tâche de nettoyage en arrière-plan avec âge max et nombre max configurables par workflow; overrides par workflow; endpoint admin pour déclenchement manuel(livré en v0.8.1)
Résumés de changement de version de workflow: compute_blueprint_diff() génère automatiquement des résumés lisibles par l’homme à partir des diffs de blueprint lors de la sauvegarde de version(livré en v0.8.1)
Refonte de qualité DAG: mise à niveau du modèle par défaut pour les étapes non-fast; auto-découverte de skill en planification; vérificateur de citation pour domaines juridique/médical/financier; préservation du contexte de contenu structuré; classification de domaine dans le routeur avec sélection de modèle consciente du domaine(livré en v0.8.1)
Escalade de modèle de domaine dans ReAct: domaines spécialisés s’escaladent automatiquement vers le modèle de reasoning avec recherche web obligatoire et vérification de citation(livré en v0.8.1)
Toggle Native Function Calling par modèle: paramètre tool_choice_enabled permet aux modèles de sauter la sélection d’outil forcée et d’aller directement au JSON Mode(livré en v0.8.1)
DatabaseMetaTool (Progressive Disclosure pour connecteurs DB): meta-outil database unique avec sous-commandes list_tables/discover/query remplace 3N outils individuels par connecteur de base de données; configurable via variable d’env DATABASE_TOOL_MODE (défaut progressive, fallback legacy)(livré en v0.8.1)
Chargement d’outil à la demande via meta-outil request_tools: quand >12 outils sont disponibles après sélection intelligente, l’LLM peut charger dynamiquement des outils supplémentaires en milieu de conversation; fonctionne en modes JSON et function-calling natif(livré en v0.8.1)
MCPServerMetaTool (Progressive Disclosure pour MCP): meta-outil mcp unique avec sous-commandes discover/call remplace N*M outils MCP individuels; configurable via variable d’env MCP_TOOL_MODE (défaut progressive, fallback legacy)(livré en v0.8.1)
Workflow Connection Dep Auto-Subscribe: Étendre la cascade d’abonnement Market pour auto-souscrire les dépendances de connexion du Workflow (API Connectors, MCP Servers). Les nœuds de workflow peuvent référencer Connectors, MCP Servers, Agents (qui référencent récursivement plus de dépendances) et sub-Workflows — toutes les dépendances de connexion dans l’arbre complet doivent être auto-souscrites à la souscription et nettoyées en cascade à la désinscription. Plus complexe que Skill/Agent en raison de la résolution récursive de sub-workflow avec détection de cycle. Contrepartie à l’auto-souscription de dépendance de connexion Solution (Skill/Agent)(livré en v0.8.1)
Exécuteurs de workflow réels: remplacé les stubs d’exécuteur de nœud MCP et BuiltinTool par des implémentations complètes (découverte de serveur MCP + appel d’outil; intégration ToolRegistry)(livré en v0.8.1)
Système de hooks d’agent: Une couche d’application déterministe qui s’exécute en dehors de la boucle LLM — les hooks s’exécutent automatiquement sur les événements d’outil et ne peuvent pas être contournés par les instructions d’agent. Trois points de hook: PreToolUse (valider / bloquer avant exécution), PostToolUse (effets secondaires après exécution), SessionStart (injecter contexte dynamique). Hooks intégrés: auto-écrire ConnectorCallLog sur chaque appel de connecteur (actuellement manuel); bloquer les opérations d’écriture quand l’org est en mode lecture seule; auto-tronquer les résultats de requête DB surdimensionnés avant qu’ils ne frappent l’agent; limiter la fréquence d’appel par connecteur. Hooks définis par l’utilisateur: configuration YAML par agent (hooks: field) déclarant des commandes shell ou callables Python déclenchés sur les événements d’outil correspondants — un pattern d’application de hook partagé entre les frameworks d’agent modernes. Principe de conception clé: les hooks sont pour la logique “doit toujours arriver” qui ne devrait jamais dépendre du fait que l’LLM se souvienne de le faire. Les instructions disent “enregistrer tous les appels”; les hooks les enregistrent réellement. Les instructions disent “ne pas écrire en mode lecture seule”; les hooks le bloquent réellement.
Squelette du système de hooks + FeishuGateHook — Abstractions PreToolUseHook / PostToolUseHook basées sur classe câblées sous la boucle ReAct; le premier hook concret est FeishuGateHook, qui intercepte les outils marqués requires_confirmation=True et route l’approbation via le canal Feishu de l’org. Le cycle de vie complet du hook (hooks YAML définis par l’utilisateur, hooks audit/block/truncate intégrés, SessionStart) reste dans le scope v0.9. Livré en avance pour la démonstration du 2026-04-24.
Hook Approval Playground — Testeur round-trip piloté par UI: la feuille de détails Channels lance maintenant une boîte de dialogue qui crée une vraie ligne ConfirmationRequest, envoie la carte de production à Feishu et interroge la décision en direct. Exerce le chemin de code exact qu’un hook de production utiliserait, rendant les répétitions et démos pré-déploiement fidèles.
Système de hooks en direct dans ReAct + runtime DAG — build_hook_registry_for_agent résout agent.model_config_json.hooks.class_hooks à chaque session de chat; les points d’entrée ReAct et DAG instancient tous deux les hooks avant la dispatch d’outil. L’adaptateur d’outil expose requires_confirmation comme propriété publique afin que les prédicats de hook puissent duck-type sans couplage d’adaptateur. Associé à un script de fumée end-to-end (scripts/smoke_feishu_gate.py) couvrant les chemins d’approbation / rejet à travers la boucle d’agent réelle.
Pass-through de config par hook — Les entrées class_hooks aujourd’hui sont des chaînes nues; pour overrider FeishuGateHook.timeout_seconds, poll_interval_seconds ou callback_base_url par agent, le schéma doit accepter des objets {"name": "feishu_gate", "config": {...}} qui sont transmis en tant que kwargs à la fabrique de hook. Suivi v0.8.5 à faible risque; les défauts actuels (timeout 120s / poll 1.5s / URL de callback var-env) sont acceptables pour v0.8.
Agent Workspace (Bureau d’agent persistant): Trois couches: (1) Tool Output Offloading — auto-sauvegarder les réponses d’outil surdimensionnées (>8K chars) vers les fichiers workspace://, retourner aperçu tronqué + URI; outils intégrés read_workspace_file, list_workspace_files, write_workspace_file pour accès sélectif et artefacts générés par agent. (2) Handoff Notes — write_handoff(summary) pour transitions de contexte entre compressions/commutations de session. (3) Workspace UI — panneau navigateur de fichiers frontend par conversation (aperçu texte/JSON/CSV, téléchargement, suppression/renommage); rétention de fichier inter-session; intégration de quota de stockage par utilisateur. Étend truncate_tool_output() dans les adaptateurs + endpoint GET /api/conversations/{id}/workspace
Smart File Content Injection + outil read_uploaded_file: Les petits fichiers téléchargés (<32K chars) sont auto-inlinés dans le contexte LLM; les grands fichiers obtiennent métadonnées + indice d’outil. Outil read_uploaded_file en mode dual (lecture paginée + recherche regex). Endpoint GET /api/files/{file_id}/content, stockage sidecar .content, content_length dans les réponses API de fichier
Intelligent Document Processing (Vision-Aware): Gestion adaptative de documents — pages PDF rendues en images via PyMuPDF pour les modèles capables de vision (GPT-4o, Claude 3/4, Gemini); fallback texte seul via pdfplumber. Flag supports_vision par modèle dans Admin. Deux modes (vision/texte) configurables via variable d’env DOCUMENT_PROCESSING_MODE. Traitement intelligent de PDF: pages riches en texte extraient texte + images intégrées (efficace en tokens), pages scannées rendent en PNG pleine page. Extraction d’image intégrée DOCX/PPTX. Persistance de vision multi-tour. Image sandbox pré-construite (Dockerfile.sandbox). Rendu de page en cache avec sidecar .pages/.(livré en v0.8.2)
Conversion universelle de documents (convert_to_markdown + OCR) — Outil d’agent intégré enveloppant Microsoft MarkItDown, disponible pour chaque agent par défaut. Convertit PDF, Word, Excel, PowerPoint, HTML, JSON, CSV, XML, ZIP, EPUB, Outlook .msg, images, audio, URLs YouTube et data URIs en Markdown propre en conversation. Les images intégrées dans les fichiers Office et les pages PDF scannées sont OCR’d automatiquement via le plugin officiel markitdown-ocr utilisant l’LLM capable de vision de l’espace de travail (DB-first, fallback ENV). Le même noyau de conversion est partagé par le pipeline d’ingestion RAG, donc la conversion au moment du chat et l’ingestion de base de connaissances produisent du Markdown byte-identical. Les fournisseurs non-OpenAI (Claude, Gemini, Bedrock, Azure) sont supportés transparemment via un LiteLLMOpenAIShim qui présente n’importe quel LLM FIM One comme un client en forme de openai-SDK, puis route via LiteLLM. Fallback sans régression: quand aucun modèle de vision n’est disponible, l’extraction texte seul continue exactement comme avant.(livré en v0.8.3)
Gestion de fichiers inter-session: UI navigateur de fichiers, quotas de stockage, nettoyage auto-expiration
Associations de fichiers au niveau session: suivre quels fichiers ont été utilisés dans quelles conversations
Rappel de conversation inter-session: outils d’agent pour lister, rechercher et lire l’historique de conversation passée — list_conversations, search_conversations (keyword/regex dans l’historique), read_conversation (récupérer le fil complet). Active les workflows “qu’avons-nous discuté la dernière fois” et “trouver le changement d’API que j’ai demandé la semaine dernière”. Associé à la gestion de fichiers inter-session pour former une couche de mémoire d’agent à long terme complète
Durcissement du sandbox: améliorations v2 de l’isolation d’exécution de code
Test de performance: benchmarks de charge concurrente
MCP Connection Pooling: le spawning de sous-processus STDIO par requête ne s’adapte pas — 100 utilisateurs concurrents = 100 sous-processus par serveur MCP. Pool les connexions STDIO avec isolation d’env par utilisateur (clé par (server_id, env_hash)); les transports SSE/HTTP partagent les sessions httpx.AsyncClient. Cible: ≤100 ms warm-start pour STDIO poolé, connexions O(1) HTTP par serveur MCP indépendamment du nombre d’utilisateurs
Internal Harness Benchmark — Suite de test intégrée pour quantifier les changements de paramètre de harnais (system prompt, fréquence d’auto-réflexion, seuil de sélection d’outil) utilisant l’infrastructure EVAL CENTER
Observabilité d’identité de déclenchement de workflow: Ajouter ExecutionContext.trigger_source ("webhook" | "cron" | "manual" | "batch" | "sub") peuplé à chacun des cinq sites d’instanciation WorkflowEngine (trigger_workflow, run_workflow, batch_run_workflow, scheduler, sub_workflow). Aujourd’hui ces chemins mélangent implicitement l’identité du propriétaire (wf.user_id — webhook/cron) avec l’identité de l’appelant (current_user.id — manual/batch); les défauts sont sensés mais la convention est non documentée, donc les défaillances de classe 401 (“pourquoi mon cron n’a pas emprunté mon token?”) nécessitent l’ingénierie inverse du chemin de déclenchement. Surface trigger_source dans les journaux d’appel de connecteur, les métadonnées d’exécution et le panneau d’exécution afin que chaque exécution déclare sa propre politique d’identité. S’associe avec l’override credential_policy ci-dessous.
Cache de Prompts + Suites de Raisonnement (à partir des MVP de Batch A)
Ces éléments complètent le travail partiellement livré dans Batch A (Récupération de Conversation, Registre de Prompts Système, Blocs de Réflexion) et étendent la couverture du cache aux familles de fournisseurs restantes.
Adaptateur de Cache de Contexte Gemini : Google Gemini utilise une API REST distincte (POST /v1beta/cachedContents → retourne cacheName → référencé via cachedContent: "<cacheName>" dans les appels generateContent suivants) plutôt que le marqueur inline cache_control qu’Anthropic utilise. Nécessite un GeminiCacheAdapter avec gestion du cycle de vie (pré-enregistrement du préfixe → référence cacheName → invalidation consciente du TTL), intégré dans le chemin Gemini de OpenAICompatibleLLM ou du fournisseur Gemini de LiteLLM. Réduction de lecture ~0,25×, préfixe minimum 32 768 tokens (Gemini Pro) / 4 096 (Flash) — les principaux bénéficiaires sont les agents KB/RAG à long contexte et les workflows lourds en documents.
Expansion du registre de prompts vers planificateur / vérificateur / classificateur de domaine : étendre le pattern PromptRegistry + DYNAMIC_BOUNDARY de ReAct aux sites d’appel LLM restants : DAGPlanner, PlanAnalyzer, StepVerifier, CitationVerifier, DomainClassifier, ExecutionModeRouter, CompactUtils. Actuellement, ces éléments reconstruisent les prompts à partir de zéro à chaque invocation. Fréquence inférieure à ReAct, donc ROI inférieur, mais complète l’histoire du cache.
Configuration cache_ttl par agent : permettre aux propriétaires d’agents de choisir entre ephemeral (5 min, par défaut, écriture bon marché) et extended (1 heure, coût d’écriture 2×, mais meilleur pour les workflows batch / planifiés). Exposer comme champ sur le modèle Agent et transmettre via cache_control: {"type": "...", "ttl": "..."} où supporté.
Table de point de contrôle au niveau des étapes DAG : le MVP actuel de Récupération de Conversation A1 persiste les tool_results synthétiques et les événements SSE en cache, mais l’état des étapes intermédiaires DAG vit uniquement en mémoire. La nouvelle table dag_execution_step crée des snapshots de chaque étape tool_calls, résultats et références d’artefacts, de sorte qu’une déconnexion mid-DAG peut reprendre sans réexécuter les étapes complétées. Associée au hook frontend useSseResume pour la continuité de bout en bout.
Colonne tool_call_id dédiée sur Message : aujourd’hui tool_call_id vit dans JSON metadata_, nécessitant des recherches json_extract(...) / ::json->> pour les requêtes d’utilisation d’outils orphelins. Pour les déploiements à fort trafic, une colonne indexée de première classe permettrait à la passe de récupération de s’exécuter en O(log n) au lieu de scans O(n). Priorité basse jusqu’à ce que l’échelle le demande.
Reconstruction de tokens de réflexion en flux : la granularité de reprise actuelle est « prochain événement SSE complet » — si la chute se produit à l’intérieur d’un delta de réflexion, le client redémarre à partir de l’événement suivant. La reprise au niveau des tokens nécessiterait de réémettre les tokens en mémoire tampon du bloc de réflexion en vol. Amélioration de niche ; seulement utile si les utilisateurs signalent une gigue UX de réflexion sur les connexions instables.
Sonde d’honnêteté du cache de relais API : outil de fond (déclenché par administrateur ou planifié) qui envoie deux requêtes Claude identiques via chaque relais configuré, compare les entrées réellement facturées par rapport à cache_read_input_tokens, et signale les relais qui suppriment le marqueur cache_control ou ne transmettent pas la réduction 0,10×. Exposé comme signal « santé du relais » au niveau de l’Espace de Travail — outil opérationnel utile pour les entreprises acheminant via des proxies API chinois.
Suivi de la fiabilité (Matrice de priorités du cœur de l’agent)
La majorité de la base de l’intégration du cœur de l’agent (Phase 0–3, I.1–I.16) a été livrée dans les versions v0.8.2 et v0.8.3. Les éléments ci-dessous proviennent de la matrice de priorités parallèle qui nécessitent encore une attention.
Persistance de l’état de remplacement de contenu (invariant de streaming #2) : « une fois vu, destin figé » — le contenu des messages qui a déjà été émis au client ne doit pas être muté rétroactivement lors de la reprise / rechargement. Nécessite un registre de remplacement aligné avec le curseur SSE de A1. Bloqué par la compréhension des véritables glitches visibles par l’utilisateur ; aucune plainte active.
Routeur de contexte des pièces jointes : injection de pièces jointes plus intelligente avec déduplication alreadySurfaced + readFileState, budget de pièces jointes agrégé et vérifications de vivacité. Empêche le renvoi du même extrait PDF de 50 Ko à chaque tour. S’associe au déchargement des fichiers de l’espace de travail (déjà prévu pour v0.9).
Workers de requête auxiliaire (pool de workers de prompt) : pools légers dédiés pour les requêtes de rappel / classification / résumé / mémoire de session afin qu’elles ne rivalisent pas avec l’appel LLM principal de l’agent pour le budget de limite de débit. Condition préalable : expansion du registre de prompt (ci-dessus).
Tâches planifiées + Agents déclenchés par événements (Loop): déclencheurs de tâches de fond de type cron; tables DB scheduled_jobs + job_runs; intégration APScheduler; API CRUD de tâches + UI d’historique des tâches; notification des résultats via connecteurs de push de messages. La portée couvre à la fois les modèles déclenchés par le temps (cron) et déclenchés par événement (webhook entrant) — un agent s’exécutant de manière asynchrone en arrière-plan EST le cas d’utilisation du sous-agent asynchrone pour le mode Hub.
Modèles de solutions préconfigurées (contenu d’amorçage du marché): 8 solutions verticales prêtes à l’emploi publiées sur le marché lors de l’enregistrement du premier utilisateur — Audit financier, Examen de contrat, Rapports de données, Service d’assistance informatique, Intégration RH, Assistant commercial, Rédacteur de contenu, Résumé de réunion. Chacune regroupe un Agent + Compétence avec procédures opératoires standard chinoises; amorcées de manière idempotente via ensure_solution_templates(), publiées sur l’organisation Market pour une disponibilité immédiate sur la place de marché(livré dans v0.8.1)
Générateur de schéma DB avancé: agent de gestion de schéma piloté par l’IA pour les bases de données à grande échelle — annotation stratégique de table (basée sur les modèles, informée par l’exécution SQL), gestion de visibilité en masse par préfixe de domaine, annotation itérative multi-tours pour les déploiements de 1K–7K+ tables; complète le travail d’annotation par lot existant avec sélectivité et raisonnement contextuel métier
Fork de ressource (phase 1 du package — prérequis pour le système de package v1.0): tous les points de terminaison de fork par ressource implémentés — MCP Server, Compétence, Agent, Connecteur, Workflow. Fork KB supprimé (intrinsèquement local à l’utilisateur). Chaque POST /api/{type}/{id}/fork crée une copie profonde détenue par l’utilisateur avec suivi de lignée forked_from.(complété dans v0.8.1)
Remplacement credential_policy par workflow (owner | caller | auto): les cinq chemins de déclenchement de workflow codent actuellement en dur l’identité qui exécute les actions du connecteur — webhook/cron passent wf.user_id (propriétaire), manuel/lot passent current_user.id (appelant). Cela correspond à l’attente courante « les automations s’exécutent en tant que propriétaire, les exécutions manuelles en tant qu’appelant », mais les déploiements d’entreprise ont parfois besoin de remplacer par workflow (par exemple, un cron qui doit s’exécuter sous l’ingénieur de garde actuel, ou un modèle partagé qui doit emprunter les identifiants du propriétaire même lors d’une exécution manuelle). Ajoutez un champ credential_policy sur le modèle Workflow, exposé dans l’interface utilisateur à côté de la configuration Schedule / API-Key, qui remplace le mappage par défaut trigger_source → identity. Prérequis: observabilité trigger_source ci-dessus.
Impact: exécutez FIM One à l’échelle en toute confiance. Quatre piliers: couche de trace (voir ce qui s’est passé), système de hook (appliquer ce qui doit se produire), espace de travail agent (gestion de fichiers persistante + transfert), canal IM (les agents vivent où les utilisateurs travaillent). Les modèles de solutions préconfigurées éliminent le démarrage à froid; l’amélioration du tableau de bord expose la santé opérationnelle. L’écart entre « les instructions que l’agent pourrait suivre » et « les garanties que le système applique » est fermé — la différence entre une démo et un outil d’entreprise de production.
Objectif : Ajout de connecteurs sans redémarrage, écosystème de paquets et livraison intégrée.
Divulgation Progressive des Connecteurs (Phase 5) : Sélection d’Outils Guidée par la Sémantique (extraction d’entités à partir de la requête → recherche dans le registre d’ontologie → réduction de l’ensemble de connecteurs ; réduction de 90%+ des jetons pour les déploiements de 50+ connecteurs) ; Mode d’échelle pour les connecteurs batch/ETL ; Interface universelle de style CLI connector <name> <action> <params>
Alignement d’Entités Cross-Connecteur (Registre d’Ontologie) : définir les types d’entités partagées (Customer, Order, Asset) avec mappages de champs entre connecteurs ; DAGPlanner résout automatiquement les clés JOIN cross-système ; active les requêtes cross-connecteur (par ex., « clients dans Salesforce qui ont commandé dans Shopify ») sans noms de champs codés en dur
Connecteurs hot-plug : télécharger la spécification OpenAPI, l’IA génère la configuration, actif en 5 minutes (pas de redémarrage)
Refonte de la Marketplace Phase 1 — Solutions + Composants : Modèle de marché à deux niveaux (Solutions : Agent/Skill/Workflow ; Composants : Connecteur/Serveur MCP) ; sélecteur de portée (Marché Global / org) ; modèle d’abonnement unifié (suppression de l’auto-apparition org) ; KB supprimée de la portée du marché ; migration de données remplissant les abonnements pour les membres org existants
Système de Paquets de Marché : Bundles de ressources distribuables pour la Marketplace — remplace les « marketplaces » par type avec une couche d’empaquetage unifiée. Le manifeste fim-package.yaml déclare : métadonnées (nom, version, description, auteur, licence, tags, min_fim_version), point d’entrée (Skill ou Agent principal), liste de ressources (agents, skills, connecteurs, KBs, serveurs MCP, workflows) avec références de configuration, dépendances inter-paquets (plages semver), identifiants requis (mappés aux références de connecteur pour la collecte au moment de l’installation), et variables configurables par l’utilisateur avec valeurs par défaut. Deux modes de consommation : (1) install — création batch de toutes les ressources + auto-câblage des références internes via substitution d’ID ; installation liée à la source pour les notifications de mise à jour de version ; POST /api/market/packages/{id}/install ; (2) fork — cloner en tant que copies modifiables appartenant à l’utilisateur sans lien de mise à jour (c’est le mode modèle) ; POST /api/market/packages/{id}/fork. Points de terminaison supplémentaires : publier (POST /api/market/packages avec flux d’examen), désinstaller (DELETE /packages/{id}/uninstall avec vérification de dépendance + confirmation de ressource modifiée), historique des versions (GET /packages/{id}/versions), mettre à niveau (POST /packages/{id}/upgrade avec aperçu de diff par ressource). Résolveur de dépendances pour les exigences de paquets imbriqués avec détection de conflits. La table PackageInstallation suit les paquets installés par utilisateur avec mappage d’ID de ressource pour la désinstallation/mise à niveau. Coexiste avec la publication de ressources individuelles — Le paquet est une couche de composition, pas un remplacement ; un seul connecteur est toujours publiable de manière autonome. Exemple d’arborescence de dépendances : Package: contract-review → Skill: contract-review (point d’entrée) → Agent: contract-analyst + Agent: risk-scorer → KB: legal-clauses + Connector: docusign-api + MCP: pdf-extractor + Workflow: contract-approval-flow
Programme Créateur : Couche de monétisation de la Marketplace — profils de créateur avec pages de portfolio, analyses par paquet (installations, forks, utilisateurs actifs, évaluations/avis), suivi des commissions d’affiliation lorsque les paquets génèrent de nouveaux abonnements. Niveau de paquet payant avec tarification, flux d’achat et flux d’approbation. Tableau de bord créateur avec tendances d’installation, rapports de revenus et retours d’utilisateurs. API créateur publique pour la publication de paquets programmatique (CI/CD pour les auteurs de paquets). Fonctionnalités communautaires : commentaires de paquet, Q&A, changelogs par version
Widget intégrable : <script src="fim-one.js"> injecté dans la page hôte
Injection de contexte de page : le widget lit le contexte de la page hôte (ID actuel, URL, sélecteurs DOM)
Déclencheurs avancés : Événements entrants webhook ; améliorations des tâches planifiées (multi-fuseau horaire, sensibilité au calendrier)
Exécution batch : traiter 1000+ éléments via DAG
Sécurité d’entreprise : liste blanche IP, chiffrement au repos, SSO
Éditeur Avancé KB : Agent en mode Builder pour les utilisateurs avancés gérant de grandes bases de connaissances — ingestion d’URL en masse, détection des doublons, analyse des lacunes, gestion du cycle de vie des documents ; étend le chat IA KB existant avec boucle d’outils ReAct
Impact : Les entreprises déploient FIM One de zéro à l’orchestration multi-système en quelques jours. Le système de paquets crée un écosystème de créateurs — les auteurs de solutions publient des bundles composites (Skill + Agents + Connecteurs + KBs + Workflows), les entreprises installent en un clic, les créateurs gagnent de l’adoption. La dualité install/fork couvre à la fois les cas d’usage « utiliser tel quel » et « personnaliser à partir d’un modèle » dans un seul mécanisme.
Selon la Stratégie d’orthogonalité, ces fonctionnalités sont livrées et fonctionnelles mais ne recevront pas de nouvelles capacités (corrections de bugs uniquement) :
Fonctionnalité
Version
Raison du gel
Agent ReAct
v0.1, v0.9
Les modèles disposent désormais d’appels d’outils natifs. L’auto-réflexion en milieu de boucle (v0.9) prévient la dérive d’objectif dans les longues chaînes. La qualité de la synthèse d’observation d’outils s’est améliorée (8K caractères, configurable via REACT_TOOL_OBS_TRUNCATION)
Planification DAG / Re-planification
v0.1, v0.5, v0.7.5
Les capacités de raisonnement des modèles s’améliorent ; la décomposition devient mono-coup. La vérification par étape est livrée en v0.7.5 (DAG_STEP_VERIFICATION). Renforcée : propagation des défaillances en cascade, correction du statut du vérificateur, descriptions des outils du planificateur, historique complet de replanification, cache d’outils basé sur liste blanche. 14 constantes de moteur exposées en tant que variables ENV — aucune nouvelle primitive de planification prévue
Mémoire (Fenêtre, Résumé, Compact)
v0.2, v0.5
Les fenêtres de contexte augmentent (200K+) ; moins besoin de gestion externe de la mémoire
Pipeline RAG
v0.5
Les fournisseurs construisent la récupération nativement (file_search OpenAI, Gemini Search Grounding)
Génération ancrée
v0.5
Les modèles s’améliorent dans les citations ; le pipeline à 5 étapes ajoute une valeur décroissante
ContextGuard / Messages épinglés
v0.5
Livraison en l’état ; aucune nouvelle fonctionnalité
Selon la Stratégie d’Orthogonalité, ces éléments représenteraient un effort élevé et feraient face à un risque d’absorption :
Fonctionnalité
Raison du report
Orchestration Multi-Agent (hiérarchies profondes)
Les fournisseurs construisent nativement (OpenAI Swarm, Google A2A, et offres multi-agent similaires). Le CallAgentTool de FIM One couvre le cas de délégation à un niveau ; les agents d’arrière-plan déclenchés par événement sont couverts par Scheduled Jobs en v0.9
Les agents mettant à jour leur propre skill.md pendant l’exécution — complexité élevée, surface de sécurité/audit. Dépend de la livraison du Système de Compétences d’Agent (v0.8) en premier. Réévaluer si les clients entreprise demandent explicitement des agents auto-améliorants
Espace de Travail d’Agent (Déchargement de Fichiers de Sortie d’Outil)
Promu à v0.9. La valeur est la lecture sélective, non la capacité de contexte — validation inter-frameworks confirmée. Le raisonnement de report original (« les fenêtres 200K+ réduisent l’urgence ») était incorrect.
Mémoire Long-Terme Inter-Session
Les fenêtres de contexte croissent rapidement (200K–2M) ; les fournisseurs ajoutent la mémoire intégrée (mémoire OpenAI, mise en cache de contexte Gemini) ; coût d’implémentation élevé par rapport à la valeur de différenciation décroissante. Réévaluer quand les clients entreprise le demandent explicitement
Cycle de Vie de la Mémoire (TTL, quotas)
Dépend de la mémoire inter-session ; reporté ensemble
Outil de Compression de Contexte Actif (déclenché par agent)
Explicitement gelé avec ContextGuard (v0.5). Les fenêtres de contexte à 200K+ réduisent la valeur. Ne sera pas revisité sauf si les coûts de contexte deviennent une plainte majeure de l’entreprise
Automatisation de Navigateur / Utilisation d’Ordinateur
Coût de maintenance élevé (changements DOM, anti-bot, sandboxing). L’industrie converge vers le mode Computer Use (Anthropic, OpenAI Operator, Google Mariner) et les outils de navigateur MCP (Puppeteer/Playwright MCP). Consommer via l’intégration MCP, ne pas auto-construire. Réévaluer quand une norme MCP Computer Use stable émerge
Notifications Web Push
Push natif du navigateur via Service Worker + VAPID. Chevauche l’Intégration de Canal IM (v0.8) qui couvre les canaux préférés de l’entreprise (Lark/Slack/WeCom/Email). Le push IM a une valeur entreprise plus élevée ; Web Push est un plus pour les utilisateurs Portal uniquement. Réévaluer après la livraison du canal IM — si les utilisateurs demandent des notifications de navigateur au-delà de la couverture IM
Édition collaborative multi-utilisateur de flux de travail
Co-édition en temps réel du même blueprint de flux de travail (style Figma/Notion) avec conscience du curseur, résolution de conflits, et verrous par nœud. Coût d’implémentation élevé (CRDT / OT, infrastructure de présence), demande entreprise peu claire par rapport au modèle actuel « un éditeur à la fois + diff de version ». Réévaluer si plusieurs entreprises demandent spécifiquement l’édition partagée en direct
Permissions d’exécution de flux de travail par nœud (RBAC à l’exécution)
Autorisation fine-grained à l’intérieur d’une seule exécution de flux de travail — par ex. « le nœud X nécessite le rôle finance_approver pour s’exécuter ». Aujourd’hui l’autorisation se fait au niveau du flux de travail (qui peut déclencher) et au niveau du connecteur (dont les identifiants exécutent) ; RBAC par nœud ajoute un troisième axe avec complexité matérielle et aucune demande client active
Partage de flux de travail inter-org avec mises à jour en direct
S’abonner à un flux de travail d’une autre org et recevoir les mises à jour en amont sans re-forker. Aujourd’hui s’abonner = forker (snapshot), donc les changements en amont cassants ne se propagent jamais. Les mises à jour en direct nécessiteraient l’évolution de schéma compatible en amont + résolution de conflits ; coût de maintenance élevé. Réévaluer si les entreprises demandent « flux de travail partagés entre filiales »
Ennuyeux mais durable ; exigence de production. La couche Agent Trace est l’ancrage commercial
Intelligence des agents (Système de compétences, agents planifiés)
15%
v0.8–v0.9
Histoire de différenciation instructions+outils+compétences ; risque d’absorption faible — les frameworks valident les modèles, mais les procédures d’entreprise sont spécifiques aux clients
Maintenance v0.1–v0.5
5%
Continu
Corrections de bugs uniquement ; aucune nouvelle fonctionnalité
Modération de la marketplace : Comment valider les packages communautaires et les ressources individuelles ? Analyse automatisée des fuites de credentials dans les configurations de packages ? (v1.0)
Économie des tokens : Comment tarifier les scénarios multi-utilisateurs et multi-agents ? (v1.0)
Versioning des packages : Changements cassants dans les packages installés — mise à niveau automatique avec scripts de migration, ou approbation manuelle par mise à jour ? Résolution du problème du diamant de dépendance ? (v1.0)
Tarification des packages : Niveaux gratuits vs payants, taux de commission pour le Creator Program, intégration du fournisseur de paiement ? (v1.0)
UX des credentials de package : Collecte de credentials au moment de l’installation — assistant étape par étape ou configuration différée ? Partage de credentials entre packages utilisant le même type de connecteur ? (v1.0)
Opt-out de télémétrie : Comment respecter les préférences de confidentialité ? (v0.8)
Versioning des connecteurs : Comment gérer les changements cassants dans les APIs des connecteurs ? (v0.8)
Rate limiting : Rate limiting par utilisateur pour les workflows implémenté (fenêtre glissante 10 exécutions/min, 3 concurrentes). Rate limiting par connecteur et par agent à déterminer (v0.9)
Sélection du niveau d’autorisation du connecteur : comment un administrateur découvre-t-il quel niveau s’applique à un système en amont donné ? Auto-détection (essayer clé API par utilisateur → revenir à login-ticket → revenir à shared-DB) vs. déclaration explicite dans la spec du connecteur ? Comment exprimer « ce connecteur supporte le Tier 2 mais l’administrateur a choisi d’opérer en Tier 1 » dans l’interface sans confondre les administrateurs non-techniques ? (v0.9)
Dualité Intégration vs Connecteur : quand une liaison Feishu est simultanément un fournisseur SSO ET une surface d’appels API, comment la présenter dans Paramètres ? Un objet avec trois bascules, ou trois liaisons séparées partageant une credential ? Implications pour la sémantique de désinstallation (révoquer SSO tue-t-il le Connecteur ?) (v0.9)
