A requirement whose surface matches no surface is never checked and never disclosed
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 56/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- playwright, typescript
- Área
- accessibility, testing
Línea de trabajo
Start with src/intake/map-to-providers.ts to see how requirements are scoped by surface, then trace the run sequencer and the existing single-page handling in checkPage. Compare loaded requirement surfaces with scanned screen ids and report unmatched ones as not-covered gaps using ref requirement:<id>. Done means a requirement naming an unscanned surface is reported with that surface, including in the CLI run.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happens
Each content or flow requirement becomes a provider that runs only when the screen id equals requirement.surface (src/intake/map-to-providers.ts). Its comment says the wrong surface is out of scope and that "coverage wiring decides this later". Nothing does. If a requirement names a surface that no configured or discovered surface has, for example a typo, its provider returns nothing on every screen and the run reports no gap for it.
Why it matters
A requirement the run never checked reads as met. That is a false green, and a typo is enough to cause it.
Fix direction
After the scan, compare each loaded requirement's surface with the set of scanned screen ids. A requirement that matched no scanned screen becomes a not-covered gap with ref requirement:<id> that names the surface. checkPage already does this for its single page. The CLI side touches the run sequencer, which is a guarded path.
- Lenguaje dominante
- TypeScript
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 2 h 48 min
- PR fusionados (30 d)
- 8
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de usabl-dev/usabl
-
area: engine bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
Stop hook allows a stop on an unknown verdict, and the self-check prints IDLE for a null verdictAbiertoarea: assistants bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
area: engine bug security
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Overlay: browser context failures are counted per plugin, not per browser, and close is not sharedAbiertoarea: overlay bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
-
area: engine enhancement performance
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Todos los issues de usabl-dev/usabl
Issues similares
-
native
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
prime-radiant-inc/evener#4839 ·
Los mantenedores suelen responder en 1 día
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
processone/fluux-messenger#1790 ·
Los mantenedores suelen responder en 1 día
-
🛣️ Infrastructure
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
opencrvs/opencrvs-core#14232 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
kunchenguid/gh-axi#220 ·
Los mantenedores suelen responder en 1 día