@orkastery/cli 0.2.0

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

@@ -0,0 +1,63 @@
+---
+name: thread-tracing
+description: "Rastro da thread: le o ledger, as sessoes, as claims e o MASTER log para reconstruir o que aconteceu, com quem decidiu e com que evidencia. Somente leitura, nunca escreve no estado."
+bucket: observability
+roteia: "ork phase list | ork thread status | ork sessions | ork board"
+license: MIT
+---
+
+# Thread Tracing
+
+## O que esta skill e
+
+Um roteador fino de leitura. Ela reconstroi a historia de uma thread a partir do que esta gravado,
+e **nunca escreve no estado**: observabilidade que altera o que observa deixa de ser
+observabilidade.
+
+## Como rotear
+
+```bash
+ork phase list <thread>       # o ledger inteiro, evento a evento
+ork thread status <thread>    # o estado gravado cruzado com o runtime real
+ork sessions --all            # as sessoes vivas do runtime
+ork claims list <thread>      # as alegacoes e o estado de cada uma
+ork board                     # todas as threads, uma visao
+ork master --batch            # o que fechou e ainda espera score
+```
+
+## O que o rastro precisa responder
+
+1. **O que foi pedido**, com o prompt exato: cada sessao gravou o prompt com `sha256` no nome.
+2. **Quem decidiu**, em cada gate: humano com nome, ou decisao autonoma com a #TAG que autorizou.
+3. **Com que evidencia**, sempre: comando, saida, sha. Evento sem evidencia e anotacao, nao rastro.
+4. **O que falhou e por que**, com o motivo tipado: `claims.failed`, `verify.regression`,
+   `policy.violation`, `lease.busy`, `tree.blocked`, `human.pending`.
+5. **Onde o tempo e a janela foram**, com a origem da medida declarada: `runtime_reported`,
+   `estimated`, `informada` ou `unavailable`.
+
+## A honestidade de medicao
+
+O que o runtime nao expoe sai `unavailable`, com o motivo. **Lacuna e publicada como lacuna, nunca
+como zero.** Um rastro que preenche buraco com estimativa silenciosa e pior que um rastro com
+buraco declarado, porque o segundo ninguem confunde com dado.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "Escrevo um evento a mais para deixar o rastro completo" | Observabilidade nao escreve no estado. Evento inventado depois nao e rastro, e reconstrucao. |
+| "O token gasto deve ter sido uns X" | Sem medida do runtime, sai `unavailable`. Estimativa apresentada como leitura e o comeco de todo painel falso. |
+| "Coloco zero onde nao tem dado" | Zero e um dado. Lacuna e publicada como lacuna. |
+| "Reordeno o ledger para ficar legivel" | O ledger e append-only e a ordem e evidencia. Legibilidade e trabalho da apresentacao, nao do arquivo. |
+
+## Bandeiras vermelhas
+
+- Evento no ledger sem evidencia.
+- Gate sem quem decidiu.
+- Metrica com numero redondo e sem origem.
+- Sessao gravada como viva que o runtime nao reconhece.
+
+## Verificacao antes de entregar o rastro
+
+Pedido, decisor, evidencia, motivo tipado e origem de cada numero, com toda lacuna declarada como
+lacuna e nenhuma escrita feita no estado. Ver `PERF 9`, `PERF 10` e `DoD 5`.

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

