@orkastery/cli 0.2.0 → 0.4.1

package/skills/README.md

@@ -15,14 +15,14 @@ faz, o nucleo vence, e a divergencia e defeito da skill.
 | phases | [goal-definition](phases/goal-definition/SKILL.md) | `ork phase run <t> GOAL`, `ork claims add` |
 | phases | [plan-specification](phases/plan-specification/SKILL.md) | `ork phase run <t> PLAN`, `ork lease acquire` |
 | phases | [go-implementation](phases/go-implementation/SKILL.md) | `ork worktree ensure`, `ork verify --baseline` |
-| phases | [check-quality](phases/check-quality/SKILL.md) | `ork verify`, `ork gate approve` |
+| phases | [check-quality](phases/check-quality/SKILL.md) | `ork verify`, `ork gate request` |
 | phases | [ship-release](phases/ship-release/SKILL.md) | `ork ship` |
-| phases | [master-metrics](phases/master-metrics/SKILL.md) | `ork master`, `ork master --batch` |
+| phases | [master-metrics](phases/master-metrics/SKILL.md) | `ork master`, `ork master --aceitar-omissao` |
 | reviewers | [code-reviewer](reviewers/code-reviewer/SKILL.md) | `references/code-review-axes.md` |
 | reviewers | [security-auditor](reviewers/security-auditor/SKILL.md) | `references/security-checklist.md` |
 | reviewers | [test-engineer](reviewers/test-engineer/SKILL.md) | `references/testing-patterns.md` |
 | reviewers | [web-performance-auditor](reviewers/web-performance-auditor/SKILL.md) | `references/performance-checklist.md` |
-| governance | [decision-triage](governance/decision-triage/SKILL.md) | `ork gate approve` |
+| governance | [decision-triage](governance/decision-triage/SKILL.md) | `ork gate request` |
 | governance | [narrative-guardian](governance/narrative-guardian/SKILL.md) | `ork verify`, `ork phase list` |
 | governance | [roadmap-keeper](governance/roadmap-keeper/SKILL.md) | `ork board`, `ork thread new` |
 | governance | [scope-check-capability-map](governance/scope-check-capability-map/SKILL.md) | `ork doctor`, `ork board plan` |

package/skills/core/onboarding/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: onboarding
+description: "Conduz ou retoma a entrevista de configuração do projeto pela pauta de ork onboarding. Use para registrar respostas públicas, consultar pendências, resetar uma resposta ou publicar a entrevista na memória."
+bucket: core
+roteia: "ork onboarding | ork doctor"
+license: MIT
+---
+
+# Onboarding do projeto
+
+Consulte `ork onboarding` para obter a pauta e `ork onboarding show --json` para retomar
+as etapas pendentes. A ordem, o contrato e a validação pertencem ao núcleo; não mantenha
+uma lista paralela de etapas na skill ou no host. Não crie thread para apenas entrevistar.
+
+Conduza as perguntas da pauta, usando as respostas do builder. Grave cada resposta pública
+com `ork onboarding set <etapa> --conteudo <JSON> --por <quem>`. Transporte o JSON como dado,
+com escaping adequado ao shell. Não invente resposta nem autoria; `owner` é o default do CLI,
+não uma declaração de que o humano respondeu.
+
+Peça somente referências de variáveis nas etapas sensíveis. Valores secretos ficam em
+`~/.hermes/.env`; não leia esse arquivo nem leve credenciais para conversa, onboarding ou ledger.
+Se o builder fornecer um segredo, não o repita: oriente a configuração local e registre apenas
+a referência pública aceita pelo núcleo.
+
+Repetir conteúdo idêntico preserva autoria, carimbo e eventos. Reset exige pedido explícito:
+use `ork onboarding reset [etapa]` (omitir etapa limpa todas). Releia o estado depois da operação.
+
+A publicação opcional usa `ork onboarding sync --json`. Regime files ou driver indisponível
+produz degradação tipada; a entrevista pode concluir em arquivos. Não anuncie memória publicada
+quando o resultado informa degradação. A escolha registrada orienta `memory.mode` no manifesto,
+sem alterá-lo automaticamente. `ork doctor` mostra pendências e divergência de escolha.
+
+Ao concluir, apresente o estado medido por `ork onboarding show --json` e eventuais pendências.
+Eval estrutural não prova comportamento de LLM nem semanas de operação; essa metade permanece
+unavailable até existir execução observada.
+
+## Racionalizacoes comuns
+
+| Desculpa | Resposta |
+|---|---|
+| "Guardar o token aqui é mais rápido" | Guarde somente referências; valores ficam no arquivo local de segredos. |
+| "#Auto permite inventar o restante" | As respostas vêm do builder; autonomia não cria fatos. |
+| "Files significa onboarding incompleto" | A entrevista local conclui; relate o motivo da degradação sem afirmar publicação. |
+
+## Bandeiras vermelhas
+
+- Lista de etapas ou validação copiada do núcleo para o host.
+- Credencial em resposta, prompt ou ledger.
+- Reset sem pedido do builder ou autoria humana inferida.
+- Publicação declarada sem conferir o resultado de sync.

