Angle complémentaire à la campagne « surfaces non couvertes » (verify-uncovered-
before-gating prouve qu'une dérive SERAIT attrapée si un gate mordait) : en phase
launch, les gates VERTS mordent-ils réellement ? J'ai mutation-testé le suite, chaque
mutation immédiatement révertée (arbre propre re-vérifié) :
- check_ci_integrity : job fantôme dans gate.needs (DANGLING) → RED · job réel retiré
de gate.needs (MISSING) → RED
- check_artifacts : octet parasite dans out/MANIFEST.json (repro byte) → RED
- check_readme_claims : README « 22/22 modules »→« 23/22 » → RED · « 15 promesses »
→« 16 » → RED
- guard_constraints : URL github.com (usage réel) → RED · « stripe payments » → RED
7/7 : les 4 gates à oracle recomputé MORDENT ; « vert » = réellement conforme.
Non-finding documenté (piège évité) : guard_constraints ne flague PAS le mot nu
« GitHub », à dessein (terme interdit = l'USAGE github.com|git@github, pas la mention —
mémoire guard-constraints-flags-usage-not-mention). Ma 1re mutation « bare word » est
restée verte → ce n'était pas un trou mais une mutation mal conçue ; re-testé avec un
vrai usage → RED.
Zéro gate ajouté (aucune surface non couverte prouvée · #5), seul fichier touché = le
log (ligne M5b citant github.com marquée ci-allow, cf. guard-constraints-log-prose).
7 gates re-joués → exit 0. Aucune commande touchant au VPS.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude Code DTP Worker
bd3572b382