Loop Ledger

Un artefact persistant à cinq sections qui permet à une tâche de survivre aux seuils tool-call, commutations de contexte, compressions et redémarrages sans re-dériver l'état.

Quand l'utiliser

• Travail tier-boucle : tâches multi-fichiers, multi-outils, multi-sessions, goal-run ou coordonnées par subagent.
• Pas pour le travail rapide mono-étape — le surcoût dépasse la valeur là-bas.

Scaffold

Créez threads/<thread_id>/artifacts/specs/ledger.md :

# Ledger: <one-line task name>

## Goal
<Une phrase : le livrable, pas l'activité.>

## Core
<Ancres établies exactement une fois, diffusées à chaque branche/enfant :>
- Paths: <répertoires repo, fichiers clés>
- Names/IDs: <goal_run_id, thread_id, session IDs, task IDs>
- Constraints: <exigences strictes, critères d'acceptation>
- Style/conventions: <langage, format, conventions de code en vigueur>

## Verified
<Append-only. Une ligne par claim :>
- <claim> | verifier: <cmd/test/review + exit code> | covers: <scope> | not: <gap>

## Open
<Questions non résolues/bloqueurs avec propriétaire ou prochaine sonde.>

## Next
<Exactement UNE prochaine action, exécutable à froid sans contexte supplémentaire.>

Règles de maintenance

1. Core est broadcast-once. Les descriptions de subagent, les brefs des tâches enfants et les reprises référencent les entrées Core littéralement au lieu de les paraphraser. Les nouvelles ancres sont ajoutées à Core et re-diffusées, jamais forkées en privé.
2. Les entrées Verified portent leur verifier et couverture. Un claim sans verifier + coverage + gap n'a pas sa place ici.
3. Next est remplacé, jamais accumulé. S'il ne peut pas être exécuté à froid, rendez-le d'abord plus spécifique.
4. À la reprise (pause/handoff/redémarrage) : lisez d'abord le ledger, confirmez que Goal correspond toujours à la requête originale, puis exécutez Next.
5. Checkpoints aux seuils : après chaque limite de chaîne d'outils, commutation de fichier ou retour de subagent, rafraîchissez par rapport au ledger avant d'agir.

Completion

La tâche est terminée quand la couverture Verified combinée correspond à la portée Goal (les lacunes explicitement acceptées), Open est vide ou déféré avec raison énoncée, et le rapport final cite verifier + coverage par claim.

Source : adapté des mécanismes J-Space Cognition Suite V3.6 (capability-realization report, Tiger3807861189, 2026) — sous-ensemble agnostique du runtime : ledger à 5 états, verifier binding, failure inheritance, broadcast-once anchors. La grammaire à la première personne et l'ancrage de persona au premier tour sont intentionnellement exclus comme surajustements spécifiques au modèle.