Plan et Mission Navin : /blueprint, /forge, /cruise et ledger natif

Planifier sans exécuter, exécuter sans perdre le fil, reprendre une mission après pause : c'est le trio /blueprint → /forge → /cruise / /mission. Navin n'improvise pas une todo dans le chat : il tient un Task Ledger et un Progress Ledger natifs sur le board.

Inspiré des boucles Magentic-One / Deep Agents, implémenté sans LangGraph ni package externe - sur le board et l'AgentLoop Navin.

Les quatre niveaux

Composer : modes UI plan / agent. Outils : board, spawn, verify, test_run, fichiers, shell, MCP…

Le protocole à chaque étape

Sur /forge, /cruise, /mission :

1. Lire le ledger (ledger_get) + board next.
2. Choisir une étape ready (ou spawn des ready indépendantes).
3. Agir avec les outils.
4. Vérifier selon validation (test / lint / verify / manual / none).
5. Écrire ledger_progress avec evidence.
6. Décider : next | retry | ledger_replan | ledger_pause.
7. Jamais done sans preuve quand la validation l'exige.

Si missing_info bloque → pause et question à l'humain. Pas d'invention de faits.

Ce qui est persisté

Fichier .navin/board/mission.json à côté du board :

• Task Ledger : goal, status, version, constraints, facts, missing_info, acceptance_criteria, steps[], history[]
• Progress Ledger : current_step_id, evidence, stall_count, loop_detected, replan_needed, budgets, next_actor

Les tâches board portent acceptance, validation, retry_count, agent, evidence. Un done avec validation en test|lint|verify sans evidence est rejeté.

Pause, resume, édition humaine

• ledger_pause / ledger_resume
• Édition humaine via ledger_update → bump de version + history (actor=human)
• Panneau plan du chat : goal, vN, badge stall, raison du dernier changement, bouton Build après /blueprint

Sous-agents

Les briefs spawn copient acceptance + validation de l'étape. Le parent fusionne les preuves avant done / ledger_progress.

Exemples concrets

/blueprint Ajouter GitHub OAuth sans casser Google Auth
# relire le panneau plan → Build

/forge Implémenter le plan approuvé

/cruise Ship dark mode end to end avec tests

/mission Migrer l'auth vers Supabase sur le monorepo

Plan/Mission + board autonome

Une fois le plan approuvé, l'autonomie du board enchaîne les ready : branche isolée, PR au done, issues sync. Le ledger décide quoi ; l'autonomie décide comment livrer en git.

Voir aussi la discipline tâches : board expert.

FAQ

/blueprint touche-t-il au code ?

Non. Design only. Le code commence avec Build / /forge.

Différence /cruise vs /mission ?

/cruise : autopilot d'une livraison. /mission : goal long, checkpoints, resume multi-sessions, rapport final.

Qui replanifie ?

D'abord replan local (ledger_replan). Pause si budget / humain / info manquante.

Télécharger Navin · Fonctionnalités · Docs Plan Mode

Maillage

• Tâches expert → board expert
• Autonomie git → board autonome
• Modes composer → module Code
• Mémoire projet → Project Brain

Conclusion

Plan/Mission, c'est la différence entre un agent qui « code un peu » et un orchestrateur qui planifie, prouve, replanifie et reprend - comme une équipe sérieuse.