Fichier de configuration

Le fichier canonique est .agentflow/config.yaml, créé par agentflow init à partir de config.yaml.example. Sauf chemin absolu, AgentFlow le résout depuis la racine du dépôt. Pour une validation lisible par machine, le schéma JSON généré est publié sur le site docs à /schemas/config.schema.json.

Les sections qui suivent reprennent la disposition du fichier : chaque bloc pilote une facette du comportement (intention, paramètres d’exécution par défaut, sources, persistance, agents, validation, modèles, coût, routage, interface, MCP et politiques de dépôt).

project

project porte un nom lisible pour l’humain et la branche par défaut utilisée dans les flux orientés worktree.

project:
  name: my-project
  default_branch: main

intent

Le bloc intent configure la résolution en langage naturel pour work et continue (application/internal/intent) : si le résolveur s’exécute, le mode utilisé et le comportement quand la confiance est faible ou qu’Ollama est disponible en repli.

intent:
  enabled: true
  default_mode: guided   # guided | auto
  resolver:
    use_ollama_fallback: true
    min_confidence: 0.75
    ask_when_below_confidence: true

work

work fixe les paramètres transverses d’orchestration : quels agents assument quels rôles, où le pipeline s’arrête, les bascules de vérification et de revue, les limites de tâches, et si une confirmation du plan est exigée.

work:
  default_agent: cursor
  default_reviewer: codex
  default_enricher: ollama
  stop_after: report
  auto_verify: true
  auto_review: false
  max_tasks_per_run: 1
  require_plan_confirmation: true

sources

Les sources locales parcourent des chemins fixes pour les specs et le handoff actif ; Notion est optionnel et tire des instantanés vers l’arbre local. Le tableau résume les deux blocs ; le YAML montre des chemins typiques et les espaces réservés Notion.

sources:
  local:
    enabled: true
    paths:
      - .agentflow/specs
      - .kiro/specs
      - docs/ai/active
  notion:
    enabled: false
    token_env: NOTION_TOKEN
    specs_database_id: ""
    import_path: .agentflow/specs

specs, state, worktrees

Ces blocs raccordent les chemins de style Kiro vers les specs, l’état SQLite et la mise en page des worktrees. cleanup_policy fixe ce qu’il advient lorsqu’une exécution laisse des résidus sous worktrees.base_path.

specs:
  kiro_path: .kiro/specs
  active_spec_path: docs/ai/active/current-spec.md
  handoff_path: docs/ai/active/handoff.md

state:
  backend: sqlite
  path: .agentflow/state.sqlite

worktrees:
  base_path: .agentflow/worktrees
  branch_prefix: agentflow
  cleanup_policy: keep_failed

agents

Le mappage des identifiants d’agents logiques vers des commandes en sous-processus et des options spécifiques tient dans ce bloc ; la page dédiée décrit les champs et exemples : configuration des agents.

validation

validation.commands liste les contrôles que le pipeline peut exiger (tests, linter, scripts personnalisés). Pour les dépôts Go, l’initialisation propose souvent des valeurs pertinentes lorsque go.mod est présent.

validation:
  commands:
    - name: tests
      command: go test ./...
      required: true

models

models regroupe les profils logiques utilisés pour le routage et le coût (specv3). Les clés sont des identifiants arbitraires ; chaque entrée lie un fournisseur, une classe de coût, un nom de modèle et les classes d’étapes autorisées.

models:
  ollama_local_qwen:
    provider: ollama
    class: local
    model: qwen2.5-coder:14b
    input_cost_per_1m_tokens: 0
    output_cost_per_1m_tokens: 0
    usage: [summarize, classify, pre_review, context_selection]

budgets

Les plafonds par exécution, par tâche et quotidiens se trouvent sous budgets. Voir Budgets.

pricing

Les taux marginaux pour le cloud et le local viennent de votre YAML — aucun prix cloud n’est codé en dur dans le logiciel. Maintenez updated_at honnête pour savoir quand quelqu’un a aligné les chiffres sur une grille tarifaire.

pricing:
  currency: EUR
  models:
    gemini-3-flash-preview:
      input_per_1m_tokens: 0.00
      output_per_1m_tokens: 0.00
      source: manual
      updated_at: "2026-05-17"

token_estimation

Le budget en jetons repose sur des heuristiques « caractères par jeton » (application/internal/cost/token_counter.go). Ajuster ces ratios rapproche les estimations du profil réel de vos contenus (code dense contre prose dense).

token_estimation:
  default_chars_per_token: 4.0
  code_chars_per_token: 3.2
  markdown_chars_per_token: 4.2
  json_chars_per_token: 3.6

routing

Les classes d’étapes se mappent vers des agents locaux ou cloud via routing. Détails : Routage.

ui

Le comportement du terminal vit sous ui (application/internal/tui) : mode de rendu, journaux temps réel, barres de progression et sortie compacte.

ui:
  mode: auto      # auto | rich | plain | json
  live_logs: true
  progress_bars: true
  compact: false

mcp

Lorsque mcp.enabled vaut true, AgentFlow peut exécuter un serveur MCP stdio local avec des délais d’outil, des limites de sortie, des plafonds d’investigation et des chemins que l’outillage ne doit pas lire.

mcp:
  enabled: false
  max_output_bytes: 1048576
  command_timeout_seconds: 120
  secret_path_denylist: [".env", "credentials.json", "id_rsa"]
  investigation:
    large_file_bytes: 524288
    max_grep_output_bytes: 262144
    command_timeout_seconds: 120
    sensitive_globs: ["*.pem", ".git/*"]

policies

policies encode les garde-fous au niveau dépôt : git propre, motifs de fichiers secrets, nombre maximal de fichiers modifiés, autorisation réseau, et étiquettes exigeant validation humaine avant certaines familles de changements.

policies:
  require_clean_git: true
  forbid_untracked_secret_files: true
  max_files_changed_per_task: 20
  allow_network: false
  require_human_approval_for:
    - database_migration
    - security_sensitive_change
    - dependency_upgrade

Valider les modifications

Après avoir édité le YAML, agentflow doctor est le contrôle rapide avant un work sur de vrais agents.

agentflow doctor