package/skills/core/orkastery-bootstrap/SKILL.md

@@ -1,89 +1,119 @@
 ---
 name: orkastery-bootstrap
-description: "Skill raiz do Orkastery: explica o ciclo de looping threads, roteia /goal /plan /go /check /ship /master para as skills de fase e para o `ork`, e le a #TAG de conducao do pedido. Ativa sempre que o repositorio tem orkastery.yaml."
+description: "Reconhece a frase exata orkastery maestro e conduz pedidos e retomadas do Maestro/Builder: consulta o panorama pelo ork e apresenta progresso, decisoes e entrega na conversa. Em sessao de fase ja despachada, retome essa fase sem abrir outra orquestracao."
 bucket: core
-roteia: "ork modos | ork thread new | ork board"
+roteia: "ork modos | ork thread new | ork thread status | ork phase list | ork pulse"
 license: MIT
 ---
 
 # Orkastery Bootstrap
 
-## O que esta skill e
+## Papel na conversa
 
-Um roteador fino. Ela nao executa fase nenhuma, nao escreve codigo e nao guarda regra de negocio:
-ela diz qual comando `ork` responde pela intencao do builder e chama esse comando. **A metodologia
-executavel mora no nucleo `ork`, nunca nesta prosa.** Em qualquer divergencia entre o que esta
-escrito aqui e o que o `ork` faz, o nucleo vence, e a divergencia e defeito desta skill.
+Um roteador fino para a conversa. A metodologia executavel mora no nucleo `ork`.
 
-Essa e a licao que matou o Orkastery original: metodologia que existe so como texto e metodologia
-que ninguem verifica.
+O dono traz objetivos e decisoes; o agente opera o `ork` e conduz o proximo passo autorizado.
+Uma resposta com uma lista de comandos para o dono executar nao conclui um pedido de trabalho.
+A metodologia, os modos, os gates e a verificacao continuam no nucleo. Esta skill traduz intencao e apresenta resultados; Adaptador que implementa a demanda no host quebra essa separacao.
 
-## Quando usar
+Distinga o contexto antes de agir:
 
-- Automaticamente, sempre que o repositorio de trabalho tem `orkastery.yaml`.
-- Quando o builder pede para comecar, retomar, listar ou avaliar trabalho.
-- Quando outra skill do catalogo precisa das regras de base repetidas.
+- **Sessao condutora:** recebe o pedido do dono, identifica ou abre a thread, despacha pelo `ork` e acompanha o resultado; nunca escreve codigo de produto no lugar da sessao despachada.
+- **Sessao de fase ja despachada:** recebeu thread, fase, prompt e worktree do `ork`.
+  Trabalhe nesse escopo pela skill da fase. Nao abra outra thread nem redespache a propria fase para fazer o trabalho que ja lhe foi atribuido.
 
-## Como rotear
+## Comecar ou retomar
 
-```bash
-ork doctor                                    # o que vale nesta maquina agora
-ork modos                                     # a tabela dos 5 modos de conducao
-ork thread new "<nome>" --mode <modo>         # abre a thread com a #TAG do pedido
-ork phase run <thread> GOAL --prompt "<...>"  # despacha a fase pelo runtime
-ork board                                     # o estado de todas as threads
-ork board plan                                # quem avanca agora, quem espera e por que
-```
+Quando a mensagem for **`orkastery maestro`**, em sessão limpa, descubra `ork_maestro`
+no namespace real do host e consulte o projeto fixado pela instalação. O equivalente
+de leitura no terminal é `ork maestro --json`; a frase conversacional não é um comando shell.
+A consulta não cria demanda, thread, sessão ou aprovação. Projeto ausente retorna
+`maestro.project.missing`; ambíguo retorna `maestro.project.ambiguous`: apresente os
+candidatos permitidos e obtenha a seleção, sem varrer home nem escolher o primeiro.
+Se já recebeu fase/thread/WT, continue esse bloco; a frase não abre outra orquestração.
 
