Vérification Conceptuelle

Que fait Vérification Conceptuelle ?

Décider si un raisonnement ou un cahier des charges tient la route avant que quiconque ne construise dessus. Rester en lecture seule sauf si l'utilisateur demande explicitement des modifications.

Commencer par les preuves

• Récupérer les preuves les moins coûteuses en premier : état du dépôt, tests, sorties du compilateur ou du vérificateur de types, documentation, logs, benchmarks, configuration et comportement à l'exécution. Le raisonnement commence là où les preuves s'arrêtent ; ne jamais raisonner à la place de chercher.
• Respecter la révision, la branche, le périmètre et les limites de lecture demandés. Lorsqu'un cahier des charges est lié à un commit, lire ce commit, pas l'arbre de travail.
• Traiter chaque citation, nombre, affirmation sur le dépôt et précédent cité comme quelque chose à vérifier.
• Étiqueter chaque prémisse matérielle comme observée, inférée, supposée ou inconnue. Une source indisponible est une lacune de couverture, pas une confirmation.

Choisir le mode

• Mode Raisonnement pour une décision, une affirmation ou une conclusion.
• Mode Cahier des charges pour un contrat d'implémentation, un plan ou un brief qu'un implémenteur suivra.

Utiliser les deux lorsqu'un cahier des charges repose sur une affirmation contestée.

Mode Raisonnement

1. Énoncer la décision ou l'affirmation.
2. Lister les prémisses dont elle dépend, étiquetées comme ci-dessus.
3. Vérifier que les preuves soutiennent la conclusion sans étapes sautées, support circulaire ou plus de certitude que les prémisses ne le permettent.
4. Chercher des prémisses qui ne peuvent pas toutes être vraies.
5. Nommer le maillon faible important.
6. Donner le contre-argument ou l'explication concurrente le plus fort et crédible. Pas d'hommes de paille.
7. Demander si une autre décision gère mieux l'incertitude clé, y compris la réversibilité quand elle compte.
8. Recommander la correction la plus petite : conserver, modifier, enquêter sur une inconnue nommée, ou changer.

Mode Cahier des charges

Vérifier ce qui pourrait rendre l'implémentation ou son acceptation incorrecte :

1. Résultat : comportement, exclusions et prérequis sont cohérents entre eux.
2. Sources : citations, plages, règles de protocole, formules et faits externes correspondent à leurs sources primaires.
3. Arithmétique : comptages, limites, matrices et totaux se recalculent exactement.
4. Couverture : chaque appelant, test, interface, invariant, promesse de compatibilité et phrase de documentation concerné est pris en compte. Effectuer une recherche bornée au-delà des chemins que le cahier des charges nomme, sans dériver vers une revue d'architecture non liée.
5. Puissance d'acceptation : chaque test requis peut échouer pour le défaut qu'il cible. Les contrôles sont significatifs, et les cas négatifs ont des échecs observables.
6. Clarté d'exécution : périmètre du fichier, ordre, comportement aux limites et en cas d'échec, et preuve d'achèvement ne laissent rien d'important à deviner.
7. Périmètre : les précédents et les travaux futurs ne justifient pas silencieusement plus que ce que les preuves actuelles exigent.

Évaluer les constats avec les termes de sévérité du dépôt, ou :

• BLOQUANT : peut produire une implémentation erronée, un faux positif ou des devinettes inévitables.
• AMENDER : une lacune ou ambiguïté concrète ; l'approche tient toujours.
• NIT : une correction de formulation ou de preuve qui ne change pas l'implémentation.

Sortie

• Commencer par le verdict. Mode Raisonnement : Le raisonnement tient la route, ou ce qui le casse. Mode Cahier des charges : Prêt ou Pas prêt, avec la raison décisive.
• Le mode Raisonnement donne ensuite seulement ce qui importe : hypothèses clés, maillon faible, meilleur contre-argument et recommandation.
• Le mode Cahier des charges donne ensuite des constats numérotés par ordre de priorité (titre, sévérité, preuve exacte, pourquoi c'est important, correction concrète) et une courte liste Vérifié des affirmations importantes qui ont survécu.
• Terminer avec la confiance (haute, moyenne ou basse), la preuve la plus susceptible de changer le verdict, et les lacunes de couverture ou sources non vérifiées.

Règles

• Ne soulever que des points qui pourraient changer la décision. Un verdict propre est valide ; ne jamais fabriquer de constats.
• Ne pas inventer de probabilités ou de scores que les preuves ne peuvent pas soutenir.
• Interroger l'utilisateur uniquement lorsqu'une décision ou une exigence manquante bloque la revue. Récupérer les faits disponibles soi-même.
• Cette revue n'autorise pas l'implémentation, les modifications ou toute autre action importante.
• Pour la conception d'interface et de jointure, recommander $codebase-design au lieu de refaire sa méthode.

Fondement : Travaux d'Anthropic et d'Aligned Research sur l'Index de Raisonnement Conceptuel, adaptés en workflow développeur. Cette compétence n'implémente pas le CRI ni ses benchmarks.