@orkastery/cli 0.2.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Orkastery
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,87 @@
+# core/, o núcleo `ork`
+
+Núcleo CLI determinístico do Orkastery (Camada 2, o Looping Threads Maestro).
+**Sem LLM embutido**: o `ork` monta prompt, despacha pelo runtime adapter, verifica no
+mundo real e registra no ledger. Quem escreve código e a orquestra (Camada 3); quem
+decide e o humano.
+
+## Instalar
+
+Publicado no npm como **`@orkastery/cli`**. O nome curto `ork` no registry pertence a outro
+projeto, mas o binario instalado continua sendo `ork`:
+
+```bash
+npm install -g @orkastery/cli
+ork doctor
+```
+
+O tarball leva junto o catalogo do produto (`skills/`, `references/`, `eval/` e `adapters/`),
+entao `ork eval` e `ork adapter install` funcionam a partir da instalacao global.
+
+## Compilar deste repositorio
+
+```bash
+cd core
+npm install
+npm run build        # gera dist/index.js (bin `ork`)
+npm test             # compila e roda a suite (node --test)
+npm link             # opcional: poe o `ork` desta arvore no PATH
+```
+
+O `prepack` roda o build e copia o catalogo da raiz do repositorio para dentro de `core/`; o
+`postpack` remove as copias. E por isso que `npm pack` e `npm publish` levam o produto inteiro
+sem que essas pastas existam na arvore versionada de `core/`.
+
+## Comandos
+
+```bash
+node dist/index.js doctor                 # o que vale nesta maquina agora
+node dist/index.js init                   # gera o orkastery.yaml do repo
+node dist/index.js modos                  # tabela dos 5 modos de conducao
+node dist/index.js thread new "<nome>" --modo default
+node dist/index.js thread list
+node dist/index.js thread status <thread-id>
+node dist/index.js phase run <thread-id> GOAL --prompt "<pedido>"
+node dist/index.js phase list <thread-id>
+node dist/index.js sessions [--all]
+node dist/index.js sessions logs|stop|attach <sessao>
+```
+
+Bloco B1 (verdade, gate de tokens, handoff e entrega):
+
+```bash
+node dist/index.js claims add <thread-id> <arquivo> --claim "<alegacao>" --verificar "<comando>"
+node dist/index.js claims list|verificar|retirar <thread-id> [...]
+node dist/index.js verify <thread-id> [--baseline] [--so-claims]
+node dist/index.js gate next <thread-id> [--proximo FASE] [--ocupacao 0..1] [--transcript ARQ]
+node dist/index.js gate approve <thread-id> push --por <quem>
+node dist/index.js handoff export <thread-id> [--proxima-fase FASE]
+node dist/index.js handoff recall <thread-id> "<path#ancora>"
+node dist/index.js ship <thread-id> --para main [--autorizar-push <quem>] [--dry-run]
+node dist/index.js lease list|release <nome>
+```
+
+## Mapa dos módulos
+
+| Arquivo | Papel |
+|---|---|
+| `src/index.ts` | CLI: parse de argumentos e roteamento dos subcomandos |
+| `src/doctor.ts` | Checks de ambiente, manifesto, abbrev, custo/provider e sessões |
+| `src/init.ts` | Detecção do repo e geração do `orkastery.yaml` |
+| `src/thread.ts` | Estado da thread em disco, slug, base carimbada, listagem |
+| `src/phase.ts` | Montagem do prompt da fase, despacho e leitura do ledger |
+| `src/modos.ts` | Matriz dos 5 modos de condução e parse da #TAG |
+| `src/slug.ts` | Slug de 3 partes, regex canonica e rotação de sessão |
+| `src/ledger.ts` | Ledger JSONL append-only por thread |
+| `src/manifest.ts` | Leitura e validação do manifesto (com fallback `devmaster.yaml`) |
+| `src/yaml.ts` | Leitor do subconjunto de YAML usado pelo manifesto (sem dependência) |
+| `src/adapters/claude-bg.ts` | Runtime adapter: `claude --bg`, `claude agents`, logs e stop |
+| `src/sessoes.ts` | Observabilidade: cruza o runtime real com o registrado nas threads |
+| `src/claims.ts` | Alegações verificaveis por thread (`claims.jsonl`) e a regra da alegação negativa |
+| `src/verify.ts` | Reexecucao no HEAD real, baseline e classificação regressão vs pré-existente |
+| `src/gates.ts` | Catálogo de motivos tipados de gate e registro de aprovação humana |
+| `src/policies.ts` | Policies do manifesto executaveis, por gate e por severidade |
+| `src/leases.ts` | Leases com aquisição atômica e TTL (o `main-tree` serializa o ship) |
+| `src/ship.ts` | Merge --no-ff serializado, verificado, e push provado por `ls-remote` |
+| `src/tokens.ts` | Gate de tokens: medida honesta da janela e veredito de rotação |
+| `src/handoff.ts` | Handoff triado em 3 níveis com proveniência, e o recall dos ponteiros |

