name: orderfield description: v0.7.46 — Kernel de contrato com suporte em disco. Use quando o usuário invocar /orderfield ou /of, um field existente precisar ser retomado, ou uma onda multi-slice / multi-writer genuína precisar de um plano que sobreviva à compactação. Instalação/verificação humana: docs/demo/mortal-install.sh depois of doctor. Doctor/status pergunta uma vez por dia quando uma versão mais nova existir (consentimento; não silencioso). Não dispare apenas por um nome de harness sozinho ou um subagente comum. Harnesses desconhecidos usam modo genérico. license: MIT compatibilidade: Requer Python 3.11+. Harnesses CLI opcionais incluem claude, codex, orca, agent ou cursor-agent, opencode, grok, agy, qwen. Kernel usa apenas stdlib. metadata: versão: "0.7.46" autor: Soy Pei / orderfield princípio: haken-slaving
O que orderfield faz?
Você é o líder. Não implemente a fatia. O disco é a sessão.
/of é esta skill. Retomar. Empacotar. Residual. Contraste. Fechar. Origem é um ponteiro, não o pino de spawn.
O harness (Claude, Codex, Orca, Grok, Cursor, OpenCode, Antigravity/agy) inicia e para processos. ORDER, pacotes, residuais e decisões de regime vivem no disco. Use quando um kernel, um produto ou uma construção multi-slice precisar de donos exclusivos, um SPEC que sobreviva à compactação e of contrast antes do fechamento. Se um agente já for suficiente, não abra um field.
Vocabulário do contrato: docs/glossary.md. Comparado (Orca, AWS CAO, Agent Teams, CrewAI/LangGraph, habilidades de harness duplo): README.md. Invariantes: references/principles.md.
Os filhos se movem livremente dentro do pacote. Um residual de limite bloqueia mais spawn naquela onda; ele não altera o ORDER por si só.
O kernel impõe schemas JSON públicos, escritas atômicas por arquivo mais um WAL em todo o field (stage + MANIFEST + publish) para mutações de múltiplos arquivos, um lock de campo entre processos para MUTATING_COMMANDS (init, new, pack, unpack, collect, integrate, phase, patch, next-wave, migrate, spec, checkpoint, close, gc), limites de pacote, identidade/caminho/revisão canônica de pacote, vinculação residual, replay de integração, transições de fase/onda protegidas, bloqueio de spawn e o menu de regime fechado quando o trabalho passa por of. Obediência de função, posse do espaço de trabalho do produto, escolha do mesmo harness, métricas verdadeiras de autoria do filho e escritas diretas fora da CLI permanecem no protocolo. Ele não bloqueia arquivos de produto, não cria worktrees automaticamente, não atesta métricas nem policia um filho desobediente. of worktree é um ajudante opcional, não um gerenciador de processos.
O que digitar em seguida
| Disco diz | Você digita |
|---|---|
.orderfield/ORDER.json existe | of resume — depois o next impresso, na mesma rodada |
| sem ORDER, trabalho multi-slice real | of init --mission "…" --source "<verbatim brief>" |
| donos conhecidos | of pack --slice "…" --owns-requirement ID depois of handoff --packet ou of spawn |
| fatia parece enorme | of pack --explain --slice "…" --role explorer — nomeia o porquê; não escreve |
| meio da épica, próximo harness ou humano | of handoff (pacote de campo) ou of handoff --json — não desempacote |
| residuais chegaram | of collect --wave N → of integrate --wave N |
| superfície pública exercitada | of spec --verified-contract ID → of contrast → of close --checklist → of close |
| multi-onda pronto para fechar | of close --checklist — contraste RESOLVIDO + residual vazio; depois of close. Voando (residual AUSENTE) não está fechado |
| o que fechado significa | docs/close-is-proof.md — RFC: contraste RESOLVIDO + residual vazio + CLOSE.json. Residual vazio não é o fechamento |
| filho diz que o field está errado | of patch … depois of next-wave |
| vários fields abertos incompatíveis | anexe --field (escreve .orderfield/ACTIVE), ou of new |
| vários irmãos, precisando de pacotes voando | of fields / of fields --json — pacotes abertos entre homes; of status --json permanece um field |
| missão longa (épica → ondas → emenda → fechar) | docs/long-mission.md — percorra os verbos; não invente um supervisor |
sessão diz FECHADO, --tokens ou desempacote um repórter | of eval recovery/adversarial-dual-truth — disco vence; --tokens morre; colete/integre um repórter |
humano pede instalar/verificar of | bash docs/demo/mortal-install.sh --global (ou --root PATH); of doctor deve imprimir ok. Pin: README / PUBLISH. Não pip. Não um daemon |
stderr/doctor diz of mais novo | pergunte ao usuário; se sim: ORDERFIELD_VERSION=… bash install.sh --global --from-release (release tar.gz + SHA256SUMS). Uma vez por dia. Não atualize no meio de um ORDER sem consentimento |
residual multi-harness / skill profunda perdeu residual.codex | of eval recovery/multi-harness-residual — Claude/Codex/Cursor compartilham um residual; Codex argv ainda nomeia o schema |
of doctor imprime FAIL | field/kernel — corrija ACTIVE/stub/packs/schemas/lock; apenas SKEW da skill é WARN / exit 0 (bash install.sh --global) |
next=HOLD e filhos voando | cite a última linha PULSE para o usuário nesta rodada; fique nesses pacotes |
Uma rodada que afirma pack, spawn, contrast ou close sem esses comandos of na mesma rodada é uma execução quebrada.
Quando usar
- O usuário invoca explicitamente Orderfield,
/orderfield,/of, Haken slaving, delegação de limite ou um order field. - Software complexo (um kernel, um produto, uma construção multi-slice) que não caberá em um contexto sem perder qualidade.
- Múltiplas fatias ou escritores precisam de posse explícita, ou vários harnesses devem coordenar.
.orderfield/ORDER.jsonjá existe no repositório.
Um nome de harness sozinho não é um gatilho. Se a tarefa couber em um agente, um subagente comum ou uma skill, não abra um field. Skill vence filho.
Auto-relato (HITL)
Orderfield relata automaticamente defeitos em si mesmo para pedroknigge/orderfield após confirmação HITL. Isto é autotelemetria do kernel/skill/CLI/docs/install — não é um helpdesk e não é um ticket contra a árvore de trabalho do consumidor. O git origin do consumidor está fora do escopo para sempre. Um fork de amarilla-platform não pode receber essas issues. Use of issue. Não é uma restrição de uma onda.
Auto-relate SOMENTE se a falha for do Orderfield:
- kernel emitiu schema inválido / WAL incoerente / pacote produziu um packet que collect não pode aceitar / metadados de spawn incoerentes / contraste se contradiz / docs reivindicam vs código / falha de atualização/pin de instalação / invariante child-forge ou lock quebrada.
NÃO faça auto-relato:
- filho não terminou, SPEC incompleto, testes do produto vermelhos, fatia não gostou, erro de compilação do consumidor, "usuário está preso." Isso permanece no disco (residual → integrate).
Se não tiver certeza, rascunhe + HITL, padrão para não postar.
Nunca crie uma issue do GitHub sem uma confirmação humana explícita na mesma rodada.
- Confirmar → criar (
of issuesem--dry-runapós HITL; executá-lo é o envio). - Recusar / editar depois / silenciar → não criar (ou apenas
of issue --dry-run).
Ambos os lados são o contrato. Auto-post, yolo post e postagem de um filho são proibidos.
of issue sempre tem como alvo --repo pedroknigge/orderfield. Funciona sem ORDER. Apenas stdlib: o kernel spawna gh com a conta logada (gh auth). Não se passem, não inventem um token, não postem no origin do consumidor. O kernel nunca solicita entrada no stdin — HITL permanece o líder/humano.
of issue --search
of issue --title "…" --body "…" --label bug --dry-run
of issue --title "…" --body-file scratch/ISSUE.md --label enhancement
Um filho (OF_CHILD definido, spawn sem cabeça, ou qualquer sessão que não possa perguntar ao humano) nunca posta. Ele escreve um rascunho em seu scratch (ISSUE.md ou issues/<slug>.md: título, corpo, labels bug ou enhancement, caminhos de evidência) ou executa of issue --dry-run, e nomeia o rascunho no residual. Você pergunta HITL, depois of issue.
Pesquise issues abertas primeiro (of issue --search); pule duplicatas. Não arquive segredos, tokens, transcrições privadas ou residuais internos do campo (estes permanecem em disco: residual → integrate). Um rascunho ou issue por descoberta distinta; não um diário. Procedimento do filho: SLAVE.md.
Processo obrigatório do líder
Execute of se estiver no seu PATH (o instalador cria link simbólico para ~/.local/bin/of). Caso contrário, execute python3 <skill>/scripts/of.py. Em um repositório de trabalho, o estado vive nesse repositório em .orderfield/, não dentro da skill. Se o humano pedir para instalar ou verificar a instalação, execute bash docs/demo/mortal-install.sh --global (árvore checkout/extraída) ou --root PATH para uma análise hermética — depois of doctor deve imprimir ok. Receita do pin: README / PUBLISH. Não invente pip, um supervisor ou um segundo instalador.
Disciplina de chamada de ferramenta. Uma rodada que afirma pack, spawn, contrast ou close sem esses comandos of na mesma rodada é uma execução quebrada. Anuncie no passado apenas após o CLI retornar.
Reativação automática. Um field aberto (spec_closed falso) não pausa quando você troca de chat, perde contexto para compactação ou o usuário trabalha em tarefas não relacionadas em outro lugar. Toda rodada de líder naquele espaço de trabalho: of resume primeiro, leia auto_continue, depois execute a ação next impressa na mesma rodada — handoff/spawn/collect/integrate/patch/next-wave/contrast/close conforme apropriado. Não pare após resume e espere o usuário dizer "continue". Não pergunte se deve retomar a menos que o usuário explicitamente tenha pausado ou parado a missão (pause / stop / wait on the field / cancel the mission / of init --force). Se resume imprimir um roster (PICK --field, exit 2) ou foreign field (vários fields abertos; este id de sessão não corresponde à origem vinculada), esse não é o next desta sessão — pergunte qual field ou of new. Um field aberto único continua automaticamente mesmo quando OF_SESSION_ID difere de ORDER.origin.session_id — origem é proveniência, não autoridade de retomada. Uma rodada que executa of resume em um field aberto que possui mas não realiza nenhum trabalho next é uma execução quebrada.
Política de direção (análogo a Eve). Enquanto uma rodada está em andamento, uma nova mensagem do usuário em um field aberto é dirigida, não enfileirada como uma missão separada: altere ou corrija o contrato (of spec --amend, of patch), continue filhos estacionados (HOLD), ou integre — não faça of init --force a menos que o usuário cancele explicitamente a missão. Um sinal verde déitico (dale, pode fazer, como discutido) em um field aberto é execute next, não of spec --amend dessas palavras. Chats intercalados e compactação não são pausa; são direcionamento de contexto de volta ao disco.
Layout de contexto (instruções vs skills vs pacotes vs subagentes): docs/context-control.md.
Após compactação ou retorno de um chat intercalado, o primeiro ato ainda é of resume — reconstruir a partir do disco, não da memória do chat.
0. Retomar do disco (quando ORDER existe)
python3 <skill>/scripts/of.py resume
Se um field existir, comece aqui. Reconstrua em andamento a partir de pacotes/residuais/estado mais um resumo opcional de checkpoint. Não faça of init quando um field já estiver aberto. Não reempacote um filho que já tem um pacote e nenhum residual. Resume é uma tela; não spawna automaticamente, não despeja logs, nem adiciona um regime. Ele imprime field (open | closed) e auto_continue (yes → execute next nesta rodada; no → field fechado, origem estrangeira entre vários fields abertos, ou um roster). Um field aberto único imprime yes mesmo quando OF_SESSION_ID difere de ORDER.origin.session_id. Quando ORDER.origin está presente, imprime uma linha origin <harness> [<session_id>]; omita essa linha quando a chave estiver ausente. Origem é proveniência (qual sessão de harness abriu o field), não autoridade de retomada e não uma transcrição. Onda viva é state.wave mais pacotes/residuais — session.json obsoleto não vence. Um host de spawn morto é o mesmo disco: metadados de spawn apenas iniciados e um WAL incompleto não escondem o filho empacotado. Não faça of init em um field aberto (recovery/multi-day-resume, recovery/process-death-resume).
Fields irmãos. Uma árvore de trabalho pode conter vários fields (.orderfield/fields/<id>/). of new abre um irmão sem matar os outros e escreve .orderfield/ACTIVE — isso é uma épica não relacionada. of new --parent abre uma fase aninhada da épica vinculada (ORDER.parent); of close retorna ACTIVE para aquele pai (não of merge). Mesma missão, novas restrições / done-when / fase neste ORDER é of patch no field vinculado. of fields os lista (* = ACTIVE; open/closed; fase/onda/idade-do-pacote; choose) e uma seção packs de filhos em andamento (residual AUSENTE) entre homes abertos. of fields --json é o objeto do painel épico (PackRoster; recovery/cross-field-pack-roster). --open / --all / --cursor paginam muitos homes. Passe --field <id> ou OF_FIELD (isso atualiza ACTIVE). Status/resume seguem ACTIVE após correspondência de origem; um stub ORDER de nível superior ignorado é ignorado quando homes aninhados existem. --field de um stub de id diferente morre; of migrate o arquiva para ORDER.json.stub (recovery/root-stub-ambiguous). O kernel nunca solicita entrada no stdin. Se resume imprimir PICK --field (exit 2), pergunte ao usuário qual field anexar ou se deve usar of new. Se auto_continue no disser foreign field, não execute o next daquele field — anexe com --field ou abra um irmão. Uma sessão posterior do único field aberto não é estrangeira. Mesmo brief, outro agente → anexe. Brief não relacionado → of new. Pergunta extra no meio do voo sobre o mesmo produto → of spec --amend, não of new. Mapa: docs/nested-fields.md. Modelos de fechamento: docs/close-honesty.md. Caminhada de missão longa: docs/long-mission.md.
O brief lista completed filhos (residual presente: status, result_ref, owns_requirements, presença de owned-path) e in_flight / parked filhos (residual AUSENTE: parked_reason, scratch, owners, owned-path present/missing, slice, idade do pacote, agents_note). Enquanto qualquer residual estiver AUSENTE, of status / of resume / of pulse imprimem running — residual AUSENTE; cromo do harness (Churned / done) não é o fie
… [truncado para tradução]