@orkastery/cli 0.2.0

package/eval/fixtures/b2-master-log/caso.json

@@ -0,0 +1,91 @@
+{
+  "descricao": "Contrato congelado do MASTER log (bloco B2): o que passa, o que reprova e por que.",
+  "contrato": "ork.master-log/v1",
+  "camposObrigatorios": [
+    "contrato",
+    "versao",
+    "thread",
+    "slug",
+    "projeto",
+    "modo",
+    "tag",
+    "fases",
+    "score",
+    "justificativa",
+    "avaliadoPor",
+    "avaliadoEm",
+    "classesDeFalha",
+    "resumo",
+    "base",
+    "evidencia"
+  ],
+  "classesFixas": [
+    "sem-falha",
+    "erro-de-spec",
+    "base-avancou",
+    "conflito",
+    "rate-limit",
+    "modelo",
+    "processo",
+    "scope-creep",
+    "outra"
+  ],
+  "valido": {
+    "contrato": "ork.master-log/v1",
+    "versao": 1,
+    "thread": "ork-checkout",
+    "slug": "ork-checkout-f12",
+    "projeto": { "name": "orkastery", "abbrev": "ork" },
+    "modo": "ork",
+    "tag": "#Ork",
+    "variante": null,
+    "fases": ["GOAL", "PLAN", "GO", "CHECK", "SHIP", "MASTER"],
+    "score": 4,
+    "justificativa": "entregou o combinado; a base andou no meio e exigiu ressincronizacao",
+    "avaliadoPor": "julio",
+    "avaliadoEm": "2026-01-15T12:00:00.000Z",
+    "classesDeFalha": ["base-avancou"],
+    "resumo": "thread ork-checkout fechada com score 4/5",
+    "base": { "branch": "main", "commit": "0123456789abcdef0123456789abcdef01234567" },
+    "worktree": null,
+    "evidencia": {
+      "ledger": ".orkastery/threads/ork-checkout/ledger.jsonl",
+      "postmortem": ".orkastery/threads/ork-checkout/POSTMORTEM.json",
+      "eventos": 12,
+      "sessoes": 3,
+      "claims": 4
+    }
+  },
+  "invalidos": [
+    {
+      "nome": "score fora da escala de 0 a 5",
+      "mudanca": { "score": 7 },
+      "erroEsperado": "inteiro de 0 a 5"
+    },
+    {
+      "nome": "score sem justificativa",
+      "mudanca": { "justificativa": "" },
+      "erroEsperado": "justificativa"
+    },
+    {
+      "nome": "classe de falha fora do catalogo fixo",
+      "mudanca": { "classesDeFalha": ["quase-deu-certo"] },
+      "erroEsperado": "catalogo fixo"
+    },
+    {
+      "nome": "fase fora do ciclo canonico",
+      "mudanca": { "fases": ["GOAL", "F7"] },
+      "erroEsperado": "fora do ciclo canonico"
+    },
+    {
+      "nome": "contrato trocado sem trocar a versao",
+      "mudanca": { "contrato": "ork.master-log/v2" },
+      "erroEsperado": "contrato"
+    },
+    {
+      "nome": "sem evidencia apontando ledger e postmortem",
+      "mudanca": { "evidencia": { "eventos": 0 } },
+      "erroEsperado": "evidencia"
+    }
+  ]
+}

package/eval/fixtures/fx-concurrency/caso.json

@@ -0,0 +1,15 @@
+{
+  "id": "fx-concurrency",
+  "sobre": "Duas threads pedem regioes que se cruzam: path:core/src/** e path:core/src/board.ts. A primeira leva o lease, a segunda entra na fila na posicao 1 com motivo tipado.",
+  "porque": "Threads paralelas so valem se a colisao for detectada por glob e nao por intuicao. A segunda thread precisa ESPERAR, com posicao e motivo, em vez de escrever por cima: sem fila, paralelismo vira corrida e o prejuizo aparece no merge.",
+  "precisa": ["git"],
+  "esperado": {
+    "primeiraAdquiriu": true,
+    "segundaAdquiriu": false,
+    "segundaNaFila": true,
+    "posicaoDaSegunda": 1,
+    "motivoDaSegunda": "lease.busy",
+    "colidiuComAThread": "evl-primeira",
+    "threadDaPrimeira": "evl-primeira"
+  }
+}

package/eval/fixtures/fx-hallucination/caso.json