@@ -0,0 +1,87 @@
+---
+name: check-quality
+description: "Fase CHECK (F4): verificacao contra a baseline, os cinco eixos de review, auditoria de seguranca e de performance, auditoria de delegacao e um veredito unico. Roteia para ork verify e para as quatro skills de reviewer."
+bucket: phases
+roteia: "ork verify <thread> | ork gate approve <thread> evidencias"
+license: MIT
+---
+
+# CHECK, verificacao
+
+## O que esta skill e
+
+Um roteador fino da fase CHECK. Ela consolida o que o `ork` mediu e o que os quatro reviewers
+acharam, e produz **exatamente um veredito**: PASSOU, PRECISA DE MUDANCA ou BLOQUEADO. Ela nao
+corrige o que encontra: correcao e trabalho de GO.
+
+## Como rotear
+
+```bash
+ork verify <thread>                  # reexecuta claims e verify contra a baseline
+ork phase list <thread>              # o ledger, para a auditoria de delegacao
+ork worktree audit <thread>          # a worktree confere no proprio git
+ork gate approve <thread> evidencias --por <quem>
+```
+
+Quando o veredito e PRECISA DE MUDANCA, o sub-loop GO-FIX / CHECK-REVERIFY do bloco B3 e
+quem conduz a volta, e ele nao depende de humano ate o veredito final:
+
+```bash
+ork fix open <thread>                # deriva a spec exata de cada correcao do verify real
+ork fix list <thread>                # as correcoes da rodada, com o tipo A ou B de cada uma
+ork fix reverify <thread>            # veredito POR correcao, mais o verify completo
+ork retry plan <thread>              # o que o ork faria pelo ultimo gate reprovado, e por que
+```
+
+Duas guardas que o nucleo executa por voce: reexecucao PARCIAL e RECUSADA quando a rodada
+tem correcao tipo B, e o limite de escalacao do manifesto (`retry.max_tentativas`) sobe o
+veredito para humano em qualquer modo, inclusive `#Auto`.
+
+Os quatro reviewers do catalogo entram aqui: `code-reviewer`, `security-auditor`, `test-engineer`
+e `web-performance-auditor`. Cada um roda no seu escopo e devolve achados categorizados.
+
+## O que o CHECK entrega
+
+1. **Comparacao contra a baseline**, separando regressao de divida pre-existente. Sem essa
+   separacao, o relatorio culpa a thread pelo que ja estava quebrado.
+2. **Os cinco eixos**, cada um com achados ou um "nenhum" explicito: correcao, seguranca,
+   performance, manutenibilidade, estilo.
+3. **Zero bloqueadores de seguranca**, condicao dura, valida em qualquer modo, inclusive `#Auto`.
+4. **Auditoria de delegacao**, cacando subclassificacao e escalacao indevida com peso igual.
+5. **Correcoes classificadas com honestidade:** tipo A e uma linha ou equivalente, registrada, com
+   as verificacoes afetadas reexecutadas; tipo B devolve a tarefa ao GO, e o CHECK seguinte e uma
+   reexecucao completa, nunca parcial.
+6. **Um veredito unico**, no diretorio da thread, com todo aviso aceito carregando seu registro.
+
+## O que o nucleo verifica por voce
+
+Os motivos tipados do `ork` fazem o veredito parar de ser conversa: `claims.failed`,
+`verify.regression`, `verify.failed`, `policy.violation`, `cost.violation`, `tree.blocked`,
+`lease.busy`, `runtime.rate-limited`. Todos reprovam em qualquer modo, porque **o modo afrouxa
+a pausa, nunca a verificacao**. Cada um deles tem uma acao de retry deterministica em
+`ork retry policy`, e `cost.violation` e o unico que NUNCA recebe retry automatico.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "So um aviso, da para passar" | Aviso passa com registro nominal de quem aceitou e por que. Aviso aceito sem registro e aviso escondido. |
+| "A correcao foi pequena, nao precisa rodar tudo de novo" | Correcao tipo B devolveu a tarefa ao GO: o CHECK seguinte e reexecucao completa. Parcial depois de tipo B nao e CHECK. |
+| "Esse teste ja falhava, ignora" | Ja falhava e afirmacao verificavel: e a baseline que responde, e a divida entra declarada no relatorio. |
+| "O bloqueador de seguranca e teorico" | Zero bloqueadores e condicao dura. Bloqueador rebaixado para aviso porque a entrega estava perto e o defeito de processo que o CHECK existe para expor. |
+| "Ja que achei, corrijo aqui mesmo" | CHECK nao corrige. Achado vira tarefa de GO, com commit proprio, ou o revisor passa a revisar a si mesmo. |
+| "A thread e `#Auto`, o CHECK pode ser mais leve" | O modo afrouxa a pausa, nunca a verificacao. `#Auto` roda o mesmo CHECK; o que ele dispensa e a espera pelo humano. |
+
+## Bandeiras vermelhas
+
+- Relatorio com dois vereditos, ou com nenhum.
+- Eixo de review sem achado e sem "nenhum" escrito.
+- Correcao tipo B seguida de reexecucao parcial.
+- Aviso aceito sem nome de quem aceitou.
+- CHECK rodado sem baseline para comparar.
+
+## Verificacao antes de sair da fase
+
+Suite reexecutada no HEAD real, cinco eixos preenchidos, seguranca com zero bloqueadores,
+performance auditada ou dispensada por escrito, delegacao auditada, veredito unico gravado e o gate
+de evidencias resolvido pelo caminho que o modo exige. Ver `DoD 6` a `DoD 11`, `REVIEW 6` e `SEC 16`.

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