-## A #TAG de conducao
+Apresente o panorama com fontes, lacunas e próximas ações: demandas, threads, sessões,
+impedimentos, leases, retries, HITL, SHIP e MASTER. Vazio difere de indisponível;
+estado nativo desconhecido não prova sessão encerrada. Respeite `coverage.nextOffset`
+para detalhes omitidos. Snapshot é leitura, não autorização; uma ação usa a operação
+tipada existente, revalida precondições e tem readback. Conflito/stale exige nova leitura.
 
-A autonomia se escolhe no pedido, nao em arquivo de configuracao. O adaptador do host extrai a
-primeira #TAG do texto do builder e repassa `--mode` ao `ork`; sem #TAG vale o
-`conduction.default_mode` do manifesto. **A validacao contra `allowed_modes` e do nucleo:** o host
-nao decide se um modo e permitido, ele so transporta a tag.
+**Prioridade máxima: usabilidade HITL.** Na própria conversa, apresente tópicos curtos,
+uma recomendação fundamentada e opções com rótulos claros. Mantenha UUIDs internos e
+preserve resposta literal, texto livre e cancelamento. Só ofereça canal comprovadamente
+disponível para aquele pedido/conexão. Telegram é opcional; falta de ingresso nativo
+no canal escolhido é uma pendência explícita, sem fingir aprovação nem impor migração.
+Mesma-harness exige sessões independentes comprovadas; o executor não revisa a si mesmo.
 
-| #TAG | Pausas humanas | Uso |
+Use o manifesto, o pedido e o estado da thread. Se o dono informou thread/roadmap, retome esse trabalho; so pergunte qual thread quando a ambiguidade impedir uma escolha segura.
+Nao repita onboarding, decisoes ou tarefas que ja estejam registrados.
+
+Prefira MCP no projeto fixado pelo servidor, sem outro root/cwd. No Claude com servidor `orkastery`, use nomes completos expostos, como `mcp__orkastery__ork_thread_status`; em `ToolSearch`, selecione esse nome completo, nunca `select:ork_thread_status`. Em outros hosts, siga o namespace realmente descoberto.
+
+| Acao | Ferramenta MCP | CLI quando a ferramenta nao esta disponivel |
 |---|---|---|
-| `#Look` | 6 | Risco alto, passo irreversivel, dominio novo |
-| `#Ork` | 5 | Veredito separado da execucao e da evidencia |
-| `#Classic` | 3 | O padrao: premissas delicadas, entrega solta, score em batch |
-| `#Maestro` | 1 | Solucao clara e agil, score em batch |
-| `#Auto` | 0 | Docs, estudos, configuracoes, auditorias |
-
-## As regras inviolaveis
-
-1. **Nenhuma fase se pula.** Demanda pequena ganha fase compacta, nunca fase a menos. Uma correcao
-   de uma linha tambem atravessa GOAL, PLAN, GO, CHECK, SHIP e MASTER.
-2. **O modo afrouxa a pausa, NUNCA a verificacao.** Claims, verify, policies e gates tipados rodam
-   identicos em `#Look` e em `#Auto`; o que muda e se o veredito espera o humano.
-3. **A camada que apresenta nunca escreve codigo de produto.** Quem escreve codigo e a orquestra
-   (Camada 3), despachada pelo `ork`. Adaptador que implementa a demanda quebrou a arquitetura.
-4. **O estado mora em disco**, em `.orkastery/threads/<id>/`. Qualquer sessao retoma qualquer
-   thread a partir do disco; conversa nao e estado.
-5. **Gate e decisao humana registrada**, ou decisao autonoma registrada com quem decidiu, com que
-   evidencia e por que. Gate sem registro nao aconteceu.
-6. **Entrega sem MASTER log nao aconteceu.** O score humano de 0 a 5 fecha toda thread, na hora ou
-   na fila de batch dos modos sem pausa de MASTER.
+| Estado/documentos/claims | `ork_thread_status`, `ork_phase_list`, `ork_artifact_read/write`, `ork_claims_list`, `ork_claim_add` | `ork thread status <thread>`, `ork phase list <thread>`, `ork claims` |
+| Demanda nova | `ork_thread_new(nome, modo)` | `ork thread new "<nome>" --mode <modo> --worktree auto` |
+| Despacho | `ork_phase_run(threadId, fase, prompt, runtime?, model?, effort?, dryRun?)` | `ork phase run <thread> GOAL --prompt "<pedido>"` |
+| Progresso nativo | `ork_observe(threadId)` | `ork thread status <thread>` |
+| Pendencia/decisao | `ork_hitl_pending`, `ork_request_decision(threadId, pedidoId)` | Consulte o ingresso suportado; nao fabrique resposta. |
 
