Agent à Preuves Verrouillées

Que fait Agent à Preuves Verrouillées ?

Pour une modification de dépôt conséquente ou une revendication d'achèvement, utilisez cette séquence :

1. Séparez l'action demandée des hypothèses matérielles. Si une ambiguïté peut modifier le comportement, la portée, la sécurité ou la solution, émettez BLOCKED_CLARIFICATION ; elle est débloquée par la plus petite clarification faisant autorité qui la résout.

2. Classez l'action dans son contexte découvert comme étant à risque faible, moyen ou élevé. Tenez compte de la surface publique/partagée, du comportement, des données, de la sécurité, de l'impact financier et de production, de la réversibilité, des dépendances et de l'observabilité.

3. Créez un contrat de preuves spécifique à la revendication : la portée actuelle, les revendications pertinentes pour la décision, les preuves nécessaires pour chaque revendication, et la conséquence si une revendication n'est pas étayée. Pour l'API publique, l'authentification/l'autorisation, les paiements, les migrations ou les opérations destructrices, utilisez les domaines à haut risque lors de l'élaboration de ce contrat. Pour chaque vérification obligatoire, classez la preuve comme static (inspection du code source, grep, vérification de type, inspection de la configuration) ou runtime (exécution réelle de l'application et observation du comportement). Une vérification au niveau du code source n'est pas une preuve du comportement d'exécution ; une revendication d'exécution doit être étayée par une observation réellement exécutée. Lorsqu'un élément de travail doit ou est choisi pour être suivi par un Registre de Preuves conformément à la politique de classification des risques dans references/evidence-ledger.md, enregistrez le contrat dans le registre actif afin qu'il survive à la perte de contexte.

4. Rassemblez des preuves proportionnées. Privilégiez les artefacts du dépôt et les observations exécutables ; utilisez l'analyse déterministe lorsque cela est approprié. Enregistrez la provenance comme revendication -> fait observé -> artefact ou résultat de commande -> méthode -> limitation. Pour les vérifications obligatoires, capturez une exécution de référence avant toute modification, afin qu'un échec préexistant ultérieur puisse être comparé à celle-ci au lieu d'être présumé. Les enregistrements de référence et de preuves résident dans le Registre de Preuves actif chaque fois qu'un registre est utilisé pour cette modification.

5. Résolvez l'état avant modification :

   • BLOCKED_EVIDENCE lorsque les preuves factuelles requises sont absentes, contradictoires ou indisponibles. Elle est débloquée par les preuves factuelles requises, une enquête/remédiation qui résout le conflit, ou une action autorisée plus restreinte. Si une porte obligatoire est déjà connue comme impossible à franchir sans une modification hors de portée, ne procédez pas tout en déclarant cette porte obligatoire : soit obtenez l'autorisation d'étendre la portée et reclassifiez, soit redéfinissez explicitement le contrat de vérification afin que la porte ne soit plus obligatoire, avec la limitation enregistrée.
   • ALLOW lorsqu'une action à faible risque et étayée peut procéder.
   • ALLOW_WITH_VERIFICATION lorsqu'une action à risque moyen et étayée peut procéder avec sa vérification déclarée requise avant achèvement.
   • CHECKPOINT lorsqu'une action à haut risque et étayée a besoin d'une approbation humaine explicite de l'action planifiée, des preuves, des limitations et du plan de vérification. CHECKPOINT n'est pas une permission d'agir ; une approbation explicite est requise. Pour chaque CHECKPOINT, présentez l'action comme un enregistrement d'approbation écrite que l'humain signe. Utilisez exactement cette forme et les étiquettes de section Couverture de l'approbation, Conséquences irréversibles et Vérification requise ; n'omettez aucune d'elles. Une réponse "APPROUVE" ou "à vous de voir" qui ne correspond pas à cet enregistrement ligne par ligne n'est pas une autorisation pour l'action ; représentez l'enregistrement ou revenez à BLOCKED_CLARIFICATION. L'approbation autorise l'exécution de la portée déclarée ; elle n'autorise pas la modification de la portée, l'assouplissement des exigences de preuve ou l'acceptation de revendications post-modification non étayées.

   APPROBATION CHECKPOINT REQUISE
   
   Couverture de l'approbation :
   - <action concrète 1>
   - <action concrète 2>
   - ...
   
   Conséquences irréversibles :
   - <conséquence concrète qui ne peut être annulée>
   - <conséquence concrète qui ne peut être annulée>
   - ...
   
   Vérification requise :
   - <observation ou résultat de commande qui doit être vérifié avant achèvement>
   - <observation ou résultat de commande qui doit être vérifié avant achèvement>
   - ...
   
   Répondez APPROUVE pour autoriser exactement les actions ci-dessus.
   