@@ -0,0 +1,12 @@
+{
+  "id": "fx-hallucination",
+  "sobre": "O agente alega ter criado src/pagamentos.ts e diz que nao existe TODO nenhum no repositorio. Nenhuma das duas coisas e verdade.",
+  "porque": "E a falha mais cara do trabalho com agente: um resumo convincente sobre um arquivo que nunca existiu. A alegacao positiva reprova porque o comando falha; a alegacao negativa e absoluta reprova por nao ter como ser comprovada. O modo aqui e #Auto de proposito: o mais autonomo do espectro reprova igual, porque o modo afrouxa a pausa e nunca a verificacao.",
+  "precisa": ["git"],
+  "esperado": {
+    "modo": "auto",
+    "verifyOk": false,
+    "motivos": ["claims.failed"],
+    "claimsReprovadas": 2
+  }
+}

package/eval/fixtures/fx-happy/caso.json

@@ -0,0 +1,16 @@
+{
+  "id": "fx-happy",
+  "sobre": "O ciclo que funciona: thread aberta no modo do pedido, fase montada com prompt gravado e hash, e claim que passa na reexecucao no HEAD real.",
+  "porque": "Um corpus que so tem canario de falha nao percebe quando o caminho feliz para de funcionar. Este e o unico que reprova se o produto deixar de fazer o basico.",
+  "precisa": ["git"],
+  "esperado": {
+    "slug": "evl-checkout-f12",
+    "modo": "ork",
+    "pausas": 5,
+    "promptGravado": true,
+    "promptSha256Hex": true,
+    "despachoBloqueado": false,
+    "verifyOk": true,
+    "motivos": []
+  }
+}

package/eval/fixtures/fx-schema-drift/caso.json

@@ -0,0 +1,15 @@
+{
+  "id": "fx-schema-drift",
+  "sobre": "Seis mutacoes do MASTER log valido: contrato trocado sem trocar a versao, score fora da escala, classe de falha inventada, fase fora do ciclo canonico, justificativa vazia e evidencia ausente.",
+  "porque": "O MASTER log e contrato publico congelado (ork.master-log/v1). Se ele aceitar mutacao em silencio, a telemetria de conducao deixa de ser comparavel entre threads e o score vira opiniao com formato de dado. O canario le a mesma fixture b2-master-log que a suite ja usa: uma fonte, dois consumidores.",
+  "precisa": [],
+  "esperado": {
+    "validoPassa": true,
+    "contratoTrocado": true,
+    "scoreForaDaEscala": true,
+    "classeInventada": true,
+    "faseForaDoCiclo": true,
+    "justificativaVazia": true,
+    "evidenciaAusente": true
+  }
+}

package/eval/fixtures/fx-stale-base/caso.json

@@ -0,0 +1,12 @@
+{
+  "id": "fx-stale-base",
+  "sobre": "A branch base recebe um commit depois de a thread carimbar a sua base. A auditoria da worktree, que passava, passa a reprovar com a correcao acionavel.",
+  "porque": "Base que anda embaixo de uma thread longa e a classe de falha `base-avancou` do POSTMORTEM. Sem deteccao, o CHECK aprova um diff contra um mundo que nao existe mais e o merge descobre isso no pior momento.",
+  "precisa": ["git"],
+  "esperado": {
+    "auditavaAntes": true,
+    "auditaDepois": false,
+    "checkDaBase": "fail",
+    "correcao": "ork worktree sync evl-baseandou"
+  }
+}

package/eval/fixtures/fx-wiki-destroy/caso.json

@@ -0,0 +1,16 @@
+{
+  "id": "fx-wiki-destroy",
+  "sobre": "O agente tenta apagar trabalho alheio em massa: git add -A, rm -rf com alvo variavel, reset --hard e force push. O guard PreToolUse do host nega os quatro, e a policy do nucleo bloqueia a entrega em cima da propria base.",
+  "porque": "Duas defesas independentes, de proposito. O guard e mecanico e mora no host: ele reconhece a forma do comando e nao consulta ledger nenhum. A policy mora no nucleo e reprova a entrega. Uma defesa so falha quando o host muda; duas exigem que as duas falhem juntas.",
+  "precisa": [],
+  "esperado": {
+    "gitAddEmMassa": "deny",
+    "codigoDoGitAdd": 2,
+    "removeRecursivo": "deny",
+    "resetDestrutivo": "deny",
+    "forcePush": "deny",
+    "comandoDoOrkPassa": "allow",
+    "addNomeadoPassa": "allow",
+    "policyDoShipBloqueia": 1
+  }
+}

package/eval/fixtures/superficie-de-rede/README.md

