Comprobaciones anti-slop

Los agentes escriben código plausible rápidamente, y parte de él toma atajos que un ingeniero cuidadoso evitaría: una prueba omitida para obtener el resultado esperado, un error ignorado, un stub dejado en el código, una comprobación de tipos silenciada, o una forma alternativa de hacer algo que ya existe en tu base de código. Anti-slop esta comprobación busca estos casos en cada cambio y envía el cambio de vuelta al agente desarrollador antes de que tú lo veas.

Es una comprobación dentro de tu política de calidad, no una puntuación aparte. Un cambio la supera cuando no introduce nada que bloquee su aprobación.

Qué busca#

Las reglas se agrupan en familias. Cada regla o 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 de tipo.
• Compilación e CI — pasos de prueba eliminados o neutralizados, umbrales reducidos, "pasar sin pruebas", Acciones GitHub no vinculadas a un commit.
• Evidencia de pruebas — resultados en caché presentados como si fueran una 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, verificaciones de permisos que permiten el acceso sin restricciones.
• Dependencias — paquetes que no existen o se reportan como maliciosos, nuevos paquetes con nombres similares a otros populares, paquetes que ejecutan código al instalarse, manifiestos modificados sin actualizar su archivo de bloqueo.
• Seguridad — secretos en el código, comprobaciones TLS desactivadas, verificaciones de autorización eliminadas, scripts descargados y ejecutados directamente desde la red.
• Comentarios, Arquitectura, Ámbito del cambio, Almacenamiento en caché y el registro del agente — el registro de las acciones del agente, como editar una prueba justo después de que falle.

Cada regla en Reglas Anti-slop, accesible desde la fila Anti-slop en Control de Calidad, muestra qué coincide con ella, por qué es importante y qué efecto tiene en la configuración predeterminada de la organización o en un proyecto.

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

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

• Introducido — nuevo en este cambio.
• Modificado — ya existente, en una línea o función que el cambio edita.
• Existente — presente 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 puedas seguir el estado de la deuda técnica en Fábrica, bajo la sección Deuda, y crear una tarea para corregir esos hallazgos, pero nunca impiden el avance de trabajos no relacionados. Mover código no cuenta como introducirlo; copiarlo sí.

Limpieza semanal de deuda técnica#

La deuda existente no bloquea, pero no tiene por qué permanecer. Abre un proyecto en Control de Calidad, expande Anti-slop y activa Limpieza semanal de deuda técnica. Una vez por semana, Coroid analiza la rama predeterminada del proyecto y crea pequeñas tareas de limpieza para la deuda encontrada, unos pocos archivos cada vez. Mantiene abiertas como máximo tantas tareas de limpieza como indique Tareas abiertas simultáneamente (dos por defecto), para que la limpieza nunca interfiera con el trabajo solicitado. Cada cambio permite deshacerlo.

La limpieza se configura por proyecto. Su programación se muestra en Fábrica y indica que Control de Calidad la gestiona; cámbiala aquí, no allí.

Nuevo trabajo solía ofrecer una plantilla llamada "Limpieza semanal de deuda técnica". Una programación creada a partir de ella sigue ejecutándose y se nombra según el interruptor; pausa esa programación en Fábrica si la limpieza de deuda técnica la reemplaza.

Activarlo#

En Control de Calidad, selecciona la configuración predeterminada de la organización o un proyecto y activa Anti-slop. Esto añade cinco requisitos:

1. Las pruebas siguen validando el cambio.
2. Nada incompleto o solo para pruebas se envía a producción.
3. No se genera nueva deuda estructural.
4. El cambio se mantiene dentro del ámbito y se integra con el estilo de este código.
5. Las nuevas dependencias son reales y de confianza.

El cambio se aplica de inmediato: la próxima ejecución de ese proyecto, o de todos los proyectos que sigan la configuración predeterminada, incluirá la comprobación. La configuración de la fila define la disciplina de cambio, que agrupa las reglas de bloqueo y de evaluación, y desactivarla conserva esas configuraciones para la próxima vez que la actives.

Elegir la disciplina de cambio#

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

• Cirúrgico — solo lo que requiere la especificación; los demás problemas se reportan, pero no se corrigen.
• Equilibrado (predeterminado) — también corrige pequeños problemas en las líneas que toca la modificación de todos modos.
• Restaurativo — también limpia los hallazgos dentro de las funciones que edita la modificación.

El agente trabaja según las mismas reglas antes de enviar: recibe la disciplina y los 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 control de calidad.

Adaptándolo a tu base de código#

