Blind Tribunal

Blind Tribunal

Effort: heavy — ocho jurados, una lente cada uno, enrutados por nivel a la familia de modelos más barata 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. Cada uno es un modelo de una familia DISTINTA a la del constructor (misma marca = misma familia). Un jurado al que le piden revisar todo no revisa nada bien.

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, FUSIONADA con un verificador de nube barato que juzga el mismo prompt: la lente pasa solo si ambos pasan; sin nube, el veredicto local queda marcado UNVERIFIED, nunca «verificado» en silencio; y 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); el verificador nunca es de la misma familia que el asiento primario, y un asiento UNVERIFIED es una retención (nunca unanimidad); 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 una familia de modelos 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. El reporte debe nombrar la puerta debilitada — "calificado a ciegas misma-familia, no entre familias" — nunca fingir en silencio que la puerta entre familias 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. Cada peldaño de esa familia se rechaza en voz alta, antes de despachar, en cada escalera. Una lente sin peldaño QUEDA EN ESPERA — nunca vuelve al constructor.
• Mismo proveedor = misma familia. Una declaración excluye al proveedor entero.
• Pruébalo en la escalera viva, no en un test: la tabla de rutas debe mostrar que sus asientos pasaron a otra familia. 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:

{"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, 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).
2. Construye hasta el verde.
3. Arma el sobre con los archivos ACTUALES.
4. Sienta a los ocho jurados, por nivel, — de familias distintas a la del constructor (fleet-ladder resuelve cuáles están vivos).
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 el piso tiene tres peldaños

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.
• Dos peldaños de nube no son un piso. Cada nivel tiene al menos tres peldaños sin context_tokens declarado (pueden cargar un artefacto de 120k tokens) antes de su cola local. Un lente equivocado más una anulación nunca deben dejar un lente en espera.
• Un veredicto estructurado nunca comparte su presupuesto con el pensamiento. Un modelo razonador al que se le pidió un veredicto JSON escueto gastó todo su presupuesto de 65536 tokens pensando en 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. Cada peldaño de nube que pide un veredicto en objeto JSON corre con el canal de razonamiento apagado (reasoning_effort: none), y la escalera del verificador guarda detrás una tercera familia por HTTP plano.
• 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: ni la misma instancia, ni la misma familia.
• 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 — el contrato que falla, commiteado antes de que corra el constructor.
• sniper-testing — efectos reales, corridas acotadas, sin teatro de mocks.
• seam-engineering — arregla la clase, barre a los hermanos, aterriza una guarda.
• repair-loop — el loop de construcción que este tribunal califica.
• blind-eval — 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.