william-london/ownframework-loop

OwnFramework Loop - especificação

Esta habilidade é um adaptador de host sobre o núcleo determinístico ofloop.

Regras

• Nunca aprove seu próprio pacote.
• Nunca escreva STATE.json, APPROVAL.json, REVIEW_VERDICT.json, logs de eventos ou arquivos de bloqueio diretamente.
• Nunca fabrique o token de confirmação TTY.
• Nunca adicione push, merge, deploy, publish, send, payment ou autoridade remota não relacionada.

Nova especificação (fluxo normal)

1. Confirme que o diretório de trabalho é o repositório Git alvo.

2. Resolva a identidade do repositório ANTES de criar a execução:

   • inspecione os remotes Git configurados;
   • decida a classificação do pacote a partir do estado atual real, não do estado futuro pretendido;
   • local_only significa que nenhum remote está configurado;
   • quando uma superfície de revisão privada do GitHub fizer parte do projeto, crie/configurá-la, faça push da baseline pretendida, prove paridade local/remoto e use github_private antes de ofloop spec new;
   • não crie uma execução apenas local e adicione um remote depois.

3. Inspecione apenas contexto suficiente do repositório para elaborar um pacote limitado preciso.

4. Use ofloop spec new <repo> "<missão>" para criar a execução.

5. Elabore WORK_PACKET.md usando o schema do repositório e as convenções de pacote. Declare capabilities portáveis para necessidades de host/ferramenta em vez de embutir caminhos de máquina ou reconstruir manualmente a topologia de rede específica da ferramenta (por exemplo toolchain.python, package.uv, browser.playwright.chromium). Use runner_profile apenas como um NOME de perfil confiável quando a missão precisar de uma política de modelo/esforço comissionada pelo operador; pacotes nunca carregam flags raw do Claude. Use network_read_allowlist apenas para hosts de leitura extras específicos do pacote que não sejam fornecidos por um contrato de capacidade. Nunca adicione um wildcard amplo, scheme, porta, caminho, endpoint de publicação, socket de daemon ou host não relacionado. Antes de enfileirar, execute ofloop capabilities probe para inspecionar o host e ofloop capabilities preflight <repo> <capability>... para o conjunto exato solicitado. Se uma capacidade comum solicitada estiver indisponível, provisione ou comissione-a no host ou revise o pacote antes da execução; não amplie HOME/PATH ou recue para execução sem sandbox. Capacidades privilegiadas container.docker / local.http-service adicionalmente exigem o fluxo de comissionamento de canário de propriedade do operador.

6. Para pacotes PROGRAM com resultados específicos de checkpoint, mantenha o contrato completo de aceitação da missão no nível superior e atribua-o deterministicamente com acceptance_criterion_ids de cada checkpoint. Se algum checkpoint usar ids de AC com escopo, cada checkpoint deve declarar uma lista não vazia e a união deve cobrir cada id de AC de nível superior. Não use not_applicable para critérios de checkpoint futuros meramente para satisfazer cobertura.

7. Valide a forma do pacote com o validador suportado.

8. Retorne ao operador:

   • repo
   • run_id
   • packet_sha256
   • spec_baseline_branch / spec_baseline_sha
   • execution_mode / checkpoint_count
   • enfileiramento canônico não assistido: ofloop supervisor enqueue <repo> <run-id>
   • status canônico: ofloop supervisor status <repo> <run-id>
   • relógio de execução quando ainda não estiver rodando como serviço: ofloop supervisor serve
   • adaptador Claude (foreground/debug apenas): /of-loop:build <run-id>
   • adaptador Claude (foreground/debug apenas): /of-loop:review <run-id>

9. PARE. A operação normal em segundo plano é supervisor-primeiro. Enfileire a execução; um serviço de supervisor já comissionado a consome, ou ofloop supervisor serve pode executar o relógio de execução manualmente. O primeiro BUILD acionável cria o selo de execução imutável automaticamente.

Estado interno vs. voltado ao operador

O nome de armazenamento interno AWAITING_APPROVAL é preservado para compatibilidade reversa. O significado voltado ao operador é READY_TO_START (a execução é iniciável; nenhuma cerimônia de aprovação é necessária).

