SirEdvin/agent-skills

Vérification sécurisée du cycle de vie

Déclencheur et limites

Utiliser avant une fin de tâche, une remise de revue, un démantèlement d'espace de travail ou toute autre transition autorisée qui pourrait supprimer ou déplacer le répertoire de travail courant. Cette compétence n'autorise pas le nettoyage, les transitions de cycle de vie, les changements d'état, l'arrêt de processus ou les nouvelles tentatives. Suivez le contrat de cycle de vie réel de la plateforme ; toutes les transitions ne suppriment pas un arbre de travail, et une transition réussie n'oblige pas à arrêter un processus de travail.

Avant la transition

1. Établissez une identité exacte : ID de tâche/enregistrement, tableau ou espace de noms, profil/compte, dépôt et état attendu. Ne vous fiez pas à la tâche en cours implicite de l'outil après avoir changé de répertoire. Utilisez des sélecteurs explicites pris en charge par la plateforme.
2. Inspectez la sémantique de nettoyage et identifiez les emplacements appartenant à la tâche par rapport aux emplacements persistants. Choisissez un répertoire stable existant en dehors de tout espace de travail que la transition peut supprimer. Un chemin parent est sûr uniquement s'il survit lui aussi au nettoyage ; un lien symbolique pointant vers l'espace de travail jetable n'est pas un emplacement durable. Résolvez les chemins réels.
3. Terminez d'abord les vérifications d'acceptation. Préservez les rapports, sommes de contrôle, commits et pièces jointes requis via le mécanisme d'artefact durable pris en charge par la plateforme, ou un autre emplacement persistant approuvé par l'utilisateur. Relisez l'identité et le contenu exacts de l'artefact. Une chaîne de chemin dans un commentaire ne préserve pas le fichier qu'elle nomme.
4. Enregistrez un reçu compact avant transition à l'extérieur du répertoire jetable : identité exacte, transition attendue, emplacements des preuves, commandes de vérification et toute limitation non résolue. Ne marquez jamais une acceptation incomplète comme complète simplement pour préserver des preuves ; utilisez plutôt l'état de point de contrôle/remise autorisé approprié.
5. Planifiez la vérification post-transition de manière à ce qu'elle n'exige pas l'ancien checkout, son virtualenv, les fichiers relatifs, la découverte de tableau dépendante de l'environnement ou les scripts d'assistance. Résolvez les exécutables requis et les chemins durables avant la transition.

Transition et relecture exacte

1. Effectuez la transition déjà autorisée une fois. Capturez son reçu sans traiter le succès comme une preuve de l'état durable souhaité.
2. Lancez la relecture avec le paramètre explicite de répertoire de travail stable de l'outil d'exécution. Un cd à l'intérieur de la commande peut ne jamais s'exécuter si l'outil échoue en entrant dans son cwd supprimé mémorisé. Si l'outil n'a pas de remplacement de répertoire de travail, utilisez une session indépendante enracinée dans un emplacement survivant. Ne répétez pas la mutation du cycle de vie pour réparer une relecture échouée.
3. Lisez la tâche/enregistrement exact et l'événement de transition à l'aide d'une interface en lecture seule prise en charge. Vérifiez l'état attendu, l'identifiant d'exécution/événement pertinent et le contenu de l'artefact durable. Si la suppression elle-même a été demandée, vérifiez séparément l'absence du système de fichiers et la désinscription de l'arbre de travail Git. Ne supposez pas que l'absence d'un répertoire signifie qu'une branche ou une pièce jointe a été supprimée.
4. Si la plateforme a transformé l'état demandé (par exemple, l'a orienté vers une revue), signalez l'état réel. Si un worker reste actif, signalez-le séparément ; ne l'arrêtez pas sans autorisation.
5. En cas d'erreur, inspectez stderr et l'étape qui a échoué. Un wrapper renvoyant 126 avec cd: ... Aucun fichier ou répertoire de ce type n'est pas une preuve que l'exécutable cible nécessite chmod. Ne réessayez que la vérification en lecture seule depuis un répertoire stable. Si l'enregistrement ne peut pas être lu, signalez la transition reconnue mais la vérification incomplète.

Fixture de régression jetable

La fixture crée son propre dépôt Git temporaire et un arbre de travail lié, préserve un reçu synthétique dans un répertoire durable frère, supprime uniquement cet arbre de travail de fixture, puis prouve que le lancement depuis le cwd supprimé échoue tandis que le lancement depuis le répertoire durable réussit. Elle vérifie également la liste des arbres de travail de Git et le contenu du reçu. Elle ne touche jamais à une tâche réelle, un dépôt distant, un espace de travail utilisateur ou une API de plateforme.

Exécutez depuis le répertoire du paquet installé :

python -m unittest discover -s scripts -p 'test_*.py' -v

Ceci teste le comportement du système de fichiers/sous-processus/Git, pas une promesse universelle de nettoyage de la plateforme. La sémantique de complétion réelle et la relecture des artefacts distants nécessitent toujours une vérification spécifique à la plateforme. N'exécutez pas de commandes de suppression sur l'espace de travail d'un utilisateur comme démonstration.

Sources et provenance

Rédigé indépendamment à partir d'échecs récurrents de vérification de cwd supprimé ; aucun journal privé, chemin ou identifiant de tâche n'est inclus. La documentation subprocess de Python documente cwd, les codes de retour et les échecs de démarrage de fils. Le manuel Git worktree documente la création, la suppression et le listage des arbres de travail liés. Ces primitives prennent en charge la fixture, pas une inférence concernant l'implémentation d'un planificateur de tâches particulier.