Objectif : Construire une plateforme d’agents tout-en-un pour les entreprises mondiales × chinoises — livrée selon trois modes progressifs : Standalone (assistant portail), Copilot (intégré au système hôte), Hub (orchestration centrale inter-systèmes). Principes : Agnostique des fournisseurs (pas de verrouillage propriétaire), abstraction minimale, axée sur les protocoles, centrée sur les connecteurs (l’intégration est la valeur centrale).

​

Vision Produit

Standalone   → Your own AI assistant (Portal)
Copilot      → AI embedded in a host system (iframe / widget / embed)
Hub          → Central cross-system orchestration (Portal / API)

​

Problèmes connus

• 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 en arrière déclenche la boîte de dialogue « Modifications non enregistrées » même si aucun champ n’a été touché. La vérification dirty compare 20+ champs par rapport à la charge utile d’agent chargée, donc une asymétrie de défaut entre l’initialisation d’état et la comparaison dirty suffit à causer une incompatibilité fantôme — la suspicion actuelle porte sur l’un des champs model_config_json / notification / approbation imbriqués, possiblement à partir de la normalisation undefined vs null vs "". Se reproduit notamment 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 correctif (cb40c86a) a supprimé un scintillement orphelin de badge 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 /api/agents/{id} PUT même si chaque valeur stockée dans la base de données est l’un des trois littéraux valides. Suspicion : le transtypage frontend as "initiator" | "agent_owner" | "org_members" n’est une promesse qu’au moment de la compilation, donc une chaîne héritée ou inattendue au runtime (possiblement à partir d’un modèle, importation ou migration plus ancienne) peut passer par setConfirmationApproverScope et être renvoyée textuellement. Solution de contournement : re-sélectionnez explicitement une valeur dans la liste déroulante Approval → Approver Scope avant d’enregistrer.
• L’arrêt et la relance du playground affichent des artefacts visuels transitoires qu’une actualisation de page efface toujours. Trois sources de rendu simultanées — activeConversation.messages (snapshot DB), le flux SSE messages et l’espace réservé optimiste pendingQuery — ne sont pas regroupées dans un seul état dérivé, donc entre le clic sur « Retry » et l’arrivée de la réponse d’assistant appariée, l’interface utilisateur peut (a) brièvement afficher deux fois la même requête dans la fenêtre de pré-flux, (b) supprimer les bulles utilisateur orphelines antérieures de l’historique de relance pendant que hasLiveMessages est vrai et avant le rechargement du snapshot, et (c) scintiller dans la fenêtre étroite entre l’événement SSE « done » et le prochain rafraîchissement selectConversation. Les données ne sont jamais perdues — chaque message utilisateur (y compris les relances abandonnées) est persisté dans conversation.messages, porté dans le prochain appel LLM via normalize_alternating_messages et rendu correctement après actualisation via HistoryTurn.orphanUserContents introduit dans le correctif de rendu 48ba08c6. Pour le contexte, la propre interface Web de Claude exhibe une classe analogue de bogue — arrêter au milieu d’une réponse et envoyer immédiatement une requête de suivi bifurque parfois la requête de suivi en tant que branche d’édition sœur de la première requête plutôt que de l’ajouter en tant que nouveau tour — donc c’est un problème difficile connu dans les conceptions optimiste-UI + SSE + historique persisté, pas un défaut spécifique à FIM One. Un correctif approprié nécessite de regrouper les trois sources de rendu en un seul état dérivé ; déféré jusqu’à une refonte plus large de la machine d’état du playground.

​

Versions expédiées

​

v0.1 (2026-02-22) — MVP: ReAct + DAG Planner

• ReActAgent avec outils (calculator, python_exec, web_search)
• DAG Planner (LLM génère des graphes de dépendances)
• UI Portail avec streaming + KaTeX

​

v0.2 (2026-02-24) — Multi-Model + Memory

• Retry / rate limiting / usage tracking
• Native function calling (no JSON-only parsing)
• Multi-model support (fast + main LLM)
• Memory: WindowMemory, SummaryMemory
• FastAPI backend with SSE streaming

​

v0.3 (2026-02-25) — Web Tools + MCP

• Outils web (web_search, web_fetch) via Jina/Tavily/Brave
• Outil d’opérations sur fichiers
• Client MCP (intégration d’outils standard)
• Découverte automatique d’outils + catégories
• Visualisation DAG avec défilement au clic
• Exécution de code dans Docker (--network=none)

​

v0.4 (2026-02-25) — Multi-Turn + Agents

• Conversations multi-tours (DbMemory)
• Interface de regroupement des étapes d’outils
• Outils de requête HTTP + exécution shell
• Gestion des agents (créer, configurer, publier)
• Authentification JWT
• Mode d’exécution par agent + contrôle de la température

​

v0.5 (2026-02-28) — Full RAG + Grounded Gen

• Pipeline RAG complet (embedding + magasin vectoriel + FTS + RRF + reranker)
• Génération ancrée (citations, scores de confiance)
• Gestion de documents de base de connaissances (CRUD, recherche, nouvelle tentative, migration de schéma)
• ContextGuard + messages épinglés (gestionnaire de budget de tokens)
• Persistance DbMemory + LLM Compact
• DAG Re-Planning (jusqu’à 3 tours)

​

v0.6 (2026-03-01) — Connector Platform

• Connector CRUD: create, read, update, delete
• ConnectorToolAdapter: converts Connector → BaseTool
• Per-user credentials: AES-GCM encryption
• Confirmation gate: write operation approval
• Audit logging: all tool calls recorded
• Circuit breaker: graceful degradation on failures
• Utility tools: email_send, json_transform, template_render, text_utils
• Embedding options: Jina, OpenAI, custom providers

