wendkeep 0.78.0 → 0.80.0

package/docs/pt-BR/commands/changes-and-verification.md

@@ -29,8 +29,11 @@ npx wendkeep change new <slug> [--simple|--guide] [--session <id>]
 npx wendkeep change status [slug] [--session <id>]
 npx wendkeep spec effective [--change <slug>] [--session <id>]
 npx wendkeep sensors list
+npx wendkeep task list [--change <slug>] [--session <id>] [--json]
+npx wendkeep task evaluate <task-id> [--change <slug>] [--session <id>] [--json]
 npx wendkeep verify [--deep] [--change <slug>] [--session <id>]
-npx wendkeep change archive <slug> [--session <id>]
+npx wendkeep change archive <slug> [--json] [--session <id>]
+npx wendkeep change archive recover <operation-id> --change <slug> [--spec-action rollback|resume] [--json]
 ```
 
 ## Opções e códigos de saída
@@ -47,6 +50,12 @@ npx wendkeep change archive <slug> [--session <id>]
   somente um contexto ativo inequívoco da worktree é aceito; ambiguidade retorna exit `2`.
 - `change relink [--apply]` e `change backlink [--apply]` reparam o grafo; dry-run é o padrão.
 - `change abandon <slug>` descarta sem ADR; `archive --force` exige decisão humana explícita.
+- `task list/show/evaluate` projeta contratos read-only da autoria da change. `task claim/release`
+  controla owner/lease no active context causal.
+- `change archive recover <operation-id> --change <slug> [--spec-action rollback|resume]` inspeciona
+  uma transação pendente por padrão; com `rollback` ou `resume`, converge somente a promoção de
+  specs preparada no journal, sob lock e validação. Não promove a change, não apaga o journal e não
+  inventa reconciliação.
 - `wendkeep spec list|show|effective|migrate|rebase` administra contratos vivos e deltas.
 - `wendkeep sensors list|add` administra provas executáveis.
 - Exit `0` indica comando concluído; os gates usam exit `1` para prova vermelha e exit `2` para
@@ -83,6 +92,111 @@ checkout provado. Se houver divergência, volte à worktree/sessão correta e ro
 `verify --deep` e `wk-verify` novamente. Campos, normalização textual/binária, códigos e recovery
 estão detalhados no [guia de verify](verify.md).
 
+O gate comum reclassifica envelope, package e verdict como `verified`, `reported`,
+`legacy-unbound`, `stale`, `conflict` ou `unproven`; somente `verified` permite archive. Um bloqueio
+retorna `WENDKEEP_PROVENANCE_GATE_BLOCKED`: estabilize/recupere o contexto, rode `verify`, depois
+`verify --deep` e obtenha novo passe `wk-verify`. `--force` pode dispensar somente tarefa aberta;
+para proveniência, integridade, package e verdict ele **não** altera o resultado nem promove spec/ADR.
+Os erros de ledger são `WENDKEEP_RECEIPT_LEDGER_BUSY`, `WENDKEEP_RECEIPT_LEDGER_CONFLICT`,
+`WENDKEEP_RECEIPT_LEDGER_CORRUPT` e `WENDKEEP_RECEIPT_LEDGER_TRUNCATED`. No bloqueio, use a saída
+`--json` sanitizada (`state`, `reasonCodes`, `diagnostics`, `repair.command`), execute o recovery
+indicado e rode `npx --no-install wendkeep verify --deep --json`; preserve e recapture a prova, sem
+editar ledger/checkpoint ou expor stderr, token, URL privada ou path do Vault.
+
+### Contrato pós-fix do archive
+
+Antes da mutação, faça a recaptura final com `wendkeep verify --deep --change <slug>`. O package
+e o verdict devem estar completos e canônicos, com binding do mesmo checkout, change, tarefas,
+spec e sensores. O archive grava primeiro um receipt de autorização no ledger separado
+`change-archive-receipts-v2`; só depois de validá-lo pode promover spec/ADR ou mover a change.
+`change archive --json` expõe o resultado serializável com os campos `state`, `reason_codes`,
+`diagnostics` e `repair`. Corrupção ou truncamento no ledger de prova ou no ledger de archive
+bloqueia fechado antes de qualquer escrita. `--force` não bypassa proveniência nem integridade,
+nem package/verdict, corrupção ou truncamento. O recovery exato é repetir
+`wendkeep verify --deep --change <slug>` no checkout correto.
+
+A mutação adquire o lock do runtime `.brain/runtime/change-archive-operation.lock` e abre uma
+transação privada ASCII em `.brain/runtime/archive-transactions/<uuid>/{original,authorized}`.
+Ela renomeia atomicamente a change viva para `original`, confere o digest e promove somente a
+cópia `authorized`; o namespace público nunca é fonte de publicação. Em caso de falha de
+selagem ou divergência `WENDKEEP_ARCHIVE_INPUT_CHANGED` antes da promoção, o snapshot
+`authorized` é removido e `original` é restaurado sem promoção parcial. O archive bem-sucedido
+mantém o journal `completed`; o finalizer pós-release valida os digests de `original` e do destino
+publicado, mas retém `original` e a transação, sem cleanup destrutivo automático.
+
+O lock do archive é um `directory lock`: o diretório canônico contém marker específico do token e
+lease. A aquisição prepara um diretório irmão `.pending`, escreve owner/lease e publica por rename
+atômico para o lock; não usa hardlink e reobserva colisões com no máximo 3 tentativas de topologia.
+Owner vivo retorna `WENDKEEP_ARCHIVE_BUSY`; owner morto pode sofrer reap seguro sem apagar sucessor.
+Estrutura/marker inválido retorna `WENDKEEP_ARCHIVE_LOCK_UNAVAILABLE`; perda de ownership retorna
+`WENDKEEP_ARCHIVE_LOCK_OWNERSHIP_LOST`.
+
+Cada operação mantém `archive-transaction.json` com as fases `prepared` → `isolated` → `copied` →
+`sealed` → `published` → `promotion-prepared` → `promotion-applied` → `completed` ou
+`recovery-required`. Um journal pending bloqueia novo archive do mesmo slug antes do gate. Em
+colisão ou falha pós-publicação, `original` permanece retido e o estado é
+`published-recovery-required`. Use a inspeção fail-closed e idempotente
+`wendkeep change archive recover <operation-id> --change <slug> [--spec-action rollback|resume] [--json]`;
+sem `--spec-action`, só retorna ações sanitizadas. `rollback` restaura before-images e `resume`
+converge after-images de uma promoção `promotion-prepared`; ambos preservam o journal para nova
+reconciliação.
+
+A promoção multi-spec é uma unidade atômica: captura before-images/digests de todos os capabilities,
+faz rollback de todos os alvos (incluindo estado/README) em falha antes ou depois da escrita e só
+permite retry após a reconciliação do journal e nova verificação. O finalizer pós-release valida os
+digests do original e do destino, mas retém o journal `completed` e `original`; sem cleanup
+destrutivo automático. Os campos sanitizados
+`operation_id` e `transaction_phase` acompanham o diagnóstico; `repair.command` aponta para
+`wendkeep change archive recover <operation-id> --change <slug>` quando há operação identificada.
+Texto e --json usam o mesmo diagnóstico sanitizado com code, operation, state, blocker, expected,
+observed, recovery, reason_codes, diagnostics e repair.
+
+## Task Contracts, artifacts e handoffs
+
+Task Contract v1 é uma projeção reconstruível cuja autoria permanece em `tarefas.md`, na spec
+efetiva e no `artifacts.json` da change. O contrato não copia a spec nem infere requisito do chat.
+Projeto, active context, HEAD e hashes de tarefas/spec/manifesto vinculam a projeção; divergência
+resulta em `stale`.
+
+```markdown
+- [ ] 2.3 gerar relatório [req:REP-1] [sensor:tests] [depends:2.2] [artifact:report]
+- [ ] 9.1 revisar pacote deep e arquivar [req:REP-1] [phase:verify]
+```
+
+```powershell
+npx wendkeep task list --session <id> [--change <slug>] [--json]
+npx wendkeep task show 2.3 --session <id> [--json]
+npx wendkeep task evaluate 2.3 --session <id> [--json]
+npx wendkeep task claim 2.3 --session <id> [--lease-seconds 900] [--json]
+npx wendkeep task release 2.3 --session <id> [--json]
+```
+
+`list`, `show` e `evaluate` não escrevem. `claim` e `release` usam o lock atômico do
+`SESSION_REGISTRY`, são escopados por repository/worktree/work session/change/task e recusam owner
+concorrente. Lease expirada pode ser retomada; release por não-owner falha com
+`TASK_LEASE_NOT_OWNER`.
+
+Um manifesto de artifacts usa `schema_version: 1` e uma lista `artifacts`; cada entrada nomeada
+pode ter tipo `name`, `path`, `glob` ou `file-count`. O fallback `fromFilesystem` é explícito, não
+lê conteúdo, ignora `.git`, `.worktrees`, `node_modules` e `dist`, tem limites de tempo/quantidade
+e falha fechado em path escape, symlink ou junction externo.
+
+Checkbox é sinal autoral, não prova. `task evaluate` retorna `can_complete`, requisitos, sensores,
+artifacts e dependências ausentes, além de `blocking_findings`. No active context causal, `verify`
+pode gravar `evidencia.json`, mas não anuncia sucesso nem cria o pacote deep enquanto houver task
+bloqueada na fase padrão `execute`; o diagnóstico fica em `task-evaluation.json`. Use
+`[phase:verify]` somente para a tarefa de revisão/arquivo que necessariamente ocorre depois do
+pacote deep: ela não integra o gate Execute → Verify, permanece bloqueada na avaliação individual
+e ainda precisa ser concluída antes de `change archive`.
+
+SessionStop vincula origem/destino, task, artifacts, Evidence Envelope, decisões, próximas ações,
+blockers e hashes de HEAD/tarefas/spec. ASSURE exige Handoff Contract v1 verificado; nos demais
+perfis ele é opcional. Handoffs históricos permanecem `legacy-reported`. Memória compartilhada,
+brain injection e Observer consomem a mesma projeção sanitizada.
+
+Schemas públicos: `schema/task-contract-v1.schema.json`,
+`schema/artifact-manifest-v1.schema.json` e `schema/handoff-contract-v1.schema.json`.
+
 ## Cerca de escopo para ferramentas
 
 O `change-guard` também é projetado para o `PreToolUse` do Codex. Antes de uma mutação Git ou de

package/docs/pt-BR/commands/operating-profiles.md

@@ -59,7 +59,7 @@ npx wendkeep flow finish <id> [--session <id>]
 npx wendkeep flow promote <id> [--change-slug <slug>] [--session <id>]
 npx wendkeep delivery start [id] --allow <capability> [--source-change <slug>] [--source-commit <sha>] [--session <id>]
 npx wendkeep delivery status [id] [--session <id>]
-npx wendkeep delivery finish [id] [--target <ref>] [--ci-url <url>] [--version <x.y.z>] [--npm-integrity <sha512>] [--release-url <url>] [--session <id>]
+npx wendkeep delivery finish [id] [--target <remote>/<branch>] [--ci-url <url>] [--version <x.y.z>] [--npm-integrity <sha512>] [--release-url <url>] [--session <id>]
 npx wendkeep delivery abandon [id] --reason <texto> [--session <id>]
 ```
 