@@ -0,0 +1,70 @@
+---
+name: go-implementation
+description: "Fase GO (F3): implementacao slice por slice dentro da worktree da thread, um commit atomico por tarefa, baseline gravada antes de comecar. Roteia para ork worktree ensure, ork verify --baseline e ork phase run GO."
+bucket: phases
+roteia: "ork worktree ensure | ork verify --baseline | ork phase run <thread> GO"
+license: MIT
+---
+
+# GO, implementacao
+
+## O que esta skill e
+
+Um roteador fino da fase GO. **A camada que apresenta nunca escreve codigo de produto:** quem
+escreve e a orquestra, despachada pelo `ork`. Esta skill garante a worktree, grava a baseline,
+despacha e depois reexecuta a verificacao no mundo real.
+
+## Como rotear
+
+```bash
+ork worktree ensure <thread>                  # worktree isolada, base resolvida pelo ork
+ork verify <thread> --baseline                # o estado do mundo ANTES de implementar
+ork phase run <thread> GO --prompt "<tarefa>"
+ork claims add <thread> <arquivo> --claim "<...>" --verificar "<comando>" --fase GO
+ork verify <thread>                           # reexecuta no HEAD real
+```
+
+## O que o GO entrega
+
+1. **Um commit atomico por tarefa**, com a thread e a tarefa na mensagem, no maximo cinco arquivos.
+2. **Trabalho dentro da worktree da thread.** A arvore principal nao e area de trabalho de thread
+   nenhuma, e a base carimbada no `thread.json` e o que diz de onde a thread partiu.
+3. **Baseline gravada antes da primeira linha.** Sem baseline, uma falha depois nao distingue
+   regressao de divida pre-existente, e a thread ou leva culpa alheia ou esconde o que quebrou.
+4. **Uma claim por alegacao.** Todo arquivo citado, todo teste citado, toda funcao dita pronta vira
+   claim com comando. Passagem relatada por agente nao e passagem.
+5. **Nada fora das tarefas do PLAN.** Melhoria oportunista sem tarefa e scope creep: ela vira
+   proposta, nunca commit escondido no meio da entrega. O que o diff faz alem do combinado o
+   revisor tem que descobrir sozinho, e e assim que uma entrega pequena vira uma revisao cara.
+
+## O que o nucleo verifica por voce
+
+`ork verify` reexecuta claims e comandos do manifesto no HEAD real e compara com a baseline:
+comando que passava antes e falha agora sai como `verify.regression`; o que ja falhava sai como
+divida declarada. Citacao sem lastro sai como `claims.failed`. Os tres reprovam em qualquer modo.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "Eu rodei e passou, pode confiar" | Passagem relatada nao e passagem. `ork verify` reexecuta no HEAD real, e e a saida real que vale. |
+| "Deixa eu commitar tudo junto no fim" | Um commit por tarefa. Commit gigante nao reverte, nao revisa e nao diz qual pedaco quebrou. |
+| "Mexo direto na arvore principal, e mais rapido" | A arvore principal nao e area de trabalho de thread. Worktree isolada e o que permite N threads sem colisao. |
+| "Baseline e perda de tempo, o repo esta verde" | Se estivesse mesmo verde, a baseline custaria um comando. Sem ela, toda falha vira discussao sobre de quem e a culpa. |
+| "Aproveitei e arrumei outra coisa no caminho" | Melhoria fora das tarefas do PLAN e scope creep: vira proposta, nunca commit escondido no meio da entrega. |
+| "O teste falhando ja falhava antes" | Isso e exatamente o que a baseline responde por comando, em vez de por memoria. |
+
+## Bandeiras vermelhas
+
+- Commit com dezenas de arquivos e mensagem generica.
+- Trabalho acontecendo fora da worktree da thread.
+- Nenhuma baseline gravada antes do primeiro commit.
+- Arquivo citado no resumo do runtime que nao aparece no `git show --stat`.
+- Teste desligado ou assercao afrouxada para fechar a tarefa.
+- Mudanca no diff que nao corresponde a nenhuma tarefa do PLAN.
+
+## Verificacao antes de sair da fase
+
+Worktree conferida por `ork worktree audit`, baseline gravada antes do GO, um commit por tarefa,
+claims com comando para tudo que foi alegado, e `ork verify` verde ou com a divida declarada. Ver
+`DoD 1`, `DoD 2`, `DoD 3` e `DoD 4`.

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

