Checklist développeur H-Logic

Statut documentaire : guide — voir Maturité et preuves.

Utiliser cette checklist avant de considérer une fonctionnalité H-Logic comme documentée au niveau production.

Modélisation

• Les types structurels utilisés par l’expression sont définis.
• Rôles et attributs sont séparés intentionnellement.
• Le contexte est un rôle explicite lorsqu’il affecte le sens.
• L’attachement d’interface utilise :: uniquement lorsque l’identité du support doit être préservée.
• Les termes nommés utilisent & uniquement pour référencer une valeur d’environnement.
• Les relations sont réifiées lorsque le fait a besoin d’identité ou de cycle de vie.

Requêtes

• La requête utilise ask ou ?, pas des variables de type ?x.
• Le mode de raisonnement est choisi explicitement.
• Les options de portée ne sont pas plus larges que nécessaire.
• Les wildcards sont traités comme des positions non contraintes.
• Le client gère les formes zéro, une et plusieurs réponses.
• Les résultats hérités utilisent les mappings Runtime plutôt que des hypothèses sur les slots bruts.

Règles et projections

• Chaque rôle public d’une définition composite est contraint par son corps.
• La validité sémantique est visible dans les règles/contraintes plutôt que cachée uniquement dans des scripts.
• La confiance, la provenance ou le contexte attachés à une relation logique restent attachés à cette relation.

Validation

• L’expression est acceptée par la grammaire H-Logic cible.
• La résolution sémantique réussit dans le Runtime ciblé.
• Un test parser ou évaluation couvre la fonctionnalité lorsque possible.
• Tout H-Logic généré ou proposé par une IA est parsé et validé avant de pouvoir modifier la mémoire conceptuelle.

Un exemple documentaire qui n’a pas passé ce gate ne doit pas être marqué Status: reference.