reins — del Quest CLI solo queda el dominio; el ratchet se vuelve framework Image: AI generated

how-make-quest era el manual para construir un Quest CLI con las manos. Qué es el ratchet, cómo se cuelga una puerta, cómo se bloquea el cheese. Le das un único artículo a un agente y sale un CLI en Go basado en cobra.

Pero ¿qué pasa cuando levantas el segundo Quest CLI? Vuelves a escribir la misma máquina de estados unidireccional. Vuelves a escribir el mismo scan/next/submit/status/export. Vuelves a escribir el mismo bloqueo PASS, el mismo decrecimiento monótono de remaining, el mismo export JSONL. Lo único que cambia es una puerta, pero cada vez reescribes todo lo demás. Ese es el impuesto de boilerplate que pagas cada vez que construyes un quest más.

El patrón era reutilizable. El código no. reins cierra esa brecha.

Qué es invariante y qué es dominio

Pon dos Quest CLI uno sobre otro, mira la diferencia, y la frontera se ve nítida.

Invariante (compartido por todo quest)     Dominio (distinto en cada quest)
─────────────────────────────────────      ────────────────────────────────
ratchet: TODO→PASS irreversible            qué es un quest
esqueleto de comandos: scan/next/submit…   qué es un "hecho"
agregación de nivel: Fail/Review→verdict   qué cheese hay que bloquear
progreso persistente·resumable
export: emisión única

La izquierda es justo lo que demostró how-make-quest — dé igual que el dominio sea un nombre de empresa, un endpoint o una función, los dientes del ratchet engranan igual. La derecha solo la conoce la persona. reins suministra la izquierda como framework y te deja a ti solo la derecha.

Esto no es una afirmación nueva, sino un viejo principio que reins fuerza con código — la separación de decisión e implementación. La puerta es la decisión (qué es verdad en este dominio) y el ratchet·CLI·agregación son la implementación. Reescribir la implementación cada vez es el fracaso de atar la decisión a la implementación.

Solo implementas una puerta

Hacer un quest con reins es rellenar los cuatro métodos de una única interfaz.

type Definition interface {
    Seed(args []string) ([]*quest.Item, error)            // entrada → semillas TODO iniciales
    Render(it *quest.Item) (string, error)                // prompt de redacción + contexto de verificación que muestra next
    Prepare(it *quest.Item, raw []byte) (gate.Context, *quest.Verdict, error) // decodifica la entrega
    Rules() []gate.Rule                                   // catálogo de reglas de violación de la puerta
}

func main() { cli.NewQuestCmd("myquest", myDef{}, cli.Options{}).Execute() }

Una sola línea de main suministra el ratchet, los seis comandos, la agregación, el export y la sesión resumable, todo. Lo que tú escribiste son solo las cuatro piezas del dominio. El agente sigue necesitando conocer únicamente dos comandos — recibe con next y entrega con submit. El resto lo decide la máquina.

La puerta es un catálogo de reglas de defensa contra el cheese

El núcleo de how-make-quest era “diseña una puerta a prueba de cheese”. reins convierte ese diseño en una estructura de datos — puerta = catálogo de reglas. Una regla es un detector de cheese. Cuando encuentra una violación se dispara (true) y carga un hecho (Fact).

// Una regla de defensa contra el cheese de un quest de extracción de eventos de noticias.
// "¿el ancla who existe realmente en el original?" — si el agente se inventa una persona, queda al descubierto.
var whoAnchorPresent = gate.Rule{
    Meta: gate.RuleMeta{ID: "who-anchor-present", Level: gate.LevelFail, Desc: "el ancla who obligatoria existe en el original"},
    Check: func(ctx gate.Context) (bool, quest.Fact) {
        sub := ctx.Submission.(*Event)
        if miss := textmatch.MissingTokens(ctx.Source, sub.Who.Anchors); len(miss) > 0 {
            return true, quest.Fact{Where: "who.anchors", Expected: "substring del original", Actual: miss[0]}
        }
        return false, quest.Fact{}
    },
}

La virtud de esta estructura es que crece. Cada vez que descubres un cheese nuevo, añades una regla y la puerta se endurece otro tanto. Y el catálogo se documenta a sí mismo — cuando el comando rules imprime la lista de reglas, eso ya es “la lista auditable del cheese que estoy bloqueando”. No hay puertas que no sepan qué bloquean.

La gravedad no es un peso, sino un nivel. Un solo Fail es FAIL inmediato. Una violación decisiva no se negocia — nueve violaciones de 99 puntos no pueden tapar un único Fail. Evaluate agrega las reglas disparadas por nivel: si hay aunque sea un Fail, FAIL; si no y hay un Review, REVIEW; si todo pasa, PASS.

La asimetría de potestad se fuerza con tipos

