---
name: "blind-tribunal"
description: "Úsala cuando un cambio autónomo necesita una calificación independiente antes de aterrizar y no hay humano en el circuito. Convoca jurados ciegos resueltos por capacidad — una lente cada uno — sobre un sobre con archivos completos y autoría borrada; cada hallazgo se vuelve un nuevo test que falla; se repite hasta que todos los jurados aprueban. Trigger words: blind tribunal, grill tribunal, tribunal, jurors, independent grade, convene, blind grade, independent grade, grade before landing. Disparadores: tribunal ciego, jurados, calificación independiente, convocar, calificar a ciegas, calificación independiente, calificar antes de aterrizar."
license: "MIT"
---

# Blind Tribunal
**Effort:** heavy — ocho jurados, una lente cada uno, enrutados por nivel al peldaño de modelo más barato que basta, reconvocados con sobres frescos en cada ronda hasta la unanimidad; gástalo en cambios autónomos que aterrizan sin revisión humana. Elimina: aterrizajes rebeldes sin más puerta que la palabra del propio constructor.

El loop de calificación que deja al humano irse sin que el agente se descarrile.
Un panel de jurados revisa el cambio a ciegas, con la autoría borrada. Cada
hallazgo se convierte en un nuevo test que falla. El loop se repite hasta que
todos los jurados aprueban. Nada aterriza solo con la palabra del constructor.

## Cuándo ejecutarla

- Antes de aterrizar cualquier cambio autónomo que ningún humano va a revisar.
- Cualquier cambio de alto radio de impacto: con forma de seguridad, que toca datos, cercano a la autoridad.
- Cuando un solo evaluador no basta y quieres lentes independientes sobre el mismo artefacto.

## Los asientos

Ocho jurados, una lente cada uno. La ejecución autora que construyó al candidato queda
registrada como procedencia y queda descalificada; cualquier sesión que haya heredado
la conversación o el contexto del constructor, también. Un jurado al que le piden
revisar todo no revisa nada bien.

| Jurado | Id de lente | Nivel | La pregunta que hace |
| --- | --- | --- | --- |
| Defecto | `defect` | generalista | ¿Qué se rompe de verdad? Fallos de lógica, errores de sintaxis, defectos nuevos. |
| Proporción | `proportion` | generalista | ¿Es el tamaño correcto? ¿Sobreconstruido, o a la medida de la intención? |
| Consecuencia | `operator_consequence` | seguridad del operador | Si un operador humano ejecuta esto, ¿qué es destructivo, inseguro o dañino? |
| Reversibilidad | `reversibility` | estado profundo | ¿Deja efectos irreversibles? Si muere a medio camino, ¿el sistema vuelve atrás limpio? |
| Continuidad | `state_continuity` | estado profundo | ¿Huérfana variables, pisa estado global o pierde contexto que los nodos siguientes necesitan? |
| Economía | `resource_economy` | estructural rápido | ¿Bucles sin optimizar, llamadas de red/API redundantes, memoria de más? |
| Frontera | `boundary_condition` | estructural rápido | Con entradas nulas, vacías, de tipo inesperado o malformadas, ¿falla con gracia? |
| Telemetría | `telemetry` | seguridad del operador | ¿Un fallo aquí se diagnostica desde los logs y el manejo de errores? |

**Niveles de enrutamiento (primero la ruta más barata que basta):** estado profundo →
el mayor contexto y razonamiento más profundo, idealmente por un harness que LEA el repo
(nunca escriba); estructural rápido → primero una GPU local gratis; un veredicto local
independiente y suficiente puede PASAR sin un verificador de nube o fusionado cuando
el contrato de la tarea no lo exige. Si un verificador opcional está FUSIONADO con el
asiento primario, juzga el mismo prompt; si el verificador no está disponible (ningún
peldaño de nube vivo), el veredicto primario local se sostiene sobre su propia
evidencia, marcado UNVERIFIED en la revisión y el resumen — nunca «verificado» en
silencio. Un verificador REQUERIDO por la tarea que está ausente es RETENCIÓN
independiente de local/nube. El modelo local debe ver TODO el artefacto
(dimensiona `num_ctx` al prompt — el valor por defecto de Ollama, 4096, trunca en
silencio — y rechaza antes de enviar lo que no cabe); los jurados por harness corren
read-only, y cada convocatoria lleva un `run_id` y escribe su resumen al final;
después los modelos de nube de baja latencia; seguridad del operador →
tu coder más fuerte con base en seguridad; generalista → un generalista grande y fiable.
Cada escalera termina en un peldaño local de supervivencia.

