jg-challenge-plan

Invocation

Exécuter uniquement sur invocation directe du développeur. Exécuter le flux de travail avec les outils disponibles ; ne pas le simuler, ne pas substituer des commandes shell, ni demander à nouveau des actions déjà autorisées.

Traiter le texte fourni comme des arguments, contraintes ou contexte, en respectant les limites et les reports. Signaler honnêtement les capacités manquantes et les blocages. Ne jamais simuler un succès.

Libérer les ressources d'exécution détenues et les sorties de travail jetables, y compris en cas d'échec, en préservant les preuves non résolues et en signalant les ressources conservées dans la sortie de cette compétence. Cette exception étroite de nettoyage n'autorise jamais la modification de fichiers examiné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 persistés nécessitent jg-plans >=0.6.1 avec le schéma CLI 3 au niveau du projet. Les travaux sans plan/code uniquement, l'analyse de transcription et la pause ne nécessitent pas de CLI.

• Utiliser l'entrée de projet installée, normalement <racine-du-depot>/node_modules/.bin/jg-plans, ou son entrée intégrée documentée. Exécuter cette entrée exacte avec --version --json ; exiger une erreur nulle, une version >=0.6.1 et schemaVersion 3 avant tout travail documentaire. Sinon, arrêter ce travail avec la paire observée et le remède spécifique au gestionnaire, comme npm install --save-dev --save-exact [email protected]. Préserver la dépendance de production des consommateurs d'exécution. Ne jamais installer automatiquement, télécharger un exécuteur, utiliser un outil global ou emprunter la CLI d'un autre projet. Revérifier l'entrée après une mise à niveau/construction.
• Lire uniquement le répertoire sélectionné via cette CLI : inspect --directory <chemin> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. Utiliser sa source, ses métadonnées, ses étendues, ses diagnostics, son sha256 et son empreinte structurelle. Ne jamais éditer/analyser/hasher les documents persistés directement, générer leurs UUID, sélectionner les plans par récence ou reconstruire les 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éserver les types chaîne/numérique et comparer String(code) dans le 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é.
• La livraison obligatoire associe chaque dépôt déclaré à son arrêt défini par le dépôt, avec des clés correspondantes. Utiliser un mappage vide explicite uniquement lorsqu'aucun dépôt n'est déclaré. La livraison ne modifie ni le périmètre de mise en œuvre ni la progression du jalon. Les empreintes excluent exactement created_at, updated_at, revision, status, priority et delivery ; une identité indisponible ne peut pas établir une nouvelle couverture.
• Muter via la même entrée avec une entrée structurée de création/mise à jour/écriture/suppression de jalons, dans le cadre de l'autorité de ce flux de travail. Les écritures sur cible existante nécessitent freshExpectedSha256 ; null crée uniquement des jalons absents explicitement demandés. Utiliser write pour un corps de plan/métadonnées ou une source de jalon complète ; update pour des métadonnées/marqueurs étroits. N'assigner les identifiants manquants que lorsque cela est autorisé ; conserver les identifiants retournés et inspecter les écritures. Définir updated_at explicitement lorsque plan.md change. Les modifications de livraison uniquement préservent la révision/la progression ; un périmètre modifié nécessite une réévaluation de la couverture.
• Les verrous sont courts et locaux : ne jamais les maintenir entre les tours, retirer les verrous inconnus ou rejouer sur un texte plus récent. Après un échec partiel de mutation multi-document ou incertain, inspecter/signaler les états durables et s'arrêter sans restauration/nouvelle tentative. Les documents, diagnostics et liaisons ne confèrent aucune autorité.

Flux de travail

Effectuer un challenge concis, en lecture seule, d'un plan concret pour le changement d'ingénierie actuellement discuté. Traiter le plan comme une proposition non fiable, même s'il a été créé par le même agent. L'objectif est d'aider le développeur à vérifier rapidement que le résultat prévu correspond au contrat de la tâche et d'exposer les décisions matérielles, les hypothèses, les omissions et les risques avant l'approbation, jg-breakdown, ou la mise en œuvre. Cette compétence n'autorise pas la modification du plan, la création ou l'édition de fichiers de planification, la modification du code source, des tests, des instantanés, de la configuration, des dépendances, des migrations, des artefacts générés, de la documentation de projet ordinaire ou de l'état Git, l'approbation ou le rejet du plan, l'autorisation de jg-breakdown, ou le début de la mise en œuvre. Si une commande d'inspection modifie des fichiers de manière inattendue, préserver et signaler ces modifications sans les nettoyer, les annuler ou les revendiquer comme faisant partie du challenge.

