Silenciando al Guardián: Excepciones explícitas en linters estáticos

El Desafío (Síntoma)

Al implementar una nueva regla en el orquestador maestro (merci-audit.py) para prohibir y detectar estilos en línea (style="..."), la herramienta bloqueó la compilación de la biblioteca. El diagnóstico reveló un Falso Positivo Legítimo: el linter estaba escaneando un artículo técnico que explicaba cómo funciona la especificidad CSS, detectando los bloques de código de ejemplo como violaciones reales de la arquitectura SASS.

La Maniobra (Lógica)

Para solucionar esto, se descartó aplicar sobreingeniería a las Expresiones Regulares (RegEx) del auditor (intentar enseñarle a distinguir si el texto estaba dentro de una etiqueta <code> o no). En su lugar, se optó por la simplicidad:

Se inyectó una válvula de escape en el código de Python que le instruye ignorar la línea actual si detecta el comentario HTML <!-- merci-audit:silence-style -->. Al añadir esta firma al final de la línea conflictiva en el Markdown, el linter la omite silenciosamente.

El Aprendizaje / Deuda Técnica

Una herramienta de QA (Quality Assurance - Aseguramiento de Calidad) implacable y sin excepciones es peligrosa, ya que incentiva a los desarrolladores a apagar el escudo por completo cuando se topan con un bloqueo.

Permitir el silenciamiento en línea (Inline Silencing) es el estándar de la industria (como eslint-disable-next-line en JavaScript). Obliga al desarrollador a firmar explícitamente la excepción, dejando constancia de que ha revisado el código y asume la responsabilidad arquitectónica, sin comprometer la seguridad del resto del repositorio. El pragmatismo vence a la complejidad algorítmica.