@orkastery/cli 0.5.6 → 0.6.1

package/eval/fixtures/security-scan/js/package.json

@@ -0,0 +1,10 @@
+{
+  "name": "fixture-js",
+  "version": "1.0.0",
+  "private": true,
+  "license": "MIT",
+  "dependencies": {
+    "express": "4.21.2",
+    "lodash": "4.17.20"
+  }
+}

package/eval/fixtures/security-scan/js/src/config.js

@@ -0,0 +1,4 @@
+// Fake credential, not a real one. Deliberately committed so the secret scanners have something to find.
+module.exports = {
+  apiKey: 'q7Zk2WmX9vB4nR8tLp3YdHs6JfC1aGe5',
+};

package/eval/fixtures/security-scan/js/src/server.js

@@ -0,0 +1,17 @@
+const express = require('express');
+const { exec } = require('node:child_process');
+const _ = require('lodash');
+
+const app = express();
+
+app.get('/ls', function (req, res) {
+  // Command injection: user input reaches a shell.
+  exec('ls ' + req.query.dir, (err, out) => res.send(_.escape(out)));
+});
+
+app.get('/calc', function (req, res) {
+  // Code injection: user input reaches eval.
+  res.send(String(eval(req.query.expr)));
+});
+
+app.listen(8080);

package/eval/fixtures/security-scan/js/src/util.ts

@@ -0,0 +1,4 @@
+export function parse(text: string) {
+  const data: any = JSON.parse(text);
+  return data.value;
+}

package/eval/fixtures/security-scan/js/tsconfig.json

@@ -0,0 +1,4 @@
+{
+  "compilerOptions": { "target": "ES2022", "module": "commonjs", "strict": true, "noEmit": true },
+  "include": ["src/**/*.ts"]
+}

package/eval/fixtures/security-scan/python/.github/workflows/ci.yml

@@ -0,0 +1,12 @@
+name: ci
+on:
+  pull_request_target:
+    branches: [main]
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: ${{ github.event.pull_request.head.sha }}
+      - run: echo "building ${{ github.event.pull_request.title }}"

package/eval/fixtures/security-scan/python/Dockerfile

@@ -0,0 +1,3 @@
+FROM python:latest
+COPY . /app
+CMD ["python", "/app/app/main.py"]

package/eval/fixtures/security-scan/python/README.md

@@ -0,0 +1,4 @@
+# python fixture
+
+Deliberately vulnerable and fake. Never run or deploy. It carries a fake secret, a dependency with a known CVE
+(`requests` 2.19.1 in `requirements.txt`), a command injection, an unsafe workflow, a Dockerfile that runs as root and a lint finding.

package/eval/fixtures/security-scan/python/app/config.py

@@ -0,0 +1,2 @@
+# Fake credential, not a real one. Deliberately committed so the secret scanners have something to find.
+API_KEY = "m4Xv8Qz2LkR7wTn3Bc9YdHs6JfP1aGe5"

package/eval/fixtures/security-scan/python/app/main.py

@@ -0,0 +1,19 @@
+import os
+import subprocess
+import sys
+
+import yaml
+from flask import Flask, request
+
+app = Flask(__name__)
+
+
+@app.route("/run")
+def run():
+    # Command injection: user input reaches a shell.
+    subprocess.call("ls " + request.args.get("dir"), shell=True)
+    return "ok"
+
+
+if __name__ == "__main__":
+    app.run(debug=True)

package/eval/fixtures/security-scan/python/requirements.txt

@@ -0,0 +1 @@
+requests==2.19.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@orkastery/cli",
-  "version": "0.5.6",
+  "version": "0.6.1",
   "description": "A software factory of AI agents that proves its work: parallel threads, verified results, and short decisions only when they matter.",
   "license": "MIT",
   "homepage": "https://github.com/orkastery/orkastery#readme",
@@ -42,6 +42,7 @@
     "!adapters/**/test/",
     "!adapters/**/__pycache__/",
     "!adapters/claude-code/ACTIVATION.md",
+    "!assets/adapters-en/claude-code/ACTIVATION.md",
     "monitor/",
     "!monitor/*.test.cjs",
     "!monitor/pulse-write-scope.json",