@@ -179,13 +179,38 @@ harness nativo da LLM.
   `contract_impact` e `operation_risk` são dimensões independentes. `delivery start` captura repo,
   branch/worktree, SHA, change de origem e capabilities em `.brain/runtime/deliveries/`; não cria
   pasta em `08-Mudanças`, delta, spec ou ADR.
-- `delivery finish` exige working tree limpa, comprova que o target contém o commit de origem e,
-  para capability `publish`, exige CI, versão, integridade npm e GitHub Release. O receipt é
-  append-only em `.brain/runtime/delivery-receipts.jsonl`. Se código/config precisar mudar, a
-  delivery para com `WENDKEEP_DELIVERY_IMPLEMENTATION_REQUIRED` e o trabalho volta a implementation.
+- Para as capabilities `git:merge` e `git:push`, `delivery finish` exige `--target
+  <remote>/<branch>` (por exemplo, `--target origin/main`). `delivery start` vincula o remote
+  `origin` ao `repository` esperado; `finish` resolve o destino com `git ls-remote` e bloqueia a
+  delivery antes dos adapters de proveniência se o target não puder ser resolvido ou o binding
+  divergir.
+- `delivery finish` exige working tree limpa e rederiva source/target. Merge/push prova
+  ancestralidade; tag prova package/version e tag no target; `publish` consulta CI, NPM e GitHub
+  Release ligados ao mesmo commit, versão, integrity e notas. No modo offline, uma claim fica
+  `reported` e não vira `verified`; a conclusão bloqueia sem gravar receipt. Novos receipts formam
+  `.brain/runtime/delivery-receipts-v2.jsonl`, com hash chain e checkpoint; o v1 é somente
+  `legacy-unbound`. `WENDKEEP_PROVENANCE_GATE_BLOCKED` traz o recovery. Se código/config precisar
+  mudar, `WENDKEEP_DELIVERY_IMPLEMENTATION_REQUIRED` devolve o trabalho a implementation.
+  O gate usa a mesma taxonomia `verified`, `reported`, `legacy-unbound`, `stale`, `conflict` e
+  `unproven`. Os erros do ledger são `WENDKEEP_RECEIPT_LEDGER_BUSY`,
+  `WENDKEEP_RECEIPT_LEDGER_CONFLICT`, `WENDKEEP_RECEIPT_LEDGER_CORRUPT` e
+  `WENDKEEP_RECEIPT_LEDGER_TRUNCATED`; consulte `state`, `reasonCodes`, `diagnostics` e
+  `repair.command` sanitizados em `--json`, execute o recovery indicado e recapture a prova, sem editar
+  ledger/checkpoint ou expor stderr, tokens, URLs privadas e paths do Vault.
 - Em Vault multi-contexto, `active_contexts[].delivery_id` é a autoridade. `--session <id>` escolhe
   explicitamente a work session; sem ela, somente um active context inequívoco da worktree pode ser
   usado. Status, finish e abandon implícitos consultam esse binding, não um ponteiro global.
