@orkastery/cli 0.6.1 → 0.6.3

package/adapters/claude-code/README.md

@@ -144,7 +144,7 @@ resultado contém o SHA do HEAD confirmado no Git. O comando recebido nunca é e
 
 Teste de integração isolado: `npm --prefix core run build && npm --prefix core run build:test && node --test core/dist-test/test/claude-sensors.test.js`.
 
-O canário `node core/dist/index.js eval --so-canarios --canario fx-sensores-runtime`
+O cenário `node core/dist/index.js eval --so-cenarios --cenario fx-sensores-runtime`
 integra hook, CLI, supervisor e watcher em um repositório temporário. Seus eventos Codex
 são sintéticos; a saída identifica esse limite e mede ingestão, morte e duplicatas.
 

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

@@ -27,7 +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.
+- 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; prefira `ork_verify` assíncrono e consulte `ork_verify_status` a cada 30–60 s; sem essa ferramenta, 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,7 +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.
+- 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; prefira `ork_verify` assíncrono e consulte `ork_verify_status` a cada 30–60 s; sem essa ferramenta, 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,7 +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.
+- 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; prefira `ork_verify` assíncrono e consulte `ork_verify_status` a cada 30–60 s; sem essa ferramenta, 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,7 +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.
+- 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; prefira `ork_verify` assíncrono e consulte `ork_verify_status` a cada 30–60 s; sem essa ferramenta, 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,7 +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.
+- 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; prefira `ork_verify` assíncrono e consulte `ork_verify_status` a cada 30–60 s; sem essa ferramenta, 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,7 +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.
+- 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; prefira `ork_verify` assíncrono e consulte `ork_verify_status` a cada 30–60 s; sem essa ferramenta, 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/commands/ork.md

@@ -1,7 +1,7 @@
 ---
 description: Reconhece orkastery maestro e conduz pedidos, retomadas e status na conversa com o Maestro/Builder.
 argument-hint: "[pedido em linguagem natural|thread|status|board|plan|doctor|modos]"
-allowed-tools: Bash(ork:*), Read, mcp__orkastery__ork_thread_status, mcp__orkastery__ork_phase_list, mcp__orkastery__ork_hitl_pending, mcp__orkastery__ork_observe, mcp__orkastery__ork_artifact_read, mcp__orkastery__ork_claims_list, mcp__orkastery__ork_git_status, mcp__orkastery__ork_thread_new, mcp__orkastery__ork_phase_run, mcp__orkastery__ork_preflight
+allowed-tools: Bash(ork:*), Read, mcp__orkastery__ork_thread_status, mcp__orkastery__ork_phase_list, mcp__orkastery__ork_hitl_pending, mcp__orkastery__ork_observe, mcp__orkastery__ork_artifact_read, mcp__orkastery__ork_claims_list, mcp__orkastery__ork_verify_status, mcp__orkastery__ork_git_status, mcp__orkastery__ork_thread_new, mcp__orkastery__ork_phase_run, mcp__orkastery__ork_preflight
 ---
 
 # /orkastery:ork

package/adapters/claude-code/mods/ork-torre/hooks/frases.ts

