Release v0.8.0 — avaliação e conteúdo¶

Data da avaliação: 2026-09-13 · De: development · Para: main (produção)

Avaliada por medição, não por leitura de mensagem de commit. O agente de Product Owner foi acionado e travou sem escrever nada; a avaliação abaixo foi feita diretamente, e cada afirmação traz o comando ou o arquivo que a sustenta.

Veredito do papel de Product Owner: 2026-09-13 — corrigido, ver a seção homônima abaixo. A versão se sustenta; quatro afirmações erradas e uma não medida apresentada como fato foram corrigidas no lugar, e duas lacunas que edição nenhuma fecha — revisão e aceitação — estão nomeadas. Confirmação pela pessoa alocada ao papel (sro.product_owner): pendente. Este veredito propõe; não consuma.

⚠️ REAVALIAÇÃO DE 2026-09-18 — 34 commits entraram depois desta avaliação¶

A avaliação abaixo foi medida em 2026-09-13 sobre origin/development em 0ccf02b, com 53 commits à frente de main. Hoje development está em 7fcb4d4, com 87 commits e 36 PRs — 34 commits e 20 PRs entraram depois, dez deles com código.

O agente de Product Owner foi acionado de novo em 2026-09-18 e travou de novo, aos 600 segundos, sem escrever nada. É a segunda ocorrência do mesmo modo de falha, e a skill /release prevê exatamente isto: a reavaliação abaixo foi feita por medição direta, e cada número traz o comando que o sustenta. Confirmação pela pessoa alocada ao papel continua pendente.

⚙️ ATUALIZAÇÃO DE 2026-09-21 — o secret existe, e mais 12 commits entraram¶

A reavaliação abaixo mediu 87 commits e 36 PRs. Hoje são 99 commits e 39 PRs. O que entrou depois:

PR	O que traz
#929	as três chaves estrangeiras que faltavam, e o comentário de `link_board` que descrevia comportamento que o código nunca teve
#931	`mint` 1.10.1 — fecha `CVE-2026-82672` (MEDIUM), contrabando de resposta no cliente HTTP/1 em conexões de pool. É o caminho por onde a coleta fala com o GitHub
#930	a credencial da API pública: token gerável na tela, revogável, guardado só como hash. Nenhuma rota responde ainda

A versão continua 0.8.0, e continua MINOR. Nenhuma rota saiu, nenhum campo público mudou de significado, e das oito migrações desta release nenhuma é destrutiva ao subir — conferido operação a operação, todo drop/remove/modify está no bloco down.

O bloqueio saiu. O secret PRODUCAO_URL foi configurado em 2026-09-21 às 13:35 UTC. O passo do CD que confirma a versão em produção pode funcionar pela primeira vez: a rota /version entrou depois da v0.7.0, e é por isso que produção devolve 404 nela hoje.

Um motivo novo de urgência. A CVE-2026-82672 está no caminho da coleta em produção, agora. Ela sai de lá com esta release, e não antes.

O veredito: a versão continua 0.8.0, e continua MINOR¶

Nada do que entrou depois muda a natureza da release:

Teste de MAJOR	Resultado
alguma rota saiu?	não — `/api/v1` foi planejada, não implementada
algum campo público mudou de significado?	não
alguma migração destrói dado ao subir?	não — ver a seção de riscos, reconferida

E o que entrou é MINOR de novo: três funcionalidades novas chegam à tela — os valores escritos em cada barra e ponto dos gráficos, a aba Flow per person que voltou a abrir com as duas hipóteses de previsão, e as quatro declarações da página do quadro.

O que entrou depois, por tema¶

A cadeia da timeline truncada — #922, #923, #924. Quatro defeitos, cada um escondido pelo anterior: o GitHub cortava a timeline dentro de issues(first: 50) e declarava totalCount igual ao que cortou, com hasNextPage: false; o critério de identidade da atividade não tinha o sujeito e colava ocorrências distintas; um comentário afirmava que a timeline não identifica seus eventos, e isso era falso; e o evento não dizia de que quadro veio, o que fazia a plataforma creditar conclusão a quem não a teve.