+- Falhas de `delivery`, tanto em texto quanto em `delivery --json`, expõem o mesmo diagnóstico
+  PROV-8: `code` estável, `operation`, `state`, primeiro `blocker`, `expected`/`observed`
+  sanitizados e `recovery` objetivo. Stderr do Git, tokens, URLs privadas e caminhos privados não
+  são propagados.
+- Receipts `delivery.completed` e `delivery.abandoned` vinculam `repository_id`, o `repository`
+  público no formato `owner/repo`, `worktree_id`, `work_session_id`, `change_slug` e `branch`.
+  O path privado da worktree nunca entra no receipt. Na finalização contextual, o receipt entra no
+  ledger e o `state` durável é gravado antes de limpar `active_contexts[].delivery_id`. Um retry
+  converge para o mesmo receipt quando o binding já está limpo ou ainda vinculado. Em
+  `delivery abandon`, o motivo livre vira `reason_digest`; o texto bruto não entra no ledger nem no
+  estado.
 - `CURRENT_DELIVERY` é somente uma projeção derivada: contém o ID quando existe um único contexto
   ativo inequívoco com delivery e fica vazio com zero ou múltiplos contextos.
   `WENDKEEP_DELIVERY_CONTEXT_MISMATCH` indica que o ID explícito pertence a outro contexto; nenhum