@@ -7,6 +7,8 @@ export const FRASE_DO_MOTIVO: Readonly<Record<string, string>> = {
   'artifact.missing': 'falta um artefato que a fase exige',
   'claims.failed': 'uma claim reprovou no HEAD',
   'claims.unverifiable': 'há claim sem comando de verificação',
+  'concurrency.lease-indeterminado': 'não foi possível provar se a vaga está livre',
+  'conducao.acao-necessaria': 'a condução precisa executar uma ação',
   'policy.violation': 'uma policy de bloqueio foi violada',
   'runtime.autoconferencia': 'o CHECK caiu no mesmo runtime do GO',
   'verify.regression': 'um teste que passava na baseline caiu',

package/adapters/codex/skills/ork/SKILL.md

@@ -44,7 +44,7 @@ O dono conversa sobre o objetivo; voce opera o nucleo `ork` e apresenta o result
 passo. Preserve o modo e as autorizacoes da thread. Se ja recebeu uma fase do Orkastery,
 execute essa fase no escopo recebido, sem redespachar a si mesmo.
 
-- 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.
+- 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; prefira `ork_verify` assíncrono e consulte `ork_verify_status` a cada 30–60 s; sem essa ferramenta, 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.
 
 Quando descobertas, prefira as ferramentas MCP vinculadas ao projeto pelo servidor:
 `ork_thread_status`, `ork_phase_list`, `ork_hitl_pending`, `ork_thread_new(nome, modo)`,

package/adapters/hermes/README.md

@@ -176,7 +176,7 @@ Verificação: `python3 -m unittest discover -s adapters/hermes/test -p conducao
 
 O gateway autenticado entrega o update original por stdin a `bin/ork-hitl-answer.py ork_gate_answer <thread> <pedido>` ou `ork_session_answer`. Configure `ORK_BIN`, `ORK_HITL_TELEGRAM_USERS` e `ORK_HITL_TELEGRAM_CHATS` com os ids permitidos. Responda ao alerta que contém a linha `ork-hitl <thread> <pedido>`; botões usam `ork:<thread>:<pedido>:<número>`. O transporte recusa bots, chat/usuário não autorizado e resposta sem correlação. O núcleo decide sobre prazo, modo e validade do pedido.
 
-O script deve receber eventos diretamente do gateway, cuja autenticação do Telegram é a fronteira de confiança. JSON criado por um agente não é evidência humana. O canário usa um transporte controlado; ele não mede a rede Telegram real. Para aposentar `ork-watchdog-5min`, desative o job no agendador do host e guarde o recibo; nenhum watchdog deve chamar aprovação em nome do builder.
+O script deve receber eventos diretamente do gateway, cuja autenticação do Telegram é a fronteira de confiança. JSON criado por um agente não é evidência humana. O cenário usa um transporte controlado; ele não mede a rede Telegram real. Para aposentar `ork-watchdog-5min`, desative o job no agendador do host e guarde o recibo; nenhum watchdog deve chamar aprovação em nome do builder.
 
 Verificação: `python3 -m unittest discover -s adapters/hermes/test -p hitl_answer_test.py -v`.
 

package/adapters/openclaw/openclaw.plugin.json

@@ -2,7 +2,7 @@
   "id": "orkastery",
   "name": "Orkastery",
   "description": "Conducao de looping threads em 6 fases pelo nucleo `ork`, exposta ao OpenClaw como tools `ork_*`. Zero regra de negocio no host: cada tool e uma chamada de CLI. Toda tool de projeto aceita projeto (nome do projeto pedido); o cwd do gateway nunca escolhe o projeto. O status do roadmap vem de ork_network_roadmap; as maquinas da pessoa, de ork_network_status (sem projeto).",
-  "version": "0.6.1",
+  "version": "0.6.3",
   "configSchema": {
     "type": "object",
     "properties": {},

package/adapters/openclaw/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@orkastery/openclaw-plugin",
-  "version": "0.6.1",
+  "version": "0.6.3",
   "description": "Plugin Orkastery para OpenClaw: 32 tools ork_* que traduzem intencao em chamada de CLI do nucleo `ork`. Zero regra de negocio no host.",
   "type": "module",
   "private": true,

package/assets/adapters-en/claude-code/README.md

@@ -144,7 +144,7 @@ result contains the HEAD SHA confirmed in Git. The received command is never exe
 
 Isolated integration test: `npm --prefix core run build && npm --prefix core run build:test && node --test core/dist-test/test/claude-sensors.test.js`.
 
-The canary `node core/dist/index.js eval --so-canarios --canario fx-sensores-runtime`
+The scenario `node core/dist/index.js eval --so-cenarios --cenario fx-sensores-runtime`
 integrates hook, CLI, supervisor and watcher in a temporary repository. Its Codex events
 are synthetic; the output states that limit and measures ingestion, death and duplicates.
 

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

@@ -27,7 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - The conduction mode loosens the PAUSE, never the VERIFICATION.
 - No self-report: every statement comes with the command that proves it and the real output.
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 - An irreversible step (push, merge, deletion) only happens when the mode authorizes it, and the authorization
   is recorded in the ledger.
 - End by saying, in one line, where the thread stands and what happens now.

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

@@ -27,7 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - The conduction mode loosens the PAUSE, never the VERIFICATION.
 - No self-report: every statement comes with the command that proves it and the real output.
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 - An irreversible step (push, merge, deletion) only happens when the mode authorizes it, and the authorization
   is recorded in the ledger.
 - End by saying, in one line, where the thread stands and what happens now.

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

@@ -28,7 +28,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - The conduction mode loosens the PAUSE, never the VERIFICATION.
 - No self-report: every statement comes with the command that proves it and the real output.
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 - An irreversible step (push, merge, deletion) only happens when the mode authorizes it, and the authorization
   is recorded in the ledger.
 - End by saying, in one line, where the thread stands and what happens now.

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

@@ -29,7 +29,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - The conduction mode loosens the PAUSE, never the VERIFICATION.
 - No self-report: every statement comes with the command that proves it and the real output.
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 - An irreversible step (push, merge, deletion) only happens when the mode authorizes it, and the authorization
   is recorded in the ledger.
 - End by saying, in one line, where the thread stands and what happens now.

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

@@ -27,7 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - The conduction mode loosens the PAUSE, never the VERIFICATION.
 - No self-report: every statement comes with the command that proves it and the real output.
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 - An irreversible step (push, merge, deletion) only happens when the mode authorizes it, and the authorization
   is recorded in the ledger.
 - End by saying, in one line, where the thread stands and what happens now.

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

@@ -27,7 +27,7 @@ ork phase list <thread>        # o que ja aconteceu, com evidencia
 
 - The conduction mode loosens the PAUSE, never the VERIFICATION.
 - No self-report: every statement comes with the command that proves it and the real output.
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 - An irreversible step (push, merge, deletion) only happens when the mode authorizes it, and the authorization
   is recorded in the ledger.
 - End by saying, in one line, where the thread stands and what happens now.

package/assets/adapters-en/claude-code/commands/ork.md

@@ -1,7 +1,7 @@
 ---
 description: Recognizes orkastery maestro and conducts requests, resumptions and status in the conversation with the Maestro/Builder.
 argument-hint: "[natural-language request|thread|status|board|plan|doctor|modos]"
-allowed-tools: Bash(ork:*), Read, mcp__orkastery__ork_thread_status, mcp__orkastery__ork_phase_list, mcp__orkastery__ork_hitl_pending, mcp__orkastery__ork_observe, mcp__orkastery__ork_artifact_read, mcp__orkastery__ork_claims_list, mcp__orkastery__ork_git_status, mcp__orkastery__ork_thread_new, mcp__orkastery__ork_phase_run, mcp__orkastery__ork_preflight
+allowed-tools: Bash(ork:*), Read, mcp__orkastery__ork_thread_status, mcp__orkastery__ork_phase_list, mcp__orkastery__ork_hitl_pending, mcp__orkastery__ork_observe, mcp__orkastery__ork_artifact_read, mcp__orkastery__ork_claims_list, mcp__orkastery__ork_verify_status, mcp__orkastery__ork_git_status, mcp__orkastery__ork_thread_new, mcp__orkastery__ork_phase_run, mcp__orkastery__ork_preflight
 ---
 
 # /orkastery:ork

package/assets/adapters-en/codex/skills/ork/SKILL.md

@@ -44,7 +44,7 @@ The owner talks about the goal; you operate the `ork` core and present the resul
 step. Preserve the thread's mode and authorizations. If you already received an Orkastery phase,
 run that phase within the received scope, without redispatching yourself.
 
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 
 When discovered, prefer the MCP tools bound to the project by the server:
 `ork_thread_status`, `ork_phase_list`, `ork_hitl_pending`, `ork_thread_new(nome, modo)`,

package/assets/adapters-en/hermes/README.md

@@ -176,7 +176,7 @@ Verification: `python3 -m unittest discover -s adapters/hermes/test -p conducao_
 
 The authenticated gateway delivers the original update over stdin to `bin/ork-hitl-answer.py ork_gate_answer <thread> <pedido>` or `ork_session_answer`. Set `ORK_BIN`, `ORK_HITL_TELEGRAM_USERS` and `ORK_HITL_TELEGRAM_CHATS` to the allowed ids. Reply to the alert that contains the line `ork-hitl <thread> <pedido>`; buttons use `ork:<thread>:<pedido>:<número>`. The transport refuses bots, an unauthorized chat/user and an answer without correlation. The core decides on the deadline, the mode and the validity of the request.
 
-The script must receive events directly from the gateway, whose Telegram authentication is the trust boundary. JSON created by an agent is not human evidence. The canary uses a controlled transport; it does not measure the real Telegram network. To retire `ork-watchdog-5min`, disable the job in the host scheduler and keep the receipt; no watchdog may call an approval on the builder's behalf.
+The script must receive events directly from the gateway, whose Telegram authentication is the trust boundary. JSON created by an agent is not human evidence. The scenario uses a controlled transport; it does not measure the real Telegram network. To retire `ork-watchdog-5min`, disable the job in the host scheduler and keep the receipt; no watchdog may call an approval on the builder's behalf.
 
 Verification: `python3 -m unittest discover -s adapters/hermes/test -p hitl_answer_test.py -v`.
 

package/assets/docs/padroes/roadmap-de-produto.md

@@ -56,7 +56,7 @@ Não use um único campo para ocultar diferenças entre plano, código e entrega
 | Código | `Não iniciado`, `Branch criada`, `PR aberto`, `Mesclado` | Repositório, branch/PR e commit. |
 | Testes | `Não iniciados`, `Em execução`, `Aprovados`, `Falhando` | Execução e data; cobertura, se relevante. |
 | Deploy | `Não implantado`, `Dev`, `Staging`, `Produção` | Pipeline, release e data efetiva. |
-| Exposição | `Flag desligada`, `Piloto/Canary`, `Parcial`, `Geral` | Configuração por ambiente/coorte e verificação. |
+| Exposição | `Flag desligada`, `Piloto/Gradual`, `Parcial`, `Geral` | Configuração por ambiente/coorte e verificação. |
 | Habilitação | `Pendente`, `Em andamento`, `Concluída` | Comunicação, treinamento ou material publicado. |
 
 `Bloqueado` exige motivo, dependência, responsável e próxima revisão. `Concluído` exige critérios de aceite cumpridos, evidência de disponibilidade e registro de medição inicial ou plano de avaliação pós-lançamento. O status não deve ser atualizado por mera passagem do tempo.

package/assets/docs-en/padroes/roadmap-de-produto.md

@@ -58,7 +58,7 @@ Do not use a single field to hide differences between plan, code and delivery. U
 | Code | `Não iniciado` (not started), `Branch criada` (branch created), `PR aberto` (PR open), `Mesclado` (merged) | Repository, branch/PR and commit. |
 | Tests | `Não iniciados` (not started), `Em execução` (running), `Aprovados` (passing), `Falhando` (failing) | Run and date; coverage, if relevant. |
 | Deploy | `Não implantado` (not deployed), `Dev`, `Staging`, `Produção` (production) | Pipeline, release and actual date. |
-| Exposure | `Flag desligada` (flag off), `Piloto/Canary` (pilot/canary), `Parcial` (partial), `Geral` (general) | Configuration per environment/cohort and verification. |
+| Exposure | `Flag desligada` (flag off), `Piloto/Gradual` (pilot/gradual), `Parcial` (partial), `Geral` (general) | Configuration per environment/cohort and verification. |
 | Enablement | `Pendente` (pending), `Em andamento` (in progress), `Concluída` (done) | Communication, training or published material. |
 
 `Bloqueado` requires a reason, a dependency, an owner and a next review. `Concluído` requires met acceptance criteria, evidence of availability and a record of the initial measurement or a post-launch evaluation plan. Status must not be updated merely because time has passed.

package/assets/orkmind_fixture.py

@@ -4,6 +4,7 @@ import os
 from pathlib import Path
 import re
 import stat
+import tempfile
 import time
 
 
@@ -11,8 +12,10 @@ def receipt_file(filename):
     try:
         path = Path(filename)
         root = path.parent
+        temp_root = Path(tempfile.gettempdir()).resolve()
         if (not path.is_absolute() or not re.fullmatch(r'receipt(?:-[a-f0-9]+)?\.json', path.name)
-                or not re.fullmatch(r'/tmp/ork-prospective-fixture-[a-zA-Z0-9-]+', str(root))
+                or root.parent != temp_root
+                or not re.fullmatch(r'ork-prospective-fixture-[a-zA-Z0-9-]+', root.name)
                 or root.resolve() != root or root.is_symlink()):
             raise ValueError()
         st = root.stat()

package/assets/references-en/testing-patterns.md

@@ -33,7 +33,7 @@ flowchart LR
 | 6 | The suite runs on the real HEAD, in the thread's working directory. A pass reported by an agent is not a pass. | `ork verify <thread>` re-runs the manifest commands and the claims, and stamps the real commit. |
 | 7 | No test was disabled, marked to skip or loosened to close the delivery. Skipping a test is a recorded scope change, never a silent course correction. | Diff over the test files, looking for removed tests, `skip` and relaxed assertions. |
 | 8 | No assertion was swapped for the value the code produces today without someone saying why the right value changed. Adjusting the expected to the observed is the most common way to turn a defect into a contract. | Diff of the assertions against the intent declared in the PLAN. |
-| 9 | A test does not depend on the network, on a paid credential or on the wall clock. A deterministic fixture is the standard; whatever needs the outside world stays out of the gate and is declared. | Run the suite offline. In `ork`, the `ork eval` canaries build a temporary git repository and do not touch the network. |
+| 9 | A test does not depend on the network, on a paid credential or on the wall clock. A deterministic fixture is the standard; whatever needs the outside world stays out of the gate and is declared. | Run the suite offline. In `ork`, the `ork eval` scenarios build a temporary git repository and do not touch the network. |
 | 10 | A test does not depend on another test or on the execution order. State shared between cases is a defect, even when the suite is green today. | Run the suspect case in shuffled order or in isolation. |
 
 ## Count and coverage

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

@@ -21,7 +21,7 @@ Distinguish the context before acting:
 - **Conductor session:** receives the owner's request, identifies or opens the thread, dispatches through `ork` and tracks the result; never writes product code in place of the dispatched session.
 - **Already dispatched phase session:** has received the thread, phase, prompt and worktree from `ork`.
   Work within that scope through the phase skill. Do not open another thread or redispatch your own phase to do the work already assigned to you.
-  - Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+  - Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 
 ## Start or resume
 

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

@@ -23,7 +23,7 @@ ork worktree audit <thread>          # a worktree confere no proprio git
 ork gate request <thread>            # o pedido da pausa; o humano responde pelo canal autenticado
 ```
 
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 
 When the verdict is PRECISA DE MUDANCA, the GO-FIX / CHECK-REVERIFY sub-loop of block B3 is
 what conducts the way back, and it does not depend on a human until the final verdict:

package/assets/skills-en/phases/go-implementation/SKILL.md

@@ -24,7 +24,7 @@ ork claims add <thread> <arquivo> --claim "<...>" --verificar "<comando>" --fase
 ork verify <thread>                           # reexecuta no HEAD real
 ```
 
-- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
+- Waits: never start verify, build or the suite with `&` inside the command, because the process gets lost and the session waits for a notice that never comes; prefer asynchronous `ork_verify` and query `ork_verify_status` every 30–60 s; without it, run `ork verify` in the foreground, with `timeout` (it waits its turn in the heavy-resource queue), or use the host's background execution, which tells you when it finishes; never wait with `pgrep -f` whose pattern shows up in the command itself, because the loop finds itself and never ends: wait for the output file with a deadline, or for the saved PID.
 
 ## What GO delivers
 

package/dist/adapters/claude-bg.js

@@ -111,11 +111,13 @@ exports.CONSULTAS_MCP = [
     'mcp__orkastery__ork_observe',
     'mcp__orkastery__ork_artifact_read',
     'mcp__orkastery__ork_claims_list',
+    'mcp__orkastery__ork_verify_status',
 ];
 // RM-037 (defeito 1): a decisao autonoma pelo MCP tem o mesmo grant nos dois runtimes.
 exports.MUTACOES_WORKTREE = [
     'mcp__orkastery__ork_artifact_write', 'mcp__orkastery__ork_claim_add', 'mcp__orkastery__ork_decision_record',
-    'mcp__orkastery__ork_git_commit', 'mcp__orkastery__ork_verify', 'mcp__orkastery__ork_ship',
+    'mcp__orkastery__ork_request_conduction', 'mcp__orkastery__ork_git_commit', 'mcp__orkastery__ork_verify',
+    'mcp__orkastery__ork_ship',
 ];
 /**
  * RM-031 KG5 (D7): as consultas do grafo, de leitura, so com a flag do manifesto da raiz; sem ela, nada muda.

package/dist/adapters/grok-mcp-servidor.js

@@ -37,6 +37,7 @@ exports.LIMITE_DE_RECUSAS_NO_LOG = exports.INTERVALO_DA_VIGIA_MS = exports.PRAZO
 exports.validarPedidoServidorGrok = validarPedidoServidorGrok;
 exports.recusaDaRequisicao = recusaDaRequisicao;
 exports.conferirArvore = conferirArvore;
+exports.motivoDeEncerramentoDoGrok = motivoDeEncerramentoDoGrok;
 exports.servirGrok = servirGrok;
 /**
  * RM-067 (F4c, thread ork-rm067f4cmcpd): o servidor MCP do `ork` da sessão filha do `grok`, num processo do `ork`, fora do
@@ -311,6 +312,21 @@ function lerCorpo(req, limite) {
 function existe(arquivo) {
     return fs.lstatSync(arquivo, { throwIfNoEntry: false }) !== undefined;
 }
+/**
+ * O evento terminal que a vigia ja pode afirmar. O recibo do `close` sempre vence; a ausencia do filho so e terminal
+ * depois que o supervisor tambem saiu, pois ele grava esse recibo entre os dois acontecimentos.
+ */
+function motivoDeEncerramentoDoGrok(logPath, inicio, prazoDaPartida, agora = Date.now()) {
+    if (existe(`${logPath}.exit.json`))
+        return 'recibo';
+    const processo = (0, grok_mcp_1.lerJsonPequeno)(`${logPath}.process.json`);
+    if (!processo)
+        return agora - inicio > prazoDaPartida ? 'sem-partida' : null;
+    if ((!processo.filho || (0, codex_runner_1.estadoProcesso)(processo.filho) === 'ausente') &&
+        (0, codex_runner_1.estadoProcesso)(processo.supervisor) === 'ausente')
+        return 'grok-ausente';
+    return null;
+}
 /** Roda um passo do fecho sem deixar a exceção dele impedir os seguintes. */
 function semFalhar(passo) {
     try {
@@ -554,18 +570,12 @@ async function servirGrok(pedido, token) {
         terminar();
     };
     const vigiar = () => {
-        if (existe(`${pedido.logPath}.exit.json`)) {
-            fechar('recibo');
-            return;
-        }
-        const processo = (0, grok_mcp_1.lerJsonPequeno)(`${pedido.logPath}.process.json`);
-        if (!processo) {
-            if (Date.now() - inicio > prazoDaPartida)
-                fechar('sem-partida');
-            return;
-        }
-        if (!processo.filho || (0, codex_runner_1.estadoProcesso)(processo.filho) === 'ausente')
-            fechar('grok-ausente');
+        // O `close` real do filho ocorre depois que ele ja aparece ausente e, dentro dele, o supervisor grava o recibo
+        // atomicamente antes de sair. Enquanto o supervisor vive, a ausencia do filho e so essa janela: o evento certo ainda
+        // e o recibo. `grok-ausente` fica para a queda do supervisor sem recibo, comprovada pela ausencia dos dois processos.
+        const motivo = motivoDeEncerramentoDoGrok(pedido.logPath, inicio, prazoDaPartida);
+        if (motivo)
+            fechar(motivo);
     };
     const vigia = setInterval(vigiar, exports.INTERVALO_DA_VIGIA_MS);
     return { porta, url, fechar, fechado };

package/dist/adapters/grok.js

@@ -132,7 +132,7 @@ const PREFIXO_DO_CLAUDE = 'mcp__orkastery__';
 /**
  * RM-067 (F4b, G2 e D1): as ferramentas do MCP do `ork` que um despacho do `grok` libera, as mesmas do `--allowedTools` do
  * `claude-bg` no mesmo caso, sem o prefixo: no PLAN que fecha o bloco, as consultas, `ork_artifact_write` e
- * `ork_decision_record`, em qualquer perfil; fora dele, as consultas e, no perfil `worktree`, `ork_git_status` e as seis
+ * `ork_decision_record`, em qualquer perfil; fora dele, as consultas e, no perfil `worktree`, `ork_git_status` e as sete
  * mutações. As consultas do grafo entram com a flag do manifesto da raiz. Montada na chamada, como no `claude-bg`: no
  * ciclo de imports, o valor importado pode ainda não existir quando este módulo carrega.
  */

package/dist/agendador-cpu.js

@@ -1,6 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.JANELA_DA_SONDA_MS = exports.LIMIAR_STEAL_DO_AGENDADOR_PCT = exports.RESERVA_DO_GRUPO = exports.ENV_CPUS_DOCKER = exports.ENV_CPUS_DA_LANE = void 0;
+exports.JANELA_DA_SONDA_MS = exports.LIMIAR_STEAL_DO_AGENDADOR_PCT = exports.RESERVA_DO_GRUPO = exports.ENV_CPUS_DOCKER = exports.ENV_SINAL_DA_RESERVA = exports.ENV_CPUS_DA_LANE_APOS_RESERVA = exports.ENV_CPUS_DA_LANE = void 0;
 exports.cargaDoProcLoadavg = cargaDoProcLoadavg;
 exports.medirCpuDoGrupo = medirCpuDoGrupo;
 exports.planejarCpuDoGrupo = planejarCpuDoGrupo;
@@ -16,6 +16,8 @@ exports.paredeAgileSimulada = paredeAgileSimulada;
 const node_fs_1 = require("node:fs");
 const steal_1 = require("./steal");
 exports.ENV_CPUS_DA_LANE = 'ORK_CHECK_CPUS_DA_LANE';
+exports.ENV_CPUS_DA_LANE_APOS_RESERVA = 'ORK_CHECK_CPUS_DA_LANE_APOS_RESERVA';
+exports.ENV_SINAL_DA_RESERVA = 'ORK_CHECK_RESERVA_DEVOLVIDA';
 exports.ENV_CPUS_DOCKER = 'ORK_CHECK_CPUS_DOCKER';
 exports.RESERVA_DO_GRUPO = 2;
 exports.LIMIAR_STEAL_DO_AGENDADOR_PCT = 10;
@@ -72,6 +74,7 @@ function planejarCpuDoGrupo(cpusInformadas, medicao) {
         saturado,
         motivo: motivos.join('; ') || `carga e steal abaixo dos limiares; ${fatia} CPU(s) reservadas ao grupo`,
         cpusHermetica: saturado ? classic : Math.max(1, cpus - fatia),
+        cpusHermeticaAposReserva: saturado ? classic : cpus,
         cpusIntegracao: ferramentas,
         cpusDaFatia: fatia,
         ferramentasDaVarredura: ferramentas,
@@ -88,5 +91,10 @@ function paredeAgileSimulada(plano, trabalho) {
         return trabalho.hermetica / plano.cpusHermetica + trabalho.varredura / plano.cpusDaFatia
             + trabalho.integracao / plano.cpusIntegracao;
     }
-    return Math.max(trabalho.hermetica / plano.cpusHermetica, trabalho.varredura / plano.cpusDaFatia + trabalho.integracao / plano.cpusIntegracao);
+    const paredeDaReserva = trabalho.varredura / plano.cpusDaFatia + trabalho.integracao / plano.cpusIntegracao;
+    const feitoAntesDaDevolucao = Math.min(trabalho.hermetica, paredeDaReserva * plano.cpusHermetica);
+    const paredeDaHermetica = feitoAntesDaDevolucao === trabalho.hermetica
+        ? trabalho.hermetica / plano.cpusHermetica
+        : paredeDaReserva + (trabalho.hermetica - feitoAntesDaDevolucao) / plano.cpusHermeticaAposReserva;
+    return Math.max(paredeDaHermetica, paredeDaReserva);
 }

package/dist/catalogo.js

@@ -99,7 +99,7 @@ function real(p) {
     }
 }
 /**
- * RM-047 (P4): o catálogo que o `ork eval` executa. O eval roda os canários, os hooks e o `core/dist`
+ * RM-047 (P4): o catálogo que o `ork eval` executa. O eval roda os cenários, os hooks e o `core/dist`
  * do catálogo, então ele só vale o do pacote que está rodando. Um diretório com `skills/`,
  * `references/` e `eval/` achado a partir do cwd (um clone qualquer) que não seja o próprio pacote é
  * recusado com `eval.catalogo-alheio`, com o comando que roda o eval daquele checkout de propósito.
@@ -112,7 +112,7 @@ function exigirCatalogoDoPacote(inicial) {
     const doCwd = subirProcurando(inicial);
     if (doCwd && real(doCwd) !== real(pacote)) {
         throw new Error(`eval.catalogo-alheio: ${doCwd} tem skills/, references/ e eval/, mas nao e o pacote deste ork ` +
-            `(${pacote}). O eval executa os canarios, os hooks e o core/dist do catalogo, e so roda o do proprio pacote. ` +
+            `(${pacote}). O eval executa os cenarios, os hooks e o core/dist do catalogo, e so roda o do proprio pacote. ` +
             `Para avaliar aquele checkout de proposito, rode o ork dele: node ${path.join(doCwd, 'core', 'dist', 'index.js')} eval`);
     }
     return pacote;
@@ -127,7 +127,7 @@ exports.BUCKETS = [
 ];
 /** Todas as skills do catalogo, varridas do disco (nunca de uma lista escrita a mao). */
 /**
- * O CLI que um canario chama. No repositorio ele fica em `core/dist/`; no pacote npm o catalogo e
+ * O CLI que um cenario chama. No repositorio ele fica em `core/dist/`; no pacote npm o catalogo e
  * a propria raiz do pacote e o CLI e o que esta rodando, ao lado deste arquivo compilado.
  */
 function cliDoCatalogo(catalogo) {

package/dist/{canarios-hitl.js → cenarios-hitl.js}

@@ -1,6 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.CANARIOS_HITL = void 0;
+exports.CENARIOS_HITL = void 0;
 const sandbox_1 = require("./sandbox");
 const thread_1 = require("./thread");
 const ledger_1 = require("./ledger");
@@ -11,7 +11,7 @@ const hitl_gates_2 = require("./hitl-gates");
 const hitl_gates_3 = require("./hitl-gates");
 const hitl_local_atestado_1 = require("./hitl-local-atestado");
 const hitl_canais_1 = require("./hitl-canais");
-exports.CANARIOS_HITL = [
+exports.CENARIOS_HITL = [
     { id: 'fx-blanket-approve', sobre: 'SIMULADO: aprovação cega e envelope sem autenticação são recusados', precisaDeGit: true, rodar: () => {
             const s = (0, sandbox_1.sandboxGit)('blanket-approve');
             try {
@@ -72,16 +72,16 @@ exports.CANARIOS_HITL = [
     // precisam responder e ficar distinguiveis depois, que e o que D12 exige.
     { id: 'fx-omnicanal', sobre: 'SIMULADO: os quatro canais respondem e ficam distinguiveis no recibo', precisaDeGit: true, rodar: () => {
             const s = (0, sandbox_1.sandboxGit)('omnicanal');
-            // FX1: cada canal de telegram tem a SUA chave; o canario nunca compartilha segredo.
+            // FX1: cada canal de telegram tem a SUA chave; o cenario nunca compartilha segredo.
             const nomes = ['ORK_HITL_INGRESS_KEY_HERMES', 'ORK_HITL_INGRESS_KEY_OPENCLAW',
                 'ORK_HITL_OPENCLAW_ACCOUNT', 'ORK_HITL_TELEGRAM_USERS', 'ORK_HITL_TELEGRAM_CHATS',
                 'ORK_HITL_ROOT', 'ORK_HITL_TELEGRAM_BOT_ID'];
             const antigos = nomes.map(n => process.env[n]);
-            const chaves = { hermes: 'chave-SIMULADA-do-canario-hermes-00000000',
-                openclaw: 'chave-SIMULADA-do-canario-openclaw-000000' };
+            const chaves = { hermes: 'chave-SIMULADA-do-cenario-hermes-00000000',
+                openclaw: 'chave-SIMULADA-do-cenario-openclaw-000000' };
             // FX5: so o OpenClaw tem conta homologada, e ela entra no corpo assinado.
-            const conta = 'conta-SIMULADA-do-canario-openclaw';
-            [chaves.hermes, chaves.openclaw, conta, '42', '-7', '/tmp/ork-hitl-canario', '999']
+            const conta = 'conta-SIMULADA-do-cenario-openclaw';
+            [chaves.hermes, chaves.openclaw, conta, '42', '-7', '/tmp/ork-hitl-cenario', '999']
                 .forEach((v, i) => { process.env[nomes[i]] = v; });
             try {
                 const registro = (0, hitl_canais_1.conferirRegistro)();