-## Racionalizacoes comuns
+Prefira `ork_git_commit` (HEAD atual, paths com claims), `ork_verify` e `ork_ship` (HEADs fonte/destino reais) para registrar, verificar e entregar. Autoria/commit nao e SHIP; retorno incomplete exige reconciliacao antes de repetir. Para demandas novas, use `ork modos --do-pedido "<pedido do dono>"` e `ork_preflight({modo})` (CLI: `ork doctor --modo <modo>`). A sonda por bloco não comprova autenticação, gates ou entrega.
+Sem MCP e com mutacao em `.git` negada pelo sandbox, informe instalacao pendente do transporte nativo; nao repita o comando negado nem amplie o sandbox.
 
-| Desculpa | Realidade |
-|---|---|
-| "E uma correcao minima, GOAL e exagero" | Compacto, nunca ausente: um GOAL de tres paragrafos custa minutos e evita o retrabalho classico de direcao errada. |
-| "Depois eu dou o score da thread anterior" | Entrega sem MASTER log nao aconteceu. Nos modos sem pausa, o score vai para a fila de `ork master --batch`, que continua sendo humana. |
-| "Como e `#Auto`, da para pular o verify" | O modo afrouxa a pausa, nunca a verificacao. Policy `block` e escalacao tipada param `#Auto` igual param `#Look`. |
-| "Eu mesmo escrevo esse trecho, e mais rapido" | A camada que apresenta nao escreve codigo de produto. Velocidade que quebra a trilha de auditoria e divida, nao velocidade. |
-| "A conversa lembra em que fase a thread esta" | Conversa termina. O estado mora em disco e e isso que faz qualquer sessao retomar qualquer thread. |
+O modo de uma thread existente e o registrado nela. Preserve autorizacoes no escopo em que valem; nao solicite confirmacao rotineira para cada tarefa. Numa demanda nova, o nucleo resolve a #TAG, `conduction.default_mode` e `allowed_modes`. Nao refaca esse parse no host. Um bloqueio real do preflight impede o despacho dependente e deve ser explicado.
 
-## Bandeiras vermelhas
+Antes do primeiro despacho, consulte `ork setup <modo>` e o bloco da fase: preserve seu runtime/modelo/esforco. O host da conversa nao impoe o runtime das fases.
+Se o dono pediu outro runtime, use `--runtime R --model M --effort E` com trio coerente ja autorizado; nunca herde modelo de outro runtime nem altere defaults do projeto para um override pontual.
+Se faltar escolha de modelo para esse runtime, obtenha apenas essa informacao. Edite `ork setup <modo> --bloco N` somente quando houver intencao de mudar a configuracao persistente.
+Confira o trio/comando com `ork phase run ... --dry-run` no primeiro despacho ou apos mudanca relevante de configuracao; nao repita esse ensaio a cada status ou etapa sem mudanca.
+Dry-run nao inicia modelo, mas pode gravar prompt/eventos. Confira o trio efetivo no resultado/ledger; doctor nao comprova modelo. O perfil filho `worktree` exige opt-in na instalacao: preserve o configurado, sem habilita-lo por toolargs nem para contornar bloqueio.
+
+## Conducao durante o trabalho
+
+O modo afrouxa a pausa, NUNCA a verificacao. Claims, verify, policies e gates tipados
+rodam identicos em `#Classic` e em `#Auto`; o modo decide se o veredito espera o humano.
+
+Depois de uma acao, use o resultado do nucleo para executar o proximo passo autorizado.
+Em #Auto/#Maestro, nao termine um bloco apenas oferecendo continuar quando ainda ha trabalho
+executavel dentro do modo. Uma pausa exigida pelo modo ou um impedimento real permanece visivel.
+
+Para status, comece pela thread conhecida. Com despacho existente, consulte `ork_observe` para estado nativo, progresso e bloqueio atual.
+`phase list` e historico: nao aguarde conclusao com loops longos, sleeps ou regex sobre sua saida. Uma espera nativa exige contexto real de decisao/impedimento.
+Use `ork_hitl_pending` ou `ork pulse --json` para a fila de atencao e `ork board plan` para a ordem de trabalho. Evite inventario global ou repetido de processos/worktrees.
+Use `ork_git_status`: `source.head` vai em `commit.expectedHead`; reconsulte apos commit para `ship.expectedSource=source.head` e `expectedDestination=destination.head`. Nao derive SHAs da base historica; ausencia de mensagem nao prova morte da sessao.
+
+Os blocos e pausas mostrados por `thread status` descrevem o modo, nao gates ja abertos.
+So diga "aguardando voce" quando o estado e o ultimo resultado em `phase list` sustentarem
+uma pendencia humana atual, identificada por gate, pedido ou evento da thread/sessao.
+Uma thread nova, sem fase executada nem pedido aberto, ainda nao aguarda veredito.
+Se faltar evidencia da pendencia, informe a incerteza e consulte a fonte; nao invente a espera.
 