La línea más importante de how-make-quest era “el bloqueo del PASS solo lo da la máquina”. reins clava esto no como convención, sino como tipo.

L1 máquina(determinista)   la única potestad para bloquear el PASS
L2 IA(escéptica)           solo REVIEW — plantea dudas pero no puede otorgar la finalización
L3 persona                 el residuo que ambas dejaron pasar

La puerta de máquina otorga el PASS. Aunque metas un verificador de IA en la puerta, lo máximo que puede hacer es sacarlo a REVIEW. Hace imposible de raíz hacer lo incorrecto — si el framework no provee una API que dé al agente la potestad de PASS, no puedes, ni por accidente, dejar el dictamen en manos del amigo borracho.

El segundo backend — el defeat graph

A muchas puertas les basta la agregación de nivel de reglas independientes. Pero en cuanto las reglas empiezan a competir entre sí — “esta violación solo importa cuando existe aquella”, “la causa raíz de este fallo es en realidad esotra” — los guards if-else escritos a mano corroen la puerta. No es donde se rompe una puerta débil, sino donde se pudre una puerta compleja.

El segundo backend de puerta de reins traslada esa competencia a un grafo declarativo — toulmin h-Categoriser. El modelo de argumentación de Toulmin se vuelve, tal cual, una estructura de datos:

  • Warrant — tautology PASS. El fundamento de “si no hay refutación, pasa”.
  • Counter — una violación ataca al warrant.
  • Supersedes — prioridad entre reglas. Qué refutación gana a qué refutación.

Las cláusulas de guard escritas a mano se evaporan en aristas Attacks·Supersedes. Y cuando hay 0 aristas, este grafo es exactamente equivalente a la agregación de nivel — la complejidad es un coste opt-in que solo se enciende cuando hace falta (se enciende si Definition implementa gate.Evaluator).

El verdadero regalo del grafo no es el dictamen, sino el feedback. La evaluación del grafo le devuelve al agente una guía directa — Verdict.Feedback: “por qué perdiste y qué cambiar para ganar”. No un simple “FAIL”, sino la causa raíz calculada desde la estructura del argumento.

Aquí vuelve a operar la paradoja de how-make-quest. El modelo adula — sigue las instrucciones con docilidad. Para las opiniones la adulación es veneno, pero para los hechos la adulación es un activo. La guía no es una opinión (“esto está raro”), sino un hecho (“who.anchors no está en el original, cámbialo”). Cuanto más adulador es el modelo, con más docilidad acepta ese hecho y converge. Grafo determinista + LLM adulador = un bucle con convergencia garantizada.

Los efectos secundarios se aíslan — evaluación ground y staged

Para que una puerta sea determinista, la red no puede estar dentro de la puerta. Una regla que llama directamente a net/http es imposible de testear de forma unitaria, y el dictamen oscila según el estado de la línea.

reins empuja los efectos secundarios a pkg/ground — primitivas como HTTPBody·MXResolves poseen las consultas externas mediante un Resolver inyectable y un snapshot por petición. La regla se queda pura, y del mundo exterior se responsabiliza ground.

Y la evaluación staged: las comprobaciones baratas corren primero, y si fallan, el fetch de red no llega a ocurrir. No hay razón para consultar el DNS de una entrega con formato inválido. Pones lo caro y oscilante detrás de lo barato y seguro.

Prohibido abstraer con N=1

Una de las convenciones de reins revela con la mayor precisión el carácter de este framework — no extraigas una abstracción de un solo consumidor. Una abstracción nueva no se congela hasta haberla validado con un segundo consumidor.

Esto no es manía, sino primer principio. Una abstracción extraída de un único caso confunde el accidente de ese caso con su esencia. Solo cuando un segundo dominio reclama la misma abstracción queda demostrado que es invariante. El framework aplica “no afirmación, sino verificación” hasta a su propia evolución. Igual que la puerta no cree la afirmación del agente, la abstracción no cree la afirmación de un solo caso.

La misma frase, hecha biblioteca

reins se sostiene sobre los siete paquetes de pkg/ — textmatch (primitivas contra la alucinación), temporal (normalización temporal), quest (núcleo del ratchet), gate (contrato de la puerta), graph (defeat graph), ground (aislamiento de la red), cli (scaffold de cobra). Pasa go build·go test, con cobertura de todas las funciones. Y toulmin queda acoplado de forma unidireccional únicamente al backend de grafo, de modo que un consumidor que no use el grafo ni siquiera enlaza toulmin.

Código: github.com/park-jun-woo/reins

Si how-make-quest fue una frase — la generación puede ser probabilística, la verificación debe ser determinista — reins es esa frase solidificada en una forma compilable. La puerta reverifica los hechos del dominio, el ratchet bloquea lo que ha pasado, el grafo devuelve como hecho la razón de haber perdido, y el modelo adulador se pliega a ese hecho.

