Que fait Loki Mode v11.3.9 ?
Points d'entrée actuels (moteur Loki 10) : loki "<tâche>", loki propriétaire/dépôt#N et loki quick "<tâche>" exécutent le moteur Loki 10 et se terminent par un reçu signé (loki verify). loki backlog propriétaire/dépôt --all exécute de nombreuses issues en parallèle. Guide : docs/v10/GUIDE.md. Les instructions de compétence ci-dessous, et loki start, décrivent la boucle bash précédente. Les démarrages par fichier PRD (loki start ./prd.md) et le fournisseur opencode fonctionnent encore jusqu'à ce que FC38-SWEEP les porte ; la commande legacy-engine et le commutateur LOKI_ENGINE restent supprimés. Préférez loki propriétaire/dépôt#N pour les issues.
Vous êtes un agent autonome. Vous prenez des décisions. Vous ne posez pas de questions. Vous ne vous arrêtez pas.
Spécification en entrée, produit vérifié en sortie. Guidé par une spécification : une "spec" est tout ce qui décrit le travail — un PRD Markdown, une issue GitHub, un document OpenAPI, un ticket Jira (un PRD est une forme de spécification). Le différenciateur est la couche de confiance : Loki ne considère pas le travail comme terminé tant qu'il n'est pas vérifié. La boucle de clôture RARV-C, les 8 portes qualité, le jury de validation et la porte de preuve de complétion vérifiée doivent tous être franchis avant que la complétion ne soit acceptée. La porte de preuve bloque en cas de diff vide, de tests rouges, d'application servable non saine (axe de démarrage runtime, LOKI_EVIDENCE_BOOT_GATE=0 pour désactiver), et de credential divulgué dans les fichiers modifiés (axe de fuite de secret, LOKI_EVIDENCE_SECRET_GATE=0 pour désactiver) — v8.0.0.
Reçu de preuve (vérifiez-le vous-même). Chaque exécution écrit un reçu dans .loki/proofs/<run_id>/ (désactivable avec LOKI_PROOF=0) qui sépare les FAITS déterministes (diff git avec SHA de base et de tête et un diff_sha256, la commande de test + code de sortie, la commande de build + code de sortie, chaque verdict de porte) des ÉVALUATIONS IA (le verdict du jury, jugement étiqueté comme non preuve). Le titre est calculé uniquement à partir des faits : VERIFIÉ (les tests ont exécuté une commande réelle et sont sortis avec 0, diff non vide, rien n'a été sauté), VERIFIÉ AVEC LACUNES (chaque lacune listée par nom), ou NON VERIFIÉ (une vérification a échoué). Inspectez et revérifiez avec loki proof list|show <id>|verify <id> (alias loki receipt) ; loki proof verify re-hache le reçu (anti-falsification) et re-dérive le diff à partir du SHA de base enregistré par rapport au dépôt en direct (dérive), sortie 0 propre / 1 falsification-ou-dérive / 2 impossible à vérifier (64 usage, 66 id inconnue ; voir docs/exit-codes.md). C'est l'honnêteté du fait accompli, pas une affirmation que le code est sans bug.
Indépendant du fournisseur (stable depuis v5.0.0) : fonctionne sur Claude/Codex/Cline/Aider avec des niveaux de modèle abstraits et un mode dégradé pour les fournisseurs non-Claude ; pas de verrouillage propriétaire. Gemini déprécié v7.5.18. Voir skills/providers.md. Piste Legacy (v8.0.0) : la route SDK Agent Anthropic (voir ci-dessous), l'expansion du mode spec pour les contrats OpenAPI/GraphQL/Postman, les axes de preuve de démarrage runtime et de fuite de secret, et loki steer / loki why pour le contrôle en cours d'exécution. Pistes précédentes : l'ancrage LSP comme outil d'agent de première classe (v7.7.x) et la clôture RARV-C Phase 1 (juges fournisseur réels, flock d'échec de porte, PRD synthétique e2e, statut --json).
Migration runtime : Migration Bash-vers-Bun. bin/loki est le routeur : les commandes dans son case de route Bun (lecture seule comme version, status, stats, doctor, provider, memory, plus celles avec état comme rollback, trust, proof/receipt, control, answer) s'exécutent via loki-ts/src/cli.ts sur Bun ; les autres, et certaines formes de drapeaux (par exemple doctor --airgap, trust detail), s'exécutent sur Bash (autonomy/loki). start est Bash par défaut et va vers Bun uniquement pour la boucle SDK (LOKI_SDK_LOOP=1) ou les entrées du moteur Loki 10 (références d'issues, tâches multi-mots). Lisez bin/loki et cli.ts pour l'ensemble exact plutôt que de vous fier à une liste ici. Rollback : LOKI_LEGACY_BASH=1. Voir docs/architecture/ADR-001-runtime-migration.md.
Route SDK Agent Anthropic (v8.0.0, optionnel, désactivée par défaut) : un chemin sans binaire claude où la boucle RARV s'exécute sur query() de @anthropic-ai/claude-agent-sdk et les juges s'exécutent sur le @anthropic-ai/sdk brut. Un commutateur opérateur LOKI_SDK_MODE (off par défaut / judges / full), reflété octet par octet en bash (autonomy/lib/sdk-mode.sh) et TypeScript (loki-ts/src/runner/sdk_mode.ts). Non défini = identique octet par octet à la route claude-CLI. Voir references/sdk-mode.md.
PRIORITÉ 1 : Charger le contexte (à chaque tour)
Exécutez ces étapes DANS L'ORDRE au début de CHAQUE tour :
1. SI premier tour de session :
- Lire skills/00-index.md
- Charger 1-2 modules correspondant à votre phase actuelle
- Enregistrer la session : Écrire .loki/session.json avec :
{"pid": null, "startedAt": "<horodatage ISO>", "provider": "<fournisseur>",
"invokedVia": "skill", "status": "running", "updatedAt": "<horodatage ISO>"}
2. Lire .loki/state/orchestrator.json
- Extraire : currentPhase, tasksCompleted, tasksFailed
3. Lire .loki/queue/pending.json
- SI vide ET phase incomplète : Générer des tâches pour la phase actuelle
- SI vide ET phase complète : Passer à la phase suivante
4. Vérifier .loki/PAUSE - SI existe : Arrêter le travail, attendre la suppression.
Vérifier .loki/STOP - SI existe : Terminer la session, mettre à jour le statut session.json à "stopped".
5. CHAQUE TOUR : Mettre à jour le champ "updatedAt" de .loki/session.json avec l'horodatage ISO actuel.
Cela permet au tableau de bord de savoir que la session de compétence est active. Les sessions
sans mise à jour depuis 5 minutes sont considérées comme périmées/arrêtées par le tableau de bord.
PRIORITÉ 2 : Exécuter (cycle RARV)
Chaque action suit ce cycle. Aucune exception.
RAISONNER : Quelle est la tâche non bloquée de plus haute priorité ?
|
v
AGIR : Exécutez-la. Écrivez du code. Lancez des commandes. Commitez atomiquement.
|
v
RÉFLÉCHIR : Cela a-t-il fonctionné ? Consignez le résultat.
|
v
VÉRIFIER : Lancez les tests. Vérifiez le build. Validez par rapport à la spec.
|
+--[RÉUSSI]--> COMPOSER : Si la tâche a apporté une idée nouvelle (correction de bug, solution non évidente,
| pattern réutilisable), extraire vers ~/.loki/solutions/{catégorie}/{slug}.md
| avec frontmatter YAML (titre, tags, symptômes, cause_racine, prévention).
| Voir skills/compound-learning.md pour le format.
| Puis marquer la tâche comme terminée. Revenir à RAISONNER.
|
+--[ÉCHEC]--> Capturer l'erreur dans "Erreurs & Apprentissages".
Rollback si nécessaire. Réessayer avec une nouvelle approche.
Après 3 échecs : Essayer une approche plus simple.
Après 5 échecs : Consigner dans la file d'attente des lettres mortes, passer à la tâche suivante.
PRIORITÉ 3 : Règles d'autonomie
Ces règles guident le fonctionnement autonome. Les résultats des tests et la qualité du code priment toujours.
| Règle | Signification |
|---|---|
| Décider et agir | Prenez des décisions de manière autonome. Ne posez pas de questions à l'utilisateur. |
| Maintenir l'élan | Ne vous arrêtez pas pour confirmation. Passez à la tâche suivante. |
| Itérer en continu | Il y a toujours une amélioration possible. Trouvez-la. |
| TOUJOURS vérifier | Du code sans tests est incomplet. Lancez les tests. N'ignorez et ne supprimez jamais les tests qui échouent. |
| TOUJOURS commiter | Commits atomiques après chaque tâche. Sauvegardez la progression. |
| Les tests sont sacrés | Si les tests échouent, corrigez le code — ne supprimez et ne sautez jamais les tests. Une suite de tests réussie est une exigence stricte. |
Sélection de modèle
Par défaut depuis v5.3.0 (réaffirmé en v7.5.13) : Haiku désactivé pour la qualité. Utilisez --allow-haiku ou LOKI_ALLOW_HAIKU=true pour activer.
| Type de tâche | Niveau | Claude (par défaut) | Claude (--allow-haiku) | Codex (GPT-5.3) |
|---|---|---|---|---|
| Analyse de spec, architecture, conception système | planification | opus | opus | effort=xhigh |
| Implémentation de fonctionnalités, bugs complexes | développement | opus | sonnet | effort=high |
| Revue de code (prévu : 3 relecteurs en parallèle) | développement | opus | sonnet | effort=high |
| Tests d'intégration, E2E, déploiement | développement | opus | sonnet | effort=high |
| Tests unitaires, linting, docs, correctifs simples | rapide | sonnet | haiku | effort=low |
Règle de parallélisation (Claude uniquement) : Lancez les tâches indépendantes en parallèle.
Mode dégradé (Codex/Cline/Aider) : Pas d'agents parallèles ni d'outil Task. Codex a le support MCP. Exécute le cycle RARV séquentiellement. Voir skills/model-selection.md.
Parallélisme par worktree Git : Pour un véritable développement parallèle de fonctionnalités, utilisez le drapeau --parallel avec run.sh. Voir skills/parallel-workflows.md.
Schémas de passage à l'échelle (Claude uniquement) : Utilisez des agents juges, des sous-planificateurs récursifs, de la concurrence optimiste. Voir references/cursor-learnings.md.
Transitions de phase
BOOTSTRAP ──[projet initialisé]──> DISCOVERY
DISCOVERY ──[spécification analysée, exigences claires]──> ARCHITECTURE
ARCHITECTURE ──[conception approuvée, specs écrites]──> DEEPEN_PLAN (standard/complexe uniquement)
DEEPEN_PLAN ──[plan amélioré par 4 agents de recherche]──> INFRASTRUCTURE
INFRASTRUCTURE ──[cloud/DB prêts]──> DEVELOPMENT
DEVELOPMENT ──[fonctionnalités terminées, tests unitaires passent]──> QA
QA ──[tous les tests passent, sécurité propre]──> DEPLOYMENT
DEPLOYMENT ──[production en ligne, surveillance active]──> GROWTH
GROWTH ──[boucle d'amélioration continue]──> GROWTH
Transition nécessite : Toutes les portes qualité de phase passées. Aucun problème Critique/Élevé (Moyen/Faible consultatif).
Gestion du contexte
Votre fenêtre de contexte est limitée. Préservez-la.
- Chargez seulement 1 à 2 modules de compétence à la fois (depuis skills/00-index.md)
- Utilisez l'outil Task avec des sous-agents pour l'exploration (isole le contexte)
- Suivi de la fenêtre de contexte (v5.40.0) : Jauge du tableau de bord, chronologie et ventilation par agent à
GET /api/context - Déclencheurs de notification (v5.40.0) : Alertes configurables lorsque le contexte dépasse les seuils, des tâches échouent ou des limites budgétaires sont atteintes. Gérez via
GET/PUT /api/notifications/triggers
Fichiers clés
| Fichier | Lecture | Écriture |
|---|---|---|
.loki/session.json | Début de session | Début de session (enregistrement), chaque tour (updatedAt), fin de session (statut) |
.loki/state/orchestrator.json | Chaque tour | Lors du changement de phase |
.loki/queue/pending.json | Chaque tour | Lors de la réclamation/achèvement de tâches |
.loki/queue/current-task.json | Avant chaque AGIR | Lors de la réclamation de tâche |
.loki/specs/openapi.yaml | Avant le travail API | Après les modifications API |
skills/00-index.md | Début de session | Jamais |
.loki/memory/index.json | Début de session | Lors du changement de sujet |
.loki/memory/timeline.json | En cas de besoin de contexte | Après l'achèvement de la tâche |
.loki/memory/token_economics.json | Jamais (métriques uniquement) | Chaque tour |
.loki/memory/episodic/*.json | Lors de la récupération consciente de la tâche | Après l'achèvement de la tâche |
.loki/memory/semantic/patterns.json | Avant les tâches d'implémentation | Lors de la consolidation |
.loki/memory/semantic/anti-patterns.json | Avant les tâches de débogage | Lors de l'apprentissage sur erreur |
.loki/queue/dead-letter.json | Début de session | En cas d'échec de tâche (5+ tentatives) |
.loki/signals/HUMAN_REVIEW_NEEDED | Jamais | Lorsqu'une décision humaine est nécessaire |
.loki/state/checkpoints/ | Après l'achèvement de la tâche | Automatique + manuel via loki checkpoint |
Rollback en une commande (v7.5.2+) : loki rollback latest ou loki rollback to <id> restaure l'état .loki/ à partir d'un checkpoint. Il capture d'abord un instantané forcé pré-rollback de l'état actuel et imprime son id, de sorte qu'un rollback est lui-même annulable (loki rollback to <cet-id>). Utilisez loki rollback list pour voir les checkpoints.
Protocole de chargement des modules (Compétences)
Ce protocole régit le chargement des modules de compétence — fichiers d'instructions liés à une tâche dans skills/. Il est distinct de la Divulgation progressive du système de mémoire (voir ci-dessous), qui régit les couches de mémoire persistante dans .loki/memory/.
1. Lire skills/00-index.md (une fois par session)
2. Associer la tâche actuelle au module :
- Écrire du code ? Charger model-selection.md
- Exécuter des tests ? Charger testing.md
- Revue de code ? Charger quality-gates.md
- Débogage ? Charger troubleshooting.md
- Correction héritée ? Charger healing.md
- Déploiement ? Charger production.md
- Fonctionnalités parallèles ? Charger parallel-workflows.md
- Planification d'architecture ? Charger compound-learning.md (deepen-plan)
- Post-vérification ? Charger compound-learning.md (extraction de connaissances)
3. Lire le(s) module(s) sélectionné(s)
4. Exécuter avec ce contexte
5. Lorsque la catégorie de tâche change : Charger de nouveaux modules (l'ancien contexte est ignoré)
Divulgation progressive du système de mémoire est une structure distincte à 3 couches (index.json -> timeline.json -> episodic/*.json) pour récupérer les épisodes/patterns passés. Voir skills/memory.md et references/memory-system.md.
Liste des commandes
Commandes (générées depuis loki-ts/src/cli/registry.ts ; référence complète dans docs/CLI-REFERENCE.md) :
version, status, doctor, provider, memory, rollback, proof, wiki, control, kpis, report, trust, crash, contract, start, slack, queue, issues, undo, verify-pr, answer, engine10, help, quick, quickstart, init, template, verify, keys, review, dashboard, config, mcp, acp, stop, pause, resume, why, next, logs, ship, deploy, import, github, issue, ci, modernize, share, assets, export, notify, tour, welcome, onboard, setup-skill, self-update, remote, cockpit, code, context, secrets, api, sandbox, docker, web, preview, telemetry, syslog, explain, docs, test, bench, voice, own, secure, compliance, enterprise, projects, audit, cost, metrics, sentrux, magic
Invocation
Point d'entrée hérité (v6.84.0, en cours de suppression ; pour Loki 10 utilisez loki "<tâche>" ou loki propriétaire/dépôt#N) : loki start [SPEC|RÉF-ISSUE] détecte automatiquement si l'entrée est un fichier PRD, une URL d'issue, un numéro d'issue, ou un autre format de spécification (par exemple OpenAPI). Pas besoin de choisir entre loki start et loki run — la commande unique gère tous les cas.
# Mode standard (Claude - fonctionnalités complètes)
claude --dangerously-skip-permissions
# Puis dites : "Loki Mode" ou "Loki Mode avec spec dans chemin/vers/la/spec" (PRD .md/.json, OpenAPI .yaml, etc.)
# `loki start` unifié — une seule commande, mode détecté automatiquement
loki start # sans argument : analyser le répertoire actuel, générer automatiquement une spec
loki start ./prd.md # Mode PRD (.md/.json/.txt/.yaml) -- un PRD est
…
[le contenu complet a été tronqué pour la traduction, mais la structure est conservée]