@@ -0,0 +1,69 @@
+---
+name: goal-definition
+description: "Fase GOAL (F1): objetivo verificavel, exploracao do repositorio real, premissas explicitas, impact map, riscos e criterios de sucesso observaveis, tudo amarrado em claims com comando de verificacao. Roteia para ork phase run GOAL e ork claims add."
+bucket: phases
+roteia: "ork phase run <thread> GOAL | ork claims add"
+license: MIT
+---
+
+# GOAL, definicao de objetivo
+
+## O que esta skill e
+
+Um roteador fino da fase GOAL. Ela nao explora o repositorio por conta propria e nao implementa
+nada: ela despacha a fase pelo `ork` e transforma o resultado em claims que o `ork` reexecuta.
+**GOAL nao implementa.**
+
+## Como rotear
+
+```bash
+ork thread new "<nome>" --mode <modo>
+ork phase run <thread> GOAL --prompt "<pedido do builder>"
+ork claims add <thread> <arquivo> --claim "<alegacao>" --verificar "<comando>" --fase GOAL
+ork verify <thread> --so-claims
+ork gate approve <thread> objetivo --por <quem>
+```
+
+## O que o GOAL entrega
+
+1. **Objetivo em tres paragrafos, no minimo.** Mesmo uma correcao de uma linha ganha um GOAL de
+   tres paragrafos: compacto quer dizer menor, nunca ausente.
+2. **Exploracao do repositorio real.** A exploracao mira o repositorio de verdade, nao a memoria do
+   modelo. Cite arquivos e trechos concretos ou a exploracao nao aconteceu.
+3. **Premissas explicitas.** Premissa implicita e a maior fonte de retrabalho e e tratada como
+   defeito de processo. Escrever a premissa custa uma linha; descobrir ela errada no GO custa a
+   thread.
+4. **Impact map.** O que muda, o que encosta e o que fica de fora, com o de fora escrito.
+5. **Criterios de sucesso observaveis.** Latencia, cobertura, comportamento verificavel: nunca
+   adjetivo. Numa demanda de correcao, reproduzir o defeito e criterio obrigatorio do GOAL.
+6. **Riscos e ambiguidades**, cada um com o que faria ele virar bloqueio.
+
+## O que o nucleo verifica por voce
+
+Todo criterio de sucesso vira `ork claims add ... --verificar "<comando>"`, e `ork verify` reexecuta
+o comando no HEAD real. Alegacao sem comando volta como `claims.unverifiable`; alegacao que reprova
+volta como `claims.failed`, motivo tipado que reprova em qualquer modo.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "Eu ja conheco esse framework, da para pular a exploracao" | A exploracao mira o repositorio real, nao a memoria do modelo. Sem arquivo e trecho citados, o GOAL e um resumo plausivel de um codigo que ninguem abriu. |
+| "Listar premissa e burocracia, elas sao obvias" | Premissa implicita e a maior fonte de retrabalho. Obvio para quem escreve costuma ser surpresa no GO. |
+| "O criterio e que funcione bem e o usuario goste" | Adjetivo nao e metrica. Criterio que nao vira comando nao gateia nada, e e no gate que a autonomia se perde. |
+| "O repositorio esta vazio, nao ha o que explorar" | Explorar repositorio vazio tambem e explorar: escreva o que foi verificado ausente, ou a ausencia vira premissa implicita. |
+| "O bug e obvio, nao preciso reproduzir antes" | Correcao cujo defeito nunca foi reproduzido nao prova que corrigiu nada. Reproduzir o defeito e criterio obrigatorio do GOAL. |
+
+## Bandeiras vermelhas
+
+- Um GOAL sem arquivo nem trecho citado do repositorio.
+- Premissas ausentes, ou descobertas depois como surpresa durante o GO.
+- Criterio de sucesso escrito com adjetivo.
+- Demanda de correcao sem passo de reproducao do defeito.
+- GOAL que ja traz codigo de implementacao: GOAL nao implementa.
+
+## Verificacao antes de sair da fase
+
+Objetivo com tres paragrafos, exploracao citando arquivos reais, premissas escritas, impact map com
+o que fica de fora, criterios virados em claims com comando, e o gate de objetivo resolvido pelo
+caminho que o modo exige. Ver `DoD 17` e `DoD 18`.

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