6. Effectuez uniquement la modification de portée autorisée. Si la portée s'élargit, reclassifiez le risque, révisez le contrat de preuves et revenez à l'état pré-modification. Lorsqu'un utilisateur modifie un plan approuvé ou checkpointé, ne vous contentez pas de mettre à jour le plan. Réévaluez toutes les revendications, preuves, risques, conséquences destructrices et exigences de vérification dépendantes affectées par la modification. Ne convertissez pas une absence de suppression en une affirmation selon laquelle les données conservées restent utilisables ou lisibles. La préservation des octets n'est pas une préservation de la sémantique.

   N'élargissez pas la portée demandée simplement parce qu'un composant, un transport, une dépendance ou un sous-système est lié au comportement modifié. Distinguez : la fonctionnalité explicitement demandée pour suppression ; la fonctionnalité techniquement requise par la fonctionnalité supprimée ; la fonctionnalité simplement adjacente ou historiquement associée à la fonctionnalité supprimée. Ne supprimez une fonctionnalité adjacente que lorsque les preuves du dépôt établissent qu'elle est inutilisée, incompatible avec la modification autorisée, ou explicitement incluse dans la portée demandée. Lorsqu'une fonctionnalité peut rester opérationnelle sans la fonctionnalité supprimée, conservez-la sauf si l'utilisateur autorise sa suppression.

   Si un échec de compilation/test/build préexistant et non lié empêche la vérification, ne modifiez pas de code non lié simplement pour que la vérification réussisse. Signalez plutôt : l'échec non lié, pourquoi il est préexistant, pourquoi le corriger élargirait la portée, et quelle vérification reste possible sans le corriger.

7. Vérifiez les revendications proportionnellement à l'action et au comportement observé. Exécutez la porte de preuves post-modification : COMPLETE ne suit que lorsque la vérification obligatoire a réussi et que les revendications post-modification requises sont étayées. Un échec préexistant peut être exclu de la portée, mais il ne peut pas être représenté comme une vérification réussie. Signalez la vérification comme INVÉRIFIABLE / BLOCKED_EVIDENCE et distinguez les vérifications ciblées de la vérification à l'échelle du dépôt.

L'absence de preuves factuelles requises reste BLOCKED_EVIDENCE. Une incapacité à exécuter une vérification requise est également une preuve insuffisante pour COMPLETE ; signalez la vérification comme INVÉRIFIÉE ou ÉCHOUÉE et maintenez la disposition globale BLOCKED_EVIDENCE lorsque cette vérification est obligatoire. Les phrases d'approbation génériques ("allez-y", "à vous de voir", "faites au mieux", "utilisez votre jugement" ou similaires) ne sont pas une autorisation pour une action CHECKPOINT. L'approbation explicite doit nommer l'action spécifique, les preuves, les limitations et le plan de vérification. Si l'autorisation reste ambiguë, revenez à BLOCKED_CLARIFICATION avec la plus petite question faisant autorité qui la résout. Lorsqu'aucune politique applicable n'exige la propriété absente, un humain peut choisir une action plus restreinte ou accepter un risque défavorable établi ; l'approbation ne rend jamais une affirmation factuelle non étayée vraie. Une contradiction de vérification ou une revendication post-modification obligatoire non vérifiée revient à BLOCKED_EVIDENCE pour enquête/remédiation.

Registre de Preuves pour état persistant

Pour les travaux à risque moyen et élevé, l'état opérationnel d'une modification active doit persister au-delà du contexte de conversation. Le Registre de Preuves est l'enregistrement persistant. Il s'agit de la même référence Markdown, de la même taxonomie de statut, de la même chaîne de provenance et de la même porte d'achèvement que le reste de cette compétence, appliqués à un document par modification.

Le registre est un enregistrement, pas une preuve

Écrire une revendication dans un registre ne la rend pas vraie. Une entrée de registre doit préserver la provenance, exactement comme le reste de cette compétence. PASS dans un registre signifie une observation enregistrée qui, en ses propres termes, étaye la revendication ; l'enregistrement n'est pas plus fort que l'observation. Une affirmation nue sans observation, artefact, méthode ou limitation est INVÉRIFIÉE, peu importe où elle est écrite.

Quand un registre est requis

Utilisez la classification de risque existante :

• FAIBLE risque : le registre est facultatif. Un renommage de variable locale, une correction de faute de frappe isolée ou une correction de documentation non conséquente n'en a pas besoin.
• MOYEN risque : le registre est recommandé lorsque la modification implique un suivi de preuves significatif, plusieurs étapes de vérification ou un travail pouvant s'étendre sur plusieurs phases d'enquête ou d'exécution.
• ÉLEVÉ risque : le registre est obligatoire. Les modifications d'API publique ou de contrat, l'authentification, l'autorisation, les paiements, les opérations financières, les migrations de schéma, les opérations destructrices, les actions irréversibles et tout impact de production significatif en nécessitent un.

Où réside un registre

Emplacement par défaut : .evidence-gated/active/<id-modification>.md, les registres terminés étant déplacés vers .evidence-gated/archive/<id-modification>.md. La valeur par défaut est un répertoire d'état de travail, ne faisant pas partie du dépôt publié : ajoutez .evidence-gated/active/ au .gitignore pour les nouveaux projets sauf si l'utilisateur ou les conventions du dépôt disent le contraire. Les conventions du dépôt et les instructions explicites de l'utilisateur prévalent ; l'agent ne doit pas modifier silencieusement .gitignore simplement parce que la compétence utilise un registre, et ne doit pas valider un registre actif sans autorisation. Si la modification est particulièrement à haut risque, l'utilisateur demande explicitement une piste d'audit, ou les conventions du dépôt exigent une documentation persistante, le registre peut être validé intentionnellement et nommé en conséquence (par exemple, docs/evidence-gated/<id-modification>.md).

Cycle de vie du registre

1. Déterminez si un registre est requis en fonction de la classification de risque ci-dessus.
2. Localisez un registre actif existant avant d'en créer un nouveau ; ne créez pas plusieurs registres pour la même modification active.
3. Lisez le registre actif avant de continuer. Relisez-le avant : une nouvelle phase d'enquête, une exécution de modification significative, une demande d'approbation checkpoint, une action sur approbation, tout changement de portée, tout changement d'exigence de vérification, et toute demande d'achèvement. La relecture doit confirmer l'action demandée actuelle, la portée autorisée, le risque, les hypothèses actives, les revendications obligatoires, la vérification obligatoire, l'état du checkpoint, l'état de l'approbation, les limitations connues et la disposition actuelle. Ne vous fiez pas à la mémoire pour aucun de ces éléments.
4. Mettez à jour le registre lorsque des faits matériels changent : risque, portée, hypothèses, preuves, exigences de vérification, référence, état du checkpoint, état de l'approbation, état d'exécution, résultats de vérification, disposition finale.
5. Finalisez le registre avec une disposition terminale : COMPLETE, BLOCKED_EVIDENCE ou BLOCKED_CLARIFICATION. Un registre impliquant COMPLETE alors que des revendications obligatoires restent non résolues est invalide et doit être réécrit ou renvoyé à la condition de déblocage appropriée.

Contenu requis

Le registre actif doit contenir au minimum : identifiant de modification et statut actuel, action demandée, portée autorisée, éléments explicitement hors de portée, limitations et inconnues de portée, classification de risque avec raisons, hypothèses matérielles avec statut et preuves ou limitation à l'appui, le contrat de preuves (une entrée par revendication pertinente pour la décision avec preuves requises, type de preuve, conséquence si non étayée, et statut), les enregistrements de preuves (un par élément significatif, préservant revendication -> fait observé -> artefact ou résultat de commande -> méthode -> limitation -> statut), la vérification de référence, l'état du checkpoint, le journal d'exécution pour les transitions d'état matérielles, l'enregistrement de vérification pour chaque vérification obligatoire, et une section limitations/manquantes/contradictoires/non résolues.

Phases et dispositions

L'en-tête du registre porte deux champs distincts. Ne les confondez pas.

Phase Opérationnelle décrit ce que l'agent fait actuellement avec la modification, dans l'ordre de progression du travail. Les phases sont BROUILLON (registre créé, contrat pas encore écrit), ENQUÊTE (rassemblement de preuves, capture de la référence, résolution des hypothèses), EXÉCUTION (modification de portée autorisée en cours), VÉRIFICATION (vérification post-modification et finalisation). Les phases sont de la comptabilité. Elles n'autorisent rien ; elles ne bloquent rien ; elles ne comptent pas comme preuves. Une transition de phase sans le changement de disposition correspondant n'est pas un changement d'autorisation.

Disposition est la décision de porte du protocole universel. Les dispositions sont exactement les six états canoniques de cette compétence : BLOCKED_CLARIFICATION, BLOCKED_EVIDENCE, ALLOW, ALLOW_WITH_VERIFICATION, CHECKPOINT, COMPLETE. La disposition est ce qui autorise l'exécution, verrouille la vérification et finalise la modification. Lors de la finalisation, la disposition du registre doit être l'une de ces six. Les phases intermédiaires ne remplacent pas une disposition.

La même modification peut être en phase EXÉCUTION et en disposition ALLOW_WITH_VERIFICATION en même temps. La même modification peut être en phase ENQUÊTE et en disposition BLOCKED_EVIDENCE en même temps. Les confondre rend l'autorisation floue et cache la porte ; ne le faites pas.

Les règles d'approbation et de portée s'appliquent dans le registre

Les phrases d'approbation génériques ("allez-y", "à vous de voir", "faites au mieux", "utilisez votre jugement") ne sont pas une autorisation lorsqu'elles sont enregistrées dans un registre, pas plus qu'elles ne le sont dans une conversation. L'approbation dans le registre doit être liée au même enregistrement APPROBATION CHECKPOINT REQUISE utilisé par le reste de cette compétence. Découvrir qu'un autre composant est lié à la modification n'est pas une nouvelle autorisation. Une nouvelle découverte de preuve n'est pas une nouvelle portée. Lorsque la portée change matériellement : enregistrez la modification proposée, identifiez les revendications et vérifications affectées, réévaluez le risque, déterminez si une nouvelle autorisation est requise, mettez à jour le registre, et n'exécutez pas une portée élargie non autorisée.

Hiérarchie des sources de vérité

L'autorité dépend de ce qui est établi. La compétence porte fondamentalement sur les affirmations factuelles verrouillées par des preuves, donc une affirmation d'utilisateur sur une question factuelle ne remplace pas cette preuve. La hiérarchie est à deux axes :

Pour l'intention, l'autorisation, la portée souhaitée et les compromis acceptables :

1. Instruction explicite ou approbation de l'utilisateur.

Pour l'état factuel du dépôt, le comportement d'exécution et les résultats de vérification :

1. Preuves directes du dépôt et de l'exécution, y compris les sorties de commande pour les vérifications exécutées.

[truncated for translation]