@orkastery/cli 0.5.3 → 0.6.0

package/adapters/README.md

@@ -42,7 +42,25 @@ nos perfis `coding` e `messaging` (`toolMetadata`): sem isso, no perfil `coding`
 plugin chega ao modelo. `ork_network_status` espera a RM-053 na `main`. `network-roadmap-hosts.test.ts` prova a rota de cada host e o aceite do incidente de 29/09
 pela extensão do OpenClaw com o `ork` real.
 
+## Paridade do conhecimento escrito
+
+O conhecimento escrito ([RM-026](../docs/roadmap/RM-026-workspace-empresarial.md) K7) chega aos quatro hosts pelas
+mesmas quatro tools `ork_conhecimento_*`: tools do MCP no Claude Code e no Codex, tool argv no OpenClaw (só no
+perfil `coding`) e wrapper no Hermes, cada uma uma chamada de `ork conhecimento <consulta> --json`. A descrição
+das tools do OpenClaw e a skill do Hermes dizem a mesma regra: a lacuna tipada é lacuna, nunca resposta.
+`conhecimento-hosts.test.ts` confere os nomes, o schema e a frase e, com o `ork` real, o mesmo JSON nas três
+superfícies.
+
 Usabilidade HITL é prioridade máxima: recomendação, opções claras e canal disponível
 associado ao pedido. MCP local conserva elicitation; Telegram segue disponível
 quando configurado. Ingresso nativo Hermes/Discord e OpenClaw depende de callback
 autenticado e binding privado; terminal Hermes/ACP não está homologado.
+
+## Batida do host e canal (RM-063)
+
+Os dois hosts de canal ganham a mesma segunda linha da fábrica: `bin/ork-vigia-batida.js` numa
+automação de comando do OpenClaw e `bin/ork-vigia-batida.py` no cron do Hermes leem o
+`ork doctor --json` a cada 30 min e avisam o dono quando a batida passou de 30 min, sem chamada de
+modelo. `#OrkRetomar` e `#OrkFabrica` entram pelo mesmo ingresso assinado do pulse nos dois, e o
+`ork onboarding` grava o `pulse-host.json` do host escolhido. `conducao-canal.test.mjs` e
+`conducao_canal_test.py` provam os dois lados com `ork` e host SIMULADOS.

package/adapters/claude-code/.claude-plugin/plugin.json

@@ -20,6 +20,7 @@
     "./skills/phases/goal-definition",
     "./skills/phases/master-metrics",
     "./skills/phases/plan-specification",
+    "./skills/phases/security-remediation",
     "./skills/phases/ship-release",
     "./skills/reviewers/code-reviewer",
     "./skills/reviewers/security-auditor",

package/adapters/claude-code/README.md

@@ -72,11 +72,11 @@ descartável; o recibo traz o sha256 dos arquivos globais antes e depois. Modelo
 | `/ork` | Painel: doctor, board, escalonador, modos, fila de score |
 
 Mais seis subagentes (`ork-goal`, `ork-plan`, `ork-go`, `ork-check`, `ork-ship`, `ork-master`) para
-isolar o contexto de cada fase, e o guard `PreToolUse`.
+isolar o contexto de cada fase, o guard `PreToolUse` e o hook `UserPromptSubmit` da resposta curta do dono.
 
 ## O guard PreToolUse
 
-Um hook, em `Bash`, chamando `hooks/ork-guard.js`. Ele bloqueia seis classes de comando:
+Um hook, em `Bash`, chamando `hooks/ork-guard.js`. Ele bloqueia sete classes de comando:
 
 | Bloqueio | Por que |
 |---|---|
@@ -86,12 +86,44 @@ Um hook, em `Bash`, chamando `hooks/ork-guard.js`. Ele bloqueia seis classes de
 | `git push` | Push na mao nao e provado: a entrega passa por `ork ship` |
 | `git reset --hard`, `git clean -fd`, `git checkout -- .` | Descarte em massa sem rastro |
 | `rm -rf` com alvo amplo ou variavel | Apaga o que ninguem pediu |
+| `ork noctum terminal` e o hook da resposta chamados pela ferramenta | A resposta do dono no terminal vem do hook da sessão dele; o agente que chama esse ingresso se passa pelo dono (RM-057) |
 
 **O guard nao tem regra de negocio.** Ele nao le ledger, nao sabe quem autorizou o que e nao
 conhece thread nenhuma: ele reconhece a forma do comando e manda o agente pelo caminho que o `ork`
 verifica. Comando que comeca com `ork` passa direto, porque quem prova o push e serializa o merge e
