verify-conformance

name	verify-conformance
description	Compare spec (vault PARA) et code (GitHub) selon completeness × correctness × coherence. Bloque les audits aval si CRITICAL détecté.
version	1.0.0
platforms	["linux","macos"]
metadata	{"hermes":{"tags":["verify","conformance","spec","quality","gate"],"related_skills":["github","code-audit","security-audit"],"model":"deepseek-v4-full"}}

verify-conformance

Adaptation de verify (65) — ULK → Hermes. Carte : docs/backlog/2026-06-28-SPEC-HERMES-VERIFY-CONFORMANCE/CARD.md (P2, GitHub #238).

Gate de qualité : matrice 3×3 (completeness × correctness × coherence) × 3 sévérités (CRITICAL / WARNING / SUGGESTION). Un CRITICAL bloque les audits coûteux aval (code-audit, security-audit). Spec lue depuis le vault, code lu via github.

Runtime & modèles

• DeepSeek V4 full : lecture spec (vault), lecture code ciblé (github), analyse croisée 3 axes, émission des sévérités, décision de gate. Tier ULK sonnet → DeepSeek full.
• Pas de délégation coding : la skill compare et juge, elle n'écrit pas de code. Le delegate_task éventuel ne sert qu'à lire un repo large par pagination — lire n'est pas coder.

Procédure

1. Entrée : chemin spec (vault) + repo GitHub (owner/repo + path ou SHA).
2. Lire spec + extraire exigences clés (headings, critères d'acceptation = source de vérité).
3. Lire le code ciblé sur les exigences (via github) — pas tout le repo.
4. Scorer 3×3 : completeness (exigences couvertes ?), correctness (comportement conforme ?), coherence (pas de contradiction ?).
5. Rapport sévérités fichier:ligne + gate : exit non-nul si CRITICAL.
6. Se brancher en pré-condition de code-audit / security-audit.

Critères d'acceptation

• Les 3 axes completeness / correctness / coherence évalués et documentés.
• Les 3 sévérités émises avec fichier:ligne.
• Un CRITICAL bloque effectivement code-audit / security-audit.
• Fonctionne avec une CARD.md Faru standard en entrée.
• Rapport < 20 lignes pour un scope normal.

Pièges

• Ne pas lire tout le repo : cibler les fichiers liés aux exigences (Étapes de la CARD).
• CARD.md Faru ≠ cahier des charges exhaustif : adapter les seuils de completeness.
• Éviter les faux CRITICAL : completeness partielle = WARNING, pas CRITICAL par défaut.