@@ -0,0 +1,65 @@
+---
+name: master-metrics
+description: "Fase MASTER (F6): POSTMORTEM tipado, MASTER log no contrato congelado ork.master-log/v1 e o score humano de 0 a 5 com justificativa. Roteia para ork master e ork master --batch."
+bucket: phases
+roteia: "ork master <thread> --score N --justificativa \"...\" | ork master --batch"
+license: MIT
+---
+
+# MASTER, fechamento e score
+
+## O que esta skill e
+
+Um roteador fino da fase MASTER. Ela nao inventa numero, nao arredonda score e nao fecha thread
+sem humano: ela chama `ork master`, que valida contra o contrato congelado e recusa o que nao
+cumpre. **Uma entrega sem MASTER log nao aconteceu.**
+
+## Como rotear
+
+```bash
+ork master classes                            # as classes de falha do catalogo fixo
+ork master <thread> --score 4 --justificativa "<texto>" --classe base-avancou --por <quem>
+ork master --batch                            # a fila de score dos modos sem pausa de MASTER
+ork master --batch --todas
+```
+
+## O que o MASTER entrega
+
+1. **POSTMORTEM tipado**, com as fases percorridas, o que falhou e a classe de falha vinda de um
+   catalogo fixo: `sem-falha`, `erro-de-spec`, `base-avancou`, `conflito`, `rate-limit`, `modelo`,
+   `processo`, `scope-creep`, `outra`. Classe inventada e recusada pelo comando.
+2. **MASTER log no contrato `ork.master-log/v1`**, congelado: mudar o contrato sem mudar a versao
+   e reprovado, porque contrato de telemetria e contrato publico.
+3. **Score humano inteiro de 0 a 5, com justificativa nao vazia.** O score e do humano, sempre. Nos
+   modos sem pausa de MASTER ele vai para a fila de batch, e a fila continua sendo humana.
+4. **Evidencia apontando o ledger e o POSTMORTEM**, com contagem de eventos, sessoes e claims. Log
+   sem evidencia e recusado.
+
+## O que o nucleo verifica por voce
+
+`ork master` recusa e **nao grava nada** quando o score esta fora de 0 a 5, quando a justificativa
+esta vazia, quando a classe esta fora do catalogo, quando uma fase esta fora do ciclo canonico,
+quando o contrato foi trocado sem trocar a versao e quando falta evidencia. Recusa parcial que
+grava metade e pior que recusa inteira.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "Score 5 porque entregou, justificativa depois" | Justificativa vazia e recusada pelo comando. Score sem razao escrita nao ensina nada a thread seguinte. |
+| "Dou 4,5, ficou entre os dois" | O score e inteiro de 0 a 5. Escala com meio ponto vira negociacao, e o que se mede aqui e conducao, nao simpatia. |
+| "A classe de falha dessa foi 'quase deu certo'" | O catalogo e fixo. Classe inventada e recusada, porque classe livre destroi a comparabilidade entre threads. |
+| "Preencho o MASTER log depois, a entrega ja foi" | Uma entrega sem MASTER log nao aconteceu. Fase de aprendizado adiada e fase de aprendizado que nao existe. |
+| "O modo e `#Auto`, entao o score pode ser automatico" | O score e humano em todos os modos. `#Auto` muda quando ele e dado, para a fila de batch, nunca quem da. |
+
+## Bandeiras vermelhas
+
+- Thread entregue sem `master-log.json`.
+- Score gravado sem nome de quem avaliou.
+- Classe de falha fora do catalogo fixo, ou nenhuma classe numa thread que teve retrabalho.
+- Fila de batch crescendo sem ninguem passar nela.
+
+## Verificacao antes de sair da fase
+
+POSTMORTEM tipado gravado, MASTER log valido contra `ork.master-log/v1`, score inteiro com
+justificativa e avaliador, e evidencia apontando ledger e POSTMORTEM. Ver `DoD 16`.

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

