ruff==0.9.6 pinned exacto

ADR — ruff pinned exacto (==0.9.6)

Contexto

Durante audit de abril 2026 (commit 70e4e57) se detectó que CI instalaba ruff sin restricción de versión, o con rango tipo >=0.8. Distintas ejecuciones del pipeline obtenían versiones distintas del linter, generando resultados inconsistentes: reglas habilitadas por defecto en una versión nueva fallaban checks que antes pasaban, o producían warnings adicionales que no existían localmente. Fenómeno conocido como rule drift: conjunto de reglas activas cambia silenciosamente entre releases de ruff, incluso en bumps de patch, porque el proyecto sigue cadencia de desarrollo rápida.

Commit 81af8ca (2026-04-21) complementó el pin corrigiendo formato en archivos que la nueva config marcaba como no conformes, cerrando el ciclo audit → fix → pin estable.

Opciones evaluadas

1. ruff (latest) — instala siempre lo más reciente. Riesgo alto rule drift. Descartada.

2. ruff>=0.9.0 — acota rango inferior pero permite cualquier futura. Mitiga regresiones hacia atrás, no garantiza reproducibilidad temporal. Descartada.

3. ruff==0.9.6 (pin exacto) — garantiza que todo entorno (local, CI, PR review) ejecuta la misma versión, con las mismas reglas y el mismo comportamiento de formato. Seleccionada.

Decisión

ruff==0.9.6 en requirements.txt con comentario explícito que documenta la razón. Config activa en [tool.ruff] de pyproject.toml define line-length, selectores de reglas y exclusiones de directorios. Comportamiento del linter completamente reproducible a partir de versión + config declarada en el repo.

Consecuencias

• CI estable: cualquier ejecución del pipeline produce el mismo resultado de linting y formato. Falsos positivos por rule drift desaparecen.
• Actualización manual: subir a versión nueva de ruff es acto deliberado que exige revisar changelog, ajustar config si hay cambios de reglas, ejecutar ruff format + ruff check --fix antes de merge. Carga menor aceptable por el beneficio en reproducibilidad.
• Deuda de upgrade visible: pin exacto hace evidente cuándo el proyecto se queda atrás de versiones recientes, facilitando decisiones de upgrade planificadas en lugar de accidentales.

Status

Accepted — aplicado en 70e4e57 (2026-04-17), formato corregido en 81af8ca (2026-04-21).

Véase también

• [[feature—refactor—audit-abril-2026]]
• [[incident—20260420—ci-red-24h-ruff-format]] — incidente CI rojo 24h por ruff format sin gemelo local