A base inteira foi recolhida: 33 repositórios, todos com veredito completa, 858 pontos de cota. As chegadas a Done foram de 1 794 para 3 294.

A declaração do que o quadro significa — #919, #928. A organização passa a declarar o que cada coluna significa, o que cada evento materializa, o critério de fim por quadro, e a recusa registrada. A regra github_project_item_status declara que a coluna não materializa sro.accepted_deliverable, por sro.rule03.

Correções de interface — #925, #927. Os valores nos gráficos, e a aba da equipe que devolvia 500 em 4 de 10 equipes.

Planejamento e registro — #909 a #918, #920, #921, #926. Specs, planos, tarefas, sprints e backlog. Nenhuma linha de código de produção.

Os três riscos, reconferidos em 2026-09-18¶

Migrações: seis novas, nenhuma destrutiva ao subir. Conferido operação a operação: todo drop, remove e modify está no bloco down.

Duas merecem nota:

Migração	O que faz	Reversível?
`identidade_da_atividade_v2`	recalcula o `internal_id` de toda a tabela de atividades, com `stream(max_rows: 500)` dentro de transação	sim
`o_quadro_e_a_coluna_na_atividade`	acrescenta três colunas e dois índices, e preenche `status_name` a partir do `payload` com `UPDATE` de tabela inteira	sim

Volume local: 46 359 linhas, 68 MB. O volume de produção não foi medido — não tenho acesso ao banco de produção daqui, e por isso não prometo tempo de migração.

Variáveis novas: oito, nenhuma obrigatória. MINIO_ROOT_USER, MINIO_ROOT_PASSWORD, MINIO_BUCKET, MINIO_PORT, MINIO_CONSOLE_PORT, PRODUCAO_URL, PRODUCAO_TESTE_EMAIL e PRODUCAO_TESTE_SENHA. O compose.yaml não exige nenhuma sem padrão.

Comportamento visível a quem usa, sem ter pedido: os valores em cima das barras e pontos de cinco gráficos; a aba Flow per person mostrando duas hipóteses de previsão onde antes dava erro; e quatro declarações novas na página do quadro.

Um risco NOVO, que a avaliação anterior não tinha¶

A fase issues da coleta foi à versão 5, e isso reabre o corte incremental em todos os repositórios na primeira coleta depois do deploy.

É intencional: é o que torna retroativo o conserto do identificador do evento e do quadro. Sem o incremento, as atividades já gravadas ficariam para sempre sem esses campos. Mas custa cota — a recoleta completa de 33 repositórios custou 858 pontos — e a primeira sincronização depois do deploy vai demorar mais do que o normal. Quem acompanhar em /syncs precisa saber disso antes de achar que travou.

⛔ O BLOQUEIO OPERACIONAL — o delivery falha sem isto¶

O secret PRODUCAO_URL não existe no repositório. Os únicos configurados são DOKPLOY_WEBHOOK_URL e SONAR_TOKEN.

O passo do CD que confirma a versão em produção (cd.yml:117) falha explicitamente quando ele falta, e a mensagem é a que o próprio workflow escreve: "o delivery aconteceu e NÃO foi verificado". Ou seja: a falha acontece depois do deploy, deixando a versão no ar e o pipeline vermelho, sem distinguir deploy quebrado de verificação impossível.

O valor é conhecido e foi conferido hoje — https://app.theband.dev responde 302 para /sign-in, servindo a aplicação:

gh secret set PRODUCAO_URL --body "https://app.theband.dev"

Esta é a primeira release em que aquele passo pode funcionar. A rota /version entrou em 2026-09-11, no #859, depois da v0.7.0 — por isso produção devolve 404 nela hoje, e por isso a verificação nunca rodou de verdade. A rota devolve texto puro (0.8.0), que é exatamente o que o CD compara, então a engrenagem está certa; falta só o endereço.

Duas coisas que a pessoa alocada ao papel precisa decidir¶

A feature 066 está entregue ou pela metade? Ela entregou a declaração — a tela onde a organização diz o que cada coluna significa. Mas as medidas ainda não a consomem: o gráfico por mês conta external_closed_at, o fechamento da issue na origem, e não a coluna do quadro. As 377 entregas do quadro 43 do Conecta Fapes continuam fora do gráfico, e as três tabelas de declaração estão zeradas — ninguém declarou nada ainda.