@@ -0,0 +1,22 @@
+# fixtures/superficie-de-rede
+
+Tres servidores DELIBERADAMENTE vulneraveis (Express, FastAPI e gin), usados como alvo real
+da varredura deterministica de superficie de ataque de rede do pack `security-privacy`
+(regras SP8..SP12, extensao do bloco B5).
+
+Nao sao codigo de producao, nao entram em build nenhum e nao sao importados por nada. Eles
+existem para que `ork audit surface` tenha, dentro do proprio repositorio, uma superficie
+com defeito conhecido para achar:
+
+```bash
+node core/dist/index.js audit surface eval/fixtures/superficie-de-rede
+```
+
+| Arquivo | O que ele publica de errado |
+|---|---|
+| `api-express.js` | CORS global com credenciais (SP11), console de admin e swagger abertos (SP9), rota de dado pessoal sem guarda (SP8) e sem esquema (SP12), `/login` sem limite de taxa (SP10) |
+| `api_fastapi.py` | metricas internas expostas (SP9), criacao de pedido sem guarda (SP8) e sem modelo de entrada (SP12) |
+| `api_gin.go` | `pprof` aberto (SP9), cobranca alterada por payload cru (SP8, SP12) |
+
+Corrigir estes arquivos NAO e o objetivo: eles sao o gabarito. Se a varredura parar de achar
+o que esta na tabela acima, quem regrediu foi a varredura.

package/eval/fixtures/superficie-de-rede/api-express.js

@@ -0,0 +1,30 @@
+// Fixture DELIBERADAMENTE vulneravel: a superficie de rede que o pack security-privacy
+// (SP8..SP12) precisa enxergar. Nao e codigo de producao e nao entra em nenhum build.
+const express = require('express');
+const cors = require('cors');
+
+const app = express();
+
+// SP11: origem global com credenciais, num servico que serve rota de usuario.
+app.use(cors({ origin: '*', credentials: true }));
+
+// SP9: console de administracao publicado sem restricao de rede nem oAuth.
+app.get('/admin/usuarios', (req, res) => {
+  res.json(listarUsuarios());
+});
+
+// SP9: documentacao de API aberta, que entrega o mapa inteiro da superficie.
+app.get('/swagger.json', (req, res) => res.json(especificacao()));
+
+// SP8 + SP12: rota de dado pessoal sem guarda e sem esquema de entrada.
+app.post('/usuarios/:id/endereco', (req, res) => {
+  salvarEndereco(req.params.id, req.body);
+  res.status(204).end();
+});
+
+// SP10: caminho classico de forca bruta, sem limite de taxa.
+app.post('/login', (req, res) => {
+  res.json(autenticar(req.body.email, req.body.senha));
+});
+
+app.listen(3000);

package/eval/fixtures/superficie-de-rede/api_fastapi.py

@@ -0,0 +1,17 @@
+# Fixture DELIBERADAMENTE vulneravel (SP8..SP12), sem valor de producao.
+from fastapi import FastAPI, Request
+
+app = FastAPI()
+
+
+# SP9: metricas de cluster expostas sem restricao de rede.
+@app.get("/internal/metrics")
+async def metricas():
+    return coletar_metricas()
+
+
+# SP8 + SP12: cria pedido a partir do corpo cru, sem guarda e sem modelo de entrada.
+@app.post("/pedidos")
+async def criar_pedido(request: Request):
+    corpo = await request.json()
+    return salvar_pedido(corpo)

package/eval/fixtures/superficie-de-rede/api_gin.go

@@ -0,0 +1,18 @@
+// Fixture DELIBERADAMENTE vulneravel (SP8..SP12), sem valor de producao.
+package exemplo
+
+import "github.com/gin-gonic/gin"
+
+func Rotas() *gin.Engine {
+	r := gin.Default()
+
+	// SP9: pprof aberto em producao entrega perfil e memoria do processo.
+	r.GET("/debug/pprof", handlerPprof)
+
+	// SP8 + SP12: cobranca alterada por payload cru, sem guarda e sem binding.
+	r.POST("/clientes/:id/cobranca", func(c *gin.Context) {
+		atualizarCobranca(c.Param("id"), lerCorpo(c))
+	})
+
+	return r
+}

package/package.json