-- Um diretorio de thread sem `thread.json` ou sem `ledger.jsonl`.
-- Uma skill do catalogo implementando o que o `ork` ja faz, em vez de chamar o comando.
-- Regra de negocio dentro do adaptador de host: validacao de modo, calculo de slug, decisao de gate.
-- Uma entrega mergeada sem relatorio de CHECK, ou uma thread fechada sem MASTER log.
+Apresente o resultado primeiro: o que ja foi comprovado, o que esta acontecendo, quem precisa agir e o proximo passo. Em trabalho demorado, comunique mudanca relevante, bloqueio ou marco.
+Nao prometa notificacoes ou execucao em segundo plano que o host nao consegue sustentar.
 
-## Verificacao antes de sair da skill
+## Decisoes na propria sessao
 
-Manifesto lido, modo da thread conhecido, estado da thread presente em disco, comando `ork` certo
-identificado, e o builder informado em uma linha de em que fase a thread esta e o que acontece
-agora. Ver `DoD 17` e `DoD 20`.
+Quando houver decisao do dono, mostre a pergunta concreta, contexto e consequencias; ofereca opcoes quando ajudarem e identifique thread e pedido/gate.
+Se pausa/escalacao real permitir e faltar pedido, use `ork_gate_request(threadId, motivo?)`; nunca crie pedido por status. Use `ork_request_decision(threadId, pedidoId)` para apresentar o dialogo nativo. A resposta vem pelo host, nunca como argumento de resposta ou identidade humana inventada pelo modelo.
+Confira o resultado do nucleo e prossiga uma vez. Sem a ferramenta, use apenas ingresso suportado; nao fabrique envelope de outro host.
+Nao transforme permissao nativa em aprovacao de gate nem aplique resposta a outro pedido.
+
+Quando o modo permite decisao autonoma, registre quem decidiu, evidencia e motivo pelo nucleo.
+Quando exige decisao humana, use somente a resposta realmente recebida; nao fabrique aprovacao ou score. Autorizacao de uma tarefa nao e autorizacao irrestrita para outras acoes.
+
+## Continuidade e entrega
+
+O estado canonico mora em `.orkastery/threads/<id>/`. Antes de trocar de sessao ou ao encontrar um impedimento, deixe checkpoint com objetivo, decisoes, ultimo resultado, artefatos e proximo passo. Retome o checkpoint e confira o estado atual antes de despachar novamente.
+
+No pedido de despacho, descreva o objetivo e o escopo de todas as fases do bloco autorizado; a fase solicitada e a entrada do bloco. Em Auto, nao peça encerrar apos GOAL: o bloco segue GOAL..MASTER, com as verificacoes e gates aplicaveis.
+
+Quando `ork_observe` mostrar `turno.estado=encerrado`, reconcilie o ultimo resultado oficial e os artefatos do bloco. Isso indica um turno encerrado, nao `phase_result`, fase concluida ou entrega. Os campos nativos `state` e `status` podem divergir; preserve a divergencia em vez de interpretar `working` isoladamente. Atividade posterior invalida a evidencia de turno encerrado. Sem resultado suficiente, registre o ponto pendente e use somente a continuacao suportada pelo nucleo, sem duplicar despacho nem fabricar conclusao. Nao use sleeps longos ou polling repetido para transformar silencio em prova de vida, morte ou progresso.
+
+Despacho nao e conclusao. Testes, CHECK, SHIP e MASTER sao provas diferentes. Entregue mudancas, validacao, publicacao efetiva e pendencias, com links uteis ao dono. SHIP usa `ork ship`; entrega sem nota humana e aceita por omissao com o indice do ledger (`ork master`), e a nota humana sobrescreve. Entrega sem MASTER log nao aconteceu; publicacao e ratificacao continuam distintas.
+## Racionalizacoes comuns
+Despacho, silêncio ou modo Auto nunca substituem resultado, `verify` e recibos.
+## Bandeiras vermelhas
+Adaptador que implementa a demanda, status sem fonte ou publicação sem gate quebram a separação.
+## Verificacao antes de responder
+O dono entende resultado e proxima acao; estado e evidencia sustentam a resposta. Ver `DoD 17` e `DoD 20`.

package/skills/core/thread-state/SKILL.md