package/adapters/README.md

@@ -0,0 +1,22 @@
+# adapters/
+
+Adaptadores de host (Camada 1: Hermes, OpenClaw, plugin do Claude Code, CI e cron).
+
+Eles traduzem intencao em chamada de `ork`, apresentam gates ao humano e registram decisoes.
+**Zero regra de negocio.** O parse da #TAG de modo de conducao acontece aqui e vira `--mode` no
+`ork thread new`, mas nem o parse e reimplementado: o host chama `ork modos --do-pedido`, que usa a
+`extrairTagDoPedido` do nucleo. A validacao contra `conduction.allowed_modes` e do nucleo.
+
+| Host | O que entra | Instalacao |
+|---|---|---|
+| [claude-code](claude-code/README.md) | Plugin com as 17 skills, 6 subagentes de fase, `/goal` ... `/master` e guard `PreToolUse` | `ork adapter install claude-code` |
+| [hermes](hermes/README.md) | Skill roteadora fina, plugin e script de abertura de thread | `ork adapter install hermes` |
+| [openclaw](openclaw/README.md) | `openclaw.plugin.json` com 16 tools `ork_*` | `ork adapter install openclaw` |
+
+Cada README traz os **3 pitfalls de instalacao** do seu host: os tres jeitos conhecidos de a
+instalacao "dar certo" e nao funcionar. O instalador cita os mesmos tres ao terminar, e o
+`--dry-run` mostra o que ele faria sem escrever nada.
+
+Os adaptadores de RUNTIME (Camada 3) sao outra coisa e ficam em `core/src/adapters/`, porque quem
+os chama e o nucleo: hoje `claude-bg`. O Claude Code aparece nas duas camadas, com papeis
+diferentes; confundir as duas e como o Orkastery original acabou prometendo um motor que nunca teve.

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

@@ -0,0 +1,15 @@
+{
+  "name": "orkastery",
+  "description": "Marketplace do Orkastery: o catalogo de skills finas, os comandos de fase e o guard PreToolUse.",
+  "owner": { "name": "Julio Pessoa e contribuidores do Orkastery" },
+  "plugins": [
+    {
+      "name": "orkastery",
+      "source": "./",
+      "displayName": "Orkastery",
+      "description": "Conducao de looping threads em 6 fases com gates humanos, estado em disco e MASTER log com score de 0 a 5.",
+      "version": "{{versao}}",
+      "license": "MIT"
+    }
+  ]
+}

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

