[NO BORRAR][REFERENCIA] Filosofía OlympusAgents: Goal-Driven · Loop-Executed · Evidence-Gated #92

NO BORRAR — REFERENCIA PERMANENTE DE FILOSOFÍA DE TRABAJO.

No es un issue de implementación ni debe incorporarse al WIP activo. Su propósito es preservar este acuerdo para consultarlo al redactar encargos futuros. Mantenerlo accesible; no cerrarlo como duplicate ni sustituirlo por nuevos issues de proceso sin decisión explícita del usuario.

Decisión del mantenedor

Desde el siguiente prompt de trabajo, DESPUÉS de que termine la ejecución que ya está en curso y se reciba su resultado, OlympusAgents debe tratar los encargos nuevos con esta filosofía:

Un objetivo · Una autorización explícita y acotada · Ejecución continua · Evidencia proporcional · Intervención humana por excepción.

No interrumpir ni reinterpretar retroactivamente el prompt que está ejecutándose. Este issue no modifica automáticamente instrucciones del runtime, permisos, archivos ni configuración: el cambio inmediato es cómo formulamos y autorizamos los próximos prompts.

Problema que queremos evitar

El proceso anterior tendía a dividir artificialmente una sola misión en múltiples mensajes humanos: 1–5 investigar (solo lectura), 6–10 implementar, 11–12 listar archivos, 13–14 commit, 15 push/PR, 16–20 qualification y 20+ merge. Cada transición exigía otra intervención aun cuando el objetivo, los permisos y el alcance ya estaban claros.

Consecuencia: más issues abiertos que cerrados, pruebas FULL/RUNTIME repetitivas, documentos de evidencia y rondas de revisión que consumen más tiempo que la funcionalidad entregada.

Filosofía operativa

1. Goal-Driven: recibir una misión completa con criterios de aceptación, no un prompt para cada paso.
2. Loop-Executed: dentro del alcance permitido, investigar → implementar → comprobar → corregir → volver a comprobar, sin pedir autorización de nuevo por pasar de fase.
3. Evidence-Gated: declarar éxito por evidencia real de los criterios, no por texto PASS, suposiciones o confianza del modelo.
4. Risk-Proportional: tests específicos y baratos durante el loop; FAST/FULL/RUNTIME según impacto y contrato oficial, sin repetir automáticamente suites completas después de cada cambio.
5. Autonomous Correction: resolver en el mismo encargo fallos directamente relacionados; reutilizar evidencia aún válida; no crear un issue por cada detalle.
6. Finish Before Expanding: terminar o bloquear honestamente el trabajo activo antes de abrir otro frente; hallazgos externos reciben triage, no expansión tácita.
7. Bounded Persistence: persistir mientras existan progresos verificables y recursos/autoridad suficientes; detenerse si se repite un fallo sin nueva información o no se puede cumplir un gate.
8. Minimum Human Interruptions: la métrica es cuántas veces debe intervenir el mantenedor, no cuántas llamadas internas hace el modelo.

Objetivos orientativos de interacción humana

No son límites artificiales para cortar una investigación de seguridad ni cuotas que animen a ocultar problemas.

Autorización integral en el prompt inicial

Cuando corresponda, un solo encargo puede autorizar investigación, implementación, pruebas focalizadas, revisión del diff, correcciones, commit, push y creación de PR, sin solicitar una nueva confirmación por etapa. Debe indicar claramente: repo, issue, rama/checkout, alcance de escritura, aceptación, acciones externas permitidas, pruebas esperadas y condiciones de parada.

Merge, release, cambios de permisos, acciones destructivas o cualquier operación protegida requieren autoridad explícita previa y cumplimiento de los gates. La autorización no se deduce por estar dentro de un loop. Respetar la ruta real de /maintain/Aegis y los DENY/ASK existentes; no fingir accesos ni capacidad de herramientas. El agente puede usar sus delegaciones autorizadas si la herramienta de ejecución directa no está disponible.

Estados terminales claros

• DONE: aceptación comprobada y entrega efectuada hasta el límite autorizado (por ejemplo PR_READY, no MERGED cuando no existe permiso de merge).
• NEEDS_DECISION: decisión externa que cambia el resultado o alcance.
• BLOCKED: impedimento real con evidencia, sin reintento ciego ni falsa aprobación.
• BUDGET_EXCEEDED: continuar sin progreso verificable no se justifica.
• FAILED: criterios incumplidos, con estado y evidencia precisos.