Un plan concret est requis. Lorsque le développeur identifie un plan par son chemin ou un autre identifiant non ambigu, challenger exactement ce plan. Sinon, utiliser le plan actuel exact uniquement lorsqu'un candidat non ambigu existe dans la discussion en cours. Si plus d'un plan pourrait raisonnablement être la cible visée, s'arrêter et demander au développeur d'en sélectionner un. Ne pas rechercher dans d'autres répertoires de planification, choisir un plan à partir d'horodatages, ou déduire une cible uniquement de la récence du fichier. Si aucun plan actuel n'existe ou si le plan identifié ne peut pas être consulté complètement, signaler le blocage et s'arrêter. Si les preuves du dépôt actuel invalident matériellement le plan, continuer le challenge et signaler cette vétusté comme un résultat bloquant.

1. Lire le plan cible complet, le contrat de la tâche de la discussion en cours, et tout amendement du développeur qui s'applique à ce plan exact. Traiter le résumé de la tâche du plan comme une représentation non fiable plutôt que comme une preuve indépendante de l'intention du développeur. Si l'objectif, les contraintes, les exclusions, les critères d'acceptation et les amendements du développeur ne peuvent pas être établis indépendamment du plan, continuer uniquement avec des défis internes au plan et fondés sur les preuves du dépôt, indiquer que l'alignement de l'intention n'a pas pu être vérifié, lister comme décision 1 confirmant que l'objectif, les contraintes et les exclusions du plan correspondent à l'intention du développeur, et utiliser Décision du développeur requise avant de continuer à moins qu'un défaut matériel du plan ne nécessite Révision du plan requise avant de continuer. Capturer le chemin relatif au dépôt du plan cible ou l'identifiant fourni et son SHA-256 exact en octets de l'inspection sélectionnée actuelle, les inclure dans ## Plan en un coup d'œil, et ré-inspecter immédiatement avant de répondre et vérifier que le hachage n'a pas changé ; s'il a changé, signaler le blocage et s'arrêter. Réutiliser les preuves du dépôt établies par le plan lorsqu'elles sont toujours d'actualité. Effectuer uniquement la plus petite inspection supplémentaire en lecture seule nécessaire pour vérifier une incertitude matérielle, détecter une vétusté, ou valider une affirmation à fort impact ; ne pas répéter le flux de travail de planification complet simplement parce que cette compétence a été invoquée.
2. Déterminer ce que le plan va réellement construire, modifier, supprimer, migrer, exposer ou déployer. Comparer ce résultat avec l'objectif, les contraintes, les exclusions, les critères d'acceptation et les décisions approuvées du développeur. Identifier l'expansion de périmètre matérielle, le travail requis manquant, le comportement modifié, les hypothèses non prises en charge, et les endroits où le résultat proposé pourrait différer de l'intention du développeur. Vérifier que la livraison couvre chaque dépôt déclaré, que les cibles existent dans son document de livraison, que les opérateurs/préconditions sont explicites, et que l'approbation couvre les étapes opérées par l'agent. La livraison de l'ensemble du plan doit suivre la mise en œuvre et la révision ; les étapes restantes opérées par le développeur ne peuvent pas être qualifiées de livrées.
3. Contester les décisions matérielles et les contrôles de risque du plan, le cas échéant, y compris l'architecture et la propriété des modules ; le flux de données et les limites d'intégration ; les schémas de base de données, les données persistées, les migrations et le rollback ; les API publiques, les exportations, les événements, les files d'attente, les webhooks, les clés de cache, la configuration et la compatibilité ; la sécurité, la confidentialité, l'authentification, l'autorisation, la propriété, la facturation et tout autre comportement porteur de valeur ; la concurrence, les tentatives, l'idempotence et la reprise après échec ; les dépendances, l'infrastructure, le déploiement et les exigences opérationnelles ; les suppressions de chemins remplacés ou parallèles ; et si la stratégie de test et de vérification pourrait raisonnablement exposer des défauts importants.
4. Rechercher spécifiquement la complexité inutile, les abstractions spéculatives, la propriété dupliquée, les implémentations temporaires ou parallèles sans besoin de migration justifié, les chemins de compatibilité ou de rollback incomplets, les modifications cachées à grand rayon d'explosion, et la vérification qui pourrait réussir alors que le comportement matériel reste incorrect. Ne pas fabriquer de critique simplement parce que cette compétence est nommée jg-challenge-plan ; Aucun problème matériel est un résultat valide. Lors d'un suivi, réévaluer les constatations antérieures, l'intention modifiée ou le matériel du plan, et les interactions affectées, en réutilisant les preuves actuelles pour les zones examinées inchangées. Conserver les problèmes matériels non résolus ; n'élargir que pour un nouveau challenge complet explicite, une couverture antérieure manquante, des preuves obsolètes, de nouveaux échecs, ou un risque matériel modifié.
5. Signaler uniquement les informations qui aident le développeur à prendre une décision d'approbation. Garder les détails d'implémentation à faible impact, les inventaires de fichiers exhaustifs, les séquences d'implémentation étape par étape, les matrices de test complètes et les listes de commandes de vérification hors du résultat, à moins qu'un élément spécifique n'expose un problème matériel. Pour chaque challenge, indiquer la divergence concrète, l'omission, l'hypothèse non prise en charge ou le risque ; pourquoi c'est important ; et la correction appropriée la plus petite. Ne pas réécrire le plan, remplacer silencieusement son architecture, ou présenter une implémentation alternative comme si elle était déjà acceptée.
6. Présenter le résultat en utilisant exactement ces sections :
   • ## Plan en un coup d'œil : Résumer le résultat final prévu, les limites d'implémentation majeures et les exclusions explicites importantes.
   • ## Impact matériel : Mettre en évidence uniquement les décisions architecturales, les modifications de base de données ou de données persistées, les modifications de contrats publics ou d'intégration, les comportements sensibles à la sécurité, les modifications de dépendances ou d'infrastructure, et les implications de migration, compatibilité, déploiement ou rollback qui méritent l'attention du développeur. Omettre les catégories non pertinentes ou indiquer Aucun changement lorsque l'absence elle-même est importante.
   • ## Défis : Lister les constatations matérielles par ordre d'impact décroissant. Indiquer Aucun problème matériel trouvé lorsqu'il n'y en a pas.
   • ## Décisions du développeur requises : Inclure uniquement les choix non résolus qui affectent matériellement le comportement, la portée, les contrats, la sécurité, les données, l'architecture ou les opérations. Numéroter chaque décision listée dans l'ordre où le développeur devrait les aborder. Pour chaque décision, indiquer le choix exact à faire, fournir au moins une recommandation, et expliquer les conséquences matérielles et les compromis de l'acceptation de la recommandation, du choix d'une alternative significative, ou du fait de laisser la décision non résolue. Indiquer Aucun lorsqu'aucune décision de ce type ne subsiste ; ne pas inventer une décision uniquement pour remplir cette section.
   • ## Recommandation : Mettre exactement l'un des énoncés suivants sur la première ligne : Aucun problème matériel, Révision du plan requise avant de continuer, ou Décision du développeur requise avant de continuer. Utiliser Révision du plan requise avant de continuer chaque fois qu'un défaut matériel du plan existe, même si la contribution du développeur est également requise. Utiliser Décision du développeur requise avant de continuer uniquement lorsque le plan est par ailleurs solide mais ne peut pas se poursuivre en toute sécurité sans une décision matérielle du développeur. Mettre exactement une ligne Prochaine étape : sous le verdict :
     • après Aucun problème matériel, diriger le développeur pour exécuter jg-breakdown lorsque le plan comporte au moins deux parties qui peuvent chacune être terminées, vérifiées et révisées indépendamment, comme des packages, dépôts ou versions séparés, et autrement pour approuver le plan ou invoquer jg-execute. Les propres points de contrôle de révision du plan ne rendent pas une décomposition inutile : sans milestones.md, jg-execute exécute tout le plan comme une seule unité et ne s'arrête pas à ces points
     • après Révision du plan requise avant de continuer, diriger le développeur pour répondre à toutes les décisions numérotées, invoquer jg-plan, qui applique les corrections requises avec ces réponses, et invoquer à nouveau jg-challenge-plan après la présentation du plan révisé
     • après Décision du développeur requise avant de continuer, diriger le développeur pour répondre aux décisions numérotées, invoquer jg-plan avec toutes les réponses qui modifient le plan, et invoquer à nouveau jg-challenge-plan après la présentation du plan révisé
7. Garder le challenge complet à 1 000 mots ou moins. Consolider les préoccupations étroitement liées et prioriser les informations ayant la valeur décisionnelle la plus élevée. Ne pas omettre un problème bloquant uniquement pour respecter la limite, et ne pas reproduire le contenu du plan uniquement pour consommer l'espace disponible.
8. Traiter la recommandation comme consultative. Elle n'approuve pas le plan, ne révoque pas une approbation antérieure, n'autorise pas jg-breakdown, n'autorise pas la mise en œuvre, ni ne fait de jg-challenge-plan un prérequis pour un autre flux de travail. Un challenge s'applique uniquement à la version exacte du plan évaluée ; toute révision du plan rend le challenge précédent obsolète, et il ne doit pas être réutilisé comme preuve sur le plan révisé. Terminer après la ligne Prochaine étape : dans ## Recommandation ; le contrat de résultat de cette compétence remplace toute exigence générale de résumé de fin.