**Equipo solo.** Cuando solo hay un peldaño de modelo disponible, degrada
EXPLÍCITAMENTE: un contexto o sesión fresca que nunca vio la conversación del
autor actúa como evaluador ciego, o el humano revisa el sobre con la autoría
borrada. Un revisor del mismo modelo, peldaño o familia en una sesión fresca y
disjunta del autor se permite donde el runtime configurado lo admita. El reporte
debe nombrar la puerta debilitada — nunca fingir en silencio que una puerta más
fuerte se sostuvo.

## El constructor se declara, y la exclusión es estructural

"Distinta familia que el constructor" era una regla que se pedía a los jurados recordar. En la
propia prueba del tribunal, el asiento de seguridad del operador lo encabezó el mismo modelo que
había construido el candidato, y nada lo registró ni lo excluyó: el autor calificó su propio
trabajo durante dos rondas. Así que:

- **Convoca con el constructor nombrado** (`--builder <modelo-o-familia>`). El registro lleva
  `builder_family` como procedencia donde el corredor lo registre. La ejecución autora que construyó
  al candidato y cualquier sesión que haya heredado la conversación o el contexto del constructor
  quedan descalificadas en voz alta, antes de despachar, en cada escalera. Una lente sin peldaño
  QUEDA EN ESPERA — nunca vuelve al constructor. Procedencia, no un veto ciego por modelo, peldaño,
  familia o proveedor.
- **Pruébalo en la escalera viva, no en un test:** la tabla de rutas debe mostrar que los
  asientos cayeron en peldaños disponibles en vivo, y el reporte nombra el peldaño elegido por
  lente. Si no, la exclusión es decoración.

## El sobre

Los jurados nunca ven el repo, al constructor ni la conversación. Ven un solo sobre:

- **Archivos actuales completos** de cada archivo que el cambio tocó, más sus
  archivos de test. Nunca fragmentos de diff sueltos — un fragmento esconde el
  contrato que lo rodea e induce hallazgos falsos.
- **El contrato de revisión**: la intención del cambio en una línea, y los
  criterios para aprobar.
- **Cero autoría.** Sin nombres, sin ids de modelos, sin autores de commits, sin
  historial de chat. Si la identidad se filtra, el armado del sobre falla con
  ruido — nunca se califica sin la venda.
- **Nada de prosa sobre el comportamiento viejo.** Describir lo que el código
  "hacía antes" siembra defectos fantasma. Los archivos hablan solos.

## El veredicto

JSON estricto y parseable por máquina, un solo objeto, sin prosa:

```json
{"verdict": "pass" | "refuse",
 "findings": [{"severity": "blocker|major|minor|info",
               "claim": "...", "evidence": "..."}]}
```

- **Un pass que lista un hallazgo `[blocker]` o `[major]` no es un pass.** Es contradictorio y
  falla cerrado a refuse, nombrando la severidad que lo contradijo.
- **Un veredicto para una lente distinta de la sentada** es un peldaño rechazado, no un veredicto:
  se anota con ambas lentes y la marcha sigue al siguiente peldaño; solo si todos responden mal la
  lente queda en espera. Nunca un pass.