@@ -37,7 +37,9 @@ comando. **Editar `thread.json` com editor de texto e corromper estado, nao adia
 ## Como rotear
 
 ```bash
-ork thread list                    # todas as threads do projeto
+ork thread list                    # as threads NAO fechadas (aberta e pausada)
+ork thread list --todas            # todas, inclusive as fechadas
+ork thread list --json             # a mesma listagem como JSON
 ork thread status <thread>         # estado da thread, cruzado com o runtime real
 ork phase list <thread>            # o ledger inteiro, evento a evento
 ork claims list <thread>           # as alegacoes e o estado de cada uma

package/skills/governance/decision-triage/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: decision-triage
-description: "A disciplina de delegacao: classifica cada decisao em classe 1 (humano decide), 2 (contrato publico, exige ratificacao) ou 3 (delegada, registrada), e sobe tradeoff real com opcoes e uma recomendacao. Roteia para ork gate approve."
+description: "A disciplina de delegacao: classifica cada decisao em classe 1 (humano decide), 2 (contrato publico, exige ratificacao) ou 3 (delegada, registrada), e sobe tradeoff real com opcoes e uma recomendacao. Roteia para ork gate request."
 bucket: governance
-roteia: "ork gate approve <thread> <sobre> --por <quem>"
+roteia: "ork gate request <thread>"
 license: MIT
 ---
 
@@ -25,8 +25,8 @@ atras de "detalhe tecnico": ela classifica, registra o que e delegado e sobe o q
 ## Como rotear
 
 ```bash
-ork gate approve <thread> <sobre> --por <quem>   # decisao humana registrada
-ork phase list <thread>                          # a auditoria de delegacao le daqui
+ork gate request <thread>    # abre o pedido; o humano responde pelo canal autenticado
+ork phase list <thread>      # a auditoria de delegacao le daqui
 ```
 
 ## Conduta

package/skills/governance/narrative-guardian/SKILL.md

@@ -25,7 +25,7 @@ nao existe nao vira promessa em README.
 ```bash
 ork verify <thread>        # o que a maquina realmente prova hoje
 ork phase list <thread>    # a origem de cada evidencia citada
-ork master --batch         # o que ja foi fechado e pode ser citado como entregue
+ork master --todas         # o que ja foi fechado e pode ser citado como entregue
 ```
 
 ## As regras do canon

package/skills/governance/roadmap-keeper/SKILL.md

@@ -20,7 +20,7 @@ silencio. **Demanda que vira thread sem estar registrada e trabalho sem dono e s
 ork board                       # o estado de todas as threads
 ork board plan                  # quem avanca agora, quem espera e por que
 ork thread new "<nome>" --mode <modo>
-ork master --batch              # o que fechou e ainda espera score
+ork master                      # as entregas, com o indice derivado do ledger
 ```
 
 ## Conduta

package/skills/governance/scope-check-capability-map/SKILL.md

@@ -2,7 +2,7 @@
 name: scope-check-capability-map
 description: "Fase 0: antes de abrir a thread, confere se a demanda cabe no que o produto e no que a maquina conseguem fazer, e devolve o que falta em vez de comecar trabalho fadado a parar no meio."
 bucket: governance
-roteia: "ork doctor | ork board plan | ork thread new --dry-run"
+roteia: "ork_preflight | ork doctor --modo | ork board plan | ork thread new --dry-run"
 license: MIT
 ---
 
@@ -16,16 +16,25 @@ consumir janela de contexto.
 
 ## Como rotear
 
+Primeiro resolva o modo pelo nucleo. Prefira `ork_preflight({modo})` no MCP do projeto;
+sem essa ferramenta, use o CLI contextual abaixo. O resultado segue o setup canonico por bloco.
+
 ```bash
-ork doctor                                # o que vale nesta maquina agora
+ork doctor --modo <modo>                   # preflight contextual do modo autorizado
 ork board plan                            # capacidade ocupada e capacidade livre
 ork thread new "<nome>" --mode <modo> --dry-run   # ensaio: slug, modo, blocos, sem gravar
 ```
 
+O `ork doctor` sem modo e um diagnostico amplo opcional, com inventario global; nao substitui
+o preflight contextual nem deve competir com ele como rota obrigatoria de despacho.
+
 ## O mapa de capacidade
 
-1. **Capacidade de maquina.** Runtime disponivel, assinatura valida, provider correto. Um `fail` do
-   `ork doctor` para o ciclo antes de ele abrir, e isso e economia, nao obstaculo.
+1. **Capacidade de maquina.** Confira `prontoPrimeiroBloco` e os checks do bloco inicial; falha
+   relevante bloqueia esse despacho. `prontoTodosBlocos` informa dependencias dos blocos futuros:
+   anuncie essas limitacoes sem confundi-las com impedimento do bloco inicial. A sonda nao comprova
+   autenticacao, modelo aceito, gates ou entrega; o despacho revalida esses contratos. VERIFY/SHIP
+   MCP dependem tambem do executor Codex isolado e do transporte de entrega, mesmo com fase Claude.
 2. **Capacidade de paralelismo.** Threads ativas contra `concurrency.max_parallel_threads`, mais os
    leases que ja estao tomados na regiao que a demanda vai tocar.
 3. **Capacidade de produto.** O que a demanda pede existe no produto, ou e capacidade nova. Se e
