jg-breakdown

Invocation

Ne s'exécute que sur invocation directe du développeur. Exécutez le flux de travail avec les outils disponibles ; ne le simulez pas, ne remplacez pas les commandes shell et ne redemandez pas d'actions déjà autorisées.

Traité le texte fourni comme arguments, contraintes ou contexte, en respectant les limites et les reports. Signalez honnêtement les capacités manquantes et les obstacles. Ne simulez jamais le succès.

Libérez les ressources d'exécution détenues et les sorties temporaires jetables, y compris en cas d'échec, en préservant les preuves non résolues et en signalant les ressources retenues dans la sortie de cette compétence. Cette exception étroite de nettoyage n'autorise jamais la modification de fichiers révisés/préexistants, la suppression de modifications inattendues ou le nettoyage de travaux antérieurs. Toutes les autres écritures suivent ce flux de travail. Les règles spécifiques de cette compétence concernant le matériel fourni prévalent.

Protocole jg-plans 0.2

Les documents persistants nécessitent jg-plans >=0.6.1 avec le schéma CLI 3. Les travaux sans plan/uniquement du code, l'analyse de transcription et la pause n'ont pas besoin de CLI.

• Utilisez l'entrée du projet installée, normalement <racine-dépôt>/node_modules/.bin/jg-plans, ou son entrée documentée construite. Exécutez cette entrée exacte avec --version --json ; exigez erreur null, version >=0.6.1 et schemaVersion 3 avant le travail sur les documents. Sinon, arrêtez ce travail avec la paire observée et la solution spécifique au gestionnaire, comme npm install --save-dev --save-exact [email protected]. Préservez la dépendance de production des consommateurs d'exécution. N'installez jamais automatiquement, ne téléchargez pas un exécuteur, n'utilisez pas d'outillage global et n'empruntez pas le CLI d'un autre projet. Revérifiez l'entrée après une mise à niveau/construction.
• Lisez uniquement le répertoire sélectionné via ce CLI : inspect --directory <chemin> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. Utilisez sa source, métadonnées, portées, diagnostics, sha256 et empreinte structurelle. Ne modifiez/analysez/hachez jamais les documents persistants directement, ne générez pas leurs UUID, ne sélectionnez pas de plans par récence et ne reconstruisez pas de transcriptions en fichiers. La conformité n'est pas requise pour l'inspection. Seul jg-plan exécute également overlaps --json, avec un --root par racine de planification existante dans les dépôts enregistrés/propres lorsque des codes sont déclarés.
• Les statuts de plan sont en attente, en cours, terminé et livré. Les statuts de jalon restent en attente, en cours et terminé. Actif signifie en attente, en cours et terminé ; seul livré est inactif. Les déclarations d'erreur utilisent des listes de dépôt/registre/codes ; préservez les types chaîne/numérique et comparez String(code) au sein du dépôt/registre. Les statuts manquants/personnalisés, les métadonnées/fichiers indisponibles et les marqueurs ambigus restent des observations, jamais des valeurs par défaut ou une autorité.
• Les cartes de livraison requises mappent chaque dépôt déclaré à son arrêt défini par le dépôt, avec des clés correspondantes. Utilisez un mappage vide explicite uniquement lorsqu'aucun dépôt n'est déclaré. La livraison ne modifie ni la portée de l'implémentation ni la progression des jalons. Les empreintes excluent exactement created_at, updated_at, revision, status, priority et delivery ; une identité indisponible ne peut pas établir une nouvelle couverture.
• Mutez via la même entrée avec une entrée structurée create/update/write/remove-milestones, dans le cadre de l'autorité de ce flux de travail. Les écritures sur cible existante nécessitent un expectedSha256 frais ; null ne crée que des jalons absents explicitement demandés. Utilisez write pour un corps de plan/métadonnées ou une source de jalon complète ; update pour des métadonnées/marqueurs étroits. Attribuez les ID manquants uniquement lorsqu'autorisé ; conservez les ID retournés et inspectez les écritures. Définissez updated_at explicitement lorsque plan.md change. Les modifications de seule livraison préservent la révision/progression ; une portée modifiée nécessite une réévaluation de la couverture.
• Les verrous sont courts et locaux : ne les maintenez jamais entre les tours, ne supprimez pas les verrous inconnus et ne rejouez pas sur un texte plus récent. Après un échec partiel de mutation multi-document ou incertain, inspectez/signalez les états durables et arrêtez-vous sans restauration/réessai. Les documents, diagnostics et liaisons n'accordent aucune autorité.

