Plan Gate
Rendre le plan visible avant l'action. Un plan n'est pas une approbation.
Suivez AGENTS.md pour l'autorité opérationnelle, la délégation, la récupération et le rapport. Cette compétence ne définit que la porte de planification ; elle n'exige ni SOP de travailleur ni application de tableau de tâches.
Pré-vol en lecture seule
Inspectez ce qui est nécessaire pour identifier les cibles exactes, l'état existant et les risques. Ne modifiez pas l'état et n'exposez pas de secrets pendant le pré-vol.
Résolvez les inconnues matérielles avant de demander une approbation d'exécution. Ne demandez pas à l'utilisateur de répéter des faits disponibles.
Quand utiliser la porte
Appliquez la porte aux modifications de fichiers, commandes modifiant l'état, implémentation, refactoring, configuration, installations et modifications persistantes du flux de travail.
Pour un changement unique, trivial et limité, utilisez la porte courte—pas aucune porte. Les questions, analyses et ébauches présentées dans la conversation ne nécessitent pas de porte d'exécution.
Porte complète
PLAN GATE — · Révision <numéro>
Tâche comprise / Objectif
- <résultat demandé>
Hypothèses
- [entrée] <hypothèse fournie par l'utilisateur>
- [exécution] <hypothèse d'outillage ou d'environnement>
- [périmètre] <hypothèse d'inclusion ou d'exclusion>
Dans le périmètre
- <actions limitées>
Hors périmètre
Fichiers/systèmes affectés
- <cible exacte et changement prévu>
Exécution
- <étape>
Vérification
- <contrôles d'acceptation observables>
Restauration
- <comment les modifications liées à la tâche peuvent être annulées, ou limites de récupération>
Limite d'approbation
- <ce qui nécessite une nouvelle décision>
Décisions ouvertes
- <décisions matérielles non résolues, ou aucune>
Statut de la porte
- PRÊT POUR APPROBATION
- ou BLOQUÉ — DÉCISION REQUISE
Omettez les catégories d'hypothèses qui ne s'appliquent pas. N'inventez pas d'hypothèses simplement pour remplir le modèle.
Porte courte
PLAN GATE — · Révision <numéro>
- Tâche : <résultat demandé>
- Cible : <fichier/système exact>
- Changement : <changement limité>
- Hypothèse : <hypothèse étiquetée, le cas échéant>
- Vérification : <contrôle>
- Restauration : <limites d'annulation ou de récupération>
- Statut : PRÊT POUR APPROBATION
Passez à la porte complète si la tâche cesse d'être triviale.
Approbation
Attendez l'approbation explicite du périmètre visible. « Approuvé », « allez-y », « procédez » ou une confirmation directe approuve la révision actuellement identifiée.
L'approbation reste valide pour un périmètre inchangé. Ne la demandez pas de manière répétée et ne faites pas en sorte qu'un travailleur l'obtienne à nouveau.
Un changement matériel des cibles, actions, exigences, vérification, restauration ou autorité nécessite une porte révisée. Arrêtez le travail concerné jusqu'à ce que cette révision soit approuvée.
Les décisions matérielles non résolues signifient BLOQUÉ — DÉCISION REQUISE, pas PRÊT POUR APPROBATION. Une cible inconnue n'est pas autorisée en l'appelant « fichiers connexes ».
Limites sensibles
Exposez toujours le périmètre spécifique et obtenez une approbation explicite avant de modifier :
- Informations d'identification, authentification ou autorisations.
- Serveurs, réseau, accès à distance (SSH, VPN) ou ports publics.
- Paramètres d'exécution de l'agent : canaux, routage ou paramètres du modèle.
- Identité persistante ou instructions opérationnelles.
- Envois externes, publication, comptes ou dépenses.
- Opérations destructrices ou données client.
Les réponses de routine à l'utilisateur dans la conversation en cours ne sont pas des envois à des tiers. La rédaction de conversation ordinaire n'est pas un changement d'instruction persistante.
Lors de l'ajout, du remplacement ou de la correction d'une information d'identification, confirmez pendant le pré-vol en lecture seule comment la cible la consomme réellement (son propre coffre d'informations d'identification, un fichier qu'elle possède, une variable d'environnement ou un proxy qui injecte le secret en transit), en utilisant le schéma, la documentation ou le code de l'intégration plutôt qu'une hypothèse. Si la cible doit lire elle-même l'information d'identification, ne l'acheminez pas via un proxy qui substitue la valeur en transit ; utilisez le coffre d'informations d'identification pris en charge par l'intégration ou son propre fichier. Portez la porte sur le nom du secret, où il sera stocké, les hôtes exacts autorisés à l'utiliser, et toute configuration d'exécution ou redémarrage que l'intégration nécessite, avant de demander le secret. Pour un fichier d'information d'identification appartenant à l'intégration, portez la porte sur la saisie masquée par l'humain, le refus de remplacer un fichier existant, le propriétaire exact et les permissions restrictives, une vérification qui n'affiche jamais la valeur, et la suppression de ce seul fichier comme restauration ; incluez un redémarrage uniquement si l'intégration l'exige. Collectez les secrets uniquement via une invite masquée ou le propre coffre de secrets de l'outil ; jamais via le chat, les journaux, les arguments de ligne de commande ou un shell multiligne collé via le chat, et jamais en copiant ou en aliasant un secret existant. Demandez une nouvelle entrée sous le nom requis. Si aucune invite masquée ou coffre de secrets n'est disponible, ou si la demande masquée n'atteint pas l'utilisateur, arrêtez-vous et dites à l'utilisateur le nom exact du secret, où il doit aller et quels hôtes peuvent l'utiliser, afin qu'il puisse le saisir lui-même. Gardez l'ancienne information d'identification jusqu'à ce que la prochaine exécution vérifie la nouvelle, et supprimez l'ancienne uniquement si cette suppression était dans la portée approuvée.
Pour une migration d'une configuration en texte clair vers un coffre de secrets, portez la porte sur l'ensemble complet des propriétaires de chaque secret et traitez la suppression du texte clair comme unidirectionnelle après vérification. Prenez un instantané uniquement de la structure non secrète et des hachages ; ne créez jamais de copie de restauration en texte clair. Collectez chaque valeur actuelle via une saisie masquée, puis utilisez l'audit ou le planificateur de migration pris en charge par l'outil pour prouver que chaque valeur stockée correspond à sa source exacte en texte clair sans afficher ni l'une ni l'autre. Examinez et exécutez à sec un plan limité aux chemins approuvés, revérifiez à la fois la configuration et les hachages du plan immédiatement avant d'appliquer, puis appliquez une fois. Vérifiez les références exactes aux secrets, zéro texte clair restant, les valeurs non résolues ou masquées, aucun résidu de secret dans tout autre magasin que l'outil conserve (caches, magasins de session ou d'authentification, sauvegardes, fichiers temporaires ou de migration), et une configuration valide avant de redémarrer quoi que ce soit. Redémarrez uniquement les propriétaires qui l'exigent, prouvez que le nouveau processus est en cours d'exécution plutôt que de faire confiance à un rapport programmé, et testez chaque propriétaire d'informations d'identification de bout en bout. Conservez le plan de migration non secret jusqu'à ce que toutes les vérifications post-redémarrage réussissent, puis supprimez uniquement ce plan. Ne faites pas pivoter les informations d'identification sauf si une exposition ou une décision de rotation distincte l'exige.
Continuité et récupération
Pour un travail en plusieurs étapes, incluez un emplacement convenu d'enregistrement des tâches dans le périmètre d'écriture. Préservez la révision approuvée, la référence d'approbation et les preuves d'exécution à cet endroit. Aucune application de suivi particulière n'est requise.
Gardez les identifiants d'enregistrement limités à un seul flux de travail. Lorsque le travail passe à un objectif ou à une famille d'artefacts matériellement différent, commencez une nouvelle série d'enregistrements et croisez les preuves antérieures au lieu de continuer leur séquence ou de consolider les historiques. Si une porte au périmètre mal défini n'a pas été approuvée et n'a créé aucun artefact, retirez son identifiant proposé et réémettez la portée inchangée sous la série correcte ; ne créez pas de travail de migration.
Pour les inventaires sensibles aux versions, enregistrez la version d'exécution/catalogue observée et conservez cet instantané. Si une mise à niveau est en attente, terminez et vérifiez la mise à niveau avant de geler les listes blanches ou les cibles de dépendances, puis créez une révision comparable après mise à niveau ; ne réécrivez jamais silencieusement l'état antérieur.
Après une interruption, inspectez l'état réel avant de reprendre. Ne répétez pas une action dont le résultat est incertain.
Appliquez la limite de récupération dans AGENTS.md ; si aucune n'est définie, autorisez au maximum une tentative sûre, logique et dans le périmètre pour un blocage, partagée entre l'agent principal et les éventuels travailleurs. Une nouvelle tentative n'est pas obligatoire et ne peut pas étendre l'autorité. Re-planifier ou démarrer un nouveau travailleur ne réinitialise pas l'allocation.
Signalez une récupération réussie ainsi qu'une récupération échouée. Préservez ce qui a échoué, ce qui a été tenté, pourquoi et le résultat observé.
Un blocage correctement signalé est un résultat valide—pas une permission d'improviser l'achèvement. Indiquez clairement lorsque le livrable demandé reste incomplet.