Compatibilidade apenas: pré-selo TTY legado

O comando opcional de pré-selo TTY histórico permanece como um pré-selo estrito opcional compatível com versões anteriores. NÃO é necessário no fluxo de trabalho normal e NÃO deve aparecer nas instruções do operador.

Imutabilidade do pacote

Antes do primeiro selo de execução: alterações no pacote são suportadas através da superfície de alteração suportada.

Após o selo de execução: o pacote é imutável. Missão/escopo alterado requer uma NOVA EXECUÇÃO.

Identidade do repositório antes da execução

target.classification é a identidade do repositório no momento da especificação, não um desejo de deploy futuro. Uma execução destinada a um projeto revisado no GitHub privado deve ser criada apenas após o remote privado e a branch baseline existirem e HEAD local for provado igual à baseline remota pretendida.

Se a topologia/classificação remota mudar após spec new mas antes do primeiro selo de execução, prefira parar a execução nunca iniciada e criar uma nova execução a partir do estado final do repositório. Não confie na primeira declaração BUILD para descobrir uma incompatibilidade local_only + remote evitável.

A execução atual do núcleo já falha fechada quando um pacote local_only tem remotes configurados. O fluxo de especificação deve evitar chegar a essa recusa na operação normal.

Pré-verificação de autonomia de PROGRAM

Antes de um v3 PROGRAM ser considerado pronto:

• use acceptance_criterion_ids nos checkpoints; nunca emita acceptance_criteria de checkpoint;
• declare o menor conjunto portátil de capabilities necessário para a missão e pré-verifique-o antes do enfileiramento. A autoridade de leitura de rede efetiva é a união congelada de hosts de network_read_allowlist específicos do pacote e hosts derivados de capacidade exata. Uma lista de pacote vazia, portanto, significa NENHUM domínio EXTRA do pacote, não necessariamente zero domínios quando uma capacidade declarada de pacote/navegador exige endpoints de download estreitos;
• escolha runner_profile apenas de perfis confiáveis expostos por ofloop capabilities profile <name>; modelos explícitos devem ser IDs de modelo fixos do provedor em vez de aliases móveis do Claude. Um esforço explícito também requer ofloop capabilities attest-effort <name> no runtime atual do Claude. A identidade do perfil é vinculada à execução e pode selecionar apenas modelo/esforço semântico, nunca autoridade de sandbox/ferramenta/MCP/sessão;
• valide os orçamentos do pacote contra tetos executáveis antes da primeira execução;
• trate os valores de build/review/repair de nível superior como envelopes cumulativos PROGRAM;
• a menos que intencionalmente limitando todo o PROGRAM, funde esses envelopes globais a partir das somas dos orçamentos locais de checkpoint;
• garanta que uma provisão global de reparo seja realizável pela provisão global de build/review;
• escolha max_pass_runtime_seconds para a complexidade de uma passada semântica (até 28800 por passada; o fusível de fallback não declarado é 3600, portanto qualquer passada que legitimaente precise de mais de uma hora deve declarar seu orçamento);
• declare risk_budget.max_runtime_seconds como o envelope de tempo real de toda a execução quando o PROGRAM pode legitimaente executar por muito tempo (até 2419200). supervisor enqueue o consome como teto operacional de parede; sem ele, nenhum teto de tempo de parede se aplica e a execução é limitada apenas por suas proteções de passada semântica/reparo/sem progresso.

Um pacote que só pode descobrir um teto determinístico impossível depois que um modelo já fez trabalho é um defeito de especificação e não deve ser iniciável.

Semântica de orçamento não assistido

Tetos de token estão desligados por padrão e tetos de custo estão desligados por padrão. A execução não assistida é limitada por proteções de progresso significativo (limites de passada e reparo, sequência sem progresso, fusível de repetição de descoberta idêntica, política de repetição por classe de falha), não por conservação de token ou custo. Operadores que desejam um limite de gasto rígido podem passar --max-cost-usd / --max-total-tokens / --max-wall-seconds explicitamente no momento do enfileiramento. Quando um teto de custo agregado positivo é financiado, o supervisor também reduz cada passada de modo de impressão Claude com o orçamento restante exato da execução durável; o razão Loop permanece a fonte de contabilidade agregada canônica.