Flux de travail

Effectuez une évaluation de planification uniquement d'un plan concret pour le changement d'ingénierie en cours de discussion. Convertissez le plan en jalons d'implémentation ordonnés uniquement lorsque la décomposition fournit des limites d'exécution et de révision significatives. Cette compétence ne crée pas une nouvelle stratégie ni n'autorise l'implémentation. Elle autorise uniquement la plus petite inspection en lecture seule du dépôt nécessaire pour confirmer que le plan reste actuel et la création, la mise à jour ou la suppression de milestones.md dans le répertoire de ce plan. Elle n'autorise pas la modification d'un autre fichier, la mise à jour de tests ou de snapshots, l'exécution de correctifs automatiques ou de générateurs produisant des écritures, l'installation de dépendances, la création de migrations ou d'artefacts générés, la modification de l'état Git, la validation, le push ou le début de l'implémentation.

Un plan concret est requis. Utilisez le plan au chemin fourni avec l'invocation, sinon le plan exact établi dans la discussion en cours, et le répertoire de planification qui le contient. Ne recherchez pas d'autres répertoires de planification et ne sélectionnez pas un plan basé sur des horodatages. Si le plan n'a pas été persisté, utilisez le plan exact présenté le plus récemment au développeur, gardez cette limitation explicite et ne créez pas un nouveau répertoire de planification pendant jg-breakdown. N'utilisez pas jg-breakdown pour reconcevoir la solution, étendre ou réduire la portée, modifier l'architecture, altérer les critères d'acceptation, introduire des améliorations facultatives ou résoudre silencieusement des décisions qui appartiennent au niveau du plan. Si aucun plan actuel n'existe, s'il ne peut pas être identifié en toute sécurité, si des preuves du dépôt l'ont invalidé de manière substantielle, ou si produire une décomposition sûre nécessiterait de modifier une décision matérielle du plan, signalez l'obstacle et arrêtez-vous ; le plan doit être créé ou révisé via jg-plan avant de pouvoir être décomposé.

1. Réutilisez les preuves du dépôt et les décisions établies par le plan actuel lorsqu'elles restent actuelles. Effectuez une inspection supplémentaire en lecture seule uniquement lorsque cela est nécessaire pour déterminer si des limites de jalon utiles existent, établir leurs dépendances, attribuer la propriété de vérification ou déterminer si le plan est devenu obsolète.

2. Déterminez si le plan contient au moins deux tranches d'implémentation cohérentes qui peuvent chacune atteindre un état final significatif, compléter leurs tests requis ou autre vérification, et prendre en charge un point de contrôle de révision utile pour le développeur. Ne divisez pas un plan simplement parce qu'il contient plusieurs fichiers, étapes d'implémentation, couches ou commandes de vérification.