@@ -0,0 +1,31 @@
+{
+  "name": "orkastery",
+  "displayName": "Orkastery",
+  "description": "Conducao de looping threads em 6 fases com gates humanos, estado em disco e MASTER log com score de 0 a 5. As skills sao roteadores finos: quem executa e o nucleo `ork`.",
+  "version": "{{versao}}",
+  "author": { "name": "Julio Pessoa e contribuidores do Orkastery" },
+  "license": "MIT",
+  "skills": [
+    "./skills/core/orkastery-bootstrap",
+    "./skills/core/thread-state",
+    "./skills/governance/decision-triage",
+    "./skills/governance/narrative-guardian",
+    "./skills/governance/roadmap-keeper",
+    "./skills/governance/scope-check-capability-map",
+    "./skills/observability/thread-tracing",
+    "./skills/phases/check-quality",
+    "./skills/phases/go-implementation",
+    "./skills/phases/goal-definition",
+    "./skills/phases/master-metrics",
+    "./skills/phases/plan-specification",
+    "./skills/phases/ship-release",
+    "./skills/reviewers/code-reviewer",
+    "./skills/reviewers/security-auditor",
+    "./skills/reviewers/test-engineer",
+    "./skills/reviewers/web-performance-auditor"
+  ],
+  "commands": "./commands",
+  "agents": "./agents",
+  "hooks": "./hooks/hooks.json",
+  "keywords": ["orquestracao", "metodologia", "governanca", "telemetria"]
+}

package/adapters/claude-code/README.md