​

v0.7 (2026-03-06) — Admin Platform + Multi-Tenant

• Admin Platform: gestion des utilisateurs, basculement des rôles, réinitialisation de mot de passe, activation/désactivation de compte
• Inscription sur invitation uniquement: trois modes (ouvert/invitation/désactivé) + CRUD de code d’invitation
• Gestion du stockage: utilisation disque par utilisateur, effacement, nettoyage des fichiers orphelins
• Modération de conversation: liste/suppression administrateur de tous les éléments
• Déconnexion forcée par utilisateur: révocation de tous les jetons
• Tableau de bord de santé de l’API: stats système, métriques des connecteurs
• Assistant de configuration initiale: création guidée du compte administrateur
• Centre personnel: instructions globales par utilisateur, préférence de langue
• Auth JWT: authentification SSE basée sur jetons, propriété de conversation
• Serveurs MCP mondiaux: provisionnés par l’administrateur, chargés dans toutes les sessions
• Rétrocompatibilité: auto-migration registration_enabled → registration_mode

​

v0.7.x (2026-03-07 à 2026-03-12) — Stabilité + Améliorations

• Gestion des codes d’invitation
• Quotas par utilisateur (application 429)
• Journalisation d’audit structurée
• Filtrage des mots sensibles
• Historique de connexion administrateur
• Navigateur de fichiers administrateur
• Vues administrateur améliorées (champs model_name, tools, kb_ids)
• Déploiement Docker Compose (image unique, volumes nommés)
• Détection automatique OAuth depuis window.location
• Support de la réflexion étendue / raisonnement (LLM_REASONING_EFFORT, LLM_REASONING_BUDGET_TOKENS) pour OpenAI o-series, 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 zéro-config) + 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 : streaming de réponse 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 builder (GetSettings, TestConnection, ImportOpenAPI pour connecteurs ; ListConnectors, AddConnector, RemoveConnector, SetModel pour agents), drapeau is_builder sur agents, actualisation automatique du prompt builder, garde SSRF
• Frontend SSE v2 : curseur pulsant avec points en streaming, 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 builder de connecteur et d’agent
• 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 agents, connecteurs, bases de connaissances, serveurs MCP
• API Publier/Dépublier pour tous les types de ressources ; délégation de propriétaire pour agents publiés
• Point de terminaison administrateur set-visibility (remplace clone-to-global) ; helper 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 + bases de données chinoises héritées ; 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 : benchmarking quantitatif de la qualité des agents — CRUD d’ensemble de données de test (prompt + comportement attendu + assertions), exécutions d’éval (exécution parallèle + évaluateur LLM + résultats par cas réussi/échoué/latence/token), 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 le passage d’artefacts
• Cache d’outils pour exécution DAG — appels d’outils identiques mis en cache par exécution avec verrou asynchrone de prévention de ruée (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 ; bascule de mode 3 voies frontend (AUTO_ROUTING)
• Organisation du marché fantôme + Abonnements aux ressources : Org Market intégré (fantôme, pas d’adhésion automatique) remplace l’org Platform ; ressources découvertes via navigation marketplace et explicitement abonnées (modèle pull) ; API Market pour s’abonner aux ressources partagées ; la publication sur Market nécessite toujours un examen ; table d’abonnements aux ressources ; partage de ressources basé sur l’org remplaçant la visibilité globale
• Découverte automatique d’agent et liaison de sous-agent : drapeau discoverable sur 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 : table mcp_server_credentials ; point de terminaison PUT /api/mcp-servers/{id}/my-credentials ; drapeau allow_fallback pour comportement de secours d’identifiants
• Bascule 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 conversations pour chat KB direct sans liaison d’agent

​

v0.8 (2026-03-20) — Connector Declarative Config + Progressive Disclosure

• Database connectors: direct SQL access (PostgreSQL, MySQL, Oracle) (shipped in v0.7.x — Phase 1-3)
• RBAC: per-user/role connector access control (shipped in v0.7.x — org system + three-tier visibility)
• Connector credential encryption + per-user override: connector_credentials table, Fernet encryption via CREDENTIAL_ENCRYPTION_KEY, allow_fallback flag, GET/PUT/DELETE /my-credentials endpoints, per-user credential resolution in chat tool loading
• Publish review UI: Org-level publish review system — review toggle per org, ReviewsSheet with approve/reject workflow, status badges on resource cards, review notice in publish dialog, resubmit for rejected resources
• Connector Progressive Disclosure (Phase 1-2): single ConnectorMetaTool replaces per-action tools; system prompt receives lightweight stubs only (name + 1-line description, ~30 tokens/connector vs ~250 tokens/action); agent calls discover(connector) to load full action schema on demand — schema only loads when the model selects a connector, keeping the prompt prefix stable for caching. Follows the deferred tool-loading pattern common in modern agent frameworks. execute subcommand; feature flag for backward compatibility.
• Agent Skill System + Compact Instructions: On-demand skill loading for agent instructions — Skill model (name, content/SOP, optional scripts) attached to agents; referenced in system prompt by name only (~10 tokens/skill); agent calls read_skill(name) to load full content on demand. Reduces per-conversation instruction token cost by ~80% while allowing richer SOP libraries. Counterpart to ConnectorMetaTool’s progressive disclosure applied at the instruction level. Enables the “指令 + 工具 + 技能” differentiation story. Also adds compact_instructions field to Agent model — per-agent compression priority list injected into ContextGuard when compacting (e.g., “preserve order IDs and amounts, drop raw API responses”), replacing the current static generic prompt. Follows the Compact Instructions convention widely adopted in modern agent frameworks.
• Connector import/export: share connector templates
• Connector fork: clone + customize existing connectors
• Workflow Phase 2 Nodes: Iterator, Loop, VariableAggregator, ParameterExtractor, ListOperation, Transform, DocumentExtractor, QuestionUnderstanding, HumanIntervention — 9 advanced node types with full frontend + backend + 150 new tests (275 total). Node retry with exponential backoff, safe expression evaluation. Stats panel with success rate bar. 12 built-in templates. Pane context menu (Paste, Select All, Fit View, Auto Layout).
• Workflow Phase 3 Nodes: SubWorkflow + ENV — 2 new node types (25 nodes total), 14 new tests (306 total), 14 built-in templates. SubWorkflow: full DB-backed nested workflow executor with target workflow selection, variable mapping, and configurable depth limit to prevent infinite recursion. ENV: reads encrypted environment variables with key picker and fallback defaults. Full frontend (node components, config panels, palette entries, minimap colors). Per-node execution statistics panel (success rates, durations, failure counts sorted worst-first). getNodeStats API client + NodeStatEntry type. Keyboard shortcuts dialog (? key).
• Workflow Scheduled Triggers: Per-workflow cron configuration with timezone, default inputs, and next-run-at calculation. Preset cron buttons, 30 trigger tests.
• Workflow API Triggers: Public per-workflow API keys (wf_ prefix) for external execution without user auth, with rate limiting. API key management dialog with generate/regenerate/revoke, trigger URL, and cURL/JS examples.
• Workflow Batch Execution: POST /batch-run with up to 100 input sets, configurable parallelism (1-10), collapsible per-item results, JSON export. 14 batch execution tests.
• Workflow Execution Log Viewer: Real-time chronological SSE event stream in the run panel with timestamps, color-coded badges, and event type filter toggles.
• Workflow Run Stats: Backend batch-fetches run counts and success rates via GROUP BY subquery; frontend displays stats on workflow cards with color-coded success rate indicators.
• Workflow Scheduler Daemon: Background async service polling every 60s for due cron-based workflows. Croniter timezone support, semaphore concurrency, last_scheduled_at tracking, webhook delivery. 14 tests.
• Workflow Import Conflict Resolver: Detects unresolved agent/connector/KB/MCP references during import. Batch DB queries with visibility filtering, frontend toast warnings. 17 tests.
• Workflow Test-Node Execution: Isolated single-node testing with mock variables, integrated into editor (config panel Test button + context menu). 23 tests.
• Workflow Version Diff: Side-by-side blueprint comparison with node/edge change detection, color-coded indicators (added/removed/modified).
• Workflow Run Management: Delete individual runs (DELETE /runs/{run_id}) and clear all completed runs (DELETE /runs), with frontend confirmation dialogs.
• Workflow Run Replay Overlay: “View on Canvas” button in run history to overlay past execution results on the canvas, showing per-node status and output without re-executing.
• Workflow Favorites/Pinning: Star/pin workflows to the top of the list with localStorage persistence.
• Workflow Run History Export: Export run history as JSON file download with full run metadata and per-node results.
• Admin Workflows Management: Admin panel tab for managing all workflows across users — list, toggle active/inactive, delete with confirmation. Batch endpoints for delete, toggle, and publish with audit logging.
• Workflow Templates System: WorkflowTemplate ORM model with admin CRUD, public listing/clone API, and 5 seed templates auto-inserted on first startup.
• Workflow Inline Validation Badges: Real-time per-node ValidationBadge on canvas with error/warning tooltips for immediate visual feedback during editing.
• Workflow Execution Trace Viewer: Timeline-based trace viewer Sheet with engine trace_level parameter and per-node variable snapshots for step-through debugging.
• Workflow Rate Limiting and Timeout: Per-user WorkflowRateLimiter (sliding window 10 runs/min, 3 concurrent) and default 10-minute global run timeout.
• Workflow Blueprint System: Visual workflow editor for designing and executing multi-step automation blueprints — Workflow / WorkflowRun ORM models, full CRUD + SSE execution API, import/export, duplicate, blueprint validation endpoint, WorkflowEngine with topological sort + semaphore-based concurrency + condition branching and 12 node types (Start, End, LLM, ConditionBranch, QuestionClassifier, Agent, KnowledgeRetrieval, Connector, HTTPRequest, VariableAssign, TemplateTransform, CodeExecution), VariableStore with {{node_id.output}} interpolation and env.* namespace, error strategies per node (STOP_WORKFLOW / CONTINUE / FAIL_BRANCH) with per-node timeout and advanced config UI, React Flow v12 visual editor with drag-and-drop palette + node config panel + variable picker combobox + add-node-on-edge + auto-layout (ELK.js) + run history sheet, Dify-style compact node design with ring-based run status styling and animated edge transitions, 4 built-in starter templates (Simple LLM Chain, Conditional Router, Knowledge-Augmented QA, HTTP API Pipeline) with template picker dialog and GET /templates + POST /from-template API, stats endpoint, ?run=true URL param auto-open, subprocess-based code execution security, 105-test suite (templates, eval namespace flattening, blueprint validation warnings, node/edge deletion, import/export/duplicate, deadlock detection, multi-condition branching)
• Operation audit: detailed logging of who did what — admin review log audit tab added (publish review trail per org/resource)
• Semantic Schema Annotations: extend connector schema fields with semantic_tag, description, and pii flags; annotations surfaced in LLM tool descriptions so the agent understands field intent without guessing from column names

​

v0.8.1 (2026-03-29) — Progressive Disclosure Maturity + ReAct Hardening

• Progressive disclosure for DB connectors (DatabaseMetaTool), MCP servers (MCPServerMetaTool), and on-demand tool loading (request_tools meta-tool)
• DAG quality overhaul (5 improvements: model upgrade, skill auto-discovery, citation verifier, structured content preservation, domain-aware routing)
• Domain model escalation in ReAct (specialist domains auto-escalate to reasoning model)
• Per-model Native Function Calling toggle (tool_choice_enabled)
• ReAct cycle detection (deterministic duplicate tool call prevention)
• ReAct completion checklist (pre-answer verification when tools were used)
• Resource Fork Phase 1 (MCP Server + Skill fork endpoints with lineage tracking)
• Workflow Connection Dep Auto-Subscribe (recursive sub-workflow dependency resolution)
• Prebuilt Solution Templates (8 vertical solutions seeded to Market on first registration)
• Admin notification improvements (timezone-aware, master switch, SMTP Reply-To)
• Per-turn token budget circuit breaker (REACT_MAX_TURN_TOKENS)
• Centralized tool truncation, dynamic system prompt budgeting
• File attachment download, duplicate message submission fix

​

v0.8.2 (2026-04-10) — Agent Core Hardening + Vision Documents

• Agent Core Phase 0 — Compact prompt upgraded to 9-section structured format; empty tool result protection (descriptive message instead of (no output)); anti-loop prompt + cycle detection threshold lowered to 2; domain classifier + pre-flight DB config resolution parallelized (400–1100 ms saved per request); SSE end event sent immediately after answer, with title/suggestions moved to background tasks
• Agent Core Phase 1 (Context Anti-Bloat) — MicroCompact rule-based old tool result cleanup (keep last 6); REACT_TOOL_RESULT_BUDGET=40000 aggregate cap; reactive compact on context overflow (auto-compact to 50% budget and retry instead of crashing)
• Agent Core Phase 2 (Speed) — Keyword-based tool pre-selection (skips LLM call on obvious matches, 200–500 ms saved); SharedHttpClient LLM connection pooling; completion check skipped for answers >200 tokens; FallbackLLM wraps primary+fast with automatic failover on 429/503/529/connection errors
• Intelligent Document Processing (Vision-Aware) — Adaptive document handling: PDF pages rendered as images via PyMuPDF for vision-capable models (GPT-4o, Claude 3/4, Gemini), text-only fallback via pdfplumber. Per-model supports_vision flag. Modes via DOCUMENT_PROCESSING_MODE, DOCUMENT_VISION_DPI, DOCUMENT_VISION_MAX_PAGES. DOCX/PPTX embedded image extraction. Multi-turn vision persistence across conversation turns. Smart PDF processing (text-rich pages extract text + images; scanned pages render as full-page PNG). Pre-built sandbox image (Dockerfile.sandbox) with common data-science packages for --network=none code execution
• Resource Fork completion — Agent / Connector / Workflow fork endpoints added, completing the five-type lineage tracking (KB fork removed — inherently user-local)
• File integrity guardrail — System prompt rule prevents the agent from substituting unrelated file contents when a target file is unreadable; uploaded files now include file_id in message context for direct read_uploaded_file access

​

v0.8.3 (2026-04-16) — Universal Document Conversion + Agent Core Phase 3

• Universal Document Conversion (convert_to_markdown + OCR) — Built-in Agent tool wrapping Microsoft MarkItDown; converts PDF, Word, Excel, PowerPoint, HTML, JSON, CSV, XML, ZIP, EPUB, Outlook .msg, images, audio, YouTube URLs to Markdown. LiteLLMOpenAIShim enables OCR via any vision-capable LLM (Claude, Gemini, Bedrock, Azure). Vision-aware RAG ingestion with zero-regression text-only fallback. LLM_SUPPORTS_VISION env var for opt-out
• Agent Core Phase 3 (Runtime Invariant Hardening) — Conversation recovery (dangling tool_use auto-repair); structured compact work card (WorkCard typed merge across compaction rounds); turn-level profiler (REACT_TURN_PROFILE_ENABLED); per-user rate limiting (LLM_RATE_LIMIT_PER_USER); empty-content assistant message with tool_calls no longer dropped

​

v0.8.4 (2026-04-17) — Prompt Cache + Reasoning Correctness

• System prompt section registry with cache breakpoints — Memoized PromptRegistry splits system prompts into stable prefix + dynamic suffix; cache-capable providers (Claude, Bedrock Anthropic, Vertex Claude) receive cache_control: {"type": "ephemeral"} on the prefix for ~60-80% per-turn input token savings. Non-cache providers get a single concatenated message (zero behavior change)
• Prompt cache observability — cache_read_input_tokens and cache_creation_input_tokens tracked through UsageSummary → TurnProfiler → done_payload.cache field. Structured turn_cache log line per turn. Doubles as relay cache-honesty probe
• Conversation recovery MVP — Synthetic tool_result rows persist after interrupted turns; POST /chat/resume replays cached SSE events from a monotonic cursor; frontend useSseResume hook auto-reconnects with exponential backoff (300ms → 1s → 3s, max 3 attempts) and “Reconnecting…” indicator
• Thinking-block persistence with signature — reasoning_content + Anthropic signature persisted in metadata_["thinking"] and replayed on subsequent turns; fixes HTTP 400 signature mismatch on Claude 4 multi-turn conversations
• Provider-aware reasoning replay policy — Centralized reasoning_replay_policy() in core/prompt/reasoning.py gates serialization per provider family: Claude replays thinking blocks with signature; DeepSeek-R1/Qwen-QwQ/Gemini-thinking/o-series drop reasoning_content on outbound (previously leaked, breaking provider KV caches and violating API docs)

​

v0.8.5 (2026-04-23) — Intégration de canaux + Système de hooks + i18n contributeur

• Canal Feishu (sous-ensemble Phase 1) — Ressource Channel à portée organisationnelle avec identifiants chiffrés par Fernet ; FeishuChannel prend en charge l’envoi de cartes interactives + callback (vérification de signature + défi d’URL) ; Interface de gestion Paramètres → Canaux (liste, créer/modifier avec protection d’état modifié, détails avec URL de callback copiable, test-envoi) ; API CRUD (/api/channels) et point de terminaison de callback d’événement (/api/channels/{id}/callback). Livré en avance 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é lorsqu’un agent appelle un outil requires_confirmation=True, bloque l’exécution, et reprend ou interrompt selon le verdict
• Portail de confirmation configurable (inline OU canal) — Chaque agent reçoit une section Approbation avec trois modes de routage (Auto / Inline seulement / Canal seulement), 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 se replie gracieusement sur une carte d’approbation inline en l’absence de canal 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 exécution peuvent envoyer une carte de synthèse au canal de l’org à la fin d’une tâche. Premier consommateur du pattern de notification sortante générique
• Terrain de jeu d’approbation de hooks — La feuille de détails des canaux dispose d’une action « Tester le flux d’approbation » qui exécute le chemin de production complet (véritable ligne ConfirmationRequest, véritable callback Feishu, transitions d’état) — le même chemin de code qu’un hook de production
• Fallback CI i18n convivial pour les contributeurs — .github/workflows/i18n-sync.yml traduit EN → ZH/JA/KO/DE/FR sur master après fusion de PR et commit automatique avec [skip ci] ; les contributeurs n’ont plus besoin de LLM_API_KEY localement. La garde de pré-commit refuses les édits manuels aux fichiers de locale générés (ALLOW_LOCALE_EDIT=1 override pour les corrections de traduction légitimes). Vérification de bout en bout via test de fumée push
• Docs d’intégration Exa — Section Intégrations dédiée avec une première page Exa de classe présentant la surface de recherche Exa complète (neural / fast / deep-reasoning / instant), filtrage, récupération de contenu, et trois préconfigurations affinées
• Support de bases 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 à partir de la CLI
• Architecture des canaux + système de hooks docs — docs/architecture/hook-system.mdx explique les trois points de hook et parcourt FeishuGateHook de bout en bout ; les pages d’architecture existantes effectuent une liaison croisée ; README liste les canaux de messagerie comme une capacité de première classe
• Durcissement — Les clics de callback Feishu en double produisent une carte de remplacement au lieu d’une double décision ; les clics de callback concurrents sont résolus via une vérification du nombre de lignes UPDATE ... WHERE status='pending' conditionnel ; les approbations en attente expirent automatiquement après CHANNEL_CONFIRMATION_TTL_MINUTES (24h par défaut) via un nettoyeur d’arrière-plan ; Paramètres → Canaux respecte le rôle org (les membres voient une interface 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

​

v0.8.6 (2026-05-08) — Facturation Stripe + Améliorations

• MVP de facturation Stripe — Niveaux Gratuit + Pro ; Checkout, Portail Client, cycle de vie webhook ; /settings?tab=billing ; CRUD plan/abonnement administrateur ; l’application des quotas respecte le plan de chaque utilisateur
• Drapeau de fonctionnalité de facturation contrôlé par l’administrateur — system_settings.billing_enabled contrôle l’ensemble du pipeline Stripe afin que les déploiements privés sans identifiants Stripe ne présentent jamais une UX de paiement non fonctionnelle
• Quota illimité par utilisateur — vide hérite de la valeur par défaut globale, 0 accorde un accès illimité ; auparavant, les deux s’effondraient dans le même état
• Glossaire de traduction comme source unique de vérité — scripts/translation-glossary.md consolide les règles par locale ; pre-commit refuse inconditionnellement les modifications manuelles aux fichiers de locale générés
• Licence + loi applicable migrées vers FIM Labs Pte. Ltd. (Singapour) ; arbitrage SIAC en anglais ; nouveau fichier NOTICE de haut niveau
• Suggestions de suivi du Playground restaurées, opt-in par agent
• Correctifs de stabilité — historique de fournisseur à alternance stricte, détection de limite d’appel d’outil parallèle, flux de confirmation d’agent non lié, contrôle d’accès au rôle de canal, suppression de duplication de nouvelle tentative, pas de paraphrase post-rejet

​

v0.8.7 (2026-06-10) — Durcissement de la sécurité + Guardrails v0 + Correction de la facturation

• Confinement du type de jeton JWT — corrige une faille d’authentification 2FA où tout jeton signé de la même manière (temp/refresh/ticket) pouvait authentifier les points de terminaison API et SSE
• Durcissement OAuth — la liaison automatique d’e-mail nécessite un e-mail vérifié par le fournisseur (correction de la prise de contrôle de compte) ; les jetons d’actualisation OAuth sont stockés hachés pour que la rotation de session fonctionne
• Guardrails de contenu v0 — couche de détection d’entrée/sortie (core/agent/guardrail) ; inclut un détecteur de jailbreak + un guardrail de longueur de sortie maximale, configuré via variable d’environnement
• file_ops.apply_patch — Correctifs de diff V4A avec correspondance floue des espaces, complète find_replace
• Correction de la facturation de cycle — réinitialisation des quotas à l’anniversaire de l’abonnement (pas au mois calendaire) ; les renouvellements avancent la période via une recherche Stripe faisant autorité ; l’affichage de l’utilisation aligné à la fenêtre d’application
• Corrections de fiabilité — fuite d’appel d’outil pseudo-protocole supprimée des réponses ; fin de keep-alive HTTP réglable met fin aux pics APIConnectionError ; les statistiques d’utilisation de clé API persistent lors des demandes en lecture seule
• Refonte visuelle de l’onglet Facturation — largeur complète, cohérente avec les autres onglets Paramètres

​

Versions Prévues

​

v0.9 — Observabilité + Durcissement de production

​

Auth & Security Hardening

• JWT token-type confinement (2FA bypass) + OAuth account-takeover & session fixes (shipped in v0.8.7)
• PostgreSQL timezone-aware timestamps (shipped in v0.8.6)
• Force-logout timestamp comparison normalizes tz-aware/naive values to UTC by conversion — revoked tokens reliably rejected on both SQLite and PostgreSQL
• Docker Compose PostgreSQL credentials overridable via POSTGRES_* env (single-sourced into the connection string) — no more accidentally-shipped fim:fim default on exposed deployments

​

Connecteur + outillage

• Phase 3-4 de divulgation progressive du connecteur — ConnectorExecutor unifié (API/DB/MCP) ; validation d’action jsonschema ; découverte/exécution agnostique du protocole
• Configuration du connecteur YAML/JSON — la plateforme génère automatiquement le serveur MCP
• Connecteurs de base de données Phase 4 — Oracle (oracledb), SQL Server (aioodbc), GBase (aioodbc + GBase ODBC). DM8 / KingbaseES / HighGo livrés en v0.8.5
• Mise en pool des connexions MCP — pool STDIO avec isolation d’environnement par utilisateur ; partage de httpx.AsyncClient pour SSE/HTTP. Cible ≤100 ms de démarrage à chaud, O(1) connexions HTTP par serveur

​

Garde-fous de contenu

• Garde-fous de contenu v0 (détecteur de tripwire entrée/sortie, détecteur de jailbreak, config var env, événement SSE guardrail_tripwired) (livré en v0.8.7)
• Filtre hors sujet (garde-fou d’entrée basé sur classificateur) — reporter à v0.5 si regex reste suffisant
• Garde-fou de sortie rédacteur PII (hybride regex + classificateur)
• Interface de configuration de garde-fou par agent (panneau admin)

​

Hook System

• Per-hook config pass-through ({"name": ..., "config": {...}} schema)
• DAG tools_used accuracy (real tool names from per-step ReAct via step-completion callback)
• Hook inheritance for CallAgentTool + Workflow AGENT nodes (security default vs flexibility default)
• Built-in hooks: ConnectorCallLog autorecord, read-only-mode block, DB result truncation, per-connector rate-limit
• SessionStart hook point + user-defined YAML hooks
• Skeleton + FeishuGateHook + Approval Playground + ReAct/DAG runtime (shipped in v0.8.5)

​

Intégration de canal IM

• Canaux : WeCom, Slack, Email, Teams sortants
• Modèles sortants : alertes de défaillance, avertissements de budget, digests programmés, escalade, reçus d’audit, escalade d’approbation
• Phase 2 — Déclencheur entrant (mention @agent dans le groupe IM)
• Canal Feishu (sous-ensemble Phase 1) + notification d’achèvement de tâche (livré dans v0.8.5)

​

Couches d’autorisation des connecteurs

• Tier 1 — Mode BD (ConnectorScopeGuard hook PreToolUse : blocage de verbe, liste d’autorisation/refus de table, masquage de colonne, injection de prédicat de portée)
• Tier 2 — Mode API ouvert (interface utilisateur d’administration pour exiger des identifiants par utilisateur ; tableau de bord de santé de la liaison de clé)
• Tier 3 — Échange de ticket de connexion (LoginTicketCredential pour les systèmes avec séparation frontend/backend sans clé API étendue à l’utilisateur)
• Auditabilité inter-tier (caller_user_id, effective_credential_source, scope_rules_applied dans ConnectorCallLog)

​

Identity Provider Module + Channel Slim-down

• identity_providers + user_identity_map modèles — configuration SSO/OAuth par organisation au niveau de la base de données remplaçant la connexion tierce au niveau ENV
• Feishu SSO via IdP (“Login with Feishu” génère une session FIM + jeton en amont, supprime les frictions de clé API par utilisateur pour Tier-2)
• Synchronisation du graphe d’organisation via IdP (départements Feishu → arborescence d’organisation FIM) ; WeCom + DingTalk ensuite
• Channel se réduit à Delivery + Gate ; les capacités d’identité (SSO / OrgSync) résident uniquement dans IdP

​

Public API Phase 2

• Limitation de débit par clé (X-RateLimit-* headers, 429)
• Quota d’utilisation par clé (budget mensuel de tokens/requêtes)
• Traitement par lot des statistiques d’utilisation pour les clés à haut QPS (flush local au processus, comptages exacts, aucune nouvelle dépendance) — reporté jusqu’à identification d’un goulot d’étranglement mesuré
• Application des scopes par endpoint
• Versioning des API (/v1/...) + headers de dépréciation
• Callbacks Webhook (par clé)
• Génération SDK (Python + TypeScript)
• Portail développeur (panneaux Try-it + analytique par clé)
• Rotation des clés API (délai de grâce de 24h)
• API Batch / asynchrone (POST /api/batch)
• Disjoncteur par dépendance externe

​

Observabilité

• Agent Trace Layer — Modèle Trace/Span, visionneuse de chronologie frontend, export OTel (exécution/trace/fil de niveau application de style LangSmith)
• Tableau de bord des métriques — latence, taux de succès, utilisation des jetons, analyse des connecteurs (par agent / utilisateur / organisation)

​

Agent Workspace

• Tool Output Offloading — URIs workspace:// pour les réponses >8K + outils read/list/write_workspace_file
• Handoff Notes — write_handoff(summary) survit à la compaction
• Workspace UI — navigateur de fichiers par conversation ; conservation entre sessions ; quota de stockage par utilisateur
• Cross-session conversation recall — outils list_conversations, search_conversations, read_conversation

​

Cache de prompt + suites de raisonnement

• Adaptateur Gemini Context Cache (cycle de vie de cache REST séparé vs marqueur inline Anthropic)
• Expansion du registre de prompts vers planificateur / vérificateur / classificateur de domaine / compact
• cache_ttl par agent (éphémère 5 min vs étendu 1 h)
• Table de points de contrôle au niveau des étapes DAG pour reprise en milieu de DAG
• Colonne Message tool_call_id dédiée (recherche d’orphelins indexée à grande échelle)
• Reconstruction de tokens de réflexion en milieu de flux (granularité de reprise plus fine qu’événement SSE complet)
• Sonde d’honnêteté de cache de relais API (déclenchée par l’admin : détecte les relais supprimant cache_control)

​

Suivi de la fiabilité (Matrice des priorités de l’Agent Core)

• Persistance de l’état de remplacement de contenu (invariant de flux #2 : « une fois vu, sort figé »)
• Routeur de contexte des pièces jointes (dédupplication, agrégation budgétaire, vérifications de vitalité ; s’associe au déchargement de l’espace de travail)
• Travailleurs de requêtes secondaires (pools dédiés pour la récupération / classification / résumé afin qu’ils ne rivalisent pas pour le budget de limite de débit principal)

​

Écosystème + mise à l’échelle

• Tâches planifiées + Agents déclenchés par événement — scheduled_jobs + job_runs + APScheduler; cron + webhook-inbound. Cas d’usage de sous-agent asynchrone pour le mode Hub
• Observabilité de l’identité du déclencheur de flux de travail — ExecutionContext.trigger_source (webhook | cron | manual | batch | sub) rempli sur les 5 sites WorkflowEngine; surfacé dans le panneau d’exécution et les journaux de connecteur
• Remplacement de credential_policy par flux de travail (owner / caller / auto) — remplace le mappage par défaut trigger_source → identity
• Générateur de schéma DB avancé — annotation pilotée par IA pour les déploiements de 1 000 à 7 000+ tables (sélectivité + raisonnement contextuel métier)
• Durcissement du bac à sable (isolation de l’exécution du code v2)
• Tests de performance (benchmarks de charge concurrente)
• Benchmark de harnais interne (quantifier les changements de paramètres de harnais via Eval Center)

​

Déjà livré en avance

• Circuit breaker, Workflow run retention cleanup, Workflow version diff summaries (v0.8 / v0.8.1)
• DAG quality overhaul, Domain model escalation, Per-model NFC toggle (v0.8.1)
• DatabaseMetaTool, MCPServerMetaTool, On-demand request_tools (v0.8.1)
• Workflow Connection Dep Auto-Subscribe, Workflow real executors (v0.8.1)
• ReAct Cycle Detection, Completion Checklist (v0.8.1)
• Prebuilt Solution Templates (8 vertical bundles), Resource Fork (MCP/Skill/Agent/Connector/Workflow) (v0.8.1)
• Vision document processing (PDF / DOCX / PPTX), MarkItDown OCR (v0.8.2 / v0.8.3)
• Smart File Content Injection + read_uploaded_file (v0.8)
• Agent Core Phase 3: Conversation Recovery MVP, Compact Work Card, Turn Profiler, Per-user Rate Limiting (v0.8.3)
• Conversation resume MVP, System prompt registry + cache, Thinking-block persistence, Reasoning replay policy, Cache observability (v0.8.4)

​

v1.0 — Hot-Plug + Embeddable

• Connector Progressive Disclosure (Phase 5): Semantic-Guided Tool Selection (entity extraction from query → Ontology Registry lookup → connector set reduction; 90%+ token reduction for 50+ connector deployments); Scale mode for batch/ETL connectors; CLI-style universal connector <name> <action> <params> interface
• Cross-Connector Entity Alignment (Ontology Registry) — downgraded 2026-04-21: on-demand custom delivery, not a core capability: define shared entity types (Customer, Order, Asset) with field mappings across connectors; DAGPlanner auto-resolves cross-system JOIN keys; enables cross-connector queries (e.g., “customers in Salesforce who ordered in Shopify”) without hardcoded field names
• Hot-plug connectors: upload OpenAPI spec, AI generates config, live in 5 minutes (no restart)
• Marketplace Redesign Phase 1 — Solutions + Components: Two-tier Market model (Solutions: Agent/Skill/Workflow; Components: Connector/MCP Server); scope selector (Global Market / org); unified subscription model (org auto-appear removed); KB removed from Market scope; data migration backfills subscriptions for existing org members
• Market Package System: Distributable resource bundles for the Marketplace — replaces per-type “marketplace” with a unified packaging layer. fim-package.yaml manifest declares: metadata (name, version, description, author, license, tags, min_fim_version), entry point (primary Skill or Agent), resource list (agents, skills, connectors, KBs, MCP servers, workflows) with config references, inter-package dependencies (semver ranges), required credentials (mapped to connector refs for install-time collection), and user-configurable variables with defaults. Two consumption modes: (1) install — batch-create all resources + auto-wire internal references via ID substitution; installation linked to source for version update notifications; POST /api/market/packages/{id}/install; (2) fork — clone as user-owned editable copies with no update link (this IS the template mode); POST /api/market/packages/{id}/fork. Additional endpoints: publish (POST /api/market/packages with review workflow), uninstall (DELETE /packages/{id}/uninstall with dependency check + modified-resource confirmation), version history (GET /packages/{id}/versions), upgrade (POST /packages/{id}/upgrade with per-resource diff preview). Dependency resolver for nested package requirements with conflict detection. PackageInstallation table tracks installed packages per user with resource ID mapping for uninstall/upgrade. Coexists with individual resource publishing — Package is a composition layer, not a replacement; a single Connector is still publishable standalone. Example dependency tree: Package: contract-review → Skill: contract-review (entry point) → Agent: contract-analyst + Agent: risk-scorer → KB: legal-clauses + Connector: docusign-api + MCP: pdf-extractor + Workflow: contract-approval-flow
• Creator Program: Marketplace monetization layer — creator profiles with portfolio pages, per-package analytics (installs, forks, active users, ratings/reviews), affiliate commission tracking when packages drive new subscriptions. Paid package tier with pricing, purchase flow, and approval workflow. Creator dashboard with install trends, revenue reporting, and user feedback. Public creator API for programmatic package publishing (CI/CD for package authors). Community features: package comments, Q&A, changelogs per version
• Embeddable widget: <script src="fim-one.js"> injected into host page
• Page context injection: widget reads host page context (current ID, URL, DOM selectors)
• Advanced triggers: Webhook inbound events; scheduled job enhancements (multi-timezone, calendar-aware)
• Batch execution: process 1000+ items via DAG
• Enterprise security: IP whitelisting, encryption at rest, SSO
• KB Advanced Editor: Builder-mode agent for power users managing large knowledge bases — bulk URL ingestion, duplicate detection, gap analysis, document lifecycle management; extends existing KB AI chat with ReAct tool loop
• Stripe Billing (v1 MVP — Pro Subscription): Free + Pro two-tier subscription with monthly token quota. Stripe Checkout (hosted) + Customer Portal (self-service) + webhook-driven lifecycle (checkout.session.completed / customer.subscription.updated|deleted / invoice.payment_succeeded|failed). Soft-cap at quota exhaustion (HTTP 402 + upgrade prompt) — no overage charges in v1. Per-user billing only; Org/Team subscriptions deferred to v3. Prerequisites:
  • Data model + SDK groundwork (P1) — billing_plans / subscriptions / stripe_webhook_events tables, ORM models, Stripe SDK singleton, Free + Pro seeds (shipped in v0.8.6)
  • Backend API + webhook handler (P2) — /api/billing/* + /api/webhooks/stripe with signature verification + idempotency; plan-aware quota; hourly lifecycle sweep (shipped in v0.8.6)
  • Frontend billing tab + 402 upgrade dialog (P3) — /settings?tab=billing quota display, upgrade CTA, past_due banner, mid-stream 402 dialog (shipped in v0.8.6)
  • Admin plan management (P4) — admin/billing/{plans,subscriptions} CRUD (shipped in v0.8.6)
  • Admin-controlled billing feature flag (P5) — system_settings.billing_enabled gates the Stripe pipeline; idempotent activation seeds Free+Pro, sets default plan pointer, backfills users; toggle off/on is pure flag flip after activation (shipped in v0.8.6)
  • Reconciliation + e2e + go-live (P6) — nightly subscriptions ↔ stripe.Subscription.list() reconcile script for missed-webhook recovery; full-stack happy-path / cancel-mid-period / past-due regression tests; switch from test-mode stripe_price_id to a live price_id; smoke test on staging with a real card.
• Team plan (Stripe seats) — Per-seat pricing via stripe.Subscription.quantity, integrated with Organization membership. Lets companies subscribe to one team-wide plan with N seats; quota and feature flags resolve through the seat group rather than the individual user. Builds on the v1.0 Stripe MVP and the existing Organization model.
• Group-level token quota for non-billing deployments — Enterprise / private deployments without Stripe configure organization-level token budgets. Quota chain extends to override > group > plan > default; group resolution uses max(user_quota, group_quota) so individual VIPs aren’t constrained by the team cap. Lands alongside the Team plan so the same primitives serve both billed and self-hosted topologies.

​

Fonctionnalités gelées (livrées, maintenance seulement)

​

À considérer (Reporté indéfiniment)

​

Comment les versions s’alignent avec les modes

​

Resource Allocation (v0.8–v1.0)

​

Jalons pilotés par les métriques

​

Open Questions / TBD

• Modération de la place de marché : Comment valider les packages communautaires et les ressources individuelles ? Analyse automatisée des fuites d’identifiants 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 majeurs dans les packages installés — mise à jour 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 ou payants, taux de commission pour le Creator Program, intégration de fournisseurs de paiement ? (v1.0)
• UX des identifiants de package : Collecte d’identifiants au moment de l’installation — étapes successives de style assistant ou configuration différée ? Partage d’identifiants entre packages utilisant le même type de connecteur ? (v1.0)
• Désabonnement de la télémétrie : Comment honorer les préférences de confidentialité ? (v0.8)
• Versioning des connecteurs : Comment gérer les changements majeurs dans les API des connecteurs ? (v0.8)
• Limitation de débit : Limitation de débit des workflows par utilisateur expédiée (fenêtre glissante 10 exécutions/min, 3 concurrentes). Limitation de débit par connecteur et par agent à définir (v0.9)
• Sélection du niveau d’autorisation du connecteur : comment un admin découvre-t-il quel niveau s’applique à un système en amont donné ? Auto-détection (essayer clé API par utilisateur → revenir à billet de connexion → revenir à base de données partagée) vs. déclaration explicite dans la spécification du connecteur ? Comment exprimer « ce connecteur supporte le niveau 2 mais l’admin a choisi de fonctionner en niveau 1 » dans l’interface sans confondre les admins non techniques ? (v0.9)
• Dualité Intégration vs Connecteur : quand une liaison Feishu est simultanément un fournisseur SSO ET une surface d’appel API, comment la présentons-nous dans Paramètres ? Un objet avec trois bascules, ou trois liaisons distinctes partageant un identifiant ? Implications pour la sémantique de désinstallation (révoquer SSO tue-t-il le Connecteur ?) (v0.9)