@@ -43,19 +52,20 @@ cada. Devolver "nao da" sem o que falta e recusa, nao scope check.
 | Desculpa | Realidade |
 |---|---|
 | "Comeco e vejo no caminho o que falta" | Descobrir a falta no GO custa a thread inteira. O scope check custa um comando. |
-| "O doctor esta com um fail, mas nao e desse ponto" | Um `fail` do doctor e a maquina dizendo que o despacho nao vale. Abrir mesmo assim gasta janela para parar no mesmo lugar. |
+| "Ignoro qualquer fail porque escolhi Auto" | Falha relevante no preflight do bloco inicial bloqueia o despacho; Auto nao remove verificacao. Dependencia de bloco futuro deve ser informada como futura. |
 | "Cabe mais uma thread, dou conta" | Quem da conta e a maquina e o humano que aprova gate, e os dois tem teto medido no manifesto. |
 | "A demanda e vaga, o GOAL esclarece" | GOAL esclarece objetivo, nao existencia de capacidade. Demanda que pede o que nao existe volta antes, com o que falta escrito. |
 
 ## Bandeiras vermelhas
 
-- Thread aberta com `ork doctor` em `fail`.
+- Despacho iniciado com `prontoPrimeiroBloco` falso ou falha relevante do bloco inicial.
 - Demanda que pede capacidade inexistente sem isso estar escrito.
 - Regiao de arquivos ja sob lease de outra thread, sem fila prevista.
 - Devolucao sem dizer o que destravaria a demanda.
 
 ## Verificacao antes de abrir a thread
 
-Doctor lido, capacidade de paralelismo conferida, capacidade de produto confirmada ou declarada
+Preflight contextual lido por bloco, dependencias futuras explicadas, capacidade de paralelismo
+conferida, capacidade de produto confirmada ou declarada
 ausente, gates humanos previstos, e ensaio com `--dry-run` mostrando slug, modo e blocos. Ver
 `DoD 17`.

package/skills/observability/thread-tracing/SKILL.md

@@ -22,7 +22,7 @@ ork thread status <thread>    # o estado gravado cruzado com o runtime real
 ork sessions --all            # as sessoes vivas do runtime
 ork claims list <thread>      # as alegacoes e o estado de cada uma
 ork board                     # todas as threads, uma visao
-ork master --batch            # o que fechou e ainda espera score
+ork master                   # as entregas, com o indice derivado do ledger
 ```
 
 ## O que o rastro precisa responder

package/skills/phases/check-quality/SKILL.md

@@ -2,7 +2,7 @@
 name: check-quality
 description: "Fase CHECK (F4): verificacao contra a baseline, os cinco eixos de review, auditoria de seguranca e de performance, auditoria de delegacao e um veredito unico. Roteia para ork verify e para as quatro skills de reviewer."
 bucket: phases
-roteia: "ork verify <thread> | ork gate approve <thread> evidencias"
+roteia: "ork verify <thread> | ork gate request <thread>"
 license: MIT
 ---
 
@@ -20,7 +20,7 @@ corrige o que encontra: correcao e trabalho de GO.
 ork verify <thread>                  # reexecuta claims e verify contra a baseline
 ork phase list <thread>              # o ledger, para a auditoria de delegacao
 ork worktree audit <thread>          # a worktree confere no proprio git
-ork gate approve <thread> evidencias --por <quem>
+ork gate request <thread>            # o pedido da pausa; o humano responde pelo canal autenticado
 ```
 
 Quando o veredito e PRECISA DE MUDANCA, o sub-loop GO-FIX / CHECK-REVERIFY do bloco B3 e

package/skills/phases/goal-definition/SKILL.md

@@ -21,7 +21,7 @@ ork thread new "<nome>" --mode <modo>
 ork phase run <thread> GOAL --prompt "<pedido do builder>"
 ork claims add <thread> <arquivo> --claim "<alegacao>" --verificar "<comando>" --fase GOAL
 ork verify <thread> --so-claims
