OwnFramework Loop - especificación

¿Qué hace OwnFramework Loop - especificación?

Esta habilidad es un adaptador de host sobre el núcleo determinista ofloop.

Reglas

• Nunca apruebes tu propio packet.
• Nunca escribas STATE.json, APPROVAL.json, REVIEW_VERDICT.json, registros de eventos ni archivos de bloqueo directamente.
• Nunca fabriques el token de confirmación TTY.
• Nunca añadas push, merge, deploy, publish, send, payment ni ninguna autoridad remota no relacionada.

Nueva especificación (flujo normal)

1. Confirma que el directorio de trabajo es el repositorio Git objetivo.

2. Resuelve la identidad del repositorio ANTES de crear el run:

   • inspecciona los remotos Git configurados;
   • decide la clasificación del packet basándote en el estado actual real, no en el estado futuro previsto;
   • local_only significa que no hay remoto configurado;
   • cuando una superficie de revisión privada de GitHub sea parte del proyecto, créala/configúrala, sube la línea base prevista, demuestra la paridad local/remota, y usa github_private antes de ofloop spec new;
   • no crees un run solo local y le añadas un remoto después.

3. Inspecciona solo el contexto suficiente del repositorio para redactar un packet acotado y preciso.

4. Usa ofloop spec new <repo> "<misión>" para crear el run.

5. Redacta WORK_PACKET.md usando el esquema del repositorio y las convenciones de packet. Declara capabilities portables para las necesidades del host/herramienta en lugar de incrustar rutas de máquina o reconstruir manualmente la topología de red específica de la herramienta (por ejemplo toolchain.python, package.uv, browser.playwright.chromium). Usa runner_profile solo como un NOMBRE de perfil de confianza cuando la misión necesite una política de modelo/esfuerzo encargada por el operador; los packets nunca contienen flags brutos de Claude. Usa network_read_allowlist solo para hosts de lectura adicionales específicos del packet que no estén ya proporcionados por un contrato de capacidad. Nunca añadas un comodín amplio, esquema, puerto, ruta, endpoint de publicación, socket de demonio ni host no relacionado. Antes de poner en cola, ejecuta ofloop capabilities probe para inspeccionar el host y ofloop capabilities preflight <repo> <capability>... para el conjunto exacto solicitado. Si una capacidad ordinaria solicitada no está disponible, aprovisiónala o encárgala en el host o revisa el packet antes de la ejecución; no amplíes HOME/PATH ni recurras a ejecución sin sandbox. Las capacidades privilegiadas container.docker / local.http-service requieren adicionalmente el flujo de comisionado canary propiedad del operador.

6. Para packets de tipo PROGRAM con resultados específicos de checkpoint, mantén el contrato completo de aceptación de la misión en el nivel superior y asígnalo determinísticamente con cada acceptance_criterion_ids del checkpoint. Si algún checkpoint usa ids de AC acotados, cada checkpoint debe declarar una lista no vacía y la unión debe cubrir cada id de AC de nivel superior. No uses not_applicable para criterios de checkpoint futuros solo para cumplir con la cobertura.

7. Valida la forma del packet con el validador compatible.

8. Retorna al operador:

   • repo
   • run_id
   • packet_sha256
   • spec_baseline_branch / spec_baseline_sha
   • execution_mode / checkpoint_count
   • encoleamiento desatendido canónico: ofloop supervisor enqueue <repo> <run-id>
   • estado canónico: ofloop supervisor status <repo> <run-id>
   • reloj de ejecución cuando no se ejecute ya como servicio: ofloop supervisor serve
   • adaptador Claude en primer plano/solo depuración: /of-loop:build <run-id>
   • adaptador Claude en primer plano/solo depuración: /of-loop:review <run-id>

9. DETENTE. La operación normal en segundo plano es supervisor-primero. Pon el run en cola; un servicio supervisor ya comisionado lo consume, o ofloop supervisor serve puede ejecutar el reloj de ejecución manualmente. El primer BUILD accionable crea automáticamente el sello de ejecución inmutable.

Estado interno vs. estado visible al operador

El nombre de almacenamiento interno AWAITING_APPROVAL se conserva por compatibilidad hacia atrás. El significado visible al operador es READY_TO_START (el run se puede iniciar; no se requiere ceremonia de aprobación).

Solo compatibilidad: TTY pre-sello heredado