La próxima vez que necesites un Quest CLI, no reescribas el ratchet. Usa solo la puerta de tu dominio y toma prestadas las riendas.

Para leer junto a esto

El principio que reins solidificó en código — la generación es probabilística, la verificación es determinista — no es un hallazgo solo de reins. Personas que no se conocían chocaron contra el mismo muro y llegaron a la misma conclusión. Los proyectos de convergencia independiente que reunió how-make-quest son la prueba.

  • episteme — fuerza una Reasoning Surface antes de tareas irreversibles. La misma intuición que el ratchet de reins — el PASS se verifica antes de bloquear.
  • MagLab — “el LLM solo razona, los números los pone una herramienta determinista”. La misma separación que el aislamiento de los efectos secundarios de reins en pkg/ground.
  • Manifesto — “Agent proposes, World verifies.” Resume en una frase la asimetría de potestad de reins (solo L1 bloquea el PASS).
  • oh-my-kamisama — “diffs beat claims.” El mismo principio que la puerta reverificando los hechos y no las afirmaciones del agente.

Y la raíz del backend de defeat graph es la teoría de la argumentación — el linaje Toulmin·Dung·Amgoud de las referencias de abajo. El pkg/graph de reins traslada esa lógica formal de más de 60 años a una estructura de datos en Go.

Referencias

  • Toulmin, S. (1958). The Uses of Argument. Cambridge University Press. — el modelo de argumentación cuyos Warrant·Ground·Backing toma tal cual el defeat graph.
  • Dung, P.M. (1995). “On the Acceptability of Arguments and its Fundamental Role in Nonmonotonic Reasoning, Logic Programming and n-Person Games.” Artificial Intelligence, 77(2), 321–357. — el origen del framework de argumentación abstracta y del grafo de attack (defeat).
  • Amgoud, L. & Ben-Naim, J. (2013). “Ranking-based semantics for argumentation frameworks.” SUM 2013, LNCS 8078, 134–147. — el weighted h-Categoriser que adopta pkg/graph. La propiedad de Compensation, por la que un nodo atacado recupera aceptabilidad si vuelve a ser defendido, garantiza la convergencia.
  • Nute, D. (1994). “Defeasible Logic.” In Handbook of Logic in Artificial Intelligence and Logic Programming, Vol. 3. Oxford University Press. — la clasificación strict/defeasible/defeater. La raíz formal de los niveles de regla de reins (Fail/Review) y de la prioridad Supersedes.
  • Modgil, S. & Prakken, H. (2014). “The ASPIC+ Framework for Structured Argumentation: A Tutorial.” Argument & Computation, 5(1), 31–62. — el sistema de argumentación que estructura la clasificación de Nute dentro del framework de Dung. La genealogía del defeat graph.
  • Gabriel, V.O. et al. (2020). “Reasoning in BDI agents using Toulmin’s argumentation model.” Theoretical Computer Science, 805, 76–91. — un caso previo que implementó el modelo de Toulmin en software (agentes BDI). El pkg/graph de reins lo traslada al dictamen de la puerta.
  • Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” Automata Studies, Princeton University Press. — el principio de montar un protocolo fiable sobre piezas inestables (la premisa de reins).
  • Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). “On the Self-Verification Limitations of Large Language Models.” arXiv:2402.08115 — la autoverificación apenas sube el rendimiento → la razón para dejar la potestad de PASS en la máquina L1.
  • McKee-Reid, L. et al. (2024). “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack.” arXiv:2410.06491 — hasta un modelo honesto manipula si dictamina su propia recompensa → el fundamento de la asimetría de potestad.
  • Bondarenko, A. et al. (2025). “Demonstrating Specification Gaming in Reasoning Models.” arXiv:2502.13295 — cuanto mayor la capacidad, mejor encuentra los huecos de la puerta → la razón por la que la puerta=catálogo de reglas debe crecer.
  • Thaman, K. (2026). “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use.” arXiv:2605.02964 — endurecer deliberadamente la puerta redujo los exploits en un 87,7%.
  • Fanous, A. et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177 — medición de la tasa de cesión por adulación. Las dos caras de “para los hechos la adulación es un activo”.
  • Shapira, I. et al. (2026). “How RLHF Amplifies Sycophancy.” arXiv:2602.01002 — el teorema de que el RLHF amplifica la adulación. La premisa del bucle de convergencia feedback de hechos + adulación.
  • Deque Systems (2021). “Automated Testing Study Identifies 57 Percent of Digital Accessibility Issues.” — la frontera entre el área dictaminable por máquina (57%) y el residuo humano (20%).

Relacionados

Registro de cambios

  • 2026-06-05: Versión inicial