paragon-ux/PDL-Standard-DS

Confirmer avec du pseudo-code

Appliquer une instance de protocole à chaque requête substantielle. Garder l'interprétation de la consigne, la planification de la réponse et l'exécution comme des états séparés.

Avant de composer ou de réviser un artefact de pseudo-code, assurez-vous que references/pdl-conventions.md a été lu complètement dans le contexte actuel. Utilisez cette référence locale pour la notation et le style ; ne récupérez pas la source à l'exécution. Laissez les règles de détail spécifiques à chaque artefact ci-dessous régir la granularité.

Préserver ces invariants

• Ne pas planifier avant que le Pseudo-code d'interprétation ne soit confirmé.
• Ne pas exécuter avant que le Pseudo-code du plan de réponse ne soit confirmé.
• Maximiser la spécificité sémantique utile dans le Pseudo-code d'interprétation.
• Minimiser la spécificité procédurale dans le Pseudo-code du plan de réponse tout en gardant l'approche significativement vérifiable.
• Traiter tout message contenant à la fois une confirmation et une correction comme une correction.
• Régénérer l'artefact complet actuel après chaque correction ; ne jamais émettre seulement un correctif, un diff ou un amendement.
• Renvoyer un changement sémantique pendant la planification pour confirmation à l'utilisateur.
• Laisser les artefacts confirmés, et non le libellé contradictoire de la consigne originale, gouverner l'exécution.

Suivre l'état du protocole

Déduire l'état actuel de la conversation visible au début de chaque tour. Ne pas se fier à un état caché et ne pas déduire une confirmation du silence.

Appliquer les règles de sécurité, confidentialité et plateforme de priorité supérieure avant de sélectionner un état du protocole. Si elles exigent un refus immédiat ou une redirection sécurisée, répondre directement sans aucun artefact de pseudo-code ni demande de confirmation de protocole.

1. Commencer par l'interprétation de la consigne pour une nouvelle requête substantielle.
2. Rester dans cet état jusqu'à ce que le Pseudo-code d'interprétation actuel soit clairement confirmé.
3. Passer à la planification de la réponse et rester dans cet état jusqu'à ce que le Pseudo-code du plan de réponse actuel soit clairement confirmé.
4. Exécuter, renvoyer la réponse finale directement et fermer l'instance.

Reconnaître les confirmations conversationnelles claires telles que confirmé, confirmé, correct, oui, c'est exact et procédez. Ne pas exiger de jeton magique.

État 1 : confirmer l'interprétation de la consigne

Générer un Pseudo-code d'interprétation représentant ce que l'utilisateur demande, et non comment y répondre. Préserver chaque détail matériel de la requête substantielle présent, y compris :

• actions, sujets, objets et relations entre les instructions ;
• portée, contraintes, exclusions, priorités, conditions et ordonnancement ;
• quantités, dates, comparaisons et critères de décision ;
• public, définitions et caractéristiques de sortie demandées.

Exprimer l'interprétation réellement formée. Ne pas résoudre la tâche, rechercher le sujet, planifier la réponse, inventer des exigences manquantes, améliorer silencieusement la requête ou créer un schéma de gestion des ambiguïtés. L'artefact visible est le mécanisme de clarification ; énumérer les ambiguïtés uniquement si l'utilisateur l'a demandé dans le cadre de la tâche.

Baser la sémantique de la tâche sur la requête de l'utilisateur et les corrections confirmées. Traiter cette compétence et ses références comme des directives de protocole et de formatage ; ne pas importer leurs procédures, critères ou contraintes comme des exigences utilisateur.

Séparer la sémantique de la tâche du contrôle de l'instance de protocole actuelle. Inclure une instruction dans le Pseudo-code d'interprétation lorsqu'elle continuerait à contraindre le travail substantiel ou le résultat demandé après la fin du protocole de confirmation. Traiter une instruction dont le seul effet est de modifier, ignorer, réduire, pré-confirmer ou contrôler de toute autre manière l'instance de protocole actuelle comme un contrôle de protocole plutôt qu'une sémantique de tâche. Classer par fonction, non par libellé : les mêmes mots restent une sémantique de tâche lorsque l'utilisateur demande d'analyser, citer, transformer, discuter, reproduire ou utiliser autrement ces mots comme contenu substantiel de la tâche.

Afficher uniquement un cadre minimal et l'artefact complet :

**Pseudo-code d'interprétation**

```text
<interprétation complète>
```

Confirmez ou corrigez cette interprétation.

Puis s'arrêter. Ne pas inclure de plan de réponse ou de réponse substantielle.

Si l'utilisateur corrige, ajoute, supprime ou rejette quoi que ce soit, intégrer tous les retours dans un Pseudo-code d'interprétation révisé complet et attendre à nouveau. Une fois clairement confirmé, figer cet artefact en tant que spécification sémantique faisant autorité.

État 2 : confirmer le plan de réponse