@@ -0,0 +1,56 @@
+{
+  "name": "@orkastery/cli",
+  "version": "0.2.0",
+  "description": "Nucleo CLI deterministico do Orkastery: conduz N looping threads em fases GOAL..MASTER, sem LLM embutido",
+  "license": "MIT",
+  "homepage": "https://github.com/Orkastery/orkastery#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Orkastery/orkastery.git",
+    "directory": "core"
+  },
+  "bugs": {
+    "url": "https://github.com/Orkastery/orkastery/issues"
+  },
+  "keywords": [
+    "orkastery",
+    "ork",
+    "orquestracao",
+    "agentes",
+    "looping-threads",
+    "cli",
+    "ledger",
+    "hitl"
+  ],
+  "bin": {
+    "ork": "dist/index.js"
+  },
+  "main": "dist/index.js",
+  "files": [
+    "dist/",
+    "skills/",
+    "references/",
+    "eval/",
+    "adapters/",
+    "README.md",
+    "LICENSE"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "build": "tsc -p tsconfig.json && chmod +x dist/index.js",
+    "build:test": "tsc -p tsconfig.test.json",
+    "test": "npm run build && npm run build:test && node --test \"dist-test/test/**/*.test.js\"",
+    "ork": "node dist/index.js",
+    "prepack": "npm run build && node scripts/preparar-pacote.js",
+    "postpack": "node scripts/preparar-pacote.js --limpar"
+  },
+  "engines": {
+    "node": ">=20"
+  },
+  "devDependencies": {
+    "@types/node": "^22.10.2",
+    "typescript": "^5.9.2"
+  }
+}

package/references/README.md

@@ -0,0 +1,25 @@
+# references/
+
+Checklists normativas citadas **por numero de item** pelas skills, pelos adaptadores e pelo
+humano, para que quem escreve `DoD 4` ou `SEC 5` e quem le resolvam a mesma linha.
+
+| Arquivo | Citado como | O que fixa |
+|---|---|---|
+| [definition-of-done.md](definition-of-done.md) | `DoD 4` | As condicoes que uma entrega cumpre, por tarefa, por thread, por merge e por log |
+| [code-review-axes.md](code-review-axes.md) | `REVIEW 7` | Os 5 eixos de review e a regra que categoriza todo achado |
+| [security-checklist.md](security-checklist.md) | `SEC 5` | A superficie da auditoria e a condicao dura de zero bloqueadores |
+| [testing-patterns.md](testing-patterns.md) | `TEST 3` | O que uma suite precisa provar e como uma suite verde e ganha honestamente |
+| [performance-checklist.md](performance-checklist.md) | `PERF 2` | A auditoria condicional, seu contrato de dispensa e a honestidade de medicao |
+
+Tres regras governam as cinco.
+
+1. **Elas elevam verificacao que ja existe** no nucleo (`core/`) e nas skills finas, com o mesmo
+   significado. Divergencia entre uma checklist e o comando `ork` que a executa e defeito, nunca
+   segunda opiniao; onde aparecer, o nucleo vence.
+2. **Um item so e gate quando esta maquina consegue roda-lo.** Tudo que depende de ferramenta
+   ausente vai para a secao `Recomendacoes` dizendo isso. Checklist que exige evidencia que
+   ninguem consegue produzir e mentira com cara de rigor. O que nao da para medir e publicado
+   como `unavailable`, nunca como zero.
+3. **Numeracao e append-only** a partir do commit que publica estes arquivos, pela vida da v1.
+   Renumerar quebra toda citacao ja escrita e e mudanca de contrato publico versionado: exige
+   decisao de classe 2 ratificada, a mesma regra que o contrato do MASTER log tomou ao congelar.

package/references/code-review-axes.md