El comando histórico opcional de TTY pre-sello permanece como compatibilidad hacia atrás / pre-sello estricto opcional. NO es requerido por el flujo de trabajo normal y NO debe aparecer en las instrucciones al operador.

Inmutabilidad del packet

Antes del primer sello de ejecución: se admiten modificaciones al packet a través de la superficie de modificación compatible.

Después del sello de ejecución: el packet es inmutable. Un cambio de misión/alcance requiere un NUEVO RUN.

Identidad del repositorio antes de la ejecución

target.classification es la identidad del repositorio en tiempo de especificación, no un deseo de despliegue futuro. Un run destinado a un proyecto con revisión privada en GitHub debe crearse solo después de que existan el remoto privado y la rama base, y se demuestre que HEAD local es igual a la base remota prevista.

Si la topología/clasificación remota cambia después de spec new pero antes del primer sello de ejecución, prefiere detener el run que nunca se inició y crear un run nuevo desde el estado final del repositorio. No confíes en el primer BUILD para descubrir un desajuste evitable local_only + remoto.

La ejecución del núcleo actual ya falla cerrada cuando un packet local_only tiene remotos configurados. El flujo de especificación debe evitar llegar a ese rechazo en operación normal.

Pre-vuelo de autonomía PROGRAM

Antes de que un v3 PROGRAM se considere listo:

• usa acceptance_criterion_ids en los checkpoints; nunca emitas acceptance_criteria de checkpoint;
• declara el conjunto más pequeño de capabilities portables que necesite la misión y haz el preflight antes de poner en cola. La autoridad de lectura de red efectiva es la unión congelada de los hosts de network_read_allowlist específicos del packet y los hosts exactos derivados de las capacidades. Por lo tanto, una lista de packet vacía significa que NO hay dominios EXTRA del packet, no necesariamente cero dominios cuando una capacidad declarada de paquete/navegador requiere endpoints de descarga estrechos;
• elige runner_profile solo de perfiles de confianza expuestos por ofloop capabilities profile <name>; los modelos explícitos deben ser IDs de modelo de proveedor fijos, no alias móviles de Claude. Un esfuerzo explícito también requiere ofloop capabilities attest-effort <name> en el runtime actual de Claude. La identidad del perfil está vinculada al run y puede seleccionar solo modelo/esfuerzo semántico, nunca autoridad de sandbox/herramienta/MCP/sesión;
• valida los presupuestos del packet contra los techos ejecutables antes de la primera ejecución;
• trata los valores de build/review/repair de nivel superior como envoltorios acumulativos de PROGRAM;
• a menos que se esté limitando intencionalmente todo el PROGRAM, financia esos envoltorios globales a partir de las sumas de los presupuestos locales de los checkpoints;
• asegura que un margen de reparación global sea realizable por el margen global de build/review;
• elige max_pass_runtime_seconds para la complejidad de un pase semántico (hasta 28800 por pase; el fusible de respaldo no declarado es 3600, por lo que cualquier pase que legítimamente necesite más de una hora debe declarar su presupuesto);
• declara risk_budget.max_runtime_seconds como el envoltorio de tiempo de pared de todo el run cuando el PROGRAM pueda legítimamente ejecutarse mucho tiempo (hasta 2419200). supervisor enqueue lo consume como el techo operativo de pared; sin él, no se aplica ningún techo de tiempo de pared y el run está limitado solo por sus protecciones de pase semántico/reparación/sin progreso.

Un packet que solo pueda descubrir un techo determinista imposible después de que un modelo ya haya hecho trabajo es un defecto de especificación y no debe poder iniciarse.

Semántica de presupuesto desatendido

Los techos de tokens están desactivados por defecto y los techos de costo están desactivados por defecto. La ejecución desatendida está limitada por protecciones de progreso significativo (límites de pase y reparación, racha de falta de progreso, fusible de repetición de hallazgo idéntico, política de reintento por clase de fallo), no por conservación de tokens o costos. Los operadores que deseen una línea de gasto dura pueden pasar --max-cost-usd / --max-total-tokens / --max-wall-seconds explícitamente al momento de poner en cola. Cuando se financia un techo de costo agregado positivo, el supervisor también reduce cada pase de modo de impresión de Claude con el presupuesto de run durable restante exacto; el libro mayor de Loop sigue siendo la fuente de contabilidad agregada canónica.