Qualification y revisión sin burocracia

• En cada iteración: solo comprobación afectada y sus dependencias necesarias.
• En entrega de PR: gates que apliquen al tipo de cambio.
• En candidato de release: FULL → Installer UX → RUNTIME y demás prerrequisitos obligatorios del contrato vigente; no se omiten por perseguir menos prompts.
• Revisión independiente solo cuando el riesgo, el contrato o un hallazgo material lo justifiquen; sus correcciones permanecen en la misma misión.
• No afirmar que la evidencia sintética demuestra el comportamiento real de OpenCode/Codex.
• No publicar secretos, raw sensibles ni reportes inseguros por acelerar.

Límites arquitectónicos

• No construir ahora otro motor de loops, daemon, scheduler, plugin, agente, framework ni un conjunto nuevo de documentos. Aprovechar el loop de herramientas y delegación nativos disponibles en OpenCode/Codex.
• Mantener las responsabilidades existentes de Kael y especialistas y los límites de ownership; no iniciar recursión/fan-out ilimitado.
• Operación sin APIs de pago, servicios externos facturables ni infraestructura adicional fuera de GitHub y gates locales.
• No introducir hooks Git automáticos.
• La filosofía aplica al flujo de trabajo de OlympusAgents y a la redacción de nuestros próximos encargos; no redefine los demás proyectos.

Cómo empezamos

1. Dejar concluir intacta la ejecución actual; esperar el resultado que compartirá el mantenedor.
2. Al recibirlo, determinar el siguiente resultado útil o bloqueo real sin iniciar otra cascada de prompts de solo lectura.
3. Redactar un prompt end-to-end con la máxima autonomía que permita la autorización explícita y el riesgo, para ejecutar el siguiente trabajo real.
4. Medir durante cinco trabajos reales: intervenciones humanas, tiempo de cierre, gates repetidos sin impacto y entregas efectivas. Ajustar reglas con evidencia.
5. No abrir un issue nuevo para implementar esta filosofía; este documento es la referencia, y los cambios de producto se gestionan solo cuando se justifiquen.

En una frase

No diseñemos prompts para que el agente termine una etapa; diseñemos misiones para que termine el trabajo, se autocorrija dentro de sus permisos y sepa exactamente cuándo detenerse.

Relacionado: #91 (gobernanza/documentación y secretos; trabajo distinto, no bloquea adoptar desde el siguiente prompt).

Inspiración — no adopción literal de un while true: https://ghuntley.com/ralph/ · https://arxiv.org/abs/2607.00038.

Aprendizaje aplicado — 2026-10-26: parar cuando el bloqueo deja de ser local

Caso práctico: preparación del colector externo de qualification para OlympusAgents v0.4.12. La misión autónoma pasó de una base de 47 pruebas a 54/54 en Windows y 4/4 en Linux/WSL, con correcciones locales revisadas independientemente: manejo de ancestros Windows por HANDLE/FileID, estados de observación separados de decisiones de gate y backend Linux por FD. El candidato, checkout y evidencias anteriores permanecieron preservados según los reportes de ejecución; esto no acredita los runners oficiales ni constituye autorización de release.

Bloqueo residual real: la observación continua obligatoria de descendientes en Windows no está disponible/validada bajo el token y restricciones actuales; ETW fue denegado. READY_FOR_QUALIFICATION_AUTHORIZATION = NO. No atribuir esta limitación a un defecto corregible por otra ronda genérica de tests ni afirmar que 54/54 habilita qualifications oficiales.

Decisión operativa:

1. Congelar el esfuerzo del colector externo en el último paquete/evidencia revisada. Preservar sus límites y hashes; no iniciar nuevas copias, suites ni revisiones por inercia.
2. Mantener v0.4.12 sin autorización de qualifications/release mientras no se observe la capacidad obligatoria en un entorno Windows expresamente autorizado o se apruebe una modificación fundada del contrato/candidato. No elevar privilegios, eludir restricciones ni degradar CLEANUP_UNKNOWN a PASS.
3. Separar el bloqueo del trabajo independiente de OlympusAgents. Puede continuar una funcionalidad no dependiente del release, sin declarar liberada v0.4.12.
4. Distinguir tipos de impedimento: defecto local → corrección focalizada dentro del mandato; capacidad/permiso/entorno ausente → NEEDS_DECISION o BLOCKED con evidencia, sin reintentos; gate de seguridad no cumplido → no promover.
5. Control de WIP: priorizar una misión de producto activa a la vez. Reutilizar/triage de los issues existentes y reducir duplicados; no transformar cada fallo del colector en otro issue o en un proyecto de infraestructura.
6. Limitar evidencia auxiliar: pruebas afectadas durante el loop; una validación final proporcionada; revisión independiente cuando el riesgo la justifique. Medir resultados aceptados e intervenciones humanas, no número de artefactos ni tests.

