hallway-test

Prueba de pasillo (Hallway test)

El nombre proviene de agarrar a una persona en el pasillo y verla usar el producto. Aquí la persona es un sub-agente que no ha visto la implementación, las especificaciones ni la conversación que produjo el código, por lo que no puede desconocer lo que el autor sabe. Lee los requisitos y la documentación orientada al usuario, decide qué debería suceder, lo intenta e informa dónde la realidad difiere. En el rastreador modama esto encontró el valor de veinte experimentos en una tarde, incluidos defectos que el conjunto de pruebas había consagrado.

Dos modos, a menudo combinados:

• Comportamiento: el evaluador construye entradas de prueba, escribe su expectativa para cada una antes de ejecutar, ejecuta la herramienta, compara y clasifica.
• Visual: para salidas destinadas a personas, el evaluador maneja la herramienta en un terminal real y juzga capturas de pantalla, lo que captura lo que el análisis de texto nunca ve: salida desplazada, ruido que ahoga la señal, líneas que se ajustan, un paginador que oculta diagnósticos. El controlador incluido ${CLAUDE_PLUGIN_ROOT}/scripts/xterm-shots.py inicia un xterm bajo un servidor X virtual, envía teclas y toma capturas de pantalla; necesita xvfb, xterm, xdotool e imagemagick (el comando import de ImageMagick) instalados, lo que un devcontainer puede tener.

Una lista de verificación tomada prestada, con agradecimientos: los once criterios de usabilidad de CLI de la skill cli-ux-tester con licencia MIT de ali5ter, en ${CLAUDE_PLUGIN_ROOT}/references/cli-ux-checklist.md, como una pasada adicional para herramientas de línea de comandos.

Antes de lanzar

Acuerda esto con el usuario; se convierten en las instrucciones del evaluador:

1. Qué puede leer el evaluador. Solo lo que un primer usuario tendría: los requisitos, la documentación de usuario, la ayuda del comando. Nombra los archivos o directorios; prohíbe explícitamente el resto (código fuente, pruebas, especificaciones, notas de diseño, historial de git). El objetivo de la prueba es la perspectiva nueva; cada documento adicional la debilita.
2. La herramienta y cómo ejecutarla. La línea de comandos o punto de entrada, dónde se pueden crear las entradas de prueba (un directorio temporal, nunca el repositorio), qué se puede instalar, qué no se debe tocar (un montaje de datos de solo lectura es de solo lectura).
3. La cobertura que se debe exigir. Una lista de casos que el evaluador debe cubrir, a partir de los requisitos y de las brechas de la última prueba de juego, más "agrega experimentos propios". Para pruebas visuales: los escenarios, el tamaño del terminal, las teclas a presionar.
4. Quién responde preguntas. El evaluador pregunta a la sesión principal cuando los requisitos no dicen qué debería suceder; la sesión principal responde desde el diseño y registra lo que no pudo responder con confianza como elementos TODO para el propietario.
5. La ubicación del informe y la longitud del resumen.

Las instrucciones

Genera un sub-agente de propósito general en segundo plano con unas instrucciones construidas a partir de la plantilla en ${CLAUDE_PLUGIN_ROOT}/references/tester-brief.md: la personalidad ("un ingeniero de software de investigación que prueba esto por primera vez, como un usuario inicial crítico"), las reglas estrictas de lectura, la referencia del comando tal como un usuario la recibiría, el método (crear, escribir la expectativa primero, ejecutar, comparar, clasificar como coincidencias / error / sorprendente pero defendible / brecha / pregunta), la cobertura obligatoria, la instrucción de preguntar y la estructura del informe. Para pruebas visuales, usa las instrucciones en ${CLAUDE_PLUGIN_ROOT}/references/visual-brief.md, que describe el controlador e insiste en que el evaluador juzgue solo las capturas de pantalla.

Modelo: un modelo más barato es suficiente para el evaluador visual, que mira e informa; el evaluador de comportamiento se beneficia del modelo de la sesión, ya que razona sobre lo que debería suceder.

Mientras se ejecuta

Responde las preguntas del evaluador desde el diseño, con el razonamiento, e indícale cuando una pregunta expuso un error (luego corrige el error de la manera habitual, con su prueba, y dile al evaluador que la herramienta ha cambiado). Mantén una lista actualizada de lo que no pudiste responder con confianza; esos elementos van al propietario como decisiones, no como tus suposiciones.

Después

1. Lee el informe. Verifica cada afirmación de error contra el código antes de aceptarla; un evaluador sin acceso al código fuente describe síntomas, y la causa puede ser diferente.
2. Escribe el registro persistente donde el proyecto guarda las notas de diseño (por ejemplo design/playtest.md): qué funcionó, qué se corrigió con su prueba y escenario de especificación, las respuestas dadas y una lista TODO para el propietario con tu opinión por elemento.
3. Para cada defecto, responde "¿qué lo habría detectado?" y añade eso: una prueba, una regla, una verificación. Un defecto sin esa respuesta solo está medio corregido.
4. Mantén los árboles y capturas de pantalla del evaluador reproducibles: un pequeño script que re-ejecute cualquier experimento, guardado junto al informe o en el directorio temporal, con la ruta nombrada en el registro.

Reglas

• El evaluador nunca modifica el repositorio, nunca lee lo que se le prohibió e informa en el informe qué se le dio, incluido cualquier cosa que el arnés adjuntó y que él no solicitó.
• Las expectativas se escriben antes de ejecutar, o la comparación no significa nada.
• Un hallazgo es un momento: el comando exacto, lo que se esperaba, lo que se observó, las líneas de stderr relevantes o el nombre del archivo de captura de pantalla.
• No corrijas durante la prueba lo que el evaluador informó como pregunta; decide primero si es un error o una decisión de diseño, luego corrígelo con su prueba.