@@ -52,10 +53,13 @@
     "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",
+    "build": "tsc --build tsconfig.json && chmod +x dist/index.js",
+    "build:test": "tsc --build tsconfig.test.json",
+    "test": "npm run build && npm run build:test && node scripts/casa-temporaria.cjs node --test dist-test/test/*.test.js",
     "test:ci": "npm run build && npm run build:test && node scripts/test-ci.js",
+    "test:hermetica": "node scripts/test-lanes.cjs hermetica",
+    "test:integracao": "node scripts/test-lanes.cjs integracao",
+    "preparo:tsgo": "node scripts/preparo-tsgo.cjs",
     "ork": "node dist/index.js",
     "prepack": "npm run build && node scripts/preparar-pacote.js",
     "postpack": "node scripts/preparar-pacote.js --limpar"
@@ -65,10 +69,11 @@
   },
   "devDependencies": {
     "@types/node": "^22.10.2",
+    "@typescript/native-preview": "7.0.0-dev.20260707.2",
     "markdownlint-cli2": "^0.22.1"
   },
   "dependencies": {
-    "@modelcontextprotocol/sdk": "1.29.0",
+    "@modelcontextprotocol/sdk": "1.32.2",
     "decode-named-character-reference": "1.3.0",
     "micromark": "4.0.2",
     "micromark-extension-gfm-table": "2.1.1",

package/references/security-checklist.md

@@ -27,8 +27,8 @@ flowchart TB
 
 | # | Verificacao | Como se comprova |
 |---|---|---|
-| 1 | Nenhum segredo na arvore de trabalho: token, chave de API, senha, bloco de chave privada, string de conexao e string de alta entropia com cara de credencial, incluindo arquivos `.env`, fixtures de teste e configs de exemplo. | Leitura do diff da branch mais varredura da arvore. O relatorio nomeia a ferramenta usada ou diz que a passagem foi manual. |
-| 2 | Nenhum segredo no historico atras da branch. Segredo commitado e depois apagado continua vazado. | `git log -p <base>..HEAD` sobre o intervalo inteiro, nao so a arvore. Bloqueador ate a credencial ser rotacionada e o historico limpo, com a rotacao verificada e nao prometida. |
+| 1 | Nenhum segredo na arvore de trabalho: token, chave de API, senha, bloco de chave privada, string de conexao e string de alta entropia com cara de credencial, incluindo arquivos `.env`, fixtures de teste e configs de exemplo. | Leitura do diff da branch mais varredura da arvore. O relatorio nomeia a ferramenta usada ou diz que a passagem foi manual. Com `verify.security_scan` declarado, a evidencia e o `security_scan` (Gitleaks na arvore); a passagem manual so vale com o scan `unavailable` declarado. |
+| 2 | Nenhum segredo no historico atras da branch. Segredo commitado e depois apagado continua vazado. | `git log -p <base>..HEAD` sobre o intervalo inteiro, nao so a arvore. Bloqueador ate a credencial ser rotacionada e o historico limpo, com a rotacao verificada e nao prometida. Com `verify.security_scan` declarado, o `security_scan` varre tambem os commits de `<base>..HEAD`; a passagem manual so vale com o scan `unavailable` declarado. |
 | 3 | Nenhuma credencial real em prompt despachado. O gate `phase.dispatch` do `ork` avalia a policy `segredo_em_prompt` ANTES de gravar o prompt em disco: prompt reprovado nao chega a existir como arquivo, porque gravar um prompt com credencial cria um segundo vazamento dentro do proprio repositorio. | `ork phase run` sai com motivo tipado `policy.violation`; o ledger registra o nome do padrao e a linha, nunca o trecho casado. |
 | 4 | Nenhuma credencial real em artefato de thread, ledger, saida de comando capturada ou no proprio relatorio de auditoria. Relatorio de vazamento que imprime o segredo e um segundo vazamento. | Leitura dos artefatos que a thread produziu. Placeholder redigido passa e e declarado como tal; credencial e referenciada por localizacao e forma redigida. |
 
@@ -46,7 +46,7 @@ flowchart TB
 | # | Verificacao | Como se comprova |
 |---|---|---|
 | 9 | Nenhuma dependencia nova sem justificativa no PLAN. Dependencia que entra sem tarefa e scope creep com superficie de ataque. | Diff dos arquivos de manifesto de pacote contra as tarefas do PLAN. |
-| 10 | Vulnerabilidade conhecida nas dependencias declaradas foi consultada, e o resultado esta no relatorio com a data e a ferramenta. Onde nao ha ferramenta, o item sai `unavailable` com o motivo. | `npm audit` onde ha dependencia de producao declarada. |
+| 10 | Vulnerabilidade conhecida nas dependencias declaradas foi consultada, e o resultado esta no relatorio com a data e a ferramenta. Onde nao ha ferramenta, o item sai `unavailable` com o motivo. | `npm audit` onde ha dependencia de producao declarada. Com `verify.security_scan` declarado, a evidencia e o `security_scan` (dependencias e `reachable` do govulncheck); a passagem manual so vale com o scan `unavailable` declarado. |
 
 ## Artefatos do repositorio
 

package/skills/README.md

@@ -17,6 +17,7 @@ faz, o nucleo vence, e a divergencia e defeito da skill.
 | phases | [plan-specification](phases/plan-specification/SKILL.md) | `ork phase run <t> PLAN`, `ork lease acquire` |
 | phases | [go-implementation](phases/go-implementation/SKILL.md) | `ork worktree ensure`, `ork verify --baseline` |
 | phases | [check-quality](phases/check-quality/SKILL.md) | `ork verify`, `ork gate request` |
+| phases | [security-remediation](phases/security-remediation/SKILL.md) | `ork fix open`, `ork fix reverify`, `ork security-scan` |
 | phases | [ship-release](phases/ship-release/SKILL.md) | `ork ship` |
 | phases | [master-metrics](phases/master-metrics/SKILL.md) | `ork master`, `ork master <thread> --aceitar-omissao` |
 | reviewers | [code-reviewer](reviewers/code-reviewer/SKILL.md) | `references/code-review-axes.md` |

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

@@ -21,6 +21,7 @@ Distinga o contexto antes de agir:
 - **Sessao condutora:** recebe o pedido do dono, identifica ou abre a thread, despacha pelo `ork` e acompanha o resultado; nunca escreve codigo de produto no lugar da sessao despachada.
 - **Sessao de fase ja despachada:** recebeu thread, fase, prompt e worktree do `ork`.
   Trabalhe nesse escopo pela skill da fase. Nao abra outra thread nem redespache a propria fase para fazer o trabalho que ja lhe foi atribuido.
+  - Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
 
 ## Comecar ou retomar
 
@@ -89,8 +90,7 @@ uma pendencia humana atual, identificada por gate, pedido ou evento da thread/se
 Uma thread nova, sem fase executada nem pedido aberto, ainda nao aguarda veredito.
 Se faltar evidencia da pendencia, informe a incerteza e consulte a fonte; nao invente a espera.
 
-Apresente o resultado primeiro: o que ja foi comprovado, o que esta acontecendo, quem precisa agir e o proximo passo. Em trabalho demorado, comunique mudanca relevante, bloqueio ou marco.
-Nao prometa notificacoes ou execucao em segundo plano que o host nao consegue sustentar.
+Apresente o resultado primeiro: o que ja foi comprovado, o que esta acontecendo, quem precisa agir e o proximo passo. Em trabalho demorado, comunique mudanca relevante, bloqueio ou marco. Nao prometa notificacoes ou execucao em segundo plano que o host nao consegue sustentar.
 
 ## Decisoes na propria sessao
 

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

@@ -23,6 +23,8 @@ ork worktree audit <thread>          # a worktree confere no proprio git
 ork gate request <thread>            # o pedido da pausa; o humano responde pelo canal autenticado
 ```
 
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
+
 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:
 
@@ -53,6 +55,18 @@ e `web-performance-auditor`. Cada um roda no seu escopo e devolve achados catego
    reexecucao completa, nunca parcial.
 6. **Um veredito unico**, no diretorio da thread, com todo aviso aceito carregando seu registro.
 
+## Com `verify.security_scan` declarado
+
+Sem `verify.security_scan`, nada desta secao vale e o CHECK e o de sempre. Com a chave, o `ork verify` roda `ork security-scan` e o veredito consolida o scan:
+
+1. Leia `report.md` e `report.json` em `.orkastery/security-scan/<sha>/`, na arvore principal; o SHA e o do HEAD verificado.
+2. Zero bloqueadores de seguranca passa a ser: nenhum achado `new` do laco sem veredito resolvido do `security-auditor` (real corrigido, falso positivo dispensado com decisao registrada, ou inconclusivo com o `ork gate request` respondido).
+3. Achado `new` com `loop: false` (`warn` no relatorio, como qualidade, licenca ou severidade abaixo do corte) vai ao eixo certo como aviso registrado, com o nome de quem aceitou, nunca como bloqueador escondido.
+4. Ferramenta `unavailable` ou `failed` e declarada no veredito e nunca conta como limpa; com `ORK_SECURITY_SCAN_REQUIRED=1` ela faz o scan sair 1.
+5. Correcao vinda do scan volta pelo GO-FIX, com a skill `security-remediation`; a prova e o `ork fix reverify`, que reexecuta o verify e o scan.
+6. O veredito por achado chega ao GO-FIX pela claim do CHECK (`--fase CHECK`), uma por achado real ou falso positivo, como a skill `security-auditor` diz. O `ork fix open <thread>` reexecuta o verify e abre uma correcao por claim reprovada, tipo B para o real (`claims.failed`) e tipo A para o falso positivo (`claims.unverifiable`), ao lado da correcao tipo B do comando `security_scan`; o `ork fix list <thread>` as mostra ao GO-FIX com o texto do veredito.
+7. Inconclusivo nao abre o pedido de dentro da sessao do CHECK: o `ork gate request` recusa enquanto o observador nao grava a conclusao da fase (`a conclusao da fase precisa estar registrada antes da pausa`), e `--motivo` so aceita escalacao tipada ja registrada no ledger (`escalacao tipada nao comprovada`). A pergunta curta vai ao parecer, a sessao termina, e quem conduz roda `ork gate request <thread> --formato telegram`, que abre a pausa do fim do bloco que termina no CHECK, com o parecer nas evidencias. Entre os modos vivos, so o #Classic tem essa pausa (bloco GO-CHECK); #Look e #Ork tambem pausavam no CHECK, mas estao aposentados (I-43) e o pedido recusa para eles. O pedido leva a pergunta generica do gate (`Qual e o veredito sobre evidencias...?`): quem conduz aponta ao dono a pergunta do parecer, com o id do achado. A resposta do dono vira claim do CHECK como a skill `security-auditor` diz, antes do `ork fix open`. Em modo sem essa pausa (#Maestro, #Auto), o pedido recusa (`modo nao preve pausa humana nesta fase`): o veredito e BLOQUEADO, com a pergunta escrita, e nada segue ate o dono responder.
+
 ## O que o nucleo verifica por voce
 
 Os motivos tipados do `ork` fazem o veredito parar de ser conversa: `claims.failed`,
@@ -79,6 +93,8 @@ a pausa, nunca a verificacao**. Cada um deles tem uma acao de retry deterministi
 - Correcao tipo B seguida de reexecucao parcial.
 - Aviso aceito sem nome de quem aceitou.
 - CHECK rodado sem baseline para comparar.
+- Achado `new` do laco sem veredito dado como zero bloqueadores.
+- Inconclusivo de achado `new` do scan levado por `ork gate request` de dentro da sessao do CHECK, ou com `--motivo` de texto livre.
 
 ## Verificacao antes de sair da fase
 

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

@@ -24,6 +24,8 @@ ork claims add <thread> <arquivo> --claim "<...>" --verificar "<comando>" --fase
 ork verify <thread>                           # reexecuta no HEAD real
 ```
 
+- Esperas: nunca dispare verify, build ou suite com `&` dentro do comando, porque o processo se perde e a sessao espera um aviso que nunca vem; rode o `ork verify` em primeiro plano, com `timeout` (ele espera a vez na fila de recursos pesados), ou use a execucao em segundo plano do host, que avisa quando termina; nunca espere com `pgrep -f` cujo padrao aparece no proprio comando, porque o laco acha a si mesmo e nao termina: espere pelo arquivo de saida com prazo, ou pelo PID guardado.
+
 ## O que o GO entrega
 
 1. **Um commit atomico por tarefa**, com a thread e a tarefa na mensagem, no maximo cinco arquivos.
@@ -39,6 +41,10 @@ ork verify <thread>                           # reexecuta no HEAD real
    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.
 
+## Com `verify.security_scan` declarado
+
+Sem `verify.security_scan`, esta fase e a de sempre. Correcao que nasce de achado do scan de seguranca usa a skill `security-remediation`: corrige so o achado, e a prova e o scan reexecutado por `ork fix reverify`, nao o relato do agente. A spec traz uma correcao por achado triado pelo CHECK, com o tipo e o texto do veredito (`ork fix list <thread>`): o tipo A fecha gravando a dispensa e anexando o comando que a prova com `ork claims verificar <thread> <claim> --comando "<comando>"`.
+
 ## O que o nucleo verifica por voce
 
 `ork verify` reexecuta claims e comandos do manifesto no HEAD real e compara com a baseline:

package/skills/phases/security-remediation/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: security-remediation
+description: "Correcao de achado do security scan no GO: corrige so o achado triado como real, exige rotacao declarada para segredo, sobe dependencia para a menor versao corrigida e prova pelo scan reexecutado. Roteia para ork fix e ork security-scan."
+bucket: phases
+roteia: "ork fix open | ork fix list | ork claims verificar | ork fix reverify | ork security-scan"
+license: MIT
+---
+
+# Remediacao de seguranca
+
+## O que esta skill e
+
+Um roteador fino para a correcao que nasce de um achado `new` do laco do `ork security-scan`, depois que o `security-auditor` o triou como real. Ela vale so com `verify.security_scan` declarado e roda dentro do GO, na worktree da thread, com a conduta de [go-implementation](../go-implementation/SKILL.md).
+
+## Como rotear
+
+```bash
+ork fix open <thread>
+ork fix list <thread>
+git ls-remote --heads <remoto> <branch>
+ork security-scan
+ork claims verificar <thread> <claim> --comando "<comando>"
+ork fix reverify <thread>
+ork decisao registrar <thread> ...
+```
+
+## O que a remediacao entrega
+
+1. **So o achado.** A correcao muda o que o achado aponta (regra, `arquivo:linha`) e nada ao redor: refatoracao vizinha e scope creep, e esconde a correcao dentro do diff.
+2. **Segredo sai do codigo E tem rotacao declarada.** Remover do arquivo nao desfaz o vazamento (`SEC 2`): o historico nao e limpo por corrigir o codigo. A correcao so fecha com a rotacao declarada ao dono da credencial, com data, e verificada, nao prometida. O valor do segredo nunca vai ao relatorio, ao commit ou ao prompt.
+   - **Quem corrige tambem nunca imprime o valor.** A regra do auditor vale no GO: a linha do achado, as vizinhas e o commit que a trouxe nao vao a saida da sessao por ferramenta nenhuma (Read, `sed -n`, `head`, `cat`, `grep -n`, editor, `git show`, `git log -p`, diff). Edite sem ler, pelo numero do relatorio: apague a linha (`sed -i '<n>d' <arquivo>`) ou troque-a inteira (`sed -i '<n>s/.*/<substituto>/' <arquivo>`, com o substituto lendo a credencial do ambiente ou do cofre, nunca com o valor). Segredo de varias linhas (chave PEM): o fim do bloco sai so como numero (`command grep -n -- '-----END' <arquivo> | cut -d: -f1`) e o intervalo se apaga com `sed -i '<n>,<m>d' <arquivo>`. Confira pelo scan, nao pelo olho: o `fingerprint` do achado sai do relatorio novo. Na reescrita do historico abaixo, refaca os commits pelo mesmo caminho, sem `git diff` nem `git show` do commit do segredo.
+   - **Segredo que entrou na thread sai do historico da thread.** O Gitleaks varre os commits de `<base>..HEAD`, e o achado continua `new` enquanto um commit da thread carregar o valor. Nunca so apague a linha num commit novo. Com a branch da thread fora de todo remoto (`git ls-remote --heads <remoto> <branch>` sai 0 e vazio para cada `git remote`; saida diferente de 0 e duvida, nao ausencia), reescreva so os commits da thread a partir do que trouxe o segredo: `git reset --soft <commit anterior ao segredo>`, com o alvo na base da thread ou depois dela (`git merge-base --is-ancestor <base> <alvo>`), e os commits de novo sem o valor, sem `push --force`. Reescrever commit ainda nao publicado da thread e o caminho que o metodo ja usa, e o `ork ship publicar` empurra sem forca: historia reescrita que ja estivesse publicada seria recusada no push de qualquer jeito.
+   - **Branch ja publicada nao se reescreve.** O achado continua `new`, porque o commit segue em `<base>..HEAD`. A rotacao declarada e verificada continua obrigatoria, e a saida e uma dispensa que cita a rotacao declarada, decidida pelo dono: o achado volta ao CHECK como inconclusivo e, com a resposta, vira tipo A como qualquer dispensa.
+3. **Dependencia sobe para a menor versao corrigida**, a que o relatorio indica, com a justificativa da escolha no commit. Pular para a ultima traz mudanca que ninguem pediu.
+4. **A prova e o scan reexecutado.** A prova e o scan reexecutado por `ork fix reverify`, que o `ork` roda no HEAD real; o relato do agente de que "corrigiu" nao e prova. O achado precisa sair do relatorio novo, e nenhum `new` pode ter entrado. **O scan le so o HEAD commitado:** a arvore varrida e um checkout do commit HEAD, entao correcao, entrada de dispensa ou config ainda nao commitada e invisivel para ele. Commite antes de reexecutar.
+5. **Dispensa e correcao tipo A**, e so quando o triador classificou falso positivo. A entrada vai ao `.ork-security/dismissals.json` com `fingerprint`, `tool`, `rule`, `file`, `reason`, `decidedBy`, `decisionRef` (a referencia da decisao registrada com `ork decisao registrar`) e `date`; sem motivo e sem decisao registrada, a config e invalida e o scan sai 1.
+6. **Arquivo excluido nao se corrige.** Achado em caminho que a config do scan exclui volta a triagem: ou o achado e de outro arquivo, ou a exclusao e que esta errada, e mudar a exclusao e decisao registrada, nao atalho.
+7. **Uma correcao por achado.** A spec do `ork fix open` traz, ao lado da correcao do comando `security_scan`, uma correcao por claim do CHECK, com o tipo e o texto do veredito (`ork fix list <thread>`): tipo B para o real, tipo A para o falso positivo. O tipo A fecha com a entrada de dispensa e com o comando que a prova anexado a claim (`ork claims verificar <thread> <claim> --comando "<comando>"`); a claim do real reprova e passa com o scan inteiro, entao o tipo B fecha quando o scan reexecutado sai sem achado `new` do laco, nao so quando este `fingerprint` some.
+
+## O que o nucleo verifica por voce
+
+O `ork security-scan` sai 1 com achado `new` no laco (todo segredo novo; dependencia, SAST, IaC e workflow novos em `high` ou `critical`) e com dispensa invalida. `ork fix reverify` da o veredito por correcao e recusa reexecucao parcial depois de tipo B. Ferramenta `unavailable` ou `failed` nunca conta como limpa.
+
+## Racionalizacoes comuns
+
+| Desculpa | Realidade |
+|---|---|
+| "Tirei o segredo do codigo, esta resolvido" | O segredo continua valido e continua no historico. Falta a rotacao declarada ao dono e verificada. |
+| "Apaguei a linha num commit novo, o achado sai" | O Gitleaks varre `<base>..HEAD`: o commit antigo ainda carrega o valor e o achado continua `new`. Reescreva o historico nao publicado da thread e declare a rotacao. |
+| "Ja que estou aqui, arrumo o resto do arquivo" | A correcao e so do achado. O resto vira proposta, com tarefa e commit proprios. |
+| "Subo para a versao mais nova, e mais seguro" | A menor versao corrigida, com justificativa. A mais nova traz mudanca que ninguem avaliou. |
+| "Funcionou aqui, o achado deve ter sumido" | A prova e o scan reexecutado, nao a impressao de quem corrigiu. |
+| "E falso positivo, dispenso e pronto" | Dispensa exige a triagem, o motivo e a decisao registrada. Sem eles a config fica invalida. |
+
+## Bandeiras vermelhas
+
+- Segredo removido do arquivo sem rotacao declarada ao dono.
+- Segredo da thread corrigido so por commit novo, com o commit que o trouxe ainda em `<base>..HEAD`.
+- `push --force` para limpar o historico de branch publicada.
+- Correcao fechada sem `ork fix reverify` e sem scan novo.
+- Diff com mudanca que nao e o achado.
+- Dependencia que pulou varias versoes sem justificativa.
+- Entrada em `.ork-security/dismissals.json` sem `reason` ou sem `decisionRef`.
+- Valor de segredo colado no commit, no relatorio ou no prompt.
+- Linha do segredo lida ou impressa para editar (Read, `sed -n`, `cat`, `git show`) em vez da edicao pelo numero.
+- Scan reexecutado com a correcao ou a dispensa ainda fora de commit.
+
+## Verificacao antes de sair da correcao
+
+Diff restrito ao achado, rotacao declarada e historico da thread sem o commit do segredo quando era segredo, versao justificada quando era dependencia, entrada de dispensa completa quando era tipo A, e o `ork fix reverify` verde com o achado fora do relatorio novo. Ver `SEC 1`, `SEC 2` e `SEC 10`.

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

@@ -36,6 +36,25 @@ ork doctor                           # provider e ambiente da maquina
 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.
 
+## Com `verify.security_scan` declarado
+
+Sem `verify.security_scan`, esta skill faz o que sempre fez: a checklist inteira por leitura, e a passagem manual continua valendo. Com a chave declarada, o relatorio do scan (`.orkastery/security-scan/<sha>/report.json`, na arvore principal) e a evidencia de `SEC 1`, `SEC 2` e `SEC 10`, e a triagem abaixo vale.
+
+1. **Declare o escopo do scan:** `base`, `head`, as stacks e cada ferramenta com o estado (`ran`, `failed` ou `unavailable`) e o `reason`.
+2. **Ferramenta `unavailable` ou `failed` nunca conta como limpa.** Declare-a assim; os itens `SEC` dela voltam para a leitura manual, marcada como tal. A passagem manual so vale com o scan `unavailable` declarado.
+3. **Triagem: um veredito por achado `new` do laco** (`loop`), nenhum sem veredito:
+   - **real:** correcao tipo B, com a regra, `arquivo:linha`, a saida real **redigida (nunca o valor do segredo; so regra, `arquivo:linha` e `fingerprint`)**, o `SEC n` e o alcance (`reachable` do govulncheck); a volta e da skill `security-remediation`;
+   - **falso positivo:** correcao tipo A, `acrescentar <fingerprint> ao .ork-security/dismissals.json, motivo <m>`, mais `ork decisao registrar`;
+   - **inconclusivo:** sem correcao; a pergunta curta vai ao parecer, o veredito nao e PASSOU e o achado fica aberto ate a resposta do dono pelo `ork gate request` (o caminho esta na skill `check-quality`).
+4. **O veredito chega ao GO-FIX como claim do CHECK, uma por achado.** O `ork fix open` deriva a spec do GO-FIX so do `ork verify`, e o verify reexecuta as claims: cada claim reprovada vira uma correcao com o texto dela.
+   - real: `ork claims add <thread> <arquivo> --fase CHECK --claim "<veredito>" --verificar "<comando de verify.security_scan>"`; o comando reprova no HEAD e a correcao nasce tipo B (`claims.failed`). A claim reprova e passa com o scan inteiro, nao com este achado (o `fingerprint` fica no texto), custa uma varredura do HEAD a mais por claim em cada verify e vai ao bundle `.ork-ci` com as outras claims;
+   - falso positivo: `ork claims add <thread> .ork-security/dismissals.json --fase CHECK --claim "<veredito>"`, sem `--verificar`; a claim sem comando nasce tipo A (`claims.unverifiable`). Alegacao que o nucleo le como negativa reprova sem comando e vira tipo B sem aviso: `ehAlegacaoNegativa` em `core/src/claims.ts` procura, sem acento e ate dentro de palavras, `nenhum`, `nenhuma`, `nunca`, `sempre`, `zero`, `todos`, `todas`, `nao ha`, `nao existe`, `nao resta`, `sem nenhum`, `100%`, `totalmente`, `completamente` (`metodos` contem `todos`). Confira a saida do `ork claims add`: o falso positivo so vale com a linha `negativa` em `nao` e a linha `estado` em `nao-verificavel` (no locale `en`, a linha `negative` em `no` e a linha `state` em `unverifiable`); fora disso, `ork claims retirar <thread> <claim> --motivo "<motivo>"` e registre de novo com texto neutro;
+   - o `<veredito>` leva o id do achado, a ferramenta, a regra, `arquivo:linha`, o `fingerprint`, o tipo e a correcao, e no falso positivo o motivo e o `eventId` do `ork decisao registrar`;
+   - a resposta do dono a um inconclusivo vira claim do mesmo jeito, registrada por quem conduz ou por um CHECK novo, antes do `ork fix open`.
+5. **O auditor nao edita:** nem codigo, nem o `.ork-security/dismissals.json`. Ele devolve o veredito, e quem escreve a correcao e o GO.
+6. **Material de segredo nunca vai a saida da sessao.** Com achado `new` do Gitleaks, a linha do achado e o conteudo do commit que a trouxe nao vao a saida por ferramenta nenhuma: Read, `sed`, `head`, `grep -n`, editor, `git log -p`, `git show`, `cat`, diff. A saida vai a transcricao e ao provider, e e um segundo vazamento. **Achado `secret` nao tem leitura de contexto nenhuma:** nem a linha, nem as vizinhas, nem o arquivo, porque um segredo de varias linhas (chave PEM) passa por qualquer mascara de uma linha. O veredito dele se faz so com a `rule`, o `arquivo:linha` e o `fingerprint` do relatorio, e comparar o valor com outro se faz por hash (`sha256sum`), sem imprimir nenhum dos dois. O contexto sem a linha do achado (`awk -v n=<linha> 'NR>=n-5 && NR<=n+5 && NR!=n' <arquivo>`) vale so para as outras categorias (`sast`, `dependency`, `iac`, `workflow`).
+7. `existing` e `dismissed` entram no relatorio como divida declarada, nunca como bloqueador novo.
+
 ## O que o nucleo verifica por voce
 
 A policy `segredo_em_prompt` roda no gate `phase.dispatch` **antes de o prompt ser gravado em
@@ -52,6 +71,7 @@ thread. As tres reprovam em qualquer modo.
 | "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. |
+| "Ja que achei, corrijo aqui mesmo" | O auditor nao edita. Auditor que corrige passa a auditar o proprio trabalho; o veredito vai ao GO e a correcao volta pelo CHECK. |
 
 ## Bandeiras vermelhas
 
@@ -60,6 +80,11 @@ thread. As tres reprovam em qualquer modo.
 - Achado sem o `SEC n` que ele viola.
 - "Nada encontrado" sem dizer o que foi olhado.
 - Dependencia nova sem justificativa no PLAN.
+- Valor de segredo do Gitleaks colado na correcao, no veredito ou no ledger.
+- Achado `new` do laco sem veredito, ou ferramenta `failed` contada como limpa.
+- Linha ou commit de achado `new` do Gitleaks na saida da sessao, por qualquer ferramenta (Read, `sed`, `grep -n`, `git log -p`, `git show`, `cat`, diff).
+- Contexto de arquivo lido para achado `secret`, mesmo sem a linha do achado.
+- Veredito de achado `new` do scan so no parecer, sem a claim do CHECK que o leva ao `ork fix open`.
 
 ## Verificacao antes de sair da auditoria