Próximo objetivo preferido para recuperar entrega funcional: issue #74, Capability Preflight de Kael (resolver capacidad de delegación antes de comunicar un bloqueo global). Mantener #92 como referencia, no como ticket implementable. Revisar prioridades con el mantenedor antes de iniciar escrituras.

Aprendizaje central: un loop eficiente también sabe detenerse cuando ya no existen acciones locales legítimas con probabilidad razonable de progreso.

Ensayo de lotes — 2026-10-26: investigación compartida #72, #76, #85 y #87

Alcance: primera prueba de agrupación temática, ejecutada como una misión Codex read-only. Se compartieron inventario, versión del CLI, configuración, contratos y fuentes upstream. El informe del ejecutor declara 4/4 issues abordados, 3/4 con investigación suficiente para proponer cierre (#76, #85, #87) y 1/4 pendiente (#72, por comparación de beneficio medido no autorizada). No se cerraron issues ni se modificó código.

Métricas reportadas: una instrucción humana inicial; 0 solicitudes de intervención adicionales; 0 delegaciones; 399,6 s (6 min 39,6 s) de adquisición/comprobación, excluyendo la redacción posterior; ningún archivo modificado. Se identificó una consulta duplicada a releases/latest, seis contrastes web/tag para fijar versión y reutilización de una sola base local. Las métricas provienen del reporte de ejecución, no de telemetría independiente de tiempo/tokens.

Evaluación: PROMISING_FOR_RESEARCH_BATCHES, todavía no validado como mejora general. La prueba demuestra que pueden tomarse cuatro decisiones relacionadas sin cuatro rondas humanas independientes, pero no demuestra reducción porcentual de tiempo ni de tokens: falta un grupo de comparación secuencial y la duración reportada no incluye la entrega completa. Tampoco prueba la eficacia del loop para implementación, regresiones, PR y merge.

Reglas provisionales: agrupar por responsabilidad y evidencias compartidas; mantener decisión y estado de aceptación por issue; separar investigaciones read-only de mutaciones privilegiadas; no cerrar por mera cobertura documental cuando falte un criterio medido; evitar ramas y PR innecesarias en trabajos de solo lectura. No aumentar WIP ni alterar DENY/ASK, /maintain, los gates de release o el carácter permanente de este issue.

Próximo contraste necesario: repetir la medición en una misión de implementación con cambios relacionados, corrección autónoma y checks proporcionados. Registrar tiempo completo hasta entrega aceptada, intervenciones, reintentos, pruebas repetidas, bloqueos y resultado por issue. Solo después decidir si formalizar nuevos límites de tamaño de lote o concurrencia.

Actualización de filosofía — 2026-10-31: /goal nativo como motor de continuidad, Olympus como contrato de aceptación

Decisión de diseño (propuesta, no adopción automática): NATIVE_FIRST / EVIDENCE_GATED. La filosofía de este issue sigue vigente. OpenCode V2 incorporó /goal <objective> en v2.2.1 (TUI/Desktop), con controles pause, resume, clear, continuación en el límite idle y revisión de progreso. Esto permite investigar → implementar → comprobar → corregir dentro de una ejecución sin diseñar otro motor de loops. Referencias oficiales: changelog V2 y PR upstream #59437.

Separación de responsabilidades

Contrato mínimo portable de misión (para formular el prompt inicial)

1. Goal: resultado de producto deseado expresado en términos verificables, no una lista artificial de fases.
2. Contexto: repositorio, directorio/worktree, rama/revisión esperada, issue y límites de entorno.
3. Autorización integral y acotada: qué lecturas, escrituras, pruebas, delegaciones, commits, push/PR están permitidos; lo protegido (merge, release, cambios destructivos, permisos) exige autorización propia.
4. Acceptance / evidence: condiciones de éxito y evidencia mínima por riesgo; resultados previos aplicables se reutilizan, sin hashes ni suites FULL por inercia.
5. Persistence / stop: seguir mientras haya progreso y autoridad; pausar ante estancamiento, fallo de entorno, permisos, presupuestos, riesgo o un resultado que exige decisión del usuario.
6. Handoff: estado terminal honesto, artefactos/cambios, evidencia ejecutada/reutilizada, límites y siguiente decisión imprescindible.

Este contrato puede usarse sin /goal en Codex, CLI o proyectos que aún no adoptan el mecanismo; su objetivo es portabilidad semántica, no dependencia obligatoria de un host.

Adaptación operacional sugerida

• Cuándo probar /goal: misiones interactivas de OpenCode TUI/Desktop, con varias iteraciones útiles y un resultado medible. Las consultas simples, investigaciones breves o tareas de un paso pueden usar el loop ordinario sin activar /goal.
• Cómo iniciar: establecer el contrato completo y la autorización antes de activar /goal <objective> en la sesión y directorio correctos. Kael ejecuta y corrige dentro del alcance; un fallo focalizado lleva a la corrección focalizada, no a repetir FULL.
• Cómo terminar: goal met/veredicto interno done es candidato a cierre, no DONE de Olympus. Reconciliar pruebas, artefactos, permisos y publicación hasta el límite autorizado. Un goal paused requiere clasificar su motivo (NEEDS_DECISION, BLOCKED, BUDGET_EXCEEDED u otro); no traducirlo automáticamente a fracaso.
• Cómo controlar costo: medir intervenciones humanas, tiempo total de orquestación frente al tiempo técnico, pruebas repetidas, vueltas sin progreso, resultado aceptado y coste/uso solo cuando el host lo exponga. No auditar rutinariamente suscripciones ni facturación; respetar restricciones económicas del usuario y no modificar autenticación sin autorización.
• Cómo preservar autoridad: /goal no altera DENY/ASK, ownership, /maintain/Aegis, ni gates de release; nunca otorgar acciones no autorizadas mediante continuaciones sintéticas.

Límites nativos confirmados en fuente — no asumir más

• El revisor de /goal usa el modelo de la misma sesión (session.generate), no un segundo revisor independiente; no reemplaza Vera ni pruebas del producto.
• El diseño incorpora mecanismos de pausa por estancamiento/límites de rondas, pero no ofrece un presupuesto configurable de tokens; una continuación nativa no garantiza economía ni cierre correcto.
• Un reinicio puede dejar el goal en pausa y requerir resume; no prometer recuperación automática universal.
• /goal es un comando de TUI/Desktop; el PR original señala que opencode run no soporta slash commands. No atribuirle capacidad en run --standalone sin verificación específica.
• La semántica de trabajo en background y notificaciones debe evaluarse con los eventos reales; un aviso done del cliente o del revisor no demuestra por sí mismo que todos los consumidores terminaron.

Evidencia y siguiente decisión

• La investigación y comparativa ADOPT / ADAPT / DEFER / REJECT corresponden a #100, que sigue siendo el issue ejecutable de investigación; [NO BORRAR][REFERENCIA] Filosofía OlympusAgents: Goal-Driven · Loop-Executed · Evidence-Gated #92 continúa como referencia permanente y abierta.
• Las pruebas funcionales de provisioning/native B/C de #77 validaron Kael y directorios en worktrees consumer, pero no probaron /goal; lifecycle B sigue históricamente UNVERIFIED.
• La política de verificación TFR fue revisada y comprometida localmente, pero su comportamiento en runtime y la adopción de /goal todavía no están verificados. No convertir esta adición documental en adopción del producto.
• Siguiente paso de [Research] Native /goal vs. reusable evidence-gated mission workflow #100: piloto opt-in, pequeño y medible, comparando la ejecución actual frente a /goal para una misión relacionada con pruebas/corrección. Mantener la misma autoridad y criterios, no añadir infraestructura ni revalidar requisitos ya demostrados. Solo después decidir una forma de uso reutilizable en nuestros proyectos.

Síntesis: Olympus define qué significa terminar y qué está autorizado; OpenCode /goal puede ayudar a sostener el trabajo hasta ese punto. Ni el loop nativo ni su revisor deben sustituir evidencia, autoridad o decisiones humanas.