-o nucleo. E se o proprio guard quebrar, ele **libera**: um hook que derruba a sessao por bug proprio
-e pior que nenhum hook.
+o nucleo; a exceção é o ingresso da resposta do dono (`ork noctum terminal`), barrado antes dessa
+passagem. E se o proprio guard quebrar, ele **libera**: um hook que derruba a sessao por bug proprio
+e pior que nenhum hook. A barreira do ingresso da resposta é lombada, não prova: quem roda como o
+mesmo usuário do sistema a contorna, e o limite está dito abaixo.
+
+## A resposta curta do dono no terminal (RM-057)
+
+**Desligada.** Desde o GO-FIX 2 da RM-057, o núcleo não grava nada pelo terminal. Numa sessão interativa do
+Claude Code, quando o dono digita a resposta curta a uma pergunta que espera por ele (`sim`, `a` ou
+`<código> a`), o hook `UserPromptSubmit` (`hooks/ork-resposta.js`) leva o evento ao núcleo pelo
+`ork noctum terminal --hook-stdin`, e o núcleo só devolve a recusa `noctum.terminal.desligado`: com alguém
+presente, o dono vê um aviso (`systemMessage`) para responder pelo Telegram, em reply à mensagem da
+pergunta ou com o código e a letra, ou pela janela de confirmação do Claude Code (o diálogo nativo, um
+clique). O prompt segue ao modelo, e nada é gravado nem encaminhado, nem a resposta a um gate. Conversa
+comum nem chama o núcleo, e o prompt que a máquina escreveu (o campo `source` do evento diferente de
+`user`) também não.
+
+**Por que desligada:** o Claude Code instalado (2.1.306) ainda não manda o `source` do evento, e sem ele
+nada do dono gravaria. E o agente da própria sessão do dono, pela ferramenta Bash, troca o shell pelo
+núcleo com `exec`, tira a marca `AI_AGENT` e forja o evento com `source` igual a `user`: a cadeia de
+processos e o guard são lombadas, não prova. Ligado, o ingresso não serviria ao dono e serviria a quem
+forja o evento.
+
+**O que falta para voltar**, numa fatia própria: o Claude Code mandar a origem humana do evento
+(`source`); uma prova de que o evento veio do hook do harness, e não de um processo do mesmo usuário; e,
+para a palavra solta, a pergunta mostrada exigida como a linha que o núcleo monta para ela, ou só o código
+com a letra. O código do ingresso segue no núcleo atrás da chave `TERMINAL_LIGADO`, desligada; só os
+testes a ligam, e o CLI e o hook nunca.
+
+**Limite:** a fronteira é a conta do sistema. No diálogo nativo, qualquer cliente MCP do mesmo usuário que
+declare o formulário passa, sem chave. Para separar o núcleo dos agentes, rode os agentes em outra conta
+ou sandbox. O aviso só aparece depois de reinstalar o plugin (`ork adapter install claude-code`) e do
+`ork` com o `noctum terminal`.
 
 ## Sensores de sessão
 
@@ -151,6 +183,164 @@ Sem `tool_use_id`, cada invocação do hook recebe uma identidade de ocorrência
 do transcript não identifica uma ocorrência; eventos de um novo episódio de permissão
 podem chegar sem alteração do arquivo. Replays com `tool_use_id` continuam idempotentes.
 
