Comprobaciones anti-slop

Los agentes escriben código plausible rápidamente, y parte de él toma atajos que un ingeniero cuidadoso no usaría: una prueba omitida para obtener aprobación, un error ignorado, un stub dejado en el código, una comprobación de tipo silenciada, o una segunda forma de hacer algo que ya existe en su base de código. El anti-slop busca estos casos en cada cambio y envía el cambio de vuelta al agente desarrollador antes de que usted lo vea.

Es una comprobación más dentro de su política de calidad, no una puntuación separada. Un cambio supera esta comprobación cuando no introduce nada que bloquee su integración.

Qué busca#

Las reglas se agrupan en familias. Cada regla bien bloquea, aconseja o registra información.

• Pruebas — pruebas enfocadas u omitidas, pruebas eliminadas, aserciones quitadas o debilitadas, pruebas que no pueden fallar.
• Supresiones — nuevas desactivaciones de linter, ignorancias de tipos y any conversiones.
• Compilación y CI — pasos de prueba eliminados o neutralizados, umbrales reducidos, "aprobar sin pruebas".
• Evidencia de pruebas — resultados en caché presentados como ejecución, cero pruebas ejecutadas, una ejecución parcial reportada como completa.
• Código de producción — restos de depuración, marcadores de posición, datos ficticios, notas para humanos, código de prueba enviado a producción.
• Manejo de errores — errores ignorados, mecanismos de respaldo que ocultan fallos, comprobaciones de permisos que siempre permiten el acceso.
• Comentarios, Arquitectura, Dependencias, Alcance del cambio, Seguridad, Almacenamiento en caché y el registro de actividad del agente — el registro de las acciones que realizó el agente, como modificar una prueba justo después de que fallara.

La página de cada regla en Calidad → Comprobaciones → Anti-slop muestra qué coincide con ella y por qué es importante.

Solo lo que el cambio introdujo puede bloquear la comprobación.#

La mayoría de los repositorios ya contienen algunos de estos patrones. Anti-slop clasifica cada Hallazgo en uno de tres grupos:

• Introducido — nuevo en este cambio.
• Modificado — ya existente, en una línea o función que el cambio edita.
• Existente — en otra parte del repositorio.

Solo un Hallazgo introducido de una regla bloqueante hace que la comprobación falle. Los Hallazgos modificados y existentes se registran para que pueda ver su deuda técnica, pero nunca impiden trabajos no relacionados. Mover código no cuenta como introducirlo; copiarlo sí.

Añadirlo a una política#

Abra una política en Calidad → Políticas y seleccione Añadir presete anti-slop. Esto añade cinco expectativas:

1. Las pruebas siguen demostrando la validez del cambio.
2. Nada incompleto o exclusivamente para pruebas se envía a producción.
3. No hay nueva deuda estructural.
4. El cambio permanece dentro del alcance y se integra con el estilo de este código.
5. Las nuevas dependencias son reales y de confianza.

Publique la política y la próxima ejecución de cada proyecto vinculado incluirá la comprobación.

Elegir una disciplina de cambio#

La disciplina indica al agente desarrollador hasta dónde puede extenderse un cambio:

• Quirúrgico — solo lo que necesita la especificación; otros problemas se reportan, pero no se corrigen.
• Equilibrado (predeterminado) — también corrige pequeños problemas en las líneas que el cambio modifica de todos modos.
• Restaurador — también limpia los Hallazgos dentro de las funciones que el cambio edita.

El agente sigue las mismas reglas antes de enviar el cambio: recibe la disciplina y sus patrones en cuarentena desde el principio, ve las reglas rápidas después de cada edición y tiene una oportunidad para corregir los Hallazgos bloqueantes antes de la fase de QA.

Adaptarlo a su base de código#

• Sobrescrituras de reglas — desactive una regla o hágalo aconsejar en lugar de bloquear, en la configuración de la comprobación.
• Paquetes de reglas — sus propios patrones, importaciones y dependencias prohibidas, límites de tamaño de archivo, o resultados de herramientas que ya utiliza (SARIF). Los paquetes tienen versión; una política fija la versión que usa.
• Cuarentena — patrones que no desea que se copien más, cada uno con el reemplazo a usar. Se indica a los agentes que no los difundan y las nuevas copias se marcan.
• Archivo del repositorio — .coroid/anti-slop.yml en el repositorio puede añadir reglas y excluir rutas generadas o externas. Se lee desde la base del cambio, por lo que un cambio no puede relajar sus propias reglas, y editarlo requiere aprobación.

Hallazgos y exenciones#

Los hallazgos aparecen en Calidad → Hallazgos, filtrados por comprobación. Para aceptar uno, indique el motivo de la exención; dicha exención se registra vinculada a ese hallazgo específico. Los agentes no pueden eximir sus propios hallazgos. Si un agente señala que una prueba es incorrecta y la modifica, un revisor debe aprobar ese cambio antes de que la comprobación se considere superada.

Reglas de juicio#

Dos reglas consultan al modelo, línea por línea: una comprobación defensiva para algo que el código mostrado hace imposible, y un comentario que contradice al código contiguo. Solo dan recomendaciones, nunca bloquean. Habilitar reglas de juicio está activado para una nueva comprobación, con un límite de decisiones por ejecución; desactívalo en la configuración de la comprobación.

Tus propios agentes#

Las mismas reglas pueden guiar a los agentes que ejecutes tú mismo:

• Descargar fragmento de AGENTS.md, en la Deuda técnica pestaña de Calidad → Comprobaciones → Anti-slop, proporciona la disciplina de cambios del proyecto, la cuarentena y las principales reglas como una sección para pegar en las instrucciones de tus agentes.
• A través del servidor MCP de Coroid, anti_slop_rules describe tu política publicada y anti_slop_scan analiza una rama de un proyecto sincronizado, en modo de solo lectura.