@@ -0,0 +1,67 @@
+---
+name: plan-specification
+description: "Fase PLAN (F2): plano com tarefas fatiadas, touch_paths consultaveis, decisoes D1..Dn com domicilio unico e verify executavel por tarefa. Roteia para ork phase run PLAN e ork lease acquire."
+bucket: phases
+roteia: "ork phase run <thread> PLAN | ork lease acquire"
+license: MIT
+---
+
+# PLAN, especificacao
+
+## O que esta skill e
+
+Um roteador fino da fase PLAN. Ela nao escreve o codigo do plano e nao decide sozinha o que e
+tradeoff do humano: ela despacha a fase pelo `ork` e transforma o plano em tarefas com verify.
+**PLAN nao implementa.**
+
+## Como rotear
+
+```bash
+ork phase run <thread> PLAN --prompt "<pedido do builder>"
+ork lease acquire "path:<glob>" --thread <thread> --motivo "PLAN reservou a regiao"
+ork gate approve <thread> premissas --por <quem>
+ork handoff export <thread> --proxima-fase GO
+```
+
+## O que o PLAN entrega
+
+1. **Tarefas fatiadas ate caberem em um commit atomico.** No maximo cinco arquivos por tarefa.
+   Tarefa maior que isso volta a ser fatiada antes do GO, nao durante.
+2. **`touch_paths` por tarefa.** O caminho que a tarefa vai tocar e declarado antes, e e ele que
+   justifica o lease `path:<glob>`. Regiao nao declarada e colisao esperando acontecer.
+3. **Um verify executavel por tarefa.** Toda tarefa carrega o comando que prova que ela terminou.
+   Tarefa sem verify e desejo, nao tarefa.
+4. **Decisoes D1..Dn com domicilio unico.** Cada decisao mora em um lugar so, e depois de decidida
+   fica travada. Reabrir e decisao nova com registro, nunca edicao silenciosa da anterior.
+5. **O que fica fora do escopo**, escrito, para que o CHECK possa chamar de scope creep o que
+   aparecer alem disso.
+
+## O que o nucleo verifica por voce
+
+O lease `path:<glob>` do `ork` recusa duas threads na mesma regiao e coloca a segunda em fila com
+posicao; o handoff tipado leva as decisoes fechadas para a fase seguinte sem depender de a sessao
+lembrar delas.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "O plano ja esta na minha cabeca, escrever atrasa" | Plano que nao esta em disco nao sobrevive a rotacao de janela, e a fase seguinte comeca adivinhando. |
+| "Essa tarefa e grande mas coesa, deixa inteira" | Tarefa maior que cinco arquivos volta a ser fatiada. Commit atomico e o que torna reversivel o que der errado. |
+| "Depois eu decido esse tradeoff, no meio do GO" | Tradeoff decidido no meio do GO e decidido sob pressa e sem registro. Decisao tem domicilio unico e trava ao fechar. |
+| "Escrever verify por tarefa e cerimonia" | Tarefa sem verify e desejo. Sem comando, "pronto" vira opiniao do agente e o CHECK nao tem contra o que comparar. |
+| "Nao preciso declarar touch_paths, e obvio onde vou mexer" | O lease sai do `touch_paths`. Regiao nao declarada e o caminho normal de duas threads se atropelarem. |
+
+## Bandeiras vermelhas
+
+- Tarefa sem comando de verify.
+- Tarefa que toca mais de cinco arquivos.
+- Decisao repetida em dois lugares do plano, com redacoes diferentes.
+- `touch_paths` ausente numa thread que roda em paralelo com outra.
+- PLAN que ja traz o codigo pronto: PLAN nao implementa.
+
+## Verificacao antes de sair da fase
+
+Tarefas fatiadas com verify, `touch_paths` declarados, decisoes com domicilio unico e travadas,
+fora de escopo escrito, e o gate de premissas resolvido pelo caminho que o modo exige. Ver
+`DoD 19` e `DoD 20`.

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

@@ -0,0 +1,68 @@
+---
+name: ship-release
+description: "Fase SHIP (F5): merge serializado por lease, atualizacao contra a base, push provado por comando e plano de rollback. Roteia para ork ship, que so entrega com push verificado no remoto."
+bucket: phases
+roteia: "ork ship <thread> --para <base>"
+license: MIT
+---
+
+# SHIP, entrega
+
+## O que esta skill e
+
+Um roteador fino da fase SHIP. Ela nao faz merge na mao, nao empurra branch por fora e nao decide
+sozinha que o push pode acontecer: ela chama `ork ship`, que serializa o merge por lease e **prova
+o push comparando o sha local com o que o remoto reporta**.
+
+## Como rotear
+
+```bash
+ork worktree sync <thread>                  # rebasa quando a base avancou
+ork gate approve <thread> push --por <quem> # autorizacao humana registrada
+ork ship <thread> --para main --dry-run     # ensaio: mostra tudo, nao toca em nada
+ork ship <thread> --para main --autorizar-push <quem>
+ork phase list <thread>                     # a prova: mergeSha, shaRemoto, pushVerificado
+```
+
+## O que o SHIP entrega
+
+1. **Merge serializado.** O lease `main-tree` faz uma thread por vez tocar a arvore de destino; as
+   outras entram em fila com posicao, em vez de disputarem o mesmo checkout.
+2. **Atualizacao contra a base mais recente**, com revalidacao completa sempre que a atualizacao
+   trouxe mudanca. Um veredito calculado antes da atualizacao descreve um diff que nao existe mais.
+3. **Push provado por comando.** O `ork` compara o sha local com `git ls-remote` no remoto e grava
+   `pushVerificado` no ledger. **Push relatado sem sha do remoto conta como push que nao aconteceu.**
+4. **Guarda de contrato.** Nada no diff final muda contrato publico versionado sem decisao de
+   classe 2 ratificada, e a guarda roda de novo depois da atualizacao contra a base.
+5. **Plano de rollback**, escrito antes do merge, com o comando exato de reversao.
+
+## O que o nucleo verifica por voce
+
+A policy `push_direto_na_base` e bloqueante: origem igual ao destino, ou origem igual a branch base
+do projeto, reprova antes de o `ork` tocar no remoto. Arvore de destino ocupada sai como
+`tree.blocked`; lease tomado por outra thread sai como `lease.busy`.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "Ja empurrei, deu certo" | Push provado por comando ou nao aconteceu. O sha do remoto e a evidencia; a sensacao de sucesso nao e. |
+| "Mergeio direto na base, e um commit so" | Push direto na base e policy bloqueante. Entrega sai da branch da thread, sempre. |
+| "A base andou mas o meu diff nao encosta nisso" | Atualize e revalide. Uma atualizacao pode trazer mudanca que toca contrato, e o veredito anterior descrevia outro diff. |
+| "Rollback eu penso se der problema" | Plano de rollback escrito antes do merge, ou o plano vai ser escrito sob pressao, em producao quebrada. |
+| "A fila esta lenta, faco o merge por fora" | Merge fora da fila e a colisao que a fila existe para impedir. Espere a posicao ou libere o lease com registro. |
+| "O modo e `#Classic`, entao push nao precisa de autorizacao" | Precisa: a autorizacao e antecipada e **registrada** no ledger, nao dispensada. Modo afrouxa quando o humano fala, nunca se ele fala. |
+
+## Bandeiras vermelhas
+
+- Merge sem relatorio de CHECK com veredito PASSOU.
+- Push sem `pushVerificado` no ledger.
+- Guarda de contrato rodada so antes da atualizacao contra a base.
+- Branch de thread ausente: a entrega saindo da propria base.
+- Nenhum plano de rollback no artefato da fase.
+
+## Verificacao antes de sair da fase
+
+Base atualizada e revalidada, guarda de contrato reexecutada no diff final, merge pela fila do
+lease, push com sha do remoto no ledger e plano de rollback escrito. Ver `DoD 12` a `DoD 15` e
+`SEC 12`.