-ork gate approve <thread> objetivo --por <quem>
+ork gate request <thread>
 ```
 
 ## O que o GOAL entrega

package/skills/phases/master-metrics/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: master-metrics
-description: "Fase MASTER (F6): POSTMORTEM tipado, MASTER log no contrato congelado ork.master-log/v1 e o score humano de 0 a 5 com justificativa. Roteia para ork master e ork master --batch."
+description: "Fase MASTER (F6): POSTMORTEM tipado, MASTER log no contrato congelado ork.master-log/v1 e o score humano de 0 a 5 com justificativa. Roteia para ork master e ork master --aceitar-omissao."
 bucket: phases
-roteia: "ork master <thread> --score N --justificativa \"...\" | ork master --batch"
+roteia: "ork master <thread> --score N --justificativa \"...\" | ork master --aceitar-omissao"
 license: MIT
 ---
 
@@ -19,8 +19,9 @@ cumpre. **Uma entrega sem MASTER log nao aconteceu.**
 ```bash
 ork master classes                            # as classes de falha do catalogo fixo
 ork master <thread> --score 4 --justificativa "<texto>" --classe base-avancou --por <quem>
-ork master --batch                            # a fila de score dos modos sem pausa de MASTER
-ork master --batch --todas
+ork master                                    # as entregas, com o indice derivado do ledger
+ork master --todas                            # inclusive as ja pontuadas
+ork master --aceitar-omissao                  # aceita as entregues, com indice e insumos no ledger
 ```
 
 ## O que o MASTER entrega
@@ -31,7 +32,8 @@ ork master --batch --todas
 2. **MASTER log no contrato `ork.master-log/v1`**, congelado: mudar o contrato sem mudar a versao
    e reprovado, porque contrato de telemetria e contrato publico.
 3. **Score humano inteiro de 0 a 5, com justificativa nao vazia.** O score e do humano, sempre. Nos
-   modos sem pausa de MASTER ele vai para a fila de batch, e a fila continua sendo humana.
+   modos sem pausa de MASTER a entrega e aceita por omissao, com o indice derivado do ledger, que
+   nenhum agente digita; a nota humana, quando vier, sobrescreve.
 4. **Evidencia apontando o ledger e o POSTMORTEM**, com contagem de eventos, sessoes e claims. Log
    sem evidencia e recusado.
 
@@ -50,14 +52,14 @@ grava metade e pior que recusa inteira.
 | "Dou 4,5, ficou entre os dois" | O score e inteiro de 0 a 5. Escala com meio ponto vira negociacao, e o que se mede aqui e conducao, nao simpatia. |
 | "A classe de falha dessa foi 'quase deu certo'" | O catalogo e fixo. Classe inventada e recusada, porque classe livre destroi a comparabilidade entre threads. |
 | "Preencho o MASTER log depois, a entrega ja foi" | Uma entrega sem MASTER log nao aconteceu. Fase de aprendizado adiada e fase de aprendizado que nao existe. |
-| "O modo e `#Auto`, entao o score pode ser automatico" | O score e humano em todos os modos. `#Auto` muda quando ele e dado, para a fila de batch, nunca quem da. |
+| "O modo e `#Auto`, entao o score pode ser automatico" | O score e humano em todos os modos. `#Auto` muda quando ele e dado (a entrega e aceita por omissao e a nota humana sobrescreve), nunca quem da. |
 
 ## Bandeiras vermelhas
 
 - Thread entregue sem `master-log.json`.
 - Score gravado sem nome de quem avaliou.
 - Classe de falha fora do catalogo fixo, ou nenhuma classe numa thread que teve retrabalho.
-- Fila de batch crescendo sem ninguem passar nela.
+- Nota de score digitada por agente em nome do humano.
 
 ## Verificacao antes de sair da fase
 

package/skills/phases/plan-specification/SKILL.md

@@ -19,7 +19,7 @@ tradeoff do humano: ela despacha a fase pelo `ork` e transforma o plano em taref
 ```bash
 ork phase run <thread> PLAN --prompt "<pedido do builder>"
 ork lease acquire "path:<glob>" --thread <thread> --motivo "PLAN reservou a regiao"
-ork gate approve <thread> premissas --por <quem>
+ork gate request <thread>
 ork handoff export <thread> --proxima-fase GO
 ```
 

package/skills/phases/ship-release/SKILL.md

@@ -18,8 +18,8 @@ o push comparando o sha local com o que o remoto reporta**.
 
 ```bash
 ork worktree sync <thread>                  # rebasa quando a base avancou
-ork gate approve <thread> push --por <quem> # autorizacao humana registrada
 ork ship <thread> --para main --dry-run     # ensaio: mostra tudo, nao toca em nada
+# autorizacao humana registrada: vai no proprio ship, com o nome de quem autorizou
 ork ship <thread> --para main --autorizar-push <quem>
 ork phase list <thread>                     # a prova: mergeSha, shaRemoto, pushVerificado
 ```