hackycy/goal-loop

Goal Loop

Compile les documents de décision en trois artéfacts :

• implementation-plan.md : contrat Gate stable, répondant à ce qu'il faut faire, les limites, comment vérifier et quand s'arrêter.
• goal-runbook.md : registre unique de l'état d'exécution et des preuves, répondant uniquement à où en est l'exécution et quelles preuves existent.
• goal-prompt.md : entrée fixe facile à copier pour les humains, pointant uniquement vers les deux premiers documents ; ne lie pas les Gates et ne duplique pas les contrats.

Ce skill établit ou valide uniquement le plan de contrôle d'exécution, sans exécuter les Gates ni refaire les décisions déjà approuvées.

Localiser l'entrée

L'utilisateur fournit un répertoire effort, un map.md, un ADR/spec ou un implementation-plan.md existant. Analyse la racine du dépôt Git et localise l'effort ; s'arrête en cas d'ambiguïté et liste les chemins vérifiés.

Lit les fichiers CLAUDE.md, AGENTS.md, CONTEXT.md / CONTEXT-MAP.md applicables, ainsi que la map, la spec, le plan d'implémentation dans l'effort et les ADR, décisions, issues et dépendances de validation locales qu'ils référencent. CONTEXT.md fournit uniquement la terminologie et les faits du domaine, il ne génère pas de Gate à lui seul.

Prend en charge deux types d'entrées convergées :

• Decision-only : les Gates, le périmètre, la validation et les conditions de sortie peuvent être déduits des ADR acceptés, des specs ou des issues résolus.
• Wayfinder : le champ Not yet specified de la map est vide ou explicitement "aucun", toutes les décisions impliquées dans l'ordre d'exécution et la validation sont résolues.

S'arrête en cas de lien de décision local manquant, d'ADR non accepté, de décision non résolue, ou si un document contient encore TBD, TODO, une question ouverte, une décision en attente ; rapporte chaque lacune. Ne doit pas combler les lacunes de décision produit, de politique de validation ou de limites de rollback par expérience.

Compiler le plan

Si implementation-plan.md n'existe pas, lit intégralement references/implementation-plan-schema.md et génère le plan à partir des décisions convergées. S'il existe déjà, le lit et le valide uniquement, sans l'écraser.

Le plan est l'unique détenteur de tous les contrats Gate stables : Objectif, Entrées, Périmètre, Contraintes, Politique de slice, Vérification, Règles de preuve, Conditions d'arrêt, Rollback et Conditions de sortie. Les commandes du projet et les contraintes techniques sont écrites uniquement dans le plan, pas dans le prompt fixe.

Si l'ancien plan contient un Current Execution State, il peut être importé une fois lors de l'initialisation du runbook ; les noms, ordre et état des Gates doivent correspondre, passed / blocked doivent déjà avoir des preuves associées. Après importation, le plan n'est plus mis à jour.

Compiler ou valider le registre

Lit intégralement references/runbook-schema.md.

Si goal-runbook.md n'existe pas :

1. Lit le numéro, le nom, les dépendances et l'emplacement des contrats de chaque Gate dans le plan.
2. Écrit la ligne de base des sources, le registre Goal unique et le journal de progression de chaque Gate.
3. S'il n'y a pas d'état à importer, marque uniquement G0 comme active, les autres comme planned.
4. Ne copie pas l'Objectif, les Contraintes, la Vérification ou d'autres contrats Gate du plan.

Si goal-runbook.md existe déjà :

1. Compare l'ensemble des chemins sources et leur SHA-256 ; en cas de dérive du plan ou des décisions, conserve le registre tel quel et s'arrête.
2. Valide l'ordre des Gates, les références au plan, les dépendances strictement linéaires, la machine d'état et les preuves dans le journal de progression.
3. Le registre ne peut présenter que passed* active planned*, passed* blocked planned* ou passed+.

Le plan est la seule source des contrats ; le registre est la seule source de l'état et des preuves. Les deux ne doivent pas se copier de champs ni dupliquer l'état.

Écrire le prompt fixe

Lit intégralement references/goal-prompt-template.md, ne remplace que {{EFFORT_PATH}}, écrit ou remplace goal-prompt.md.

Le prompt fixe doit :

• rester exactement le même pour tous les Gates du même effort ;
• ne pas mentionner de Gate spécifique (G0/G1), de nom de Gate ou d'Objectif ;
• ne pas développer les Entrées, Contraintes, Vérification, Conditions d'arrêt, Rollback ou Conditions de sortie ;
• conserver les règles d'exécution et de comportement stables entre les projets : slice minimum, contrôle du périmètre, boucle de fermeture sur échec de validation, division des responsabilités, conservation des implémentations non pertinentes, non-affaiblissement des tests, fin de validation manuelle avec remise, et interdiction de push ;
• exiger qu'au démarrage d'un Goal, le Gate actif unique soit verrouillé et uniquement celui-ci exécuté ; lors de la validation manuelle, ne demander confirmation qu'une seule fois, enregistrer d'abord la preuve de remise, puis terminer le Goal en cours avec l'état de succès fourni par l'agent hôte (ne pas marquer blocked, paused ni continuer l'exécution), enfin afficher un résultat de remise incluant le Gate, les résultats automatisés, le point d'entrée de validation, la checklist minimale, le format de réponse explicite et la mention "Goal terminé, Gate toujours actif", puis terminer la session normale. À ce stade, le Gate doit rester active ; seuls les utilisateurs peuvent ultérieurement déclencher manuellement un nouveau Goal avec des résultats de validation explicites. S'il n'y a pas de mécanisme d'état de Goal, terminer directement la tâche en cours sans créer de boucle d'attente. Une fois le Gate passé, marquer le Gate actuel passed, son successeur direct active, résumer les preuves et terminer explicitement le Goal entier, sans inclure le successeur dans le même Goal.

goal-prompt.md est un fichier de commodité, supprimable et recréable. Il ne fait pas partie de la ligne de base des sources, n'est pas référencé par le plan ou le runbook, et ne participe pas à la validation de l'état.

La réponse finale doit indiquer s'il s'agit d'une compilation ou d'une validation, donner les chemins du plan, du runbook et du prompt fixe, et afficher le contenu du prompt. En cas d'optimisation uniquement des artéfacts, ne pas exécuter les Gates.