@@ -274,6 +299,27 @@ continuam disponíveis e executam seus próprios contratos. Um FLOW concluído d
 consultável; um FLOW promovido passa a seguir o lifecycle normal de change. Uma delivery concluída
 deixa receipt sem gerar ADR; GUIDE compacto arquiva o resultado sem spec/design/ADR artificiais.
 
+Para archive em GOVERN/ASSURE, o `directory lock` usa marker específico do token e lease: a
+aquisição prepara um diretório irmão `.pending` e publica por rename atômico, sem hardlink, com no
+máximo 3 tentativas de topologia. Owner vivo retorna `WENDKEEP_ARCHIVE_BUSY`, owner morto pode ser
+reapado com segurança, marker inválido retorna `WENDKEEP_ARCHIVE_LOCK_UNAVAILABLE` e perda de
+ownership retorna `WENDKEEP_ARCHIVE_LOCK_OWNERSHIP_LOST`. O journal `archive-transaction.json`
+percorre `prepared` → `isolated` → `copied` → `sealed` → `published` → `promotion-prepared` →
+`promotion-applied` → `completed` ou `recovery-required`; um journal pending bloqueia novo archive
+do mesmo slug antes do gate.
+`original` fica retido em collision/falha pós-publicação e `published-recovery-required` exige
+inspeção. `operation_id` e `transaction_phase` aparecem apenas sanitizados. Use
+`wendkeep change archive recover <operation-id> --change <slug> [--spec-action rollback|resume] [--json]`:
+sem `--spec-action`, inspeção somente-leitura, fail-closed e idempotente, sem promoção, deleção ou
+reconciliação inventada; `rollback` restaura before-images e `resume` converge after-images de
+`promotion-prepared`, retendo o journal. Quando há operation ID, `repair.command` aponta para esse
+recovery; não trate `command:null` como fluxo normal.
+
+A promoção multi-spec é atômica, com before-images/digests, rollback dos alvos antes/depois da
+escrita e retry somente após reconciliação e nova verificação. O finalizer pós-release valida os
+digests do original e do destino publicado, mas o `completed` journal mantém o `original` retido;
+sem cleanup destrutivo automático.
+
 ## Erros comuns e diagnóstico
 
 - Perfil desconhecido: use exatamente `OFF`, `FLOW`, `GUIDE`, `GOVERN` ou `ASSURE`.

