Scanners: consistent status rules and calibrated severities

Abierto
  • ¿Algo no está bien?
#138 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
54/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, shell
Área
testing, tooling

Línea de trabajo

Start by reading scan-path-standards.py, scan-scripts.py, the prepass scripts, and validate-module.py, then find how analysis grades and lenses consume scanner results. Check the existing documentation under references/ and how Ruff and ShellCheck findings are represented. Done means the status contract, severity mappings, and isolated Ruff invocation are consistent across the named scanners and documented once.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Describe your idea

Agree on one status contract across scan-path-standards.py, scan-scripts.py, the prepass scripts and validate-module.py, and map lint rule families to severities.

Why is this needed?

Today scan-scripts maps any high finding to warning but scan-path-standards maps any finding to fail, and every ruff rule is high (I001 import order weighs the same as F821 undefined name). The analysis grade and the lenses consume these, so the noise skews the quality report and pushes the Edit intent toward style churn.

How should it work?

  • Status: fail if any critical/high, warning if any medium, else pass, documented once in references/.
  • Ruff: F8xx, E9xx, B, S high, PL/SIM medium, I/E5xx/W/style low. Shellcheck error/warning/info/style map the same way.
  • Run ruff with --isolated --select so results don't depend on the target project's config.

PR

Happy to help implement this if the direction is agreed.

Lenguaje dominante
Python
Estrellas
220
Forks
54
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bmad-code-org/bmad-builder

Todos los issues de bmad-code-org/bmad-builder

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.