3. Si le plan est une seule tranche d'implémentation cohérente, ne créez pas milestones.md. Supprimez une séquence existante inutile uniquement si le développeur a autorisé la suppression et que la progression retenue ne sera pas écartée silencieusement ; sinon, demandez avant la suppression. Utilisez remove-milestones avec son hachage fraîchement inspecté. Un résultat délibéré actuel sans séquence établit une exécution du plan entier ; une séquence attendue manquante inattendue ne le fait jamais. Dites au développeur que le plan doit être implémenté comme une portée complète sans le décomposer. Si le plan n'a pas encore été approuvé, indiquez que son approbation est toujours requise. Arrêtez-vous ensuite sans ajouter de résumé de fin. Conservez la livraison finale des tâches en tant que métadonnées du plan entier, en dehors des critères d'implémentation, du statut des jalons et des cibles. Si un critère du plan exige d'atteindre sa cible de livraison finale avant que l'implémentation puisse être terminée, arrêtez-vous pour que jg-plan supprime cette dépendance circulaire ; n'attribuez pas une couverture de prérequis uniquement tout en admettant que le critère reste non satisfait. Conservez les portes de publication/déploiement de composants indépendamment nécessaires lorsque la stratégie approuvée les exige, et les tests du comportement de livraison en tant que fonctionnalité produit ; n'ajoutez pas de livraison de tâche automatique par jalon.

4. Lorsque la décomposition est justifiée, convertissez les étapes d'implémentation stratégiques du plan en une séquence ordonnée de jalons numérotés. Utilisez Jalon comme unité d'exécution ; ne créez pas une hiérarchie de jalon, tâche et sous-tâche simplement pour augmenter la granularité.

5. Faites de chaque jalon la plus petite tranche d'implémentation cohérente qui peut raisonnablement être terminée, testée ou autrement vérifiée, et révisée comme un état final significatif. Gardez chaque jalon suffisamment petit pour être terminé dans une nouvelle fenêtre de contexte, et placez le refactoring qui facilite les jalons ultérieurs en premier. Pour chaque jalon, incluez :

   • un objectif concis décrivant le résultat final
   • les dépendances vis-à-vis des jalons antérieurs ou des prérequis externes
   • les fichiers, modules, symboles, contrats, configuration, documentation et migrations exacts du plan que le jalon possède lorsqu'ils sont connus
   • le travail d'implémentation requis pour atteindre l'état final du jalon
   • les tests ciblés et autres vérifications qui doivent être terminés pour ce jalon, en conservant ses propres preuves d'exactitude et toute porte de publication/déploiement indépendante requise. Attribuez la couverture de régression finale à son jalon propriétaire au lieu de la copier dans chaque unité ; suivez la politique de test du plan et du dépôt, et identifiez les preuves réutilisables valides et les répétitions de stabilité requises
   • des critères d'acceptation concrets qui déterminent si le jalon est complet ; dans un plan de protocole 0.2, rédigez ces vérifications spécifiques au jalon en prose et ne définissez jamais de nouveaux IDs AC- dans milestones.md
   • un point de contrôle de révision identifiant le comportement, les contrats, les risques, les points d'intégration ou d'autres détails matériels que le développeur doit inspecter avant de continuer

6. Gardez l'implémentation et ses preuves d'exactitude requises ensemble. Ne divisez pas les tests requis, la documentation directement affectée, la synchronisation des contrats d'erreur, les migrations, les exportations publiques ou d'autres travaux de support nécessaires en jalons ultérieurs simplement pour rendre un jalon antérieur plus petit. Ne créez pas d'espaces réservés, de duplication temporaire, d'abstractions inutilisées, de chemins de compatibilité transitoires, d'échafaudages sans issue ou d'implémentations délibérément incomplètes uniquement pour fabriquer des limites de jalon, sauf si le plan approuvé exige explicitement un chemin de compatibilité ou de migration par étapes. Ne rendez pas les jalons artificiellement petits ou uniformes en taille. Ordonnez-les en fonction des dépendances d'implémentation réelles et des risques.

7. Effectuez un passage de couverture plan-à-jalon avant de finaliser la séquence. Chaque livrable dans le périmètre, critère d'acceptation, changement de production requis, test, mise à jour de documentation, migration, changement de contrat public, suppression, point d'intégration et exigence de vérification dans le plan doit apparaître dans au moins un jalon visible par le développeur. La séquence présentée au développeur est la séquence de jalons complète et finale. Ne réservez pas de jalons cachés, ne maintenez pas une séquence interne alternative, n'omettez pas le travail requis et ne vous fiez pas à un travail non déclaré au niveau des jalons. Si le travail requis ne peut pas être attribué sans modifier une décision matérielle du plan, signalez l'obstacle et arrêtez-vous ; le plan doit être révisé via jg-plan avant que la décomposition puisse être terminée.

