CL-2026-03-17-BK-130

• Status: (V) conferido e aprovado
• Backlog: BK-130
• Escopo: plataforma (documentacao e governanca)
• Projetos afetados: cerebro
• Aprovacao humana obrigatoria: nao
• Revisor IA: auto-revisao

Resumo

Foi formalizado o workflow documental em que cada BK ganha um arquivo vivo em docs/backlog/ durante a execucao e, quando o BK fecha, esse material e promovido para docs/changelog/<ano>/CL-YYYY-MM-DD-BK-xxx.md, com atualizacao do indice curado em docs/CHANGELOG.md e do status em docs/BACKLOG.md.

Entregas

• Definido o blueprint do workflow durante o proprio BK em documento temporario de backlog, depois promovido para este changelog detalhado no fechamento.
• Aplicado o fluxo completo no BK-104: backlog vivo detalhado, changelog dedicado (CL-2026-03-17-BK-104.md) e retirada do backlog ativo depois do fechamento.
• Atualizados os indices centrais (docs/BACKLOG.md e docs/CHANGELOG.md) para explicitar que o backlog detalhado existe apenas enquanto o BK esta em andamento; depois disso, o historico oficial passa a morar no changelog.
• Alinhado o fechamento documental com o estado de docs/LOCK.md, deixando os arquivos do BK-104 em DONE e registrando o BK-130 como parte da organizacao final do workflow.

Validacoes executadas

• Leitura e auditoria manual dos documentos ativos em docs/backlog/, docs/changelog/2026/, docs/BACKLOG.md, docs/CHANGELOG.md e docs/LOCK.md.
• Confirmacao de aplicacao real do fluxo usando o BK-104 como caso piloto encerrado.

Riscos residuais

• O workflow ainda depende de disciplina operacional: abrir o arquivo de backlog vivo no inicio do BK e promover o conteudo ao changelog no fechamento.
• O proximo passo natural e reforcar essa regra em AGENTS.md e/ou docs/GIT_WORKFLOW.md para evitar que o processo volte a depender de memoria humana.