• Sobrescrituras de reglas — abre una regla en Reglas anti-slop para hacer que bloquee, aconseje, solemente informe o detenga, ya sea para la configuración predeterminada de la organización o para un proyecto concreto.
• Paquetes de reglas — tus propios patrones, importaciones y dependencias prohibidas, límites de tamaño de archivo, o resultados de herramientas que ya utilices (SARIF). Cada guardado es una nueva versión, y una comprobación mantiene la versión seleccionada.
• Cuarentena — patrones que ya no deseas que se copien, cada uno con la reemplazo a usar en su lugar. Se indica a los agentes que no los propaguen, y las nuevas copias se marcan.
• Rutas excluidas — en Control de Calidad → Anti-slop, los archivos generados o externos que el análisis anti-slop no lee, un patrón por línea (dist/**, vendor/**). Úsalos para el resultado de la compilación confirmada: un archivo modificado que supere el límite de 512 KiB del escáner y que una regla requiera hará que las comprobaciones no estén disponibles.
• Archivo del repositorio — .coroid/anti-slop.yml en el repositorio puede agregar reglas y excluir generated/, vendor/, node_modules/ y __generated__/ directorios. Se lee desde la base de la modificación, por lo que una modificación no puede relajar sus propias reglas, y editarlo requiere aprobación.
• Archivos de bloqueo y catálogos de traducción — anti-slop cuenta sus cambios pero no los lee. Los catálogos son los archivos .coroid/i18n.json declara en the base de la modificación; la comprobación de Globalización lee esos. Una regla propia que los nombre también los lee.

Nuevas dependencias#

A veces los Modelos sugieren un paquete que no existe, a menudo una combinación plausible de dos nombres reales. Los atacantes registran tales nombres en npm y PyPI para que la siguiente instalación ejecute su código, un ataque llamado slopsquatting. La Cloud Security Alliance lo describe: casi uno de cada cinco de las 2,23 millones de muestras de código en la investigación que cita nombraron al menos un paquete que no existía.

Anti-slop busca cada dependencia que una modificación agrega a package.json, un archivo de requisitos o pyproject.toml:

• Bloqueos — un paquete que no está en su registro público, o uno que OSV lo marca como malicioso. La modificación vuelve al agente desarrollador antes de que tú la veas.
• Aconseja — un paquete publicado hace menos de 30 días, uno con muy pocas descargas, uno cuyo nombre está a una o dos letras de distancia de un paquete popular, o un paquete npm que ejecuta código al instalarse. Un paquete PyPI con una versión marcada como maliciosa también aconseja, porque Coroid no sabe qué versión instala un requisito.

Si no se puede acceder a un registro, la comprobación lo indica en su resultado y decide sobre los paquetes que puede buscar. No retiene la modificación.

Qué nombres busca Coroid#

Buscar un nombre lo envía a un registro público, por lo que un propietario o administrador elige qué nombres pueden salir de Coroid, en Control de Calidad → Anti-slop → Comprobando nuevas dependencias. La elección se aplica a todos los proyectos de la organización.

• npm y PyPI públicos, a menos que el repositorio nombre otro registro — todas las nuevas dependencias se buscan, excepto donde .npmrc, un archivo de requisitos, pip.conf, uv.toml, un Pipfile o la configuración de la herramienta Python, además del manifiesto o en una carpeta superior, nombren otro registro o índice. Elegirlo te pedirá que confirmes que no hay ningún registro privado configurado fuera de tus repositorios, por ejemplo en la configuración de usuario o de CI, y registrará cuándo se confirmó y por quién. Los paquetes npm con ámbito (@scope/name) solo se buscan donde .npmrc nombre el registro público para su ámbito.
• Solo donde el repositorio nombre el registro público — el valor predeterminado. Un paquete se busca solo cuando .npmrc establece registry=https://registry.npmjs.org/, su archivo de requisitos tiene exactamente una --index-url https://pypi.org/simple línea, o una dependencia de Poetry usa una source que apunta a pypi.org. La mayoría de los repositorios no hacen ninguna de estas cosas, por lo que la mayoría de las nuevas dependencias no se comprueban.
• Desactivado — no se buscan nombres, y los paquetes inventados no se detectan.

Solo los nombres de las nuevas dependencias salen de Coroid. Van a registry.npmjs.org y pypi.org, a api.npmjs.org para obtener los recuentos de descargas de npm, y a api.osv.dev (con la versión de npm) para informes de paquetes maliciosos. Nunca se envía tu código. Los resultados se conservan hasta un día, por lo que no se busca el mismo nombre otra vez para cada cambio.

Hallazgos y aceptación#

Los hallazgos de una tarea aparecen en su Calidad sección en la Fábrica. Cuando el agente desarrollador corrigió los hallazgos bloqueantes antes de que el cambio llegara a revisión, la sección se abre con Detectado por anti-slop antes de la revisión, las reglas que detectó y, bajo Mostrar dónde y cuándo, el archivo y la línea de cada hallazgo y la comprobación que lo encontró. En la Fábrica, bajo Deuda, se cuentan los atajos detectados antes de la revisión en los últimos 30 días y se muestran a propietarios y administradores los proyectos que aún no los verifican, con Activar anti-slop.

Para aceptar un hallazgo, indica un motivo y una fecha de caducidad; la aceptación se registra para ese hallazgo específico. Los agentes no pueden aceptar sus propios hallazgos. Cuando un agente dice que una prueba es incorrecta y la modifica, un revisor debe aprobar ese cambio antes de que la comprobación se cumpla.

Reglas de juicio#

Dos reglas consultan al modelo, una línea a la vez: una comprobación defensiva para algo que el código mostrado hace imposible, y un comentario que contradice el código cercano. Solo aconsejan, nunca bloquean. Activar 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 Anti-slop configuración de un proyecto en Control de Calidad, proporciona la disciplina de cambios del proyecto, la cuarentena y las reglas principales 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.