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