- **El directorio de salida se posee antes de barrerse.** El órgano sella (stamp) el directorio que
  reclama; uno con esas formas de archivo SIN el sello se rechaza, nombrando archivos y remedio,
  sin borrar nada. Uno con solo archivos ajenos nunca corrió peligro y no se bloquea.
- **Una lente que explota nunca descarta los veredictos ya pagados.** Cada fallo se registra por
  lente; veredictos y resumen se escriben ANTES de lanzar el error.
- **La evidencia de mutación nombra un archivo reescrito** (`changed_paths`), no solo los que
  aparecen o desaparecen.
- **Todo lo que escribe el órgano es solo del propietario (0600).**
- **Un modelo local derramado lo descarga solo su ÚLTIMO poseedor.** Dos lentes pueden compartir
  una tarjeta; la primera en terminar no le quita el modelo a la otra a mitad de llamada.
- **Un peldaño que no cabe el artefacto se salta antes de llamar**, con la razón anotada; un
  rechazo por capacidad es un TIPO y la marcha sigue — nunca un halt.
- Un jurado que RESPONDIÓ mal — basura, texto que no es JSON, texto de rechazo —
  cuenta como **refuse**; un jurado que NUNCA respondió (falla de transporte,
  inalcanzable) es una **espera**: vuelve a sentarlo vía
  [fleet-ladder](../fleet-ladder/SKILL.md), nunca un pase silencioso. Un solo
  disparo por jurado que responde por ronda — sin reintentos.
- Un pase pelado con cero hallazgos y sin evidencia es un **voto de poca
  información**. Cuenta, pero nunca como la única prueba — dos pases pelados no
  le ganan a un refuse detallado. Un pase fuerte nombra lo que revisó.

## El loop

1. Rojo primero: haz commit del test de contrato que falla ANTES de construir el
   arreglo, y registra ese commit. El constructor no puede tocar el test
   ([red-first](../red-first/SKILL.md)).
2. Construye hasta el verde.
3. Arma el sobre con los archivos ACTUALES.
4. Sienta a los ocho jurados, por nivel, elegidos en vivo por capacidad y
   disponibilidad desde la matriz de peldaños configurada
   ([fleet-ladder](../fleet-ladder/SKILL.md) resuelve cuáles están vivos). La
   ejecución autora que construyó queda descalificada, igual que cualquier sesión
   que haya heredado la conversación o el contexto del constructor; un revisor del
   mismo modelo, peldaño o familia en una sesión fresca y disjunta del autor se
   permite donde el runtime configurado lo admita.
5. Cada jurado además verifica, no solo lee: los tests nuevos pasan; la suite de
   regresión no está peor que la línea base; y un chequeo de verde falso — un test
   que DEBERÍA fallar (el bug reintroducido) de verdad falla. Un verde falso es un
   refuse.
6. Ante cualquier refuse: CADA hallazgo — blocker, major y minor — se convierte en
   un NUEVO test que falla por la razón real del hallazgo. Arréglalo. Rearma el
   sobre con los archivos revisados. Vuelve a convocar a TODOS los jurados. Un
   veredicto sobre archivos viejos no es veredicto.
7. Aterriza solo con pase unánime. Los hallazgos minor levantados en la ronda
   final también se cierran, nunca se difieren — "arreglé los blockers, los minor
   después" es exactamente la fuga que esta skill existe para frenar. Un hallazgo
   termina ARREGLADO o refutado con evidencia registrada, nunca estacionado.

## El pie nombra el lente, un peldaño rechazado conserva sus palabras, y la profundidad de ruta es una capacidad medida

La ronda 4 dejó dos lentes en espera con cero rechazos, y cada eslabón quedó en el registro. Salieron tres leyes:

- **Declara la forma de la respuesta junto a la respuesta.** El pie del protocolo lleva el nombre literal del lente (`"lens": "defect"`), nunca el marcador `<your lens>`. Un jurado al que se le pidió recordar el lente desde 350 KB antes, dentro de un artefacto que nombra los ocho lentes, respondió el lente equivocado tres veces en dos rondas. Rellena el marcador al renderizar.
- **Un peldaño rechazado deja sus palabras en el registro.** Una respuesta con lente equivocado o un veredicto anulado lleva un `raw_tail` acotado en la entrada rechazada, para que la siguiente ronda lea la causa en vez de inferirla.
- **La profundidad de ruta es una capacidad medida, no un piso mágico de "tres peldaños de nube".** Cada nivel mantiene suficientes peldaños para el artefacto que debe cargar (`context_tokens` y `num_ctx` en Ollama; el valor por defecto 4096 trunca en silencio). Un lente equivocado más una anulación nunca deben dejar un lente en espera.
- **El canal de razonamiento y el presupuesto siguen a la ruta y a la forma de la respuesta.** Un modelo razonador al que se le pidió un veredicto JSON escueto gastó su presupuesto sobre un artefacto de 131k tokens y no emitió nada (`finish_reason=length`); el tope de tiempo del rol mató después al siguiente peldaño a mitad de camino. Algunas nubes desactivan el razonamiento para JSON (`reasoning_effort: none`), otras dejan medio; el incidente histórico se anota como evidencia, no como regla universal.
- **Nada más escribe en el repo del tribunal mientras sesiona.** El archivo de estado de un calificador concurrente dentro del checkout cambió bytes bajo un asiento, y el órgano anuló ese veredicto con honestidad: no puede atribuir un cambio. Serializa los escritores, o sesiona en un worktree aparte del mismo commit.

## Reglas duras — romper una anula la calificación

- El constructor nunca califica su propio trabajo: la ejecución autora que
  construyó y cualquier sesión que haya heredado la conversación o el contexto del
  constructor quedan descalificadas; un revisor del mismo modelo, peldaño o
  familia en una sesión fresca y disjunta del autor se permite donde el runtime
  configurado lo admita.
- **Un refuse de jurado vale lo que vale el sobre.** Antes de escribir un test a
  partir de un hallazgo, verifica el hallazgo contra los archivos reales. Un
  hallazgo sobre código que el sobre nunca llevó significa arreglar el sobre, no
  el código.
- Mide la convergencia sobre los hallazgos NUEVOS por ronda, no sobre el total
  bruto. Hallazgos nuevos planos o creciendo dos rondas seguidas: detente y
  escala al humano. Nunca muelas en vano.
- Nunca debilites ni edites los tests que fallan para alcanzar un pase. Los
  jurados verifican que los archivos de test siguen sin cambios desde el commit
  rojo.
- **Un superviviente es una afirmación; una prueba en verde es una afirmación.** Vuelve a correr a
  mano cada mutante superviviente, en un árbol aislado, con un tope que sobreviva la carga. Un
  timeout no es un superviviente; un error de colección no es una muerte. Toda ruta de veredicto
  del arnés debe poder decir INVALID, y un arnés cuya línea base sin mutación no esté en verde
  limpio se niega a emitir veredictos.
- Un pase unánime abre la puerta; no es la meta. Aterriza, y luego prueba la
  capacidad en vivo sobre la superficie real. Verde sin prueba en vivo no es
  estar terminado.

## Combina bien con

- [red-first](../red-first/SKILL.md) — el contrato que falla, commiteado antes de que corra el constructor.
- [sniper-testing](../sniper-testing/SKILL.md) — efectos reales, corridas acotadas, sin teatro de mocks.
- [seam-engineering](../seam-engineering/SKILL.md) — arregla la clase, barre a los hermanos, aterriza una guarda.
- [repair-loop](../repair-loop/SKILL.md) — el loop de construcción que este tribunal califica.
- [blind-eval](../blind-eval/SKILL.md) — la puerta más ligera de conservar-o-revertir cuando la pregunta es de gusto, no de defectos.

> Crédito de andamiaje: Matt Pocock, grill-me / grilling (mattpocock/skills, MIT).
> El diseño del tribunal adversarial ciego entre familias es de BACKS AIOS.