Comment SOKKAN fonctionne
Trois diagrammes, générés depuis le code et vérifiés contre lui. Cliquez une boîte pour voir ce qu’elle fait et à qui elle parle ; Live dans la vue complète retrace le chemin principal ; Export donne PNG, SVG ou un clip WebM. English version.
1.Une session, de bout en bout
Vous ouvrez une carte ou tapez un prompt. L’API fait elle-même la recherche mémoire et écrit les meilleures notes dans le premier message de la session : l’agent démarre en sachant déjà ce que les sessions précédentes ont appris. La session tourne sur le Claude Agent SDK ; chaque appel d’outil qui modifierait quelque chose passe par la porte HITL et vous revient sous forme de bouton. Le tout vit dans un conteneur, sur votre machine.
Chaque boîte marquée SRC pointe vers le fichier et la ligne dans ninabot-ch/sokkan, au commit depuis lequel le diagramme a été généré. Si le diagramme et le code divergent, le code a raison et on régénère.
2.D’une carte à un changement approuvé
La boucle que vous ferez tous les jours. Ce qui compte, c’est l’ordre : le rappel avant tout code, un plan ancré dans les notes et le code, puis une porte sur chaque étape qui modifie. Refusé = l’agent replanifie, il ne contourne jamais. Une carte n’arrive en Done que si un humain l’y déplace.
3.Un run d’agent (Crew)
Les agents Crew tournent seuls : un cron, ou une alerte de prod. Un run reste une session ordinaire, avec la mémoire du projet, les outils autorisés de l’agent, les secrets du coffre par nom et un budget par run. Il s’arrête dès qu’il veut écrire, stoppe à 100 % de son budget, ouvre un incident s’il échoue, et les notes qu’il écrit restent en quarantaine jusqu’à ce que vous les promouviez.
4.Pour aller plus loin
- Premiers pas — du login à une mémoire qui travaille, en 20 minutes.
- Spécification des agents Crew, Operate, multi-utilisateur — sur GitHub.
- Diagrammes réalisés avec archify (MIT). Les sources sont dans le dépôt et régénérées à chaque release.