package/docs/pt-BR/commands/sessions-and-import.md

@@ -141,3 +141,10 @@ confirmada de um lock ocupado ou de um caminho que foi pulado, sem reabrir a ses
 
 Leia [Perfis de Operação](operating-profiles.md), [importação retroativa](retroactive-import.md),
 [custos e observabilidade](costs-and-observability.md) e [notas](notes-and-knowledge.md).
+# Handoff Contract v1
+
+Em active context causal, o SessionStop projeta um handoff tipado com task, artifacts, Evidence
+Envelope, decisões, próximas ações, blockers e hashes de HEAD/tarefas/spec. ASSURE bloqueia a
+publicação quando esse contrato verificado não pode ser produzido; outros perfis preservam o
+fallback opcional. Handoffs históricos continuam `legacy-reported`. Veja
+[Changes e verificação](changes-and-verification.md).

package/docs/pt-BR/commands/verify.md

@@ -91,6 +91,44 @@ no verdict.
 Evidência v1 continua legível como `legacy-unbound`, nunca como autoridade equivalente. Rode
 `wendkeep change status <slug>` para ver `bound`, `stale` ou `context-mismatch`.
 
+O gate de proveniência normaliza a visão legada numa taxonomia única: `verified` quando toda prova
+obrigatória está fresca e vinculada; `reported` para claim registrada sem observação autoritativa;
+`legacy-unbound` para v1; `stale` para um snapshot anterior; `conflict` para identidade/conteúdo
+incompatível; e `unproven` para prova ausente ou insuficiente. A precedência é `conflict` > `stale`
+> `legacy-unbound` > `unproven` > `reported` > `verified`, e somente `verified` fecha o gate.
+
+Para o archive pós-fix, o passe final é `wendkeep verify --deep --change <slug>`. Ele deve deixar
+package e verdict completos e canônicos, ligados ao mesmo checkout, change, tarefas, spec e
+sensores. O archive grava o receipt de autorização antes da mutação no ledger separado
+`change-archive-receipts-v2`. Sua saída `change archive --json` é serializável e expõe `state`,
+`reason_codes`, `diagnostics` e `repair`; corrupção ou truncamento de ledger bloqueia fechado.
+`--force` não bypassa proveniência ou integridade. O recovery exato é repetir
+`wendkeep verify --deep --change <slug>` depois de estabilizar o contexto.
+
+O archive usa um `directory lock` com marker específico do token e lease. A aquisição prepara um
+diretório irmão `.pending` e publica-o por rename atômico, sem hardlink, com no máximo 3 tentativas
+de topologia. Owner vivo produz `WENDKEEP_ARCHIVE_BUSY`; owner morto só é reapado com observação
+segura; marker/estrutura inválida produz `WENDKEEP_ARCHIVE_LOCK_UNAVAILABLE`; perda de ownership
+produz `WENDKEEP_ARCHIVE_LOCK_OWNERSHIP_LOST`. O manifest `archive-transaction.json` registra
+`prepared` → `isolated` → `copied` → `sealed` → `published` → `promotion-prepared` →
+`promotion-applied` → `completed` ou `recovery-required`. Um journal pending bloqueia novo archive
+do mesmo slug antes do gate. Em
+collision ou falha pós-publicação, `original` é retido e o estado
+`published-recovery-required` bloqueia retry destrutivo. `operation_id` e `transaction_phase` são
+campos sanitizados. Inspecione com
+`wendkeep change archive recover <operation-id> --change <slug> [--spec-action rollback|resume] [--json]`:
+sem `--spec-action`, é somente-leitura, fail-closed e idempotente, sem promoção, deleção ou
+reconciliação inventada. `rollback` restaura before-images e `resume` converge after-images de uma
+promoção `promotion-prepared`, mantendo o journal para reconciliação. Quando há operation ID,
+`repair.command` aponta para `wendkeep change archive recover <operation-id> --change <slug>`; não
+trate `command:null` como fluxo normal.
+
+A promoção multi-spec é uma unidade atômica: captura before-images/digests de todos os capabilities,
+faz rollback de todos os alvos (incluindo estado/README) em falha antes ou depois da escrita e só
+permite retry após reconciliação do journal e nova verificação. O finalizador pós-release valida os
+digests do original e do destino, mas o `completed` journal mantém o `original` retido; sem cleanup
+destrutivo automático. Falha mantém `published-recovery-required`.
+
 ## Erros comuns e diagnóstico
 
 - `no change`: isso é exit 2 e estado ocioso válido; crie/use uma change ou não rode verify.