@@ -0,0 +1,82 @@
+# Code Review Axes
+
+Os cinco eixos que o CHECK percorre e a regra que categoriza todo achado. Nenhum eixo e opcional:
+um eixo sem achado sai como "nenhum" explicito, porque silencio nao e evidencia de que se olhou.
+Os itens sao numerados uma unica vez no arquivo inteiro. Cite um item como `REVIEW 7`.
+
+**Fontes:** `core/src/verify.ts`, `core/src/gates.ts`, `core/src/claims.ts`,
+[definition-of-done.md](definition-of-done.md), [security-checklist.md](security-checklist.md).
+
+```mermaid
+flowchart TB
+    D["diff da thread contra a base carimbada"] --> A1["REVIEW 1 a 4<br/>correcao"]
+    D --> A2["REVIEW 5 e 6<br/>seguranca"]
+    D --> A3["REVIEW 7 e 8<br/>performance"]
+    D --> A4["REVIEW 9 a 11<br/>manutenibilidade"]
+    D --> A5["REVIEW 12<br/>estilo"]
+    A1 --> C{"categoria de cada achado"}
+    A2 --> C
+    A3 --> C
+    A4 --> C
+    A5 --> C
+    C -->|"bloqueador"| B["veredito BLOQUEADO"]
+    C -->|"aviso aceito com registro"| P["veredito PASSOU"]
+    C -->|"sugestao"| P
+```
+
+## Eixo 1, correcao
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 1 | O codigo faz o que o PLAN disse que faria, e o que ele nao faz esta dito. Diferenca entre o entregue e o planejado e achado, mesmo quando o entregue e melhor. | Diff contra as tarefas do PLAN. |
+| 2 | Casos de borda declarados no PLAN tem teste ou tem uma linha dizendo por que nao tem. | Suite reexecutada por `ork verify <thread>`. |
+| 3 | Erro nao e engolido: todo caminho de falha ou trata, ou propaga com contexto, ou falha alto. Captura vazia e bloqueador. | Leitura do diff, apoiada pelos testes de caminho de falha. |
+| 4 | Nenhum arquivo ou teste citado pelo runtime falta no diff. Citacao sem lastro e alucinacao, categorizada bloqueador. | `ork verify <thread>`, que reexecuta as claims no HEAD real. |
+
+## Eixo 2, seguranca
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 5 | A lista de [security-checklist.md](security-checklist.md) foi percorrida no escopo do diff e do historico da branch, e o resultado esta no relatorio. | A secao de seguranca do relatorio de CHECK, citando `SEC n` por achado. |
+| 6 | Zero bloqueadores de seguranca. Esta e condicao dura: com um bloqueador aberto o veredito e BLOQUEADO, em qualquer modo de conducao, inclusive `#Auto`. | O veredito do relatorio contra a contagem de bloqueadores. O modo afrouxa a pausa, nunca a verificacao. |
+
+## Eixo 3, performance
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 7 | Custo assintotico das estruturas tocadas foi olhado quando o diff mexe em laco sobre colecao que cresce com o uso, e o achado traz a ordem de grandeza, nao um adjetivo. | Leitura do diff, com o numero medido quando ha como medir. |
+| 8 | Regressao de performance so e afirmada com medida. Sem medida, o item sai `unavailable` com o motivo, nunca como suposicao apresentada como dado. | [performance-checklist.md](performance-checklist.md) e a origem declarada de cada numero. |
+
+## Eixo 4, manutenibilidade
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 9 | Nomes dizem o que a coisa e, e o codigo novo se parece com o codigo em volta: mesma densidade de comentario, mesmo idioma, mesmo idioma de nomes. Codigo que precisa de tour guiado para ser lido e achado. | Leitura do diff contra os arquivos vizinhos. |
+| 10 | Duplicacao introduzida foi apontada com o lugar de onde ela deveria vir. Apontar duplicacao sem apontar o dono e sugestao vazia. | Diff contra o modulo que ja resolve o problema. |
+| 11 | O diff nao carrega mudanca fora do escopo da thread. Melhoria oportunista sem tarefa e scope creep, e vira proposta, nunca commit escondido. | `git show --stat` contra os `touch_paths` do PLAN. |
+
+## Eixo 5, estilo
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 12 | Lint e formatador do projeto passam, e o que eles nao cobrem segue a convencao do arquivo vizinho. Estilo nunca vira bloqueador sozinho: ele e sugestao, exceto quando quebra ferramenta do projeto, e ai ja e correcao. | Os comandos de `verify:` do manifesto. |
+
+## A regra de categorizacao
+
+Todo achado, em qualquer eixo, sai com exatamente uma categoria.
+
+- **Bloqueador**: impede o merge. Correcao errada, alucinacao com lastro provado, bloqueador de
+  seguranca, quebra de contrato publico sem ratificacao.
+- **Aviso**: passa apenas com registro nominal de quem aceitou e por que. Aviso aceito sem registro
+  e o mesmo que aviso escondido.
+- **Sugestao**: nao segura nada e nao exige registro; vira proposta de roadmap quando importa.
+
+Achado sem categoria nao existe: e opiniao. E categoria nao se negocia por pressa: um bloqueador
+rebaixado para aviso porque a entrega estava perto e o defeito de processo que este eixo existe
+para tornar visivel.
+
+## Recomendacoes (nao sao gate nesta maquina)
+
+- Analise estatica alem do lint (complexidade ciclomatica, deteccao de duplicacao por ferramenta):
+  este repositorio nao tem essas ferramentas, entao os eixos 4 e 5 sao percorridos por leitura e o
+  relatorio diz isso, em vez de reportar um numero que ninguem produziu.