package/skills/reviewers/code-reviewer/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: code-reviewer
+description: "Reviewer de codigo do CHECK: percorre os cinco eixos de code-review-axes.md sobre o diff da thread e devolve achados categorizados bloqueador, aviso ou sugestao. Nunca corrige o que encontra."
+bucket: reviewers
+roteia: "ork verify <thread> | references/code-review-axes.md"
+license: MIT
+---
+
+# Code Reviewer
+
+## O que esta skill e
+
+Um roteador fino que aplica [code-review-axes.md](../../../references/code-review-axes.md) ao diff
+da thread. **A separacao e a regra central: quem revisa nao corrige.** O achado vira tarefa de GO,
+com commit proprio, ou o revisor passa a revisar o proprio trabalho e a revisao deixa de existir.
+
+## Como rotear
+
+```bash
+ork worktree audit <thread>          # confere a worktree no proprio git
+ork verify <thread>                  # a suite reexecutada no HEAD real
+git diff <base>...HEAD               # o escopo declarado da revisao
+```
+
+## Escopo e conduta
+
+1. **O escopo e declarado antes dos achados:** qual diff, qual intervalo, quais arquivos.
+   Revisao sem escopo declarado nao e reproduzivel.
+2. **Os cinco eixos sao percorridos, todos.** Eixo sem achado sai com "nenhum" explicito; silencio
+   nao e evidencia de que se olhou.
+3. **Todo achado sai com exatamente uma categoria** e o item que ele viola, no formato `REVIEW 7`.
+   Achado sem categoria e opiniao.
+4. **Nada de reescrever o codigo do outro no meio da revisao.** O reviewer aponta o lugar, a razao
+   e o custo; a mudanca acontece no GO.
+
+## O que o nucleo verifica por voce
+
+Arquivo ou teste citado que nao existe no diff volta como `claims.failed` em `ork verify`; o
+revisor nao precisa acreditar no resumo do runtime, ele reexecuta.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "Ja que achei, corrijo aqui mesmo" | Quem revisa nao corrige. Revisor que edita passa a revisar o proprio trabalho, e a revisao vira formalidade. |
+| "O diff e grande, reviso so o que parece importante" | Escopo parcial e resultado parcial: declare o que ficou de fora, ou o relatorio afirma mais do que olhou. |
+| "Estilo eu deixo passar, nao e importante" | Estilo e sugestao, exceto quando quebra ferramenta do projeto, e ai ja e correcao. A regra e categorizar, nao ignorar. |
+| "Esse eixo nao se aplica a este diff" | Entao escreva "nenhum" e por que. Eixo em branco e indistinguivel de eixo esquecido. |
+| "Deixo como aviso para nao travar a entrega" | Categoria nao se negocia por pressa. Bloqueador rebaixado porque a entrega estava perto e o defeito de processo que o eixo existe para expor. |
+
+## Bandeiras vermelhas
+
+- Commit do reviewer dentro da branch que ele esta revisando.
+- Achado sem categoria, ou sem o `REVIEW n` que ele viola.
+- Relatorio sem escopo declarado.
+- Duplicacao apontada sem dizer de onde o codigo deveria vir.
+
+## Verificacao antes de sair da revisao
+
+Escopo declarado, cinco eixos preenchidos, cada achado com categoria e item, nenhuma edicao feita
+pelo reviewer, e o veredito consolidado entregue ao CHECK. Ver `REVIEW 1` a `REVIEW 12` e `DoD 8`.

