O audit record Shipped

A resposta para "quem aprovou isto?" é um arquivo, não uma reunião

Toda task fechada deixa um registro — no branch em que aconteceu quando é fechada pela CLI, por padrão, e no board quando o console ou um merge a fecha, ou quando o repositório guarda os registros lá: o que o trabalho disse que ia tocar, o que o diff prova que tocou, quem abriu o que estava fechado, e o que passou por um override, com o nome de quem assinou. Um fechamento pelo connector carrega a lista de arquivos que o agente reportou, e o registro diz que ela foi reportada, não observada.

A unidade é o argumento inteiro

Proveniência durável para código escrito por IA já existe e é boa: há ferramentas que gravam o agente, o modelo e o prompt em Git Notes, linha a linha, e sobrevivem a rebase e a squash. Se é disso que você precisa, use uma — isto é outro objeto.

Um registro aqui é por task, não por linha. Não é "quem escreveu esta linha", e sim "esta mudança foi autorizada, e ficou dentro do que foi autorizado?" — uma pergunta de governança que a autoria por linha não consegue responder, por mais completa que seja.

O que vai em um

• Declarado contra tocado — as zones que a spec nomeou, ao lado das zones que o change manifest calculou a partir do branch — ou da lista que o agente reportou num fechamento pelo connector, marcada como reportada
• Evidência — o que o quality gate da task pediu: uma revisão, um check de contrato, uma rodada de regressão, um aceite formal
• Aprovações — cada access request que abriu uma zone fechada, com quem respondeu e quanto tempo durou
• Overrides — legítimos, e nunca silenciosos. Um bypass carrega um motivo e um owner
• Exceções, antes da narrativa — o que foi bloqueado, escalado ou passou por override vem primeiro, e uma lista de arquivos que quem fechou reportou é marcada como reportada, não observada

O censo, inclusive a parte que não nos favorece

Numa contagem de 2026-08-21 este repositório tinha 131 tasks fechadas, 112 delas com audit records commitados — e no primeiro censo de 77 fechamentos, 34 foram fechadas por um único override assinado, um fechamento em lote de trabalho anterior ao gate de fechamento, registrado uma vez com um motivo em vez de fabricado task por task. De 2026-10-06 (CC-1150) a 2026-10-10 (CC-1288) este repositório guardou os registros no board; desde então eles voltaram a ser commitados aqui.

Esse número está nesta página pelo mesmo motivo que está no audit trail: um produto que defende que overrides são sempre registrados, e que depois escondesse o seu maior override, estaria argumentando contra si mesmo. O registro só vale alguma coisa se puder dizer algo que você preferia que ele não dissesse.

Ele sobrevive a nós, de propósito

Por padrão um fechamento pela CLI escreve o registro como markdown em .zones/audit/, no seu repositório, no seu branch, escrito para ser lido por uma pessoa sem ferramenta nenhuma. Desinstale o CommitCycle e cada um deles fica exatamente onde está. O board guarda uma cópia de cada um, e a única cópia de um registro que o console ou um merge escreveu, ou de todos num repositório configurado com "records": "board"; cycle export --audits entrega esses como o mesmo Markdown — a saída faz parte do produto, e uma resposta de compliance que você não pode levar consigo não é uma resposta.

Onde ele para

• É escrito no fechamento, não continuamente. Trabalho em andamento tem eventos; o registro é o que o segundo gate produz, e uma task que nunca fecha nunca escreve um.
• Evidência é uma URL ou uma captura que você já tem. Não há hospedagem de previews aqui, e inventar uma para guardar capturas de tela seria outro produto.
• Ele registra; não julga. Um override com um motivo ruim continua sendo um override com um motivo, e nenhum arquivo conserta isso. O que ele consegue é tornar impossível ficar calado sobre isso.

O formato do registro está na documentação (em inglês), o gate que o escreve é o gate de fechamento, e aquilo contra o que ele mede é o mapa de zones.