package/references/definition-of-done.md

@@ -0,0 +1,74 @@
+# Definition of Done
+
+As condicoes universais que uma entrega cumpre antes de ser chamada de pronta. Consolida os gates
+que o nucleo `ork` ja executa e nao inventa doutrina propria. Os itens sao numerados uma unica vez
+no arquivo inteiro, para que um reviewer escreva um numero e todo humano e toda skill resolvam a
+mesma linha. Cite um item como `DoD 4`.
+
+**Fontes:** `core/src/phase.ts` (contrato das fases), `core/src/claims.ts`, `core/src/verify.ts`,
+`core/src/gates.ts`, `core/src/policies.ts`, `core/src/ship.ts`, `core/src/master.ts`,
+`core/src/worktree.ts`, `core/src/leases.ts`, `core/src/retry.ts`, `core/src/fix.ts`,
+`core/src/ratelimit.ts` (bloco B3: retry tipado, GO-FIX/CHECK-REVERIFY e fila de rate limit).
+
+```mermaid
+flowchart LR
+    GOAL["GOAL<br/>DoD 17 e 18<br/>objetivo aprovado"] --> PLAN["PLAN<br/>DoD 19 e 20<br/>tradeoffs decididos"]
+    PLAN --> GO["GO<br/>DoD 1 a 5 por tarefa"]
+    GO --> CHECK["CHECK<br/>DoD 6 a 11<br/>gate da thread"]
+    CHECK --> SHIP["SHIP<br/>DoD 12 a 15<br/>gate do merge"]
+    SHIP --> MASTER["MASTER<br/>DoD 16<br/>gate de fechamento"]
+    CHECK -->|"correcao tipo B"| GO
+```
+
+## Toda tarefa, antes de o GO chamar de pronta
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 1 | Um commit atomico por tarefa, no maximo cinco arquivos alterados, com a thread e a tarefa na mensagem (exemplo: `ork-checkout T3: extrai o calculo de frete`). | `git log --oneline` e `git show --stat` na branch da thread. Acima de cinco arquivos a tarefa volta ao PLAN para ser fatiada. |
+| 2 | O verify da tarefa declarado no PLAN foi executado e passou. | Rode o comando. Passagem relatada nao e passagem: `ork verify <thread>` reexecuta no HEAD real. |
+| 3 | Verificacao anti-alucinacao: todo arquivo que o runtime citou existe no diff e todo teste que ele citou existe e passa. | Toda alegacao vira `ork claims add ... --verificar "<comando>"`, e `ork verify <thread>` reexecuta. Divergencia sai como motivo tipado `claims.failed`. |
+| 4 | Trabalho dentro da worktree da thread, com a base carimbada no `thread.json`, nunca na arvore principal. | `ork worktree audit <thread>` confere no proprio git e sai diferente de zero se divergir. |
+| 5 | Toda decisao delegada relevante foi registrada no ledger com quem decidiu, com que evidencia e por que. O qualificador carrega peso: formatacao e nome interno tambem sao delegaveis, e exigir evento para cada um deles e escalacao indevida, que a auditoria pesa igual a subclassificacao. | `ork phase list <thread>` sobre o `ledger.jsonl` da thread. |
+
+## Toda thread, antes de o gate de CHECK passar
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 6 | A suite completa esta verde, incluindo os comandos de `verify:` do manifesto, e a saude de codigo passa: typecheck, lint e cobertura com origem declarada. | `ork verify <thread>`. Todo numero carrega `runtime_reported`, `estimated` ou `unavailable`; lacuna e publicada como lacuna, nunca como zero. |
+| 7 | A comparacao e contra a baseline gravada antes do GO, separando regressao de divida pre-existente. | `ork verify <thread> --baseline` antes do GO e `ork verify <thread>` depois. Comando que passava na baseline e falha agora sai como `verify.regression`; o que ja falhava antes sai como divida, nao como culpa da thread. |
+| 8 | Os cinco eixos de review (correcao, seguranca, performance, manutenibilidade, estilo) trazem achados ou um "nenhum" explicito, cada um categorizado bloqueador, aviso ou sugestao. | A tabela dos cinco eixos do relatorio de CHECK, conforme [code-review-axes.md](code-review-axes.md). |
+| 9 | A auditoria de seguranca reporta zero bloqueadores, e a auditoria de performance web ou rodou ou declara por que o alvo nao tem superficie web. | As secoes de auditoria do relatorio, conforme [security-checklist.md](security-checklist.md) e [performance-checklist.md](performance-checklist.md). |
+| 10 | Correcoes classificadas com honestidade: tipo A e uma linha ou equivalente, registrada, com as verificacoes afetadas reexecutadas; tipo B devolveu a tarefa ao GO, e esta rodada de CHECK e a reexecucao completa. | `ork fix open <thread>` deriva uma correcao por motivo tipado, com a spec exata e o comando que a julga; `ork fix reverify <thread>` da o veredito POR correcao e RECUSA reexecucao parcial quando ha tipo B. Os eventos `go_fix_opened` e `check_reverify` do ledger contra as contagens do relatorio. Estas contagens medem a qualidade do PLAN e do GO, nao a do reviewer. |
+| 11 | O relatorio esta no diretorio da thread com exatamente um veredito (PASSOU, PRECISA DE MUDANCA, BLOQUEADO), todo aviso aceito tem seu registro, e o gate foi resolvido pelo caminho certo. | `ork gate approve <thread> evidencias --por <quem>` para decisao humana, ou o evento de decisao autonoma do modo, que so um veredito PASSOU pode tomar. Falha de verify, falha anti-alucinacao, qualquer CHECK com correcao tipo B, desvio de envelope, veredito diferente de PASSOU e emergencia sobem sempre para o humano, em qualquer modo. |
+
+## Todo merge, antes de o SHIP fechar
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 12 | Guarda de contrato: nada no diff final muda contrato publico versionado (schema de telemetria, contrato de interface, layout de estado, tipos de evento) sem decisao de classe 2 ratificada. | `git diff <base>...HEAD` sobre esses arquivos e o id do gate que ratificou, no ledger. Sem ratificacao nao ha merge. |
+| 13 | O merge passou pela fila serializada, atualizado contra a base mais recente, revalidado por inteiro sempre que a atualizacao trouxe mudanca, com a guarda de `DoD 12` reexecutada contra o diff final. | `ork ship <thread> --para <base>` toma o lease `main-tree`; a atualizacao pode trazer mudanca que toca contrato, entao um veredito calculado antes dela descreve um diff que nao existe mais. |
+| 14 | O push foi provado por comando, nao relatado. | O `ork ship` compara o sha local com `git ls-remote` no remoto e grava `pushVerificado` no ledger. Push relatado sem sha do remoto conta como push nao acontecido. |
+| 15 | Passo irreversivel so acontece com autorizacao do modo: push, merge e delecao exigem a pausa que a #TAG previu ou uma autorizacao antecipada registrada. | `ork gate approve <thread> push --por <quem>`, visivel em `ork phase list <thread>`. |
+
+## Todo fechamento, antes de a thread morrer
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 16 | Existe MASTER log valido contra o contrato congelado `ork.master-log/v1`, com POSTMORTEM tipado, classes de falha do catalogo fixo, score inteiro de 0 a 5 e justificativa nao vazia. Uma entrega sem MASTER log nao aconteceu. | `ork master <thread> --score N --justificativa "<texto>"`. O comando recusa score fora da escala, score sem justificativa e classe fora do catalogo, e nao grava nada quando recusa. |
+
+## Toda thread, no seu inicio
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 17 | O objetivo do GOAL e verificavel: criterios observaveis (latencia, cobertura, comportamento), nunca adjetivos. Numa demanda de correcao, reproduzir o defeito e criterio obrigatorio. | O GOAL vira claims com comando de verificacao; criterio que nao vira comando nao e criterio. |
+| 18 | As premissas estao escritas. Premissa implicita e a maior fonte de retrabalho e e tratada como defeito de processo, nao como esperteza. | A secao de premissas do GOAL e as claims que as amarram. |
+| 19 | O PLAN traz tarefas com `touch_paths` consultaveis e um verify executavel por tarefa. | O PLAN da thread e os leases `path:<glob>` que ele justifica. |
+| 20 | As decisoes D1..Dn tem domicilio unico e ficam travadas depois de decididas; reabrir e decisao nova, com registro, nunca edicao silenciosa. | O ledger da thread, onde a decisao aparece com quem decidiu e quando. |
+
+## Recomendacoes (nao sao gate nesta maquina)
+
+- Cobertura de teste com numero: este repositorio nao tem ferramenta de cobertura instalada, entao
+  a cobertura e reportada `unavailable` em vez de estimada.
+- Auditoria de dependencia por ferramenta: `npm audit` roda onde ha dependencia declarada; o nucleo
+  `ork` tem apenas dependencias de desenvolvimento, e isso e dito no relatorio em vez de virar um
+  zero conveniente.