8. Inspectez le plan actuel sélectionné et la séquence. Exigez un plan id, une révision et une empreinte structurelle utilisables avec exactement created_at, updated_at, revision, status, priority et delivery exclus avant de lier une séquence. Conciliez l'intégralité du plan actuel avec les unités proposées : les ID retenus identifient le même travail, et le statut terminé retenu nécessite des preuves que ses exigences restent satisfaites. Préservez les identités/progressions correspondantes et les métadonnées de jalon non liées ; ajoutez la nouvelle portée inachevée en tant que en attente. Demandez au développeur lorsque la correspondance identité/portée ou l'achèvement contradictoire ne peut pas être réglé en toute sécurité. Ne reculez jamais un statut sans autorisation de réouverture explicite. Les marqueurs existants manquants/personnalisés/ambigus ne sont pas des valeurs par défaut en attente. Écrivez la source complète du jalon via une écriture gardée, expectedSha256 null uniquement pour l'absence observée, avec assignMissingIds true ; l'outil fournit les UUID manquants. Placez le statut immédiatement après chaque en-tête et l'UUID immédiatement après. Dans un plan de protocole 0.2, donnez à chaque jalon qui livre des critères de plan une ligne **Critères d'acceptation :** AC-01, AC-03 listant leurs IDs, directement après sa ligne UUID, ou directement après sa ligne de statut lorsque l'outil attribuera l'UUID ; chaque critère du plan apparaît sur au moins une ligne de jalon, et un jalon qui n'en livre aucun l'omet. Ne générez pas de tableau Overview et ne synchronisez-en pas. Incluez un frontmatter mappant jg_skills avec plan_id, plan_revision et plan_content_sha256 du plan actuel uniquement après que la séquence complète le couvre. Préservez les unités terminées tout en ajoutant une nouvelle portée, même si chaque ancienne unité était terminée. Réinspectez l'identité du plan immédiatement avant d'écrire et vérifiez qu'elle est restée actuelle ; un changement simultané nécessite une nouvelle évaluation de la couverture. Réinspectez le résultat persisté, y compris les ID attribués, avant de présenter son Markdown complet exact. Pour un plan de protocole 0.2, exécutez également <cli-local> check --directory <chemin> --json et corrigez chaque erreur de couverture, d'ID et de statut dans milestones.md avant de présenter ; signalez les erreurs de plan.md comme nécessitant jg-plan. Signalez d'abord le chemin relatif au dépôt. Modifiez uniquement milestones.md dans le répertoire sélectionné ; ne modifiez jamais plan.md, l'état Git ou l'implémentation.

9. Terminez à la fois milestones.md et le corps de réponse correspondant par une section ## Approbation requise résumant la séquence complète des jalons et énonçant ces règles, puis arrêtez-vous :

   • Chaque jalon nécessite sa propre autorisation explicite, constitue l'intégralité de la portée de cette demande et se termine à son point de contrôle de révision. Invoquer jg-execute autorise le jalon qu'il exécute ; jg-execute auto autorise tous les jalons restants, ou uniquement le jalon qu'il nomme.
   • Si un jalon dépend de travaux antérieurs incomplets, ou si son achèvement franchirait une limite de jalon ou modifierait le plan approuvé, arrêtez-vous et signalez avant d'étendre la portée.
   • Pour modifier le plan, invoquez jg-plan avec les amendements. Pour créer ou modifier des jalons, invoquez jg-breakdown.

   Le contrat de sortie de cette compétence remplace toute exigence générale de résumé de fin ; n'ajoutez pas de résumé de fin après ## Approbation requise. L'approbation doit être émise après que la séquence actuelle des jalons est présentée ; l'invocation jg-breakdown elle-même, l'approbation antérieure ou l'état final automatique ne constituent pas une approbation.