Référence de configuration

Ceci est la référence clé par clé de config.toml. Le fichier annoté config.toml.example à la racine du dépôt Takuto Core fait foi — quand cette page et ce fichier divergent, c’est l’exemple qui l’emporte.

Les réglages sont rechargés à chaque changement de fichier (un poller toutes les 5 secondes). Quelques clés sont startup-only et nécessitent un redémarrage (signalé en ligne). Les secrets vont dans takuto.env, jamais dans config.toml — voir Variables d’environnement.

Takuto Core répartit la config en deux types :

• Bootstrap — nécessaire avant que la base de données/le dashboard n’existent, ou appliqué uniquement au démarrage. Éditez-les à la main dans config.toml avant le premier démarrage.
• Géré par l’UI — a une valeur par défaut sensée et s’édite normalement depuis un écran Configuration du dashboard. L’UI réécrit les changements dans config.toml, donc le fichier reste le magasin de référence ; une valeur définie ici n’est qu’une valeur par défaut au moment du déploiement.

La colonne Scope marque chaque clé comme Bootstrap ou nomme la surface du dashboard qui la gère. 🔒 marque les clés sensibles pour la sécurité — à revoir avant de les changer dans un déploiement partagé.

[general]

Comportement à l’échelle du processus : mode de ticketing, polling, concurrence, logging.

[jira]

Utilisé uniquement quand [general] ticketing_system = "jira".

[polling]

Politique de polling d’éléments ajustable par l’admin : quels éléments découverts les pollers ajoutent automatiquement, quel flow ils auto-démarrent, et combien tournent en parallèle. Lue en direct à chaque cycle (pas de redémarrage). Toutes les clés [polling] sont gérées par l’UI depuis Configuration → Item Polling.

[polling.jira]

[polling.github]

[git]

Toutes les clés [git] sont des réglages Bootstrap.

[github]

Authentification GitHub App optionnelle. Quand elle est configurée, les commits et les PR sont attribués au compte bot plutôt qu’à votre utilisateur gh personnel. Les trois champs (app_id, app_installation_id et une source de clé privée) doivent être définis ensemble ; les erreurs ne sont pas fatales — Takuto Core bascule sur l’auth gh personnelle et logge un avertissement. Permissions App requises : contents (write), pull_requests (write), metadata (read).

[web]

Le serveur du dashboard.

L’authentification est multi-utilisateur uniquement. Au premier démarrage, le dashboard vous invite à créer le compte admin initial. Les anciennes clés mono-utilisateur [web] dashboard_username / dashboard_password ont été retirées — si elles sont présentes dans un vieux config.toml, elles sont silencieusement ignorées.

Politiques de session (non configurables) : TTL d’inactivité 24 h ; TTL absolu 30 jours ; verrouillage du compte après 5 tentatives échouées de connexion/récupération en 10 min (l’admin déverrouille via POST /api/users/{id}/unlock) ; limite de débit par IP sur /api/auth/login et /api/auth/recover de 10 / minute.

[database]

Là où Takuto stocke les utilisateurs, les sessions et les snapshots. Omettez la section (ou laissez connection vide) pour conserver le défaut SQLite zéro-config à {data_dir}/takuto.db. Définissez connection pour utiliser un PostgreSQL / MariaDB / MySQL externe. Au démarrage uniquement — PUT /api/config ne patche pas cette section ; changer de backend nécessite un redémarrage du processus.

Vous faites tourner la base dans un container ? L’hôte de connection doit être joignable depuis l’intérieur du container Takuto — utilisez le nom de container de la base et son port interne (par ex. takuto_db:5432), pas localhost ni le port publié sur l’hôte (par ex. localhost:5433), et placez les deux containers sur le même réseau. Le pas-à-pas complet est dans Base de données externe.

[agent]

Le fournisseur d’IA pour les étapes de workflow portant un prompt. Chaque clé [agent] est gérée par l’UI depuis Configuration → AI Settings ; les valeurs ici sont des valeurs par défaut au moment du déploiement.

Les réglages par fournisseur (modèle, endpoint, chemin du CLI, args supplémentaires) vivent dans les sous-tables [agent.providers.<name>]. Champs communs : model, extra_args, allow_shared_default ; Claude/Codex/OpenCode utilisent base_url, Cursor utilise cli.

[agent.providers.cursor]

Utilisé uniquement quand provider = "cursor".

[agent.providers.opencode]

L’adaptateur OpenCode (auto-hébergé, compatible OpenAI). Utilisé uniquement quand provider = "opencode". Voir Modèles auto-hébergés.

Claude et Codex utilisent leurs propres sous-tables [agent.providers.claude] / [agent.providers.codex] avec model, base_url et extra_args, tous éditables depuis Configuration → AI Settings.

[docker]

Toutes les clés [docker] sont Bootstrap (consommées au build d’image / au compose up).

[editor]

Le VS Code dans le navigateur (openvscode-server) et le transfert de port dynamique. Toutes les clés [editor] sont Bootstrap.

[terminal]

Le terminal web (ttyd) dans le container de l’éditeur. Toutes les clés [terminal] sont Bootstrap.

[network]

Politique de firewall — au moment du déploiement uniquement. Toutes les clés [network] sont Bootstrap.

L’allowlist est provider-aware : le firewall autorise automatiquement les hôtes d’API du ou des fournisseurs d’IA que vous activez — le [agent].provider actif plus chaque fournisseur listé dans [agent].available_providers (Claude, Codex/OpenAI, Cursor), ainsi que tout base_url auto-hébergé. Avec la config par défaut (les quatre fournisseurs disponibles), chaque éditeur pris en charge est joignable d’emblée ; réduisez available_providers pour resserrer le firewall aux seuls fournisseurs que vous utilisez. Les hôtes exacts sont résolus au moment de l’application par la commande takuto egress-hosts du moteur.

[provisioning]

Outils CLI supplémentaires installés dans le volume d’outils partagé au démarrage, en plus de ceux intégrés à l’image. Utilisez-le pour épingler une version d’outil, ajouter un outil retiré de l’image, ou en sauter un entièrement. Bootstrap (appliqué au démarrage). Voir Étendre Takuto Core.

[dev]

Réglages réservés au dev. À laisser commentés en production. Toutes les clés [dev] sont Bootstrap.

Sections ignorées

Les sections suivantes sont entièrement ignorées au chargement — un avertissement de démarrage est loggué pour que vous le remarquiez, mais leur contenu n’est jamais lu. Elles ont quitté config.toml parce qu’elles sont par utilisateur et par espace de travail, et vivent désormais uniquement dans la base de données, éditées depuis le dashboard :

• [commands] — les commandes d’initialisation de worktree (autrefois pre_install, install, pre_workflow, désormais worktree_init_commands) vivent dans la base de données, résolues par (user, workspace) et éditées depuis Configuration → Worktree Settings.
• [[run_commands]] — les commandes de dev-server longue durée affichées comme boutons run/stop sont par utilisateur et configurées depuis le même onglet Worktree Settings.

Il n’y a aucun fallback de config : si une section est absente de la base de données, le workflow n’exécute simplement aucune commande pour elle.

Variables d’environnement

Les secrets et les overrides par hôte vont dans takuto.env (monté sur /etc/maestro/env). Seules les lignes export VAR=value sont prises en compte.

Exemple de takuto.env :

export ANTHROPIC_API_KEY="sk-ant-..."
export GH_TOKEN="github_pat_..."
export ANTHROPIC_BASE_URL="https://custom-proxy.example.com/claude"