+## Mods nas sessões de fase (RM-059)
+
+Mod é plugin de *function hooks* do Claude Code 2.1.287 ou mais novo. Cada mod do Orkastery mora
+em `adapters/claude-code/mods/<mod>/`, com o próprio `.claude-plugin/plugin.json`, e declara o
+papel em `orkastery-mod.json`:
+
+```json
+{"formato":"ork.mod/v1","papeis":["fase"],"claudeCodeMinimo":"2.1.287"}
+```
+
+O papel `dono` roda na sessão de quem conduz; o papel `fase`, nas sessões de fase que o `ork`
+despacha. O `ork adapter install claude-code` copia os mods com o resto do adaptador e grava cada
+arquivo deles no `INSTALADO.json`. No despacho `claude-bg`, cada mod de papel `fase` entra com o
+próprio `--plugin-dir`, logo depois do plugin do Orkastery, quando:
+
+- a pasta instalada do mod tem exatamente os arquivos do recibo, com os mesmos bytes e sem link;
+  os tipos que o próprio Claude Code escreve em `.claude-plugin/types/` (`*.d.ts` e
+  `tsconfig.json`) ficam fora da conta;
+- o `claude --version` atende o `claudeCodeMinimo` do mod e o 2.1.287 da API de mods.
+
+Mod que pede versão mais nova fica fora do comando, e o despacho segue: o núcleo não depende de
+mod. Mod cuja dependência ficou de fora (pela versão, ou por ser só de papel `dono`) também fica.
+Declaração inválida, manifesto fora do recibo ou arquivo a mais na pasta recusa o despacho com
+`runtime.context.installation`, como um byte divergente. Arquivo de mod que saiu do catálogo sai da
+cópia na reinstalação: o `ork adapter install claude-code` tira o que ele mesmo instalou e ninguém
+editou. Arquivo editado ou acrescentado à mão fica, e a recusa diz o caminho para apagar. A dependência (`dependencies` do
+`plugin.json` do mod) entra antes de quem depende; o resto segue o nome. Os mods que foram ficam no
+comando gravado no evento `phase_dispatch` do ledger da thread.
+
+O arquivo comum da raiz de `mods/`, como a lista de autoridade que a ponte lê em `../autoridade.json`
+antes da própria pasta, segue a mesma regra quando há mod de fase no despacho: fora do recibo, link
+ou arquivo especial recusam, e o que saiu do catálogo sai da cópia na reinstalação.
+
+Para tirar um mod das sessões de fase, mude o papel no `orkastery-mod.json` do catálogo, ou tire o
+mod, e rode `ork adapter install claude-code` de novo.
+
+O mod de papel `dono` não vai ao despacho: ele roda na sessão de quem conduz. Num projeto com o
+adaptador instalado, a cópia dele já está em `.claude/plugins/orkastery/mods/<mod>`, com cada
+arquivo registrado no `INSTALADO.json` e os arquivos comuns da raiz de `mods/` ao lado. Nesse
+carregamento ninguém confere os bytes: a conferência contra o recibo roda no despacho, para mod de
+fase. Carregue-a na sessão com:
+
+```bash
+claude --plugin-dir .claude/plugins/orkastery/mods/<mod>
+```
+
+Sem o adaptador local, cada mod tem uma entrada no marketplace próprio do repositório
+(`.claude-plugin/marketplace.json`, gerado por `node core/scripts/gerar-marketplaces.cjs`), que aponta
+para uma cópia gerada em `marketplaces/claude-code/mods/<mod>/`. Instalado pelo marketplace, o plugin
+é só a própria pasta, então o arquivo comum da raiz de `adapters/claude-code/mods/` (a lista de
+autoridade da ponte, por exemplo) vai dentro de cada cópia. A instalação é no escopo do projeto:
+
+```bash
+claude plugin marketplace add orkastery/orkastery
+claude plugin install <mod>@orkastery --scope project
+```
+
+Os dois marketplaces se chamam `orkastery`, e o local, registrado na instalação acima a partir de
+`.claude/plugins/orkastery`, não lista os mods. Não troque um pelo outro num projeto que usa o
+plugin do adaptador: remover um marketplace desinstala os plugins que vieram dele (medido no
+Claude Code 2.1.296), e o plugin do marketplace do repositório não traz o guard `PreToolUse` nem o
+MCP do adaptador.
+
+### Freio de Lote (`ork-freio`)
+
+O primeiro mod de papel `fase`. Na sessão de fase, depois de cada lote de ferramentas, ele:
+
+- acha os arquivos que o lote mexeu: os caminhos de `Edit`, `Write`, `MultiEdit` e `NotebookEdit` e a
+  diferença do `git status` entre um lote e outro, que pega também a edição feita por `Bash`;
+- acha as claims da thread que citam esses arquivos, pelo `arquivo` ou pelo texto do comando, e avisa
+  quando o lote mexeu fora dos `touch_paths` do plano;
+- pede ao núcleo, em segundo plano, a conferência dessas claims com
+  `ork claims conferir <thread> --claims ... --json`, no sandbox do verify, uma rodada por vez;
+- devolve ao modelo, no lote seguinte do laço principal, o que quebrou: o id da claim, o comando e o
+  fim da saída. Lote sem claim afetada passa sem texto, e a linha de status mostra as claims em risco.
+  O lote de um subagente conta os arquivos tocados, mas não leva a entrega nem o aviso.
+
+O Freio nunca roda o comando de uma claim, nunca grava estado de claim e nunca para o laço: quem
+verifica de verdade continua sendo o `ork verify`. Ele lê o papel e a thread pelo `$.ork` da ponte, e
+as claims e o plano pelas ferramentas de leitura `ork_claims_list` e `ork_artifact_read`, nunca do
+disco em `.orkastery/`. Precisa de um `ork` com `ork claims conferir` no `PATH` da sessão; sem ele, ou
+sem o sandbox do verify, avisa uma vez que a conferência está indisponível e segue. Teste que cria
+processo pode reprovar no sandbox e passar no `ork verify`, e o aviso diz isso junto da falha. O
+resultado chega no lote seguinte: se a sessão terminar antes dele, a última conferência fica sem
+entrega. Falha de claim cujo arquivo foi tocado de novo durante a conferência não é entregue, porque
+uma conferência nova já foi pedida. Um `Edit` que falhou também conta como toque e pode pedir uma
+conferência a mais.
+
+### Portão de Tarefas (`ork-portao`)
+
+O segundo mod de papel `fase`. Os portões do quadro agem só na sessão de fase cujo bloco atual tem o GO
+(pelo slug do bloco no retrato do núcleo) e cuja thread tem plano com ao menos uma tarefa `T<n>` que
+serve ao quadro: com `touch_paths` (caminhos entre crases, com barra, ponto ou curinga) e um verify com um
+comando só entre crases, a regra do `ork claims conferir --tarefa`. Plano sem nenhuma tarefa assim não
+ganha portão, para não travar o quadro do GO. Com o portão ligado:
+
+- **criação:** `TaskCreated` recusa a tarefa cujo assunto não traz o id de uma tarefa do plano
+  (`T2.1 ...`), ou cuja tarefa do plano não serve ao quadro. A recusa volta ao modelo com o motivo e as
+  tarefas do plano que servem;
+- **conclusão:** `TaskCompleted` da tarefa registrada na criação, ou da que cita no assunto uma tarefa do
+  plano que serve, pede ao núcleo `ork claims conferir <thread> --tarefa T2.1 --prazo 540 --json`, no
+  sandbox do verify, e só deixa a tarefa fechar com o item aprovado. Reprovação volta com o comando, o
+  código e o fim da saída; sem veredito, recusa tipada, outra condução na thread, conferência que não roda
+  ou falha do próprio Portão também bloqueiam, sempre com a saída: corrigir e concluir de novo, ou devolver
+  a tarefa para `pending` e seguir. A tarefa registrada continua conferida mesmo com o plano ilegível na
+  hora, porque o núcleo lê o plano por conta própria. Uma conferência por vez: a conclusão que chega no
+  meio de outra é recusada na hora. Da terceira reprovação igual em diante, o texto manda deixar a tarefa
+  aberta;
+- **teammate ocioso:** com agent teams no piloto (abaixo), `TeammateIdle` entrega ao teammate a próxima
+  tarefa do plano que serve, não fechou nesta sessão e cuja região está livre: nenhum lease `path:` ativo,
+  de nenhuma thread, cruza os `touch_paths` dela e ela não cruza as tarefas dos outros teammates. Os leases
+  vêm do retrato de todas as threads pela consulta `maestro` da ponte
+  (`ork maestro --json --section leases --offset N`), seguindo o `nextOffset` das páginas que o teto de
+  bytes do retrato corta, até 10 páginas, porque o servidor MCP da sessão de fase só mostra os da própria
+  thread. O Portão não toma nem solta lease: o `ork_git_commit` toma o `path:` de cada arquivo na hora do
+  commit e recusa o commit com qualquer lease no caminho. Quem fica ocioso sem concluir devolve a tarefa,
+  que sai da distribuição automática desta sessão. Sem a lista de leases inteira (seção indisponível,
+  lacuna, retrato em conflito ou mais de 10 páginas), no teto de custo ou sem tarefa livre, o teammate
+  fica ocioso.
+
+O Portão nunca roda o verify por conta própria: quem verifica de verdade continua sendo o `ork verify`.
+Ele lê o papel pelo `$.ork.contexto` da ponte, o estado e o bloco pelo `$.ork.retrato`, os leases pela
+consulta `maestro` da ponte e o plano pelo `ork_artifact_read`, nunca do disco em `.orkastery/`. Teste que
+cria processo pode reprovar no sandbox e passar no `ork verify`, e o bloqueio diz isso.
+
+Agent teams na sessão de fase só rodam no piloto, desligado por padrão. Quem conduz liga no manifesto da
+raiz:
+
+```yaml
+runtime:
+  agent_teams:
+    ligado: true
+    teammates: 2   # teto de teammates vivos, de 1 a 8
+    custo_usd: 10  # teto do custo da sessão, como o /cost soma, até 500
+```
+
+Com a chave ligada, o GO no bloco da fase atual e o Portão entre os mods que vão à sessão, o despacho
+`claude-bg` acrescenta ao `--settings` a variável `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`, os dois tetos
+(`ORK_AGENT_TEAMS_TEAMMATES` e `ORK_AGENT_TEAMS_CUSTO_USD`) e `teammateMode` `in-process`, porque a sessão
+de fundo não tem `tmux`. Teto inválido vira aviso do manifesto e deixa desligado. Em toda sessão de fase,
+com ou sem o portão do quadro, o Portão recusa o nascimento de teammate sem os tetos, no teto de teammates
+vivos ou com o custo da sessão no teto, e no teto de custo não entrega tarefa nova.
+
+Limites conhecidos:
+
+- o quadro do Portão vale para a sessão: numa sessão de GO redespachada, tarefa fechada na anterior pode
+  ser entregue de novo ao teammate, que a encontra pronta no quadro e no git;
+- o líder não recebe aviso quando um teammate devolve uma tarefa; ele a vê aberta no quadro;
+- a conferência do Freio, em segundo plano, e a do Portão, na conclusão, podem rodar ao mesmo tempo na
+  mesma worktree; cada mod só serializa as próprias;
+- os tetos dependem de o Portão carregar de verdade: o despacho decide pelo `--plugin-dir`, e se o mod não
+  registrar na sessão, agent teams fica ligado sem ninguém aplicando os tetos;
+- se o turno for interrompido no meio da conferência, o Claude Code segue sem a resposta do gancho;
+- nome de lease que o retrato redige (caminho absoluto ou texto com cara de segredo) chega irreconhecível e
+  não cruza nenhuma região;
+- o comportamento desses eventos numa sessão `claude --bg` real com agent teams ainda não foi medido; os
+  testes do kit e do núcleo cobrem o mod e o despacho.
+
 ## A #TAG de conducao
 
 O comando `/goal` extrai o modo do proprio pedido, sem reimplementar nada:
@@ -174,7 +364,7 @@ tres e o `--dry-run` mostra o que ele vai fazer sobre cada um.
    (`core/`, `phases/`, `reviewers/`, ...) que este catalogo usa. Por isso `plugin.json` declara os
    caminhos um a um. O teste compara esses caminhos com o catálogo fonte e exige
    `onboarding`, acrescentada por I15. Neste catálogo, `claude plugin details orkastery`
-   deve reportar 28 entradas: 20 skills e 8 comandos (a linha `Skills (28)`). O startup registra
+   deve reportar 29 entradas: 21 skills e 8 comandos (a linha `Skills (29)`). O startup registra
    separadamente skills e comandos. As provas anteriores, com 17 e 18 skills, são históricas.
    Confira também os seis agentes e seis eventos de hooks, sem erros de carregamento.
 

package/adapters/claude-code/agents/ork-check.md

@@ -27,6 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - O modo de conducao afrouxa a PAUSA, nunca a VERIFICACAO.
 - Nada de self-report: toda alegacao vem com o comando que a comprova e a saida real.
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
 - Passo irreversivel (push, merge, delecao) so acontece quando o modo autoriza, e a autorizacao
   fica registrada no ledger.
 - Termine dizendo, em uma linha, em que ponto a thread esta e o que acontece agora.

package/adapters/claude-code/agents/ork-go.md

@@ -27,6 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - O modo de conducao afrouxa a PAUSA, nunca a VERIFICACAO.
 - Nada de self-report: toda alegacao vem com o comando que a comprova e a saida real.
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
 - Passo irreversivel (push, merge, delecao) so acontece quando o modo autoriza, e a autorizacao
   fica registrada no ledger.
 - Termine dizendo, em uma linha, em que ponto a thread esta e o que acontece agora.