A 066 foi implementada sem plan.md e sem tasks.md, direto do protótipo aprovado, pulando duas etapas do ciclo. É dívida declarada no #928, e cabe decidir se ela é paga antes ou depois desta release.

A decisão: cabe release, e a versão é 0.8.0¶

MINOR, e não PATCH: quatro funcionalidades novas chegam à tela — a conta desativada, a aba Flow per person, o vínculo pessoa-equipe, e os rótulos no item de trabalho. Nenhuma quebra contrato existente, e nada foi removido.

Não é MAJOR: nenhuma rota saiu, nenhum campo público mudou de significado, nenhuma migração destrutiva.

Veredito do Product Owner (2026-09-13)¶

Corrigido. A versão 0.8.0 se sustenta como MINOR. O registro tinha quatro afirmações erradas — a lista de PRs, o "rollback sem perda", o estado da 065 e o último CI verde — e uma não medida apresentada como fato — o profile backup fora da produção. Estão corrigidas no corpo (lista ao fim desta seção), junto de acréscimos de proveniência. E há duas lacunas que nenhuma edição fecha — revisão e aceitação —, nomeadas aqui para a decisão de quem desempenha o papel.

Medido sobre origin/main dd4272f → origin/development 0ccf02b (53 commits à frente, 0 atrás), branch chore/release-v0.8.0 em d191866, merge-base 130c0dd (o merge do #907 — a branch foi cortada antes do #908). Sem mix neste worktree, que não tem deps/ nem _build/: tudo por git, gh, curl e leitura de arquivo. Onde a medida não coube no tempo ou não há acesso, está escrito não medido — nunca "confere".

A versão¶

Regra	O que se mediu	Resultado
MINOR quando funcionalidade nova chega à tela sem quebrar contrato	`<:col` em `lib/the_band_web/live/work_item_live/index.ex`: 7 → 8 (`label="labels"`); `vinculo_possivel.ex:46-52`, `@type veredito` com 6 átomos; `test/the_band/teams/flow_per_person_test.exs:113`, `assert uma == 3`; `router.ex`: +1 rota (`get "/version"`)	funcionalidade nova em tela: sim
não MAJOR: nenhuma rota sai	`git diff origin/main..origin/development -- lib/the_band_web/router.ex` filtrado por `^-\s*(get\\|post\\|live\\|…)`	nenhuma removida
não MAJOR: nenhum campo público muda de significado	único controller alterado no intervalo: `version_controller.ex`, novo	sim
não MAJOR: nenhuma migração destrói dado	`up` só com `add`, `create table`, `create index` e um `INSERT` de backfill	sim — com a ressalva do `down`, corrigida no corpo

0.8.0 ratificada. PATCH não cabe (há user story nova em tela); MAJOR não cabe (nada sai, nada muda de significado, nada se destrói no up).

Afirmação a afirmação¶

Afirmação do documento	Comando	Resultado	Confere?
a lista dos PRs que a release carrega (o corpo nomeava 14)	`git log origin/main..origin/development --format='%s' \\| grep -oE '$#[0-9]+$\\|#[0-9]+ from'`	16 distintos: #853 #854 #855 #856 #857 #858 #859 #860 #861 #862 #863 #864 #865 #889 #907 #908 — 8 por squash `(#NNN)`, 8 por merge commit. Cruzado com `gh pr list --state merged --base development`: os mesmos 16 depois do #851	não — faltavam #856 e #908; corrigido. E o #916 (o bump) embarca com eles
uma migração, aditiva	`git diff --name-only origin/main..origin/development -- priv/repo/migrations/` e leitura do arquivo	`20260910050000_episodio_de_desativacao.exs`. `up`: `alter table(:users)` com dois `add`, `create table(:account_disablements)`, dois índices, `execute INSERT` (backfill de `users.disabled_at IS NOT NULL`). `down`: `drop table` e dois `remove`	parcial — aditiva, sim; "rollback sem perda" só vale para o que existia antes; corrigido
nenhuma variável obrigatória nova	`git diff origin/main..origin/development -- .env.example \\| grep -E '^\+[A-Z_]+='`; `grep ':?' compose.yaml`	5 `MINIO_*`, todas `${VAR:-x}` (linhas 128-163), profile `backup`; as `:?` seguem só `DATABASE_URL_CONTAINER`, `SECRET_KEY_BASE`, `THE_BAND_MASTER_KEY`; `compose.yaml` só ganhou linhas (+74, −0)	sim — e a branch de release acrescenta 3 `PRODUCAO_*` que o compose não lê; acrescentado
"o profile `backup` a produção não usa"	configuração do Dokploy	não medido — sem acesso ao Dokploy daqui. Há decisão em curso: PR #914, aberto, propõe MinIO como destino de produção	—
`/version` dá 404 hoje	`curl -s -o /dev/null -w '%{http_code}' https://app.theband.dev/version`	`404`. Junto: `/sign-in` `200`; `/` `302 → /sign-in`	sim
`/version` existe em `development` desde #859 e nunca chegou à `main`	`git show origin/{main,development}:lib/the_band_web/router.ex \\| grep version`	só em `development` (linha 60); ausente em `main`	sim
versão no `mix.exs`	`git show <ref>:mix.exs \\| grep version:`	`main` 0.7.0 · `development` 0.7.0 · `d191866` 0.8.0	sim
a tag `v0.8.0` não existe	`git tag -l v0.8.0`; `git ls-remote --tags origin v0.8.0`	vazio nos dois; a última é `v0.7.0`	sim
o CD cria a tag, falha se repetida, e confirma a versão em produção	`git show origin/development:.github/workflows/cd.yml \\| grep 'name:'`	passos a versão vem do mix.exs, e versão repetida FALHA nomeando (l.35), a tag git nasce do merge (l.85), a produção confirma a versão — resposta diferente FALHA (l.117). `cd.yml` mudou no intervalo (+59)	sim
a listagem ganha uma oitava coluna	`grep -c '<:col'` em `work_item_live/index.ex`, `main` × `development`	7 → 8; a nova é `labels`	sim
seis vereditos de vínculo, inclusive a recusa a quem já é membro	`git show origin/development:lib/the_band/ontology/seon/eo/vinculo_possivel.ex`	`@type veredito` com 6 átomos; `:recusado_ja_e_membro` entre eles	sim
três consultas para qualquer número de membros	`test/the_band/teams/flow_per_person_test.exs:101-113`	`describe "o lote: três consultas para qualquer número de pessoas"`; `assert uma == 3`; trinta pessoas = uma	sim — o teste existe e o CI passou; não foi executado aqui
1 733 vínculos, 1 519 issues com prefixo	`specs/065-rotulos-no-item/plan.md:30-31`; `docs/modelos/banco/mapa-das-tabelas.md:100`	os mesmos números	sim — como registro; o banco não foi consultado
cinco vínculos em 1 953 com `other repository`	corpo do PR #907 (l.48); `git show origin/development:lib/the_band_web/live/work_item_live/show.ex` l.881	"5 vínculos cruzam repositório, 1 948 não" = 1 953; a marca existe no código	sim — afirmação de quem implementou; o banco não foi consultado
259 colunas, zero; 260 MB restaurados com 0 erros	`docs/backlog/rotacionar-o-token-que-vazou.md:48`; corpo do PR #864 (l.55-62)	259 colunas em 2026-09-12; `pg_dump` 260 MB, 0 no padrão, 1 marca de redação, restauração 0 erros	sim — afirmação de quem implementou; proveniência acrescentada ao corpo
constituição 1.8.0	`git show origin/development:.specify/memory/constitution.md \\| grep 1.8.0`	l.619 `Version: 1.8.0`, emenda de 2026-09-13; `main` não a tem	sim
22 issues da 064 seguem abertas	`gh issue list --state open --search 064`	19 tarefas (T001–T019) + 3 US (#885–#887) = 22, mais o épico #888 — 23 com ele	sim, com o épico acrescentado
"T009–T014 da 065 fechadas, mas a T014 segue aberta"	`gh issue view 898…906 --json state,closedAt`	#898–#903 todas CLOSED — a T014 (#903) em 2026-09-13T20:59Z; US #904–#906 OPEN; `tasks.md` em `development` ainda com T014 `[ ]`	não — autocontraditória e vencida pelo GitHub; corrigido
rotação adiada para 2026-10-12; token `…[redigido]`; oito dias	`grep -rn 2026-10-12 docs specs`; `docs/backlog/README.md:9`	`rotacionar-o-token-que-vazou.md:50`, `specs/064/plan.md:160`; 2026-09-04 → 2026-09-12	sim
"o último verde em `development` foi antes do merge do #907"	`gh run list --branch development`	verde em `130c0dd` (#907) e em `0ccf02b` (#908) — run 34779226200, três jobs `success`	não — desatualizada; corrigido
"saída 0, 16 gates, 2149/2149"	`gh run view --job 103783038583 --log`; `gh api …/actions/jobs/103783038583/logs`	não medido — o log não veio por nenhum dos dois caminhos no tempo disponível	—
CI da branch de release	`gh run list --branch chore/release-v0.8.0`	`4262540` e `5a72ab6` verdes; `d191866`: Tipo de merge verde, CI em andamento/na fila às 21:09Z	não medido para `d191866`
FR-016: o momento do delivery é do papel	`specs/050-em-producao/spec.md:183-186`	"a release tem dona … O momento do delivery É o merge desse PR"	sim
L83; #851 como bump da v0.7.0	`docs/sprints/licoes-aprendidas.md:203`; `gh pr view 851`	L83 existe; #851 `chore/release-v0.7.0 → development`, mergeado 2026-09-10	sim
bump por branch `chore/release-*` → `development`	`docs/releases/README.md`, §O bump vive na `development`	compatível: o README recusa `release/* → main`; aqui o bump chega à `development` antes do PR de release	sim

As duas lacunas que edição nenhuma fecha¶

Revisão: 16 de 16 PRs sem revisão registrada e sem revisor pedido. gh pr view <n> --json reviews,reviewRequests devolve 0 e vazio para cada um dos 16 — e o corpo do #864 já declarava "os PRs #859 a #863 também estão sem revisor". É o mesmo resíduo da v0.7.0 (21 de 21). Pela formulação da casa é revisão não pedida: o vazio prova ausência de registro, não que ninguém leu — mas ninguém foi notificado, e o princípio VII não tem prova aqui. PR mergeado não admite pedido de revisão: para estes 16 é resíduo que não se recupera. O #916, o bump, ainda está aberto e também está sem revisor pedido e fora do projeto (reviewRequests vazio, projectItems 0) — este se corrige antes do merge: gh api -X POST repos/The-Band-Solution/theband/pulls/916/requested_reviewers -f 'team_reviewers[]=the-band', conferindo depois com gh pr view 916 --json reviewRequests.

Aceitação: nenhum dos quatro entregáveis visíveis tem fase registrada. O último docs/sprints/*/aceitacao.md é o do sprint 026. Não há registro para 045 (#853), 060 (#860), 055/FR-003 (#863) nem 065 (#907) — e as US #904–#906 da 065 estão abertas com todas as tarefas fechadas, que é exatamente o estado executada, sem fase. O invariante da release é o do entregável de sprint: só aceito embarca. Agrava o #853: é o retrabalho da D06 recusada na v0.7.0 (quatro critérios não conformes, um sem evidência, tela sem protótipo aprovado — ver v0.7.0.md l.374), e a reavaliação, que é ato do papel, não aconteceu. Este veredito não faz essa aceitação: ela exige percorrer os critérios de cada user story com evidência, e não é o que foi pedido aqui. O que ele faz é impedir que o registro afirme que aconteceu.

Adendo, 2026-09-13 às 21:40Z — a avaliação da 065 foi feita pelo papel, em separado, e está proposta nas issues (comentários em #904, #905 e #906; nenhuma fechada, porque a aceitação é ato da pessoa alocada ao papel): US1 não aceita — a listagem cumpre, mas o campo labels do detalhe (work_item_live/show.ex) mostra só o observado, sem origem e sem o derivado, e nenhum dos três protótipos cobre esse campo; US2 não aceita — "rótulo" na spec é o label do GitHub, "label" no mecanismo de divergência é o tipo declarado, e a plataforma nunca produz label_vs_structure: a tela mostra os dois lados e não diz que divergem nem qual foi seguido; US3 aceita, pendente de confirmação e da revisão do #907. Cinco arquivos de teste prometidos no tasks.md não existem, e o SC-002 (1 519) mede 1 489 pela função entregue — 47 variantes de caixa não derivam. O #907 embarca nesta release com uma user story não aceita e uma conceitualmente errada — é isto que a decisão de exceção precisa nomear.

O que isto significa para a decisão que é sua (FR-016), e que este veredito não toma: a versão está certa e o registro agora é exato. O que embarcar sem aceitação registrada embarca como exceção nomeada — como a v0.4.0 e a v0.5.0, cuja lacuna o README.md deste diretório carrega —, e a página da aplicação não anuncia como entregue o que não foi aceito. Ou a aceitação vem antes do PR de release. Não é este veredito que escolhe entre as duas.

Correções feitas no corpo¶

O que a release carrega: contagem explícita (16 + o bump); #856 e #908 acrescentados, com o que cada um carrega; #916 declarado; #855 ganhou a descrição que faltava;
#864: proveniência dos números (corpo do PR) e o ensaio de 2026-09-13 pelo caminho completo com MinIO;
Migração: o backfill declarado; o down nomeado, com o que um rollback perde depois do deploy;
Variáveis: as três exigidas de sempre nomeadas; as três PRODUCAO_* da branch de release; "a produção não usa o profile" marcado como não medido, com o #914;
O que NÃO carrega: 065 reescrita — T009–T014 todas fechadas, a divergência do tasks.md, as três US abertas; 064 com o épico #888;
O que NÃO foi verificado: o último verde é em 0ccf02b; "16 gates, 2149/2149" marcado como não remedido; estado da branch de release;
Como executar: o #916 sem revisor e fora do projeto, com o comando que corrige.

O motivo mais urgente de subir, e ele não é uma feature¶

Medido em 2026-09-13:

curl -s -o /dev/null -w '%{http_code}' https://app.theband.dev/version
→ 404

A produção não sabe dizer que versão está servindo. O endpoint existe em development desde o PR #859 e nunca chegou à main. Era exatamente o achado H7.

Enquanto isso for verdade, qualquer conferência do que está no ar é palpite — inclusive a desta release. É a primeira coisa que muda depois do merge, e o CD passa a falhar se a produção devolver versão diferente da publicada.

O que a release carrega¶

Dezesseis PRs mergeados em development desde a v0.7.0 (#852, dd4272f), medidos por git log origin/main..origin/development — (#NNN) no assunto para os squash, #NNN from para os merge commits — e cruzados com gh pr list --state merged --base development: os mesmos 16 depois do #851. Mais o #916, o bump desta release, que entra em development antes do PR de release e por isso embarca com ele.

Funcionalidade visível¶

#853 — A conta desativada, como o protótipo pediu. O desligamento deixa de ser implícito: a razão fica registrada, e na tela a conta desligada deixa de ser indistinguível da recém-criada. Era risco em produção naquele momento.

#860 — A aba Flow per person. A tela do protótipo aprovado, com o burn por pessoa e a previsão que diz sua confiança. Três consultas para qualquer número de membros.

#863 — Vincular pessoa a equipe (FR-003). A tela ganha o ato, com os seis vereditos de vínculo possível — inclusive a recusa quando a pessoa já é membro.

#907 — Os rótulos do GitHub no item de trabalho. Duas origens: o campo da ferramenta (sólido) e o prefixo do título (hachurado). 1 733 vínculos e 1 519 issues com prefixo passam a ser consultáveis. E a ontologia entra no desenho das sub-listas — part_whole ganha régua, association ganha seta, e é isso que explica por que as duas contagens nunca somam.

Segurança¶

#864 — TheBand.Segredo. Um segredo decifrado deixa de ser binário nu: o tipo recusa inspect, recusa interpolação e recusa serialização. Nasceu de um token do GitHub que ficou em texto claro em oban_jobs.errors por oito dias.

Junto: a linha foi redigida, o banco varrido (259 colunas, zero — 2026-09-12, docs/backlog/rotacionar-o-token-que-vazou.md), e o ensaio do dump feito — pg_dump de 260 MB varrido por dentro e restaurado com 0 erros, segundo o corpo do PR #864: é afirmação de quem implementou, e o banco não foi consultado nesta avaliação. O ensaio foi repetido em 2026-09-13 pelo caminho completo com MinIO — 248 MiB ao balde e de volta, 66 tabelas, 0 erros, checksum igual (docs/seguranca/2026-09-13-o-caminho-completo-do-backup.md, na branch de release).

#859 — H7 e H8, a cadeia do deploy. /version, e a verificação no CD que falha se a produção responder outra coisa.

Infraestrutura e processo¶

#861 — MinIO como destino do ensaio de backup. O §6 do runbook deixa de esperar conta em provedor.

#889 — A constituição 1.8.0. A evidência passa a morar na issue, com comando e código de saída; e a auditoria contra a origem vira obrigação antes de abrir PR.

#854, #855, #857, #858, #862, #865 — a ramp tipográfica; a revisão do vínculo, o ato de subequipe e o merge por comando, nos docs; o ato de subequipe numa transação; o detector que para de rodar cego; os modelos em Mermaid; e o plano da 064.

#856 e #908 — faltavam nesta lista (veredito do Product Owner, 2026-09-13). O #856 é o back-merge da v0.7.0: git diff --stat 198dbd5^1 198dbd5 é vazio — convergência de histórico, nenhum conteúdo próprio. O #908 reescreve o escopo da fase 4 da 065 e marca as caixas T001–T013 em specs/065-rotulos-no-item/tasks.md — só documentação, mas está no intervalo.

#916 — o bump. mix.exs 0.7.0 → 0.8.0, este documento, o agente aceitacao-em-producao, o registro do ensaio de backup de 2026-09-13 e três linhas no .env.example. Entra em development primeiro (ver Como executar), e por isso embarca.

Riscos, medidos¶

A migração nova é aditiva¶

Uma só desde o PR #852: 20260910050000_episodio_de_desativacao.exs.

alter table(:users) do
  add :password_source, :string
  add :password_set_by_user_id, :binary_id
create table(:account_disablements, ...)
create index(...); create unique_index(..., where: "enabled_at IS NULL")
execute "INSERT INTO account_disablements ... FROM users u WHERE u.disabled_at IS NOT NULL"

No up, nenhum drop, nenhum modify, nenhuma coluna removida — e um execute INSERT que preenche account_disablements a partir de users.disabled_at IS NOT NULL, com disable_reason = 'not_recorded'. Aditiva.

"Rollback sem perda" só vale para o que existia antes (corrigido em 2026-09-13). O down faz drop table(:account_disablements) e remove das duas colunas: cada episódio de desativação escrito depois do deploy — razão, nota, autor, reativação — se perde num rollback; users.disabled_at fica. Não é motivo para não subir; é o que um rollback custa, escrito antes de precisar.

As variáveis novas não bloqueiam a subida¶

As cinco MINIO_* entraram no .env.example, e todas têm padrão no compose.yaml (${MINIO_ROOT_USER:-theband}, compose.yaml l.128-163). Vivem no profile backup.

Nenhuma variável obrigatória nova. As exigidas (${VAR:?}) no compose.yaml seguem as três de sempre — DATABASE_URL_CONTAINER, SECRET_KEY_BASE, THE_BAND_MASTER_KEY — e o arquivo só ganhou linhas no intervalo (+74, −0). A lista fechada do contrato do pipeline não mudou.

A branch de release acrescenta mais três ao .env.example — PRODUCAO_URL, PRODUCAO_TESTE_EMAIL, PRODUCAO_TESTE_SENHA —, lidas só pelo agente aceitacao-em-producao; o compose.yaml não as referencia. Sem elas o agente roda e declara o que não mediu.

"A produção não usa o profile backup" não foi medido: a configuração do Dokploy não é acessível daqui, e a afirmação anterior desta seção vinha de memória. Há decisão em curso — o PR #914, aberto, propõe MinIO como destino de produção.

O que muda de comportamento em tela já em uso¶

a listagem de itens ganha uma oitava coluna. Em tela estreita, a rolagem lateral fica mais frequente. Não esconde nada — é custo de leitura;
a tela de contas passa a distinguir desativada de recém-criada. É correção: antes as duas eram iguais;
o detalhe do item ganha repositório nas sub-listas. Cinco vínculos em 1 953 mostram a marca other repository; os outros ganham só o caminho.

O que a release NÃO carrega, e alguém pode esperar que carregue¶

A spec 064 inteira. Só o TheBand.Segredo e a redação foram entregues. O token de sessão continua em claro no banco, a migração de sessão não foi feita, e as 22 issues da 064 — 19 tarefas (T001–T019) e 3 user stories — seguem abertas, mais o épico #888;
A varredura como tarefa repetível (064/T002) — o ensaio de 2026-09-12 foi manual;
A rotação do token …[redigido], adiada pela pessoa mantenedora para 2026-10-12. Ele esteve legível oito dias, e a janela de risco vai de 2026-09-04 até o dia da rotação;
O backup para o segundo host — decidido para a semana que vem;
A aceitação da 065. As tarefas T009–T014 (#898–#903) estão todas fechadas no GitHub — a T014, fechar os gates, às 20:59Z de 2026-09-13 —, e as três user stories #904–#906 seguem abertas com veredito proposto pelo papel em 2026-09-13 (US1 e US2 não aceitas, US3 aceita pendente de confirmação — ver As duas lacunas). O tasks.md em development ainda mostra a T014 desmarcada; a issue venceu o arquivo. (Corrigido em 2026-09-13: a linha anterior dizia que a T014 seguia aberta, e era autocontraditória.)

O que NÃO foi verificado¶

Não medi a produção autenticado. Sem /version no ar e sem conta de aceitação configurada, o que se sabe do ambiente hoje é: /sign-in responde 200, / redireciona, /version dá 404;
Não rodei mix gates nesta branch. O CI está verde em development em 130c0dd (#907) e em 0ccf02b (#908) — run 34779226200, três jobs success: a imagem de produção builda, quality-gates, cobertura. O "saída 0, 16 gates, 2149/2149" da linha anterior não foi remedido: o log do job não veio pela CLI nem pela API no tempo disponível. Na branch de release, 4262540 e 5a72ab6 verdes; d191866 com Tipo de merge verde e CI em andamento às 21:09Z de 2026-09-13. A branch de release não acrescenta código de produto;
Não conferi o build da imagem de produção para este conjunto — o CD o faz, e é ele que decide.

Como executar¶

São dois PRs, nesta ordem — e nenhum deles é o deploy sozinho:

o bump: chore/release-v0.8.0 → development, squash. Leva o mix.exs a 0.8.0 e este documento. É o passo que vem antes do PR de release, como na v0.7.0 (#851). É o #916, e às 21:09Z de 2026-09-13 estava sem revisor pedido e fora do projeto — a regra da casa exige os dois ao abrir. Corrige-se antes do merge: gh api -X POST repos/The-Band-Solution/theband/pulls/916/requested_reviewers -f 'team_reviewers[]=the-band', e confere-se com gh pr view 916 --json reviewRequests (lista vazia = ninguém foi pedido);
a release: development → main, merge commit — nunca squash. L83: squash faz as duas linhas divergirem, e a divergência não se desfaz.

gh pr create --base main --head development --title "Release v0.8.0"
# depois da aprovação, por comando — o botão não tem método default:
gh pr merge <n> --merge

A tag não se cria à mão. Ela nasce do CD no push em main (.github/workflows/cd.yml, passo a tag git nasce do merge), e o primeiro passo do mesmo CD falha nomeando se v0.8.0 já existir em outro commit. Criar a tag antes reprovaria o próprio deploy.

Depois do deploy, a primeira medida é /version — e ela passa a ser possível pela primeira vez. O CD já a faz: a produção confirma a versão — resposta diferente FALHA.

O momento do delivery é decisão do Product Owner (FR-016). Este documento avalia e prepara; não autoriza.