@@ -103,6 +141,13 @@ Evidência v1 continua legível como `legacy-unbound`, nunca como autoridade equ
   checkout e repita. A evidência anterior não foi substituída.
 - `legacy-unbound`, `stale` ou `context-mismatch`: volte à worktree/sessão correta, recupere o
   contexto se necessário e rode `verify` + `verify --deep` novamente.
+- `WENDKEEP_PROVENANCE_GATE_BLOCKED`: leia `state`, `reasonCodes` e `repair`; não reutilize uma
+  prova de outra branch/worktree/sessão. Rode o comando indicado e recapture o envelope.
+- Os erros `WENDKEEP_RECEIPT_LEDGER_BUSY`, `WENDKEEP_RECEIPT_LEDGER_CONFLICT`,
+  `WENDKEEP_RECEIPT_LEDGER_CORRUPT` e `WENDKEEP_RECEIPT_LEDGER_TRUNCATED` exigem preservar o
+  ledger/checkpoint e executar o recovery objetivo em `repair.command` (ou
+  `npx --no-install wendkeep verify --deep --json` para uma prova fresca); a saída textual/JSON
+  permanece sanitizada e não contém stderr bruto, tokens, URLs privadas ou paths do Vault.
 - Mutantes sobreviventes: fortaleça o teste discriminante; após três rodadas, revise manualmente.
 
 ## Próximos passos
@@ -110,3 +155,11 @@ Evidência v1 continua legível como `legacy-unbound`, nunca como autoridade equ
 Volte ao [ciclo de changes](changes-and-verification.md) para archive, confira os
 [Perfis de Operação](operating-profiles.md) ou consulte
 [manutenção](maintenance-and-diagnostics.md) quando não houver change.
+# Gate de Task Contract
+
+Depois de executar sensores e gravar o Evidence Envelope atual, `verify` avalia os Task Contracts
+do active context causal. Checkbox aberta, requisito/sensor/artifact ausente, dependência aberta ou
+binding stale bloqueia exit `1`, preserva `evidencia.json`, grava `task-evaluation.json` e não cria
+o pacote deep. Tasks explicitamente autoradas com `[phase:verify]` ficam fora apenas desta
+transição porque dependem do pacote deep; continuam abertas para o gate de archive. Veja
+[Changes e verificação](changes-and-verification.md).

package/docs/pt-BR/commands/worktrees.md

@@ -58,6 +58,31 @@ interrompido/failed e uma recuperação objetiva.
 head comprovado; divergência ou rede indisponível bloqueia. Branch já ausente é sucesso idempotente.
 `--open-main` abre a worktree principal somente depois da conclusão.
 