package/skills/reviewers/security-auditor/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: security-auditor
+description: "Auditor de seguranca do CHECK: percorre security-checklist.md sobre o diff, o historico da branch e os artefatos da thread, com a condicao dura de zero bloqueadores. Nunca imprime o segredo que encontra."
+bucket: reviewers
+roteia: "ork verify <thread> | references/security-checklist.md"
+license: MIT
+---
+
+# Security Auditor
+
+## O que esta skill e
+
+Um roteador fino que aplica [security-checklist.md](../../../references/security-checklist.md) ao
+escopo da thread. A condicao de passagem e dura: **zero bloqueadores de seguranca, em qualquer modo
+de conducao, inclusive `#Auto`.**
+
+## Como rotear
+
+```bash
+git diff <base>...HEAD               # a arvore de trabalho
+git log -p <base>..HEAD              # o historico atras da branch
+ork phase list <thread>              # policies e gates ja registrados
+ork doctor                           # provider e ambiente da maquina
+```
+
+## Escopo e conduta
+
+1. **O escopo e declarado antes dos achados:** quais diretorios, qual intervalo de historico,
+   quais artefatos. Auditoria sem escopo declarado nao vale como evidencia.
+2. **Fixture de teste e config de exemplo estao no escopo.** Credencial em teste e credencial
+   vazada, com a agravante de ninguem olhar para la; `SEC 1` inclui `.env`, fixtures e exemplos.
+3. **O historico entra no escopo.** Segredo commitado e depois apagado continua vazado; a auditoria
+   le o intervalo, nao so a arvore.
+4. **Relatorio nao imprime credencial.** O achado nomeia o padrao, o arquivo e a linha, em forma
+   redigida. **Relatorio de vazamento que imprime o segredo e um segundo vazamento.**
+5. **Ausencia e afirmada como resultado**, com o que foi olhado: "nada encontrado" sem escopo e
+   diferente de "auditado e limpo", e a diferenca fica escrita.
+
+## O que o nucleo verifica por voce
+
+A policy `segredo_em_prompt` roda no gate `phase.dispatch` **antes de o prompt ser gravado em
+disco**: prompt reprovado nao chega a existir como arquivo. A policy `provider` bloqueia despacho
+por provider pago sob `subscription-only`, e a `push_direto_na_base` bloqueia entrega sem branch de
+thread. As tres reprovam em qualquer modo.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "A chave esta so no fixture de teste" | Fixture esta no escopo de `SEC 1`. Credencial em teste e credencial vazada, com a agravante de ninguem olhar para la. |
+| "Apaguei o commit que tinha o token" | Apagar da arvore nao apaga do historico. Bloqueador ate a credencial ser rotacionada e a rotacao verificada, nao prometida. |
+| "Colo o trecho no relatorio para o time ver" | Relatorio de vazamento que imprime o segredo e um segundo vazamento. Nomeie o padrao e a linha, redigido. |
+| "Esse bloqueador e teorico, ninguem exploraria" | Zero bloqueadores e condicao dura, nao negociavel por probabilidade estimada no olho. |
+| "A thread e `#Auto`, a auditoria pode ser mais leve" | O modo afrouxa a pausa, nunca a verificacao. A lista e a mesma; o que muda e quem espera pelo veredito. |
+
+## Bandeiras vermelhas
+
+- Relatorio de seguranca sem escopo e sem intervalo de historico.
+- Segredo real colado dentro do relatorio ou do ledger.
+- Achado sem o `SEC n` que ele viola.
+- "Nada encontrado" sem dizer o que foi olhado.
+- Dependencia nova sem justificativa no PLAN.
+
+## Verificacao antes de sair da auditoria
+
+Escopo declarado, arvore e historico varridos, artefatos da thread lidos, cada achado com categoria
+e `SEC n`, credencial nenhuma impressa, e zero bloqueadores para o veredito PASSOU. Ver `SEC 15` a
+`SEC 17` e `DoD 9`.