package/adapters/claude-code/agents/ork-goal.md

@@ -28,6 +28,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - O modo de conducao afrouxa a PAUSA, nunca a VERIFICACAO.
 - Nada de self-report: toda alegacao vem com o comando que a comprova e a saida real.
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
 - Passo irreversivel (push, merge, delecao) so acontece quando o modo autoriza, e a autorizacao
   fica registrada no ledger.
 - Termine dizendo, em uma linha, em que ponto a thread esta e o que acontece agora.

package/adapters/claude-code/agents/ork-master.md

@@ -29,6 +29,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - O modo de conducao afrouxa a PAUSA, nunca a VERIFICACAO.
 - Nada de self-report: toda alegacao vem com o comando que a comprova e a saida real.
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
 - Passo irreversivel (push, merge, delecao) so acontece quando o modo autoriza, e a autorizacao
   fica registrada no ledger.
 - Termine dizendo, em uma linha, em que ponto a thread esta e o que acontece agora.

package/adapters/claude-code/agents/ork-plan.md

@@ -27,6 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - O modo de conducao afrouxa a PAUSA, nunca a VERIFICACAO.
 - Nada de self-report: toda alegacao vem com o comando que a comprova e a saida real.
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
 - Passo irreversivel (push, merge, delecao) so acontece quando o modo autoriza, e a autorizacao
   fica registrada no ledger.
 - Termine dizendo, em uma linha, em que ponto a thread esta e o que acontece agora.

package/adapters/claude-code/agents/ork-ship.md

@@ -27,6 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - O modo de conducao afrouxa a PAUSA, nunca a VERIFICACAO.
 - Nada de self-report: toda alegacao vem com o comando que a comprova e a saida real.
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
 - Passo irreversivel (push, merge, delecao) so acontece quando o modo autoriza, e a autorizacao
   fica registrada no ledger.
 - Termine dizendo, em uma linha, em que ponto a thread esta e o que acontece agora.

package/adapters/claude-code/hooks/hooks.json

@@ -17,6 +17,7 @@
     "Notification": [{ "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/ork-sensor.js\"", "timeout": 5 }] }],
     "Stop": [{ "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/ork-sensor.js\"", "timeout": 5 }] }],
     "SubagentStop": [{ "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/ork-sensor.js\"", "timeout": 5 }] }],
-    "PostToolUse": [{ "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/ork-sensor.js\"", "timeout": 5 }] }]
+    "PostToolUse": [{ "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/ork-sensor.js\"", "timeout": 5 }] }],
+    "UserPromptSubmit": [{ "hooks": [{ "type": "command", "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/ork-resposta.js\"", "timeout": 10 }] }]
   }
 }

package/adapters/claude-code/hooks/ork-guard.js

@@ -62,11 +62,25 @@ const BLOQUEIOS = [
   },
 ];
 