+### Cleanup pós-fix: retomada crash-safe
+
+A operação de cleanup é **crash-safe** e retomável antes do receipt, depois do receipt e antes do
+finalize, e depois do finalize: um crash em qualquer fronteira preserva operation/state e permite
+repetir a mesma prova sem duplicar remoção ou receipt. O subject de cada operação inclui todos os
+active contexts, actor, pr, head e merge. O PR canônico é a autoridade resolvida pelo adapter
+GitHub; texto fornecido pelo chamador não substitui essa autoridade.
+
+O HEAD é rederivado antes do finalize, a partir do checkout, e comparado ao head/merge comprovado. O reason
+fica sanitizado e recebe digest para auditoria, sem armazenar path privado, token ou stderr.
+Checkpoint ausente ou inválido é WENDKEEP_RECEIPT_LEDGER_TRUNCATED. Receipt v1 continua
+legacy-unbound e nunca autoriza cleanup.
+
+Texto e --json expõem sempre operation, state, blocker, recovery e os códigos estáveis
+WENDKEEP_WORKTREE_CLEANUP_BUSY, WENDKEEP_RECEIPT_LEDGER_CORRUPT e
+WENDKEEP_RECEIPT_LEDGER_TRUNCATED; a recuperação retoma a reserva ou indica o reparo objetivo.
+
+O gate comum classifica a operação de cleanup e bloqueia antes da mutação, inclusive em finish,
+remove e cleanup --apply. Depois do append, o receipt é classificado pelo mesmo gate antes do
+finalize; falha de proveniência não finaliza nem marca sucesso. Um estado cleaned sem receipt v2
+fica bloqueado como unproven; um receipt v1 não autoriza e permanece legacy-unbound.
+
+Texto e --json de bloqueio mantêm o diagnóstico equivalente e sanitizado: code, operation, state,
+blocker, expected, observed, recovery, reason_codes, diagnostics e repair.
+
 ## Cleanup, remove e prune
 
 `cleanup --merged` e `prune` são dry-run por padrão. `--dry-run` apenas torna essa intenção
@@ -70,9 +95,19 @@ mas mantém todo o preflight e preserva as branches local e remota.
 
 O registry fica no Git common-dir, em `wendkeep/worktrees-v1.json`, sob lock multiprocesso. Ele
 guarda identidade do repositório/worktree, binding canônico, PR e estado transitório de cleanup;
-`.wendkeep.json` permanece inalterado. Receipts ficam em
-`wendkeep/worktree-cleanup-receipts-v1.jsonl`. `.worktrees/` entra no ignore versionado e no exclude
-privado. A saída JSON de `list`/`status` não expõe path nem conteúdo do Vault.
+`.wendkeep.json` permanece inalterado. Novos receipts ficam em
+`wendkeep/worktree-cleanup-receipts-v2.jsonl`: cada linha inclui `previous_hash` e `receipt_hash`, e
+um checkpoint separado fixa a sequência/hash/tamanho validado. O v1 permanece legível como
+`legacy-unbound`, sem append ou reescrita silenciosa. `WENDKEEP_RECEIPT_LEDGER_CORRUPT` indica
+adulteração/JSON parcial; `WENDKEEP_RECEIPT_LEDGER_TRUNCATED` indica cauda removida. Ambos bloqueiam
+antes da remoção e exigem diagnosticar o store, nunca inventar receipt. `.worktrees/` entra no
+ ignore versionado e no exclude privado; JSON de `list`/`status` não expõe path/conteúdo do Vault.
+O gate de cleanup usa `verified`, `reported`, `legacy-unbound`, `stale`, `conflict` e `unproven`;
+`WENDKEEP_PROVENANCE_GATE_BLOCKED` e os códigos `WENDKEEP_RECEIPT_LEDGER_BUSY`,
+`WENDKEEP_RECEIPT_LEDGER_CONFLICT`, `WENDKEEP_RECEIPT_LEDGER_CORRUPT` e
+`WENDKEEP_RECEIPT_LEDGER_TRUNCATED` falham fechados. O recovery objetivo lê o JSON sanitizado de
+`worktree status <slug> --json`, executa `repair.command` quando presente e recaptura a prova; não
+edite ledger/checkpoint nem exponha stderr, tokens, URLs privadas ou paths do Vault.
 
 `create` é idempotente quando slug, path e branch já correspondem. Colisões falham fechadas.
 Falhas depois da reserva ficam como `failed`; rode `worktree status <slug>` e siga `recovery`.