• Situação: aceita
• Data: 2026-10-10
• Dono: Bruno dos Santos Vaz (BrunodosSantosVaz)
• Decisão: #221 (E1); implementação: #225 (E5), #226 (E6) e #227 (E7), pendente; release: #220 (v3.0.0).

A v2 usa três GitHub Projects (Planejamento, Execução, Bugs). O dono pediu um quadro único, com colunas separadas por campos ou labels, "desde que funcione no GitHub e que use o padrão do mercado e toda a totalidade do potencial do GitHub". Projects de conta pessoal não emitem eventos de arraste, e a posse atual é otimista (comentário + releitura), sem exclusão real.

• Substitui, na v3, o protocolo otimista do ADR-0011 (label + comentário + releitura) pelas travas atômicas deste ADR. O ADR-0011 continua valendo para projetos no modelo legado até migrarem.
• Os três painéis do processo v2 continuam disponíveis como legado ([board] model = "three-boards").

1. Um Project por repositório com o campo Status em quinze estados:

   • épico: Brainstorm, Backlog, Refinement, Prototyping, Ready, Selected, In Progress, QA, Releasing;
   • tarefa: Todo, Coding, In Review;
   • bug (unidade de release que também carrega o próprio PR): Brainstorm, Backlog, Ready, Selected, Coding, In Review, QA, Releasing;
   • comuns aos três: Done, Rejected, Cancelled.

   Rotas por aplicabilidade:

   • produto: In Progress → QA → Releasing → Done, com a feature flag ligada no final;
   • docs ou operação: In Progress → Releasing → Done;
   • só repositório: In Progress → Done.

   Toda reprovação passa por Rejected, com motivo.

2. Recursos nativos do GitHub antes de label:

   • sub-issues e progresso;
   • dependências (blocked by), que substituem tem-dependencia;
   • milestone para a versão;
   • campos do Project para planejamento: Priority, Size, Sprint, Awaiting, QA decision, Prototype, Flag, posse, tentativas, evidência.

3. Labels ficam para o que os gates leem barato e precisa aparecer em qualquer lista: tipo, área, risco, decisões do dono, impedimentos, motivos de reprovação.

4. A issue é a fonte de verdade, com labels e comentários-recibo estruturados. O Project é a visão, reconciliada periodicamente; movimento manual inválido volta com explicação.

5. Travas atômicas por ref Git (refs/bigbang/locks/<recurso>): criar uma ref que já existe falha, o que dá exclusão real para a posse de tarefas, versão, release e ambiente de staging. A trava tem prazo, renovação e geração; uma sessão vencida não conclui trabalho.

6. Limites de conta pessoal são verificados no bootstrap, nunca presumidos: GitHub App sem acesso a Project pessoal, merge queue e Issue Types apenas em organização.

• O modelo de três painéis continua disponível no legado ([board] model = "three-boards").
• A migração para o quadro único é um passo separado (bb migrate board), com snapshot, pausa, mapeamento por evidência e volta.
• A faxina passa a remover também as travas vencidas.