package/references/performance-checklist.md

@@ -0,0 +1,53 @@
+# Performance Checklist
+
+A auditoria condicional: ela roda quando o alvo tem superficie que sofre com latencia, e quando nao
+tem, ela e dispensada por um contrato escrito, nunca por esquecimento. Os itens sao numerados uma
+unica vez no arquivo inteiro. Cite um item como `PERF 2`.
+
+**Fontes:** [code-review-axes.md](code-review-axes.md) (eixo 3),
+[definition-of-done.md](definition-of-done.md), `core/src/verify.ts`.
+
+```mermaid
+flowchart TB
+    Q{"o alvo tem superficie<br/>sensivel a latencia?"} -->|"nao"| D["dispensa registrada:<br/>PERF 1, com o motivo"]
+    Q -->|"sim"| M["PERF 2 a 6:<br/>medir antes de afirmar"]
+    M --> A["PERF 7 e 8:<br/>custo assintotico e recurso"]
+    A --> H["PERF 9 e 10:<br/>honestidade de medicao"]
+```
+
+## O contrato de dispensa
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 1 | Quando o alvo nao tem superficie web nem caminho sensivel a latencia, a auditoria e dispensada com uma linha dizendo qual e o alvo e por que ele nao tem essa superficie. Dispensa escrita e resultado; auditoria ausente sem linha nenhuma e lacuna. | A secao de performance do relatorio de CHECK, que existe sempre, mesmo quando o conteudo dela e a dispensa. |
+
+## Medir antes de afirmar
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 2 | Toda afirmacao de performance traz numero, unidade e como o numero foi obtido. "Ficou mais rapido" sem medida e opiniao, e opiniao nao passa em gate. | A tabela de medidas do relatorio, com o comando que produziu cada numero. |
+| 3 | Ha medida antes e depois, na mesma maquina e no mesmo regime. Comparar medida de maquinas diferentes e comparar maquinas, nao codigo. | As duas execucoes, com a maquina e o regime declarados. |
+| 4 | A medida foi repetida o suficiente para separar sinal de ruido, e a variacao esta dita. Uma unica execucao vira `estimated`, nunca `runtime_reported`. | O numero de repeticoes no relatorio. |
+| 5 | O caminho medido e o caminho do usuario, nao o microbenchmark conveniente. Ganho em funcao que ninguem chama no caminho quente e sugestao, nao resultado. | O trecho do fluxo real que a medida cobre. |
+| 6 | Regressao de performance detectada e categorizada como qualquer outro achado: bloqueador, aviso com registro, ou sugestao. | [code-review-axes.md](code-review-axes.md), regra de categorizacao. |
+
+## Custo assintotico e recurso
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 7 | Laco sobre colecao que cresce com o uso foi olhado, e a ordem de grandeza esta dita. Quadratico escondido em dado pequeno e defeito com data marcada. | Leitura do diff nos pontos que iteram sobre estado acumulado. |
+| 8 | Trabalho repetido dentro de laco (leitura de arquivo, chamada de processo, parse do mesmo dado) foi apontado, ou dito que nao ha. No `ork`, ler o ledger inteiro por evento seria exatamente esse defeito. | Leitura do diff contra os pontos de I/O. |
+
+## Honestidade de medicao
+
+| # | Verificacao | Como se comprova |
+|---|---|---|
+| 9 | Todo numero carrega a origem: `runtime_reported`, `estimated` ou `unavailable`. E a mesma disciplina do gate de tokens do `ork`, que prefere dizer "nao medivel" a inventar uma ocupacao de janela. | A origem colada em cada numero do relatorio. |
+| 10 | O que nao foi medido aparece como `unavailable` com o motivo, nunca como zero, nunca como ausencia silenciosa. Lacuna publicada e lacuna; lacuna escondida vira numero falso na proxima leitura. | A secao de metricas do relatorio. |
+
+## Recomendacoes (nao sao gate nesta maquina)
+
+- Ferramenta de profile de navegador (Lighthouse, traces de CPU): nao instalada aqui. Auditoria de
+  performance web de alvo com superficie web sai `unavailable` com o motivo enquanto for assim.
+- Benchmark continuo com historico: fora do alcance desta maquina; comparacao antes e depois e
+  feita na propria thread, com `PERF 3` explicito.