사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/adminoryslabs/armory --skill veredicto시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
Veredicto (v2)
Goal
Responder con evidencia "¿esta unidad de trabajo cumple su contrato?", y cuando no lo cumple, quién se apartó. Cada resultado lleva una prueba, un comando o un archivo:línea, o queda NO VERIFICADO.
Novedades v2: arbitraje con tres desenlaces y matriz de trazabilidad. En el Sprint 0 se aplica el mismo workflow conSPRINT0.mdcomo spec: cada punto de la Definition of Done ocupa el lugar de un caso del contrato, el desenlace "el contrato no lo decía" se lee como "SPRINT0.mdno lo decía", la matriz de trazabilidad se reemplaza por la tabla de la DoD (punto → evidencia → resultado) y el informe va ainformes/VEREDICTO-SPRINT0.md. Las pruebas marcadasNO EJECUTADASpor el TESTER se corren ahora que el runner existe.
Input
- La spec:
contratos/CONTRATO-<HU>.md(versión vigente) oSPRINT0.md. - La HU (para la matriz: sus criterios de aceptación).
- Los informes de
ENTREGA TESTERyENTREGA DEV. - El mapa de propiedad de rutas en
AGENTS.md. - La rama de trabajo y su punto de partida.
Si falta cualquiera de las dos entregas, no se dicta veredicto: se espera.
Workflow
- Verificar la propiedad de rutas.
git log <base>..HEAD --name-only --format="%s", agrupar
por prefijo ([TESTER] / [DEV]) y comparar contra el mapa de AGENTS.md. Archivos fuera de las rutas del rol o commits sin prefijo son hallazgos, aunque todo pase.
- Verificar que los dos trabajaron sobre la misma versión del contrato. Si no, el veredicto
no vale: se avisa a quien quedó atrasado.
- Correr las pruebas del TESTER contra el código del DEV. Guardar la salida.
- Resultado por cada caso del contrato: 🟢 / 🔴 /
NO VERIFICADO, con la prueba que lo cubre.
Un caso del contrato sin prueba es NO VERIFICADO, no verde.
- Arbitrar cada 🔴 con el contrato en la mano. Leer qué dice el contrato del caso, qué espera
la prueba y qué hace el código:
- Se apartó el código — la prueba coincide con el contrato y el código no → vuelve al
DEV con el caso, la cita del contrato y la evidencia.
- Se apartó la prueba — el código coincide con el contrato y la prueba no (nombre, formato,
caso que el contrato no pide) → vuelve al TESTER con lo mismo.
- El contrato no lo decía — los dos son lecturas razonables de un contrato incompleto o
ambiguo → no corrige ningún agente: se prepara la pregunta para el humano y, con su respuesta, el LEAD emite el contrato v2 y avisa a ambos. Corrige quien se apartó del contrato.
- Vigilar trampas y reportarlas como hallazgos aunque todo esté en verde:
- pruebas que pasan sin verificar nada (sin aserciones sobre lo que dice el contrato);
- código con casos especiales que solo sirven para pasar una prueba puntual;
- pruebas modificadas entre vueltas para que pasen sin un contrato v2 que lo justifique.
- Contar vueltas. El mismo desacuerdo no se devuelve una tercera vez: se escala al humano.
- Construir la matriz de trazabilidad:
| Criterio de aceptación (HU) | Caso del contrato | Prueba | Resultado |
|---|
- Criterio sin caso o sin prueba → se señala: algo no se verificó.
- Caso del contrato sin criterio de la HU → se señala: el negocio debe confirmar que lo quiere.
- Escribir el veredicto en
informes/VEREDICTO-<HU>.md: matriz, hallazgos de rutas,
arbitrajes (desenlace + destinatario + vuelta N), trampas detectadas, NO VERIFICADO y versión del contrato usada.
- Si todo está en verde (o los
NO VERIFICADOfueron aceptados por el humano), el LEAD abre
el PR con la matriz y la versión final del contrato en la descripción.
Constraints
- No se modifica código ni pruebas para "hacer pasar" el veredicto.
- No se confía en lo que dicen los informes: se verifica.
- El LEAD no decide lo que el contrato no dice: lo escala.
- No se publica nada (ni push a main, ni merge).