+/**
+ * RM-057 (resposta curta, D11 da ork-rm057respost): a resposta do dono no terminal vem do hook `UserPromptSubmit` da
+ * sessao dele. Um agente que chama esse ingresso pela ferramenta se passa pelo dono, e por isso esta regra roda ANTES da
+ * passagem livre do `ork`. E lombada, nao prova: quem roda como o mesmo usuario contorna (o limite dito na RM-058), ate
+ * com o subcomando entre aspas. Desde o GO-FIX 2 (D22) o ingresso do terminal esta desligado e nao grava nada.
+ */
+const RESPOSTA_DO_DONO = {
+  nome: 'resposta-do-dono-por-ferramenta',
+  regex: /\bnoctum\s+terminal\b|ork-resposta\.js/,
+  motivo: 'a resposta do dono no terminal vem do hook UserPromptSubmit da sessao dele; o agente que chama esse ingresso se passa pelo dono',
+  caminho: 'mostre a pergunta ao dono e espere a resposta dele no Telegram ou pela janela de confirmacao do host; nunca responda por ele',
+};
+
 function decidir(entrada) {
   const nome = entrada && entrada.tool_name;
   if (nome !== 'Bash') return null;
   const comando = String((entrada.tool_input && entrada.tool_input.command) || '');
   if (comando.trim() === '') return null;
+  if (RESPOSTA_DO_DONO.regex.test(comando)) return RESPOSTA_DO_DONO;
   // Comando do proprio `ork` passa: quem verifica o push provado e o merge serializado e ele.
   if (/^\s*(?:[A-Za-z0-9_]+=\S*\s+)*(?:\S*\/)?ork\s/.test(comando)) return null;
   for (const b of BLOQUEIOS) {
@@ -127,4 +141,4 @@ process.stdin.on('end', () => {
   process.exitCode = codigo;
 });
 
-module.exports = { BLOQUEIOS, decidir };
+module.exports = { BLOQUEIOS, RESPOSTA_DO_DONO, decidir };

package/adapters/claude-code/hooks/ork-resposta.js

@@ -0,0 +1,91 @@
+#!/usr/bin/env node
+'use strict';
+/**
+ * Hook `UserPromptSubmit` do adaptador Claude Code: a resposta curta do dono no terminal (RM-057, ork-rm057respost).
+ *
+ * GO-FIX 2 (D22): o ingresso do terminal esta DESLIGADO no nucleo. Quando o dono digita a resposta curta a uma pergunta
+ * que espera por ele, o nucleo nao grava nada e devolve so a recusa `noctum.terminal.desligado`, que este hook mostra ao
+ * dono (`systemMessage`): responda pelo Telegram (em reply a mensagem da pergunta, ou com o codigo) ou pela janela de
+ * confirmacao do Claude Code (o dialogo nativo). O transporte abaixo continua o mesmo, para quando uma fatia propria
+ * religar o ingresso.
+ *
+ * O dono aprova onde estiver. Numa sessao interativa, ele responde a pergunta do arco #Noctum com "sim", "a" ou
+ * "<codigo> a"; este hook leva o evento ao nucleo (`ork noctum terminal --hook-stdin`) e transporta a decisao dele:
+ *
+ *  - gravada (ou sem efeito, detalhe, ou a pergunta de volta): a frase do nucleo substitui o prompt (`decision: block`),
+ *    e o "sim" nao chega ao modelo;
+ *  - resposta a um gate: o contexto vai ao modelo (`additionalContext`), para o condutor abrir o dialogo nativo;
+ *  - recusa pela origem com alguem presente: um aviso ao dono (`systemMessage`), e o prompt segue ao modelo;
+ *  - o resto: nada, e o prompt segue como sempre.
+ *
+ * Ele NAO tem regra de negocio: nao le ledger, nao conhece pergunta e nao prova nada; quem confere a origem da sessao e o
+ * nucleo. So texto curto de uma linha chama o nucleo. Erro do hook ou do nucleo nunca bloqueia nem quebra a sessao.
+ *
+ * GO-FIX 1 (achado 1): o prompt que a maquina injeta na sessao do dono (a tarefa agendada, a volta do /loop, a mensagem
+ * de canal ou de outra sessao, o SDK) nunca chega ao nucleo: o evento diz quem o escreveu (`source`), e so `user`, o
+ * compositor interativo, passa. Sem o campo (versao do Claude Code que ainda nao o manda), o nucleo recebe o evento,
+ * recusa e diz ao dono por que; ele tambem exige `user`, para quem chamar o nucleo sem este hook.
+ */
+const fs = require('node:fs');
+const path = require('node:path');
+const { spawnSync } = require('node:child_process');
+
+/**
+ * A forma da resposta curta, larga o bastante para o nucleo decidir e estreita o bastante para conversa comum nem chamar o
+ * nucleo: o codigo com a resposta ("NX4K a"), o numero com a letra ("1a") ou uma palavra solta de ate duas palavras e 20
+ * caracteres ("sim", "pode seguir"). Tudo numa linha so, ate 64 caracteres.
+ */
+const TETO_DO_PROMPT = 64;
+const CODIGO_E_RESPOSTA = /^[A-HJKMNP-TV-Z](?=[2-9A-HJKMNP-TV-Z]{0,2}[2-9])[2-9A-HJKMNP-TV-Z]{3}\s+\S/i;
+const NUMERO_E_LETRA = /^[0-9]{1,2}\s*[a-e][.!]?$/i;
+const PALAVRA_SOLTA = /^\S+(?:\s\S+)?$/;
+const TETO_DA_ENTRADA = 1024 * 1024;
+
+function pareceRespostaCurta(t) {
+  if (!t || t.length > TETO_DO_PROMPT || /[\r\n]/.test(t)) return false;
+  return CODIGO_E_RESPOSTA.test(t) || NUMERO_E_LETRA.test(t) || (t.length <= 20 && PALAVRA_SOLTA.test(t));
+}
+
+function lerEntrada() {
+  const buffer = Buffer.alloc(TETO_DA_ENTRADA + 1);
+  let bytes = 0;
+  while (bytes <= TETO_DA_ENTRADA) {
+    const n = fs.readSync(0, buffer, bytes, buffer.length - bytes, null);
+    if (!n) break;
+    bytes += n;
+  }
+  if (bytes > TETO_DA_ENTRADA) return null;
+  return JSON.parse(buffer.subarray(0, bytes).toString('utf8'));
+}
+
+/** O texto que o nucleo montou, com teto: o hook transporta, nunca reescreve. */
+const texto = (v, teto) => (typeof v === 'string' && v.trim() ? v.slice(0, teto) : '');
+
+function executar() {
+  const h = lerEntrada();
+  if (!h || h.hook_event_name !== 'UserPromptSubmit' || typeof h.prompt !== 'string' ||
+      typeof h.cwd !== 'string' || !path.isAbsolute(h.cwd)) return;
+  // O prompt que a maquina escreveu nao e do dono: nao chega ao nucleo, e segue ao modelo como sempre.
+  if (h.source !== undefined && h.source !== 'user') return;
+  if (!pareceRespostaCurta(h.prompt.trim())) return;
+  const r = spawnSync(process.env.ORK_SENSOR_CLI || 'ork', ['noctum', 'terminal', '--hook-stdin'], {
+    cwd: h.cwd, input: JSON.stringify(h), encoding: 'utf8', timeout: 8000, maxBuffer: 256 * 1024, windowsHide: true,
+  });
+  if (r.status !== 0 || typeof r.stdout !== 'string' || !r.stdout.trim()) return;
+  let d;
+  try { d = JSON.parse(r.stdout); } catch { return; }
+  if (!d || d.contrato !== 'ork.noctum-terminal/v1') return;
+  let saida = null;
+  if (['registrada', 'sem-efeito', 'detalhe', 'pergunta'].includes(d.acao) && texto(d.mensagem, 8000)) {
+    saida = { decision: 'block', reason: texto(d.mensagem, 8000) };
+  } else if (d.acao === 'encaminhar' && texto(d.contexto, 2000)) {
+    saida = { hookSpecificOutput: { hookEventName: 'UserPromptSubmit', additionalContext: texto(d.contexto, 2000) } };
+  } else if (d.acao === 'recusada' && d.presenca === true && texto(d.mensagem, 2000)) {
+    saida = { systemMessage: texto(d.mensagem, 2000) };
+  }
+  if (saida) process.stdout.write(JSON.stringify(saida) + '\n');
+}
+
+try { executar(); }
+catch { process.stderr.write('ork resposta: entrada invalida ou nucleo indisponivel; o prompt segue sem mudanca.\n'); }
+process.exitCode = 0;

package/adapters/claude-code/hooks/ork-sensor.js

@@ -5,6 +5,7 @@ const fs = require('node:fs');
 const path = require('node:path');
 const { spawnSync } = require('node:child_process');
 const { createHash, randomUUID } = require('node:crypto');
+const { accountFailure } = require('./quota-signal');
 
 function executar() {
   const limite = 1024 * 1024;
@@ -25,6 +26,15 @@ function executar() {
   if (!tipo) return;
   const payload = { observedAt: new Date().toISOString() };
   if (h.hook_event_name === 'Notification') payload.notificationType = h.notification_type;
+  // RM-037 (CHECK 3 da ork-rm037defeit2): o Stop conta o trabalho que ainda vai acordar a sessão. Com despertar agendado
+  // (CronCreate, ScheduleWakeup, /loop) ou tarefa MCP, o Claude Code mostra a sessão `idle`; só a entrada do Stop separa
+  // a sessão encerrada da que vai voltar a escrever. Runtime sem os campos não manda nada, e o ork não supõe zero.
+  if (h.hook_event_name === 'Stop') {
+    if (Array.isArray(h.background_tasks)) payload.backgroundTasks = h.background_tasks.length;
+    if (Array.isArray(h.session_crons)) payload.sessionCrons = h.session_crons.length;
+  }
+  const falhaDaConta = accountFailure(h);
+  if (falhaDaConta && (tipo === 'notification' || tipo === 'stop')) payload.accountFailure = falhaDaConta;
   // tool_use_id identifica replay da mesma ferramenta. Sem id do protocolo,
   // cada invocação é uma ocorrência; stat do transcript não identifica eventos.
   payload.eventId = typeof h.tool_use_id === 'string'
@@ -47,11 +57,17 @@ function executar() {
       }
     }
   }
-  const r = spawnSync(process.env.ORK_SENSOR_CLI || 'ork',
+  const enviar = (p) => spawnSync(process.env.ORK_SENSOR_CLI || 'ork',
     ['sessions', 'event', '--tipo', tipo, '--sessao', h.session_id], {
-      cwd: h.cwd, input: JSON.stringify(payload), encoding: 'utf8', timeout: 3000,
+      cwd: h.cwd, input: JSON.stringify(p), encoding: 'utf8', timeout: 3000,
       maxBuffer: 32768, windowsHide: true,
     });
+  let r = enviar(payload);
+  // O `ork` de antes das contagens recusa o campo novo antes de gravar qualquer coisa: o Stop vai de novo sem elas, como ia.
+  if (r.status === 1 && /^evento recusado: campo de payload inválido: (?:backgroundTasks|sessionCrons)$/m.test(r.stderr || '')) {
+    const { backgroundTasks: _tarefas, sessionCrons: _despertares, ...semContagens } = payload;
+    r = enviar(semContagens);
+  }
   if (r.status !== 0) {
     // Recusa conhecida não identifica o papel da sessão nem comprova ingestão.
     const semVinculo = r.status === 1 && !r.error && !r.stdout?.trim() &&

package/adapters/claude-code/hooks/quota-signal.js

@@ -0,0 +1,14 @@
+'use strict';
+
+/**
+ * RM-064 T1: reconhece apenas o fato de a conta ter esgotado. O chamador persiste
+ * o código devolvido, nunca os textos que serviram de entrada.
+ */
+function accountFailure(h) {
+  const partes = [h?.message, h?.reason, h?.stop_reason, h?.error?.message, h?.error?.code]
+    .filter((v) => typeof v === 'string').join('\n');
+  return /(?:you(?:'|’)ve hit your (?:weekly|session|individual spend|usage) limit|seu limite de uso foi atingido|usage_limit_(?:exceeded|reached)|insufficient_quota|out of credits|spend (?:cap|limit))/i.test(partes)
+    ? 'runtime.quota-exhausted' : null;
+}
+
+module.exports = { accountFailure };

package/adapters/claude-code/mods/autoridade.json

@@ -0,0 +1,56 @@
+{
+  "formato": "ork.mods-autoridade/v1",
+  "regra": "Nenhum mod aprova gate, permissão, nota do MASTER, push ou tag pelo dono, nem fala como o dono (D5 do plano dos mods, com o nome que o dono deu a ela). A decisão autônoma registrada pelo núcleo não entra nesta lista: está em permitidos.",
+  "leitores": [
+    "core/scripts/checar-mods.cjs",
+    "adapters/claude-code/mods/ork-ponte/hooks/register.ts"
+  ],
+  "ganchosProibidos": [
+    { "id": "elicitation", "evento": "classic.Elicitation", "porque": "responderia o diálogo nativo do MCP no lugar do dono" },
+    { "id": "elicitation-result", "evento": "classic.ElicitationResult", "porque": "trocaria a resposta que o dono deu no diálogo nativo" },
+    { "id": "permission-request", "evento": "classic.PermissionRequest", "porque": "aprovaria permissão pelo dono" },
+    { "id": "ask-user-question", "evento": "ui.render", "componente": "AskUserQuestion", "porque": "redesenharia a pergunta feita ao dono" }
+  ],
+  "decisoesProibidas": [
+    { "id": "tool-check-allow", "evento": "tool.check", "decisao": "allow", "porque": "aprovaria uma chamada de ferramenta pelo dono" }
+  ],
+  "chamadasProibidas": [
+    { "id": "prompt-submit", "chamada": "prompt.submit", "porque": "manda texto como se fosse o dono" },
+    { "id": "session-append-usuario", "chamada": "session.append", "tipo": "user", "porque": "grava linha de usuário que o modelo lê como palavra do dono" }
+  ],
+  "argvProibido": [
+    { "id": "gate-answer", "sequencia": ["gate", "answer"], "porque": "responde gate pelo dono" },
+    { "id": "sessions-answer", "sequencia": ["sessions", "answer"], "porque": "entrega resposta a uma sessão como se fosse do dono" },
+    { "id": "pulse-responder", "sequencia": ["pulse", "responder"], "porque": "responde o resumo pelo dono" },
+    { "id": "master-nota", "sequencia": ["master"], "opcao": "--score", "porque": "dá ou propõe a nota do MASTER" },
+    { "id": "master-batch", "sequencia": ["master", "batch"], "porque": "aceita MASTER em lote pelo dono" },
+    { "id": "master-digest-responder", "sequencia": ["master", "digest", "responder"], "porque": "responde o digest pelo dono" },
+    { "id": "retry-run-por", "sequencia": ["retry", "run"], "opcao": "--por", "porque": "autoriza o retry quando o modo pausa" },
+    { "id": "ship-autorizar-push", "sequencia": ["ship"], "opcao": "--autorizar-push", "porque": "autoriza push pelo dono" },
+    { "id": "git-push", "programa": "git", "subcomando": "push", "porque": "publica sem a prova do núcleo" },
+    { "id": "git-tag", "programa": "git", "subcomando": "tag", "porque": "tag é ato do dono; listar tags sai por outro comando de leitura" },
+    { "id": "gh", "programa": "gh", "porque": "PR, merge e release ficam com o núcleo e o dono" }
+  ],
+  "ambienteProibido": [
+    { "id": "hitl-env", "prefixo": "ORK_HITL_", "porque": "credenciais e verificadores do ingresso humano" }
+  ],
+  "caminhosProibidos": [
+    { "id": "hermes-env", "trecho": ".hermes/.env", "porque": "segredos do canal do dono" }
+  ],
+  "reservadosAPonte": [
+    { "id": "processos", "evento": "process.*", "porque": "a guarda da ponte vigia os processos" },
+    { "id": "ambiente", "evento": "env.*", "porque": "a guarda vigia o ambiente, e o papel da sessão sai dele" },
+    { "id": "arquivos", "evento": "fs.*", "porque": "a guarda vigia leituras, e a lista de autoridade sai do disco" },
+    { "id": "mcp", "evento": "mcp.*", "porque": "o retrato do núcleo sai do MCP" },
+    { "id": "store", "evento": "store.*", "porque": "o registro do que foi mostrado ao dono fica no store da ponte" },
+    { "id": "estado", "evento": "state.*", "porque": "a faixa, os caminhos vigiados e o cache ficam no estado da ponte" },
+    { "id": "ferramentas", "evento": "tool.list", "porque": "o papel dono sai da lista de ferramentas" },
+    { "id": "raiz", "evento": "session.root", "porque": "o papel e a raiz do estado saem da raiz da sessão" },
+    { "id": "registro", "evento": "plugin.register", "porque": "só a ponte confere os mods que carregam" },
+    { "id": "prompt", "evento": "prompt.submit", "porque": "só a ponte decide sobre texto enviado por mod" },
+    { "id": "transcript", "evento": "session.append", "porque": "só a ponte decide sobre linha anexada por mod" }
+  ],
+  "permitidos": [
+    { "id": "decisao-autonoma", "sequencia": ["decisao", "registrar"], "porque": "decisão autônoma registrada pelo núcleo, com critério e evidência, que vai ao dono no lote seguinte com o custo de reverter (M4)" }
+  ]
+}

package/adapters/claude-code/mods/ork-clima/.claude-plugin/plugin.json

@@ -0,0 +1,14 @@
+{
+  "name": "ork-clima",
+  "version": "0.1.0",
+  "description": "Clima de Cota do Orkastery no Claude Code: prevê quando a cota da conta acaba no ritmo atual, avisa na faixa antes de a fase morrer no meio e diz qual retomada não cabe. Só lê e avisa.",
+  "author": {
+    "name": "Orkastery contributors",
+    "url": "https://github.com/orkastery"
+  },
+  "homepage": "https://orkastery.com/",
+  "repository": "https://github.com/orkastery/orkastery",
+  "license": "MIT",
+  "types": "./types/index.d.ts",
+  "dependencies": ["ork-ponte"]
+}