@@ -0,0 +1,102 @@
+# Adaptador Claude Code
+
+O Orkastery chega ao Claude Code como **plugin**: as 17 skills finas do catalogo, seis subagentes
+de fase, os slash commands `/goal` ... `/master` e um guard `PreToolUse`.
+
+## Instalacao
+
+```bash
+ork adapter install claude-code                 # instala em <projeto>/.claude
+ork adapter install claude-code --dir ~/.claude # instala para todos os projetos da maquina
+ork adapter install claude-code --dry-run       # lista o que seria escrito, sem escrever
+```
+
+O instalador copia o catalogo unico de `skills/` e `references/`, renderiza o manifesto do plugin
+com os caminhos declarados um a um, e grava `INSTALADO.json` com a origem e o sha256 de cada
+arquivo. E esse arquivo que permite detectar depois que alguem editou a copia instalada em vez do
+catalogo.
+
+## O que voce ganha
+
+| Voce digita | Voce recebe |
+|---|---|
+| `/goal <pedido com #TAG>` | Abre a thread no modo da tag e conduz a fase GOAL |
+| `/plan <thread>` | PLAN: tarefas com verify, `touch_paths`, decisoes travadas |
+| `/go <thread>` | GO: worktree garantida, baseline gravada, commit por tarefa |
+| `/check <thread>` | CHECK: verificacao contra a baseline, cinco eixos, um veredito |
+| `/ship <thread>` | SHIP: merge serializado por lease e push provado |
+| `/master <thread>` | MASTER: POSTMORTEM tipado e o score humano de 0 a 5 |
+| `/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`.
+
+## O guard PreToolUse
+
+Um hook, em `Bash`, chamando `hooks/ork-guard.js`. Ele bloqueia seis classes de comando:
+
+| Bloqueio | Por que |
+|---|---|
+| `git add -A`, `git add --all`, `git add .` | Engolem arquivo de outra thread na mesma arvore |
+| `git commit -a` | Comita o que esta rastreado, nao a tarefa |
+| `git push --force` | Reescreve historico publico e apaga entrega alheia |
+| `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 |
+
+**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.
+
+## A #TAG de conducao
+
+O comando `/goal` extrai o modo do proprio pedido, sem reimplementar nada:
+
+```bash
+MODO=$(ork modos --do-pedido "$ARGUMENTS")
+ork thread new "<nome>" --mode "$MODO" --worktree auto
+```
+
+`ork modos --do-pedido` usa a mesma `extrairTagDoPedido` do nucleo. Sem tag no texto, vale o
+`conduction.default_mode` do manifesto. **A validacao contra `conduction.allowed_modes` e do
+nucleo**, dentro do `ork thread new`: o host transporta a tag, nunca decide se ela vale.
+
+## Os 3 pitfalls de instalacao
+
+Sao os tres jeitos conhecidos de a instalacao "dar certo" e nao funcionar. O instalador confere os
+tres e o `--dry-run` mostra o que ele vai fazer sobre cada um.
+
+1. **Manifesto sem os caminhos das skills instala limpo e nao expoe nada.** Um plugin do Claude
+   Code auto-descobre `skills/<nome>/SKILL.md` e para ai: ele nao desce nos diretorios de bucket
+   (`core/`, `phases/`, `reviewers/`, ...) que este catalogo usa. Por isso `plugin.json` declara os
+   17 caminhos um a um. Depois de instalar, confira a contagem em vez de confiar no manifesto:
+   `claude plugin details orkastery` precisa reportar 17, o mesmo numero de `SKILL.md` em disco.
+   Quando divergir, quem esta errado e o manifesto.
+
+2. **Duas copias do catalogo divergem, e a divergencia so aparece quando ja custou uma entrega.**
+   A fonte unica e `skills/` na raiz do produto. O instalador copia de la e grava a origem e o
+   sha256 de cada arquivo em `INSTALADO.json`; reinstalar com `--force` ressincroniza. Editar a
+   copia instalada e bandeira vermelha: a correcao volta para o catalogo e desce de novo pelo
+   instalador.
+
+3. **Hook com caminho relativo silenciosamente nao roda, e o guard vira decoracao.** O
+   `hooks.json` chama `node "${CLAUDE_PLUGIN_ROOT}/hooks/ork-guard.js"`, nunca um caminho relativo
+   ao diretorio de trabalho, que muda a cada worktree de thread. Depois de instalar, prove que o
+   guard esta vivo em vez de supor:
+
+   ```bash
+   echo '{"tool_name":"Bash","tool_input":{"command":"git add -A"}}' \
+     | node <plugin>/hooks/ork-guard.js ; echo "codigo: $?"
+   ```
+
+   Codigo 2 e decisao `deny` na saida: guard vivo. Codigo 0: o hook nao esta bloqueando nada.
+
+## Nao confunda as duas camadas
+
+O Claude Code aparece duas vezes na arquitetura do Orkastery. **Aqui ele e Camada 1**, o podio: o
+host onde o builder conversa e de onde as chamadas de `ork` saem. Ele tambem e **Camada 3**, a
+orquestra, quando o `ork` despacha `claude --bg` para escrever codigo, e esse adaptador de runtime
+mora em `core/src/adapters/claude-bg.ts`, chamado pelo nucleo. Sao papeis diferentes no mesmo
+programa, e misturar os dois e como o Orkastery original acabou prometendo um motor que nunca teve.

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

@@ -0,0 +1,32 @@
+---
+name: ork-check
+description: Conduz a fase CHECK: reexecuta a verificacao contra a baseline, percorre os cinco eixos e consolida um veredito unico. Nao corrige o que encontra.
+tools: Bash(ork:*), Bash(git:*), Read, Glob, Grep
+---
+
+Voce conduz a fase CHECK de uma thread do Orkastery, e so ela.
+
+A metodologia executavel esta no nucleo `ork` e na skill `check-quality`; este arquivo nao a duplica.
+Em qualquer divergencia entre o que voce lembra e o que o `ork` responde, **o `ork` vence**.
+
+## Como comecar
+
+```bash
+ork thread status <thread>     # o estado real, lido do disco
+ork phase list <thread>        # o que ja aconteceu, com evidencia
+```
+
+## Regras desta fase
+
+- **CHECK nao corrige.** Achado vira tarefa de GO, com commit proprio.
+- Eixo sem achado sai com "nenhum" explicito.
+- Zero bloqueadores de seguranca e condicao dura, em qualquer modo.
+- Correcao tipo B devolve ao GO e o CHECK seguinte e reexecucao completa.
+
+## Regras que valem em toda fase
+
+- 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.
+- 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

@@ -0,0 +1,32 @@
+---
+name: ork-go
+description: Conduz a fase GO dentro da worktree da thread: um commit atomico por tarefa, baseline gravada antes de comecar.
+tools: Bash, Read, Write, Edit, Glob, Grep
+---
+
+Voce conduz a fase GO de uma thread do Orkastery, e so ela.
+
+A metodologia executavel esta no nucleo `ork` e na skill `go-implementation`; este arquivo nao a duplica.
+Em qualquer divergencia entre o que voce lembra e o que o `ork` responde, **o `ork` vence**.
+
+## Como comecar
+
+```bash
+ork thread status <thread>     # o estado real, lido do disco
+ork phase list <thread>        # o que ja aconteceu, com evidencia
+```
+
+## Regras desta fase
+
+- Trabalhe SOMENTE na worktree da thread. A arvore principal nao e area de trabalho.
+- Baseline antes da primeira linha: `ork verify <thread> --baseline`.
+- Um commit por tarefa, arquivos nomeados. `git add -A` e bloqueado pelo guard.
+- Toda alegacao vira claim com comando. Passagem relatada nao e passagem.
+
+## Regras que valem em toda fase
+
+- 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.
+- 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

@@ -0,0 +1,33 @@
+---
+name: ork-goal
+description: Conduz a fase GOAL de uma thread do Orkastery: exploracao do repositorio real, premissas explicitas e criterios que viram claims verificaveis. Nao implementa.
+tools: Bash(ork:*), Read, Glob, Grep
+---
+
+Voce conduz a fase GOAL de uma thread do Orkastery, e so ela.
+
+A metodologia executavel esta no nucleo `ork` e na skill `goal-definition`; este arquivo nao a duplica.
+Em qualquer divergencia entre o que voce lembra e o que o `ork` responde, **o `ork` vence**.
+
+## Como comecar
+
+```bash
+ork thread status <thread>     # o estado real, lido do disco
+ork phase list <thread>        # o que ja aconteceu, com evidencia
+```
+
+## Regras desta fase
+
+- **GOAL nao implementa.** Nenhuma edicao de arquivo de produto sai desta fase.
+- A exploracao mira o repositorio real: cite arquivos e trechos concretos ou a exploracao nao
+  aconteceu.
+- Premissa implicita e defeito de processo: escreva as premissas.
+- Criterio de sucesso e observavel, nunca adjetivo, e vira `ork claims add ... --verificar`.
+
+## Regras que valem em toda fase
+
+- 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.
+- 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

@@ -0,0 +1,32 @@
+---
+name: ork-master
+description: Conduz a fase MASTER: POSTMORTEM tipado, MASTER log no contrato congelado e coleta do score humano. Nunca inventa nota.
+tools: Bash(ork:*), Read
+---
+
+Voce conduz a fase MASTER de uma thread do Orkastery, e so ela.
+
+A metodologia executavel esta no nucleo `ork` e na skill `master-metrics`; este arquivo nao a duplica.
+Em qualquer divergencia entre o que voce lembra e o que o `ork` responde, **o `ork` vence**.
+
+## Como comecar
+
+```bash
+ork thread status <thread>     # o estado real, lido do disco
+ork phase list <thread>        # o que ja aconteceu, com evidencia
+```
+
+## Regras desta fase
+
+- **O score e do humano, em todos os modos.** Este agente coleta, nunca atribui.
+- Classe de falha vem do catalogo fixo (`ork master classes`).
+- Justificativa vazia e recusada pelo comando, e a recusa nao grava nada.
+- Entrega sem MASTER log nao aconteceu.
+
+## Regras que valem em toda fase
+
+- 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.
+- 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

@@ -0,0 +1,32 @@
+---
+name: ork-plan
+description: Conduz a fase PLAN: tarefas fatiadas com touch_paths e verify por tarefa, decisoes com domicilio unico. Nao implementa.
+tools: Bash(ork:*), Read, Glob, Grep
+---
+
+Voce conduz a fase PLAN de uma thread do Orkastery, e so ela.
+
+A metodologia executavel esta no nucleo `ork` e na skill `plan-specification`; este arquivo nao a duplica.
+Em qualquer divergencia entre o que voce lembra e o que o `ork` responde, **o `ork` vence**.
+
+## Como comecar
+
+```bash
+ork thread status <thread>     # o estado real, lido do disco
+ork phase list <thread>        # o que ja aconteceu, com evidencia
+```
+
+## Regras desta fase
+
+- **PLAN nao implementa.**
+- Tarefa maior que cinco arquivos volta a ser fatiada, antes do GO.
+- Toda tarefa carrega o comando que prova que ela terminou.
+- Decisao fechada trava: reabrir e decisao nova com registro.
+
+## Regras que valem em toda fase
+
+- 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.
+- 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

@@ -0,0 +1,32 @@
+---
+name: ork-ship
+description: Conduz a fase SHIP pelo `ork ship`: merge serializado por lease e push provado por comando.
+tools: Bash(ork:*), Bash(git status:*), Bash(git log:*), Read
+---
+
+Voce conduz a fase SHIP de uma thread do Orkastery, e so ela.
+
+A metodologia executavel esta no nucleo `ork` e na skill `ship-release`; este arquivo nao a duplica.
+Em qualquer divergencia entre o que voce lembra e o que o `ork` responde, **o `ork` vence**.
+
+## Como comecar
+
+```bash
+ork thread status <thread>     # o estado real, lido do disco
+ork phase list <thread>        # o que ja aconteceu, com evidencia
+```
+
+## Regras desta fase
+
+- Nada de `git push` na mao: o push do Orkastery e provado contra o sha do remoto.
+- Ensaie com `--dry-run` antes de entregar.
+- Base que andou se ressincroniza e o veredito se refaz.
+- Plano de rollback escrito ANTES do merge.
+
+## Regras que valem em toda fase
+
+- 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.
+- 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/check.md

@@ -0,0 +1,45 @@
+---
+description: Conduz a fase CHECK da thread e consolida um veredito unico.
+argument-hint: "<thread-id>"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /check
+
+Fase CHECK (F4): verificacao contra a baseline, os cinco eixos de review, seguranca com zero bloqueadores, auditoria de delegacao e exatamente um veredito.
+
+## O que este comando faz
+
+1. Reexecuta tudo no HEAD real:
+
+```bash
+ork verify <thread>
+ork worktree audit <thread>
+```
+
+2. Roda os quatro reviewers do catalogo sobre o escopo declarado: `code-reviewer`,
+   `security-auditor`, `test-engineer` e `web-performance-auditor`. Use os subagentes
+   `ork-check` e companhia quando quiser isolar o contexto de cada um.
+
+3. Le o ledger para a auditoria de delegacao:
+
+```bash
+ork phase list <thread>
+```
+
+4. Consolida UM veredito (PASSOU, PRECISA DE MUDANCA, BLOQUEADO) e, se o modo pausa, apresenta ao
+   builder e espera:
+
+```bash
+ork gate approve <thread> evidencias --por "<quem>"
+```
+
+## Regras do adaptador
+
+- **Zero regra de negocio aqui.** Este comando traduz intencao em chamada de `ork` e nada mais.
+  Quem valida modo, monta prompt, decide gate e prova entrega e o nucleo.
+- **A #TAG vem do pedido, nao de configuracao.** O modo sai de `ork modos --do-pedido`, que usa a
+  mesma funcao do nucleo; sem tag vale o `conduction.default_mode` do manifesto. A validacao
+  contra `conduction.allowed_modes` acontece dentro do `ork thread new`, nunca aqui.
+- **Nada de escrever codigo de produto neste comando.** Quem escreve e a sessao que o `ork`
+  despacha, com o prompt gravado e o sha no ledger.

package/adapters/claude-code/commands/go.md

@@ -0,0 +1,46 @@
+---
+description: Conduz a fase GO da thread pelo `ork`, dentro da worktree isolada.
+argument-hint: "<thread-id> [tarefa]"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /go
+
+Fase GO (F3): implementacao slice por slice, um commit atomico por tarefa, dentro da worktree da thread. Quem escreve codigo e a sessao despachada, nunca este comando.
+
+## O que este comando faz
+
+1. Garante a worktree e grava a baseline ANTES da primeira linha de codigo:
+
+```bash
+ork worktree ensure <thread>
+ork verify <thread> --baseline
+```
+
+2. Despacha a tarefa:
+
+```bash
+ork phase run <thread> GO --prompt "<tarefa do PLAN, uma por vez>"
+```
+
+3. Reexecuta a verificacao no HEAD real e compara com a baseline:
+
+```bash
+ork verify <thread>
+```
+
+4. Confere que a worktree continua consistente no proprio git:
+
+```bash
+ork worktree audit <thread>
+```
+
+## Regras do adaptador
+
+- **Zero regra de negocio aqui.** Este comando traduz intencao em chamada de `ork` e nada mais.
+  Quem valida modo, monta prompt, decide gate e prova entrega e o nucleo.
+- **A #TAG vem do pedido, nao de configuracao.** O modo sai de `ork modos --do-pedido`, que usa a
+  mesma funcao do nucleo; sem tag vale o `conduction.default_mode` do manifesto. A validacao
+  contra `conduction.allowed_modes` acontece dentro do `ork thread new`, nunca aqui.
+- **Nada de escrever codigo de produto neste comando.** Quem escreve e a sessao que o `ork`
+  despacha, com o prompt gravado e o sha no ledger.

package/adapters/claude-code/commands/goal.md

@@ -0,0 +1,54 @@
+---
+description: Abre a thread do pedido e conduz a fase GOAL pelo `ork`.
+argument-hint: "<pedido do builder, com #TAG opcional>"
+allowed-tools: Bash(ork:*), Read, Glob, Grep
+---
+
+# /goal
+
+Fase GOAL (F1): objetivo verificavel, exploracao do repositorio real, premissas explicitas e criterios que viram claims com comando. GOAL nao implementa.
+
+## O que este comando faz
+
+1. Extrai o modo de conducao do proprio pedido, sem reimplementar o parse:
+
+```bash
+MODO=$(ork modos --do-pedido "$ARGUMENTS")
+```
+
+2. Abre a thread com esse modo (o `ork` valida contra `conduction.allowed_modes` e recusa o que
+   o projeto nao permite):
+
+```bash
+ork thread new "<nome curto da demanda>" --mode "$MODO" --worktree auto
+```
+
+3. Despacha a fase, com o pedido inteiro do builder:
+
+```bash
+ork phase run <thread> GOAL --prompt "$ARGUMENTS"
+```
+
+4. Registra como claim tudo que o GOAL alegou, com o comando que comprova cada alegacao, e
+   reexecuta:
+
+```bash
+ork claims add <thread> <arquivo> --claim "<alegacao>" --verificar "<comando>" --fase GOAL
+ork verify <thread> --so-claims
+```
+
+5. Se o modo pausa neste bloco, apresenta a evidencia ao builder e para. A liberacao e registrada:
+
+```bash
+ork gate approve <thread> objetivo --por "<quem>"
+```
+
+## Regras do adaptador
+
+- **Zero regra de negocio aqui.** Este comando traduz intencao em chamada de `ork` e nada mais.
+  Quem valida modo, monta prompt, decide gate e prova entrega e o nucleo.
+- **A #TAG vem do pedido, nao de configuracao.** O modo sai de `ork modos --do-pedido`, que usa a
+  mesma funcao do nucleo; sem tag vale o `conduction.default_mode` do manifesto. A validacao
+  contra `conduction.allowed_modes` acontece dentro do `ork thread new`, nunca aqui.
+- **Nada de escrever codigo de produto neste comando.** Quem escreve e a sessao que o `ork`
+  despacha, com o prompt gravado e o sha no ledger.