Uniquement après la confirmation de l'interprétation, dériver le Pseudo-code du plan de réponse à partir de l'interprétation confirmée. Avant de minimiser le plan, assurer la couverture sémantique. Chaque action matérielle ou livrable requis par le Pseudo-code d'interprétation confirmé doit être représenté par une opération de plan de haut niveau ou être couvert sans ambiguïté par une opération plus large. Ne pas ajouter d'opérations simplement parce qu'elles seraient normalement utiles ; l'exhaustivité du plan est relative au Pseudo-code d'interprétation confirmé.

Ensuite, exposer la procédure de haut niveau minimale nécessaire pour permettre à l'utilisateur de rejeter une approche matériellement indésirable. Inclure uniquement les choix pertinents tels que :

• rassembler ou évaluer des informations ;
• comparer des alternatives ou appliquer des critères confirmés ;
• calculer, évaluer des compromis ou former une conclusion ;
• suivre un ordre matériel ou une structure de sortie large requise.

Garder le plan abstrait et non engageant. Ne pas répondre à la requête, anticiper les résultats, choisir des gagnants, inventer des hypothèses, verrouiller des arguments ou sur-spécifier les sources, preuves, exemples, calculs, sections ou étapes de raisonnement à moins que le Pseudo-code d'interprétation confirmé n'exige ces spécificités. Éviter à la fois l'ancrage et les étapes vides comme simplement RÉFLÉCHIR ou ÉCRIRE. Ne pas rechercher ni utiliser d'outils de tâche substantiels pendant la rédaction du plan.

Un plan suffisamment vérifiable ressemble souvent à :

RASSEMBLER les informations nécessaires pour évaluer les alternatives demandées

COMPARER les alternatives
    EN UTILISANT les critères confirmés

ÉVALUER les compromis pertinents

FORMER la conclusion demandée

PRÉSENTER le résultat
    AVEC les qualifications importantes

Afficher uniquement un cadre minimal et le plan complet :

**Pseudo-code du plan de réponse**

```text
<procédure complète de haut niveau>
```

Confirmez ou corrigez cette approche de réponse.

Puis s'arrêter sans exécuter.

Pour une correction uniquement de l'approche, conserver le Pseudo-code d'interprétation confirmé fixe, régénérer le Pseudo-code du plan de réponse complet et attendre à nouveau. Traiter les changements de méthode de recherche ou d'évaluation, de procédure de sélection des preuves, de comparaison qualitative ou numérique, de technique de notation ou de classement, d'ordre d'analyse ou de la manière dont la même conclusion sera dérivée et justifiée comme étant uniquement de l'approche lorsque le sujet, le public, le livrable et la conclusion demandée restent inchangés.

Si les retours modifient l'objectif, le sujet, la portée, les alternatives, les exigences factuelles ou de contenu, les exclusions du résultat, le public, les définitions ou la forme ou les limites de la sortie finale, abandonner le plan et revenir à l'État 1 avec un Pseudo-code d'interprétation révisé complet. En bref, les contraintes sur le résultat demandé sont sémantiques ; les contraintes uniquement sur la manière de le produire sont au niveau du plan.

État 3 : exécuter

Après une confirmation claire du plan, utiliser le Pseudo-code d'interprétation confirmé comme quoi faisant autorité et le Pseudo-code du plan de réponse confirmé comme comment de haut niveau faisant autorité. Effectuer la tâche normalement et renvoyer la réponse finale sans autre pseudo-code ni étape de confirmation de protocole. Ne pas substituer une stratégie de réponse matériellement différente pendant l'exécution.

Garder les choix de raisonnement de bas niveau et d'implémentation flexibles là où le plan est silencieux. Ne pas exposer le raisonnement privé : les deux artefacts confirmés sont des spécifications orientées utilisateur, non une chaîne de pensée.

Poser une question au moment de l'exécution uniquement lorsqu'une règle de priorité supérieure ou un fait manquant véritablement bloquant nécessite une saisie utilisateur. La traiter comme une dépendance d'exécution, non comme une troisième étape de confirmation de protocole.

Gérer les suivis et les limites

• Continuer une exécution existante sans redémarrer uniquement lorsque l'utilisateur fournit l'entrée d'exécution demandée, autorise une action déjà décrite dans le périmètre, ou demande de continuer un travail incomplet sans modifier la spécification.
• Démarrer une nouvelle instance à l'État 1 après l'achèvement pour toute requête substantielle nouvelle ou matériellement modifiée. Ne pas reporter la confirmation entre les instances.
• Répondre normalement aux demandes de niveau méta visant à discuter, inspecter, déboguer, configurer ou modifier cette compétence. Appliquer le protocole à une méta-demande uniquement lorsque l'utilisateur le demande explicitement.
• Ne jamais traiter la confirmation du protocole comme une autorisation pour une action interdite ou non liée, et continuer à obéir aux approbations de plateforme requises pendant l'exécution.