Débogage de la logique de vérification de build de Claude Code : pourquoi la recherche par nom échoue et comment la recherche par empreinte structurelle la corrige

Un développeur sur r/ClaudeAI rapporte que Claude Code n'a pas détecté des fonctionnalités existantes à plusieurs reprises, affirmant « est-ce que X est construit ? » renvoyait « non » quatre fois en une seule session — alors que la fonctionnalité existait déjà. La cause profonde : l'agent cherchait par nom (mots-clés, synonymes) au lieu de chercher par empreinte structurelle (routes, schémas, outils enregistrés, tâches planifiées, décisions documentées). Les noms dérivent ; les artefacts architecturaux, non.

Le schéma

Demander « cette fonctionnalité est-elle déjà construite ? » déclenchait un « non, voici comment la construire » confiant, même lorsque la fonctionnalité était partiellement implémentée. À chaque fois, l'utilisateur devait insister pour obtenir la vraie réponse. Le développeur a diagnostiqué que l'agent cherchait bien, mais avec des requêtes basées sur le vocabulaire qui manquaient le code avec des conventions de nommage différentes.

La règle (recherche par empreinte structurelle)

La règle synthétisée force l'agent à chercher par forme, pas par nom. Par exemple, au lieu de « trouver la fonctionnalité X », il demande « quels outils plugin existent ? » ou « quelles routes, schémas, ou tâches enregistrées correspondent à cette fonctionnalité ? » Cela attrape le code antérieur qu'une recherche par nom n'aurait jamais trouvé.

Changement clé : « Chercher avec de meilleurs synonymes reste chercher par nom. La version empreinte l'attrape (le code antérieur a enregistré un outil plugin, et 'quels outils plugin existent ?' est une recherche étroite à fort signal). »

Retour demandé à la communauté

• Formes d'hallucination que la recherche par empreinte structurelle n'attraperait PAS
• Schémas d'audit de façade où la forme est satisfaite sans substance
• Déclenchement excessif sur des questions qui ne sont pas réellement des affirmations d'absence
• Amplification de confiance : post-audit, l'agent est plus confiant dans ses conclusions, rendant les erreurs d'ontologie erronée plus difficiles à détecter
• Rigueur d'ontologie erronée : l'agent cherche des motifs GraphQL sur un système REST, ne trouve rien, confirme l'absence

Le développeur teste la règle dans un projet séparé pendant 2 à 3 semaines avant d'envisager une configuration globale. Il invite les autres à partager des règles qui ont résolu « l'hallucination avec rigueur » (pas seulement l'hallucination).