v0.9.1 — o limite passa a valer, o CD volta a dizer a verdade, e a tela de tokens muda¶

No ar desde 2026-09-24. Tag v0.9.1, CD verde — a primeira execução verde em três releases —, e a produção respondendo 0.9.1 em /version, HTTP 200.

O número desta release está errado, e fica escrito aqui¶

0.9.1 é PATCH, e o que ela carrega é MINOR. Três coisas que quem administra passa a conseguir fazer — escolher um token sem prazo, dizer por que revogou, ver o que a credencial leu — mais uma migração. Pela regra desta casa, isso é 0.10.0.

Como aconteceu, medido e não lembrado: esta nota foi escrita em 2026-09-23 propondo uma release de correção, com um commit só, e recomendando explicitamente não esperar o #939 — para isolar a variável e provar o conserto do CD com a carga mais barata possível. O PR de release já estava aberto, e ele é development → main: quando o #939 foi mergeado em development, em 2026-09-24, ele entrou na release sem que nada fosse decidido. O PR foi mergeado antes de a correção do número chegar.

O que isso ensina, e é o motivo de estar escrito aqui e não apagado: um PR de release aberto contra development não carrega uma carga — carrega o que development tiver no instante do merge. A avaliação que o justifica envelhece sozinha, sem aviso, e a única coisa que a mantém honesta é reabrir a medida antes de clicar.

O que NÃO foi feito, de propósito: a tag v0.9.1 não foi apagada nem movida. Tag publicada é fato, e reescrevê-la faria a série de versões mentir de um jeito pior — sem deixar rastro. O mix.exs na development já está em 0.10.0, e é esse o número da próxima.

As três afirmações que esta nota fazia e que a carga desmentiu foram corrigidas abaixo: um commit virou três, apareceu uma migração, e a release passou a mudar uma tela em uso.

Decidida por: proposta do papel sro.product_owner_role em 2026-09-23 — pendente de confirmação de sro.product_owner PR de release: a abrir (development → main) · Merge/deploy: pendente Aceitação que a sustenta: docs/sprints/033-a-api-publica/aceitacao.md, com uma reavaliação proposta — o SC-004, que aquele registro recusou, e que esta release conserta Carga (medida em 2026-09-24): três commits — e9cb31e (#938), 1094049 (esta nota e o bump) e 4d0f716 (#939). Uma migração, aditiva. Nenhuma variável de ambiente nova. Três mudanças numa tela em uso

Medido em 2026-09-23, contra a origem e contra a produção, e não lembrado:

O que se mediu	Comando ou consulta	Resultado
o que separa `main` de `development`	`git log --oneline origin/main..origin/development`	um commit: `e9cb31e`
migração nova	`git diff --name-only origin/main...origin/development -- priv/repo/migrations/`	vazio
variável nova	`git diff origin/main...origin/development -- .env.example docker-compose.yml config/runtime.exs \\| grep '^+'`	vazio
tela alterada	mesmo diff, filtrado por `.heex` e `live/`	só `test/.../fluxo_na_tela_test.exs` — nenhuma tela de produção
a versão no ar	`curl https://theband.5.189.161.85.sslip.io/version`	`0.9.0`, HTTP 200
o `mix.exs`	`grep 'version:' mix.exs`	`0.9.0` — igual ao que a produção serve

O que esta release entrega¶

1. O limite de taxa passa a valer 120 por minuto de verdade — antes deixava passar 240 na virada¶

A janela era fixa: o contador zerava na virada do minuto, e quem chamasse 120 vezes nos últimos segundos de um minuto e 120 nos primeiros do seguinte passava 240 em poucos segundos, com limite declarado de 120. A limitação estava declarada no #936 quando ele entrou, e foi para produção assim.

Agora o minuto é contado em fatias de dez segundos, e a conta soma as fatias que cobrem os últimos sessenta. A rajada na virada cai de um minuto inteiro para dez segundos de imprecisão, e a soma é mais estrita que a janela declarada, nunca mais frouxa.

A razão de não ser a janela exata está registrada no PR e importa aqui: guardar o instante de cada chamada daria a janela perfeita, mas contar exigiria ler, podar e escrever — e isso não é atômico. Duas requisições simultâneas do mesmo token leriam a mesma lista e as duas passariam, justamente sob a carga que o limite existe para conter. update_counter sobre a fatia é atômico.

Quem usa a API não vê diferença nenhuma, exceto quem estava aproveitando a virada.

2. Quem opera passa a distinguir cinco causas de recusa no log, e o cliente continua vendo exatamente a mesma resposta¶

Era o SC-004, e o registro de aceitação da 061 o classificou não conforme em 2026-09-23: as cinco causas chegavam ao log como credencial_recusada, e "alguém varrendo tokens que nunca existiram" e "credencial que vazou e ainda não foi revogada" começavam a mesma investigação. A informação existia e era descartada uma linha antes de chegar ao log.

O log interno agora nomeia: inexistente, malformado, revogado, expirado, segredo_errado — mais sem_cabecalho, que já existia.

E a resposta ao cliente continua idêntica nas cinco, que é o SC-003 e é o que impede confirmar a quem testa credencial roubada que ela existiu e quando. As duas afirmações são sustentadas juntas, em lugares diferentes: api_tokens_test.exs afirma que os motivos internos diferem; motivo_da_recusa_test.exs afirma que as respostas HTTP são idênticas. Nenhum dos dois basta sozinho, e é essa a razão de serem dois.

3. O CD volta a dizer a verdade — ele reprovou as duas últimas releases com o deploy funcionando¶

A conferência final do CD comparava /version, que devolve o número puro do mix.exs, com o nome da tag, que leva o prefixo v. Nunca casava.

Medido nesta avaliação, direto nas execuções do workflow:

Release	Execução	Resultado	O que a produção respondia
v0.8.0	35609527649, 2026-09-21	failure	`404` e `502` nas primeiras tentativas; a partir da 19ª, `0.8.0` — e reprovou mesmo assim, esperando `v0.8.0`
v0.9.0	35880777724, 2026-09-23	failure	`0.8.0` até a 3ª tentativa; `0.9.0` a partir da 4ª, às 15:22:25Z — e reprovou nas trinta, esperando `v0.9.0`

Duas coisas que essa medição fixa, e que nenhuma delas estava escrita antes:

o deploy da v0.9.0 levou 31 segundos da janela de cinco minutos disponível. A margem é larga: o vermelho foi só o formato, e não lentidão de implantação;
foram duas releases seguidas reprovadas por engano. Um CD que reprova quando deu certo treina quem lê a ignorá-lo, e a próxima falha real passa despercebida. É por isso que este item é o mais urgente dos três, apesar de ser o que menos muda o produto.

4. A tela de tokens muda em três lugares, e quem usa vai notar sem ter pedido¶

Entrou pelo #939, mergeado em 2026-09-24 — depois de o protótipo ser republicado no mesmo endereço e reaprovado.

"Sem expiração" passa a ser oferecido no formulário. Reverte a regra que dizia "máximo do qual se abre mão não é máximo", e a consequência está escrita na própria tela: um token sem prazo só sai de circulação por revogação deliberada, e nada anuncia que ele existe.

Revogar passa a gravar por quê — quatro cláusulas em lista fechada, mais nota livre. A que justifica o campo é suspeita de vazamento: é o único caso em que o próximo ato muda. A migração 20260923120000_motivo_da_revogacao_do_token é aditiva — duas colunas nulas, e o rollback não perde nada além delas. Não preenche o passado: revogação anterior fica com cláusula nula e a tela escreve "no reason recorded · revoked before 23 Sep 2026".

A linha abre um painel de uso, por rota, com a janela escolhida e dita — e nunca como nona coluna. Ele fecha o item 6 do plano de correções: até aqui o registro de leitura existia e nenhuma tela o lia.

E o que a conferência achou DEPOIS do merge¶

O QA e o Design conferiram a entrega depois de ela já estar em development. Acharam, cada um por seu lado e sem combinar, o mesmo defeito mais grave — e ele não é do #939:

o botão Copy value não copia nada, e está em produção desde a v0.8.0. A tela despacha the_band:copy e ninguém escuta: o JS.dispatch tem uma ocorrência no repositório, a que dispara. O botão não dá erro. O valor do token é mostrado uma vez, a tela diz que ele não volta, e quem clica e sai perde a credencial sem ver um erro.

E a guarda do SC-013 media nada. Com data-h={Base.encode16(token_hash)} plantado em cada linha, o hash aparecia duas vezes no HTML servido e os 84 testes ficavam verdes — inclusive o que leva o nome do critério. A varredura rodava sobre o texto com as tags já removidas, que é exatamente onde um atributo se esconde.

Os dois consertos NÃO estão nesta release: estão nos PRs #941 e #942, abertos. Se forem mergeados antes do PR de release, entram; se não, esta release vai ao ar com o botão morto, que é o estado de hoje em produção e não uma regressão.

Restam 29 dos 70 itens da régua sem guarda nenhuma, e nove divergências entre a tela entregue e o protótipo aprovado — entre elas a coluna state imprimindo "ativo" em português. Nenhuma foi aceita formalmente: a aceitação da tela item a item não aconteceu antes do merge, e o Product Owner a tinha posto como pré-condição.

Por que o grau certo era 0.10.0, e saiu 0.9.1¶

Esta seção foi reescrita em 2026-09-24, depois do delivery. Ela concluía 0.9.1 sobre uma carga de três consertos, e a carga mudou antes do merge: com o #939 dentro, a release entrega três coisas que quem usa passa a conseguir fazer. O raciocínio original fica logo abaixo, porque ele continua certo sobre a parte dele — e porque apagar a conclusão anterior apagaria que a decisão foi tomada duas vezes, sobre cargas diferentes.

A regra é semver sobre o que a release carrega:

Grau	Cabe?	Por quê
MAJOR	não	nada sai, nenhuma rota some, nenhum campo público muda de significado. A migração é aditiva, e o `401` continua byte a byte idêntico nas cinco causas
MINOR	sim	escolher um token sem prazo, dizer por que revogou, e ver o que a credencial andou lendo são três coisas que não se podia fazer ontem. Nenhuma quebra contrato; todas mudam a tela debaixo de quem a usa
PATCH	não	PATCH conserta sem mudar o prometido, e esta release muda uma tela em uso e acrescenta colunas ao banco

O grau certo era 0.9.0 → 0.10.0, e o que foi ao ar foi 0.9.1. A correção do número chegou à development depois de o PR de release já ter sido mergeado. O mix.exs da development está em 0.10.0, e a próxima release leva esse número.

O raciocínio de 2026-09-23, quando a carga era só o #938¶

Concluía 0.9.1, e concluía certo para aquela carga:

Grau	Cabe?	Por quê
MAJOR	não	nada sai, nenhuma rota some, nenhum campo público muda de significado. A resposta `401` continua byte a byte idêntica nas cinco causas — o SC-003 é preservado e testado
MINOR	não	nenhuma user story nova é entregue. A US5 (limite de taxa por token) já foi declarada entregue na v0.9.0; o que muda é a fidelidade do limite ao número prometido. Quem usa a API não passa a conseguir nada que não conseguisse ontem
PATCH	sim	conserta sem mudar o prometido: a janela passa a respeitar o limite declarado, o log passa a cumprir a FR-016 que a v0.9.0 descumpria, e o CD passa a comparar o que devia

A contra-hipótese, para que ela fique escrita. Alguém pode argumentar MINOR pelo item 2: quem opera passa a ver cinco motivos onde via um, e isso é capacidade nova para essa pessoa. Recuso, e a razão é que a FR-016 já prometia o motivo real no log interno — a v0.9.0 foi ao ar sem cumprir, e o registro de aceitação nomeou isso como não conforme. Cumprir promessa descumprida é retrabalho, e retrabalho é PATCH. Chamar de MINOR faria a correção de um critério recusado aparecer na série de versões como valor novo, que é exatamente o que apaga o retrabalho da contagem.

E a conclusão de então: "0.9.0 → 0.9.1. O bump vive na development, antes do PR de release." Ela valeu por um dia.

A decisão de escopo, e como ela foi ultrapassada¶

O #939 foi mergeado em development em 2026-09-24, e o PR de release é development → main — então ele entrou na release sem que a decisão abaixo fosse recusada ou aceita. Ela simplesmente deixou de ter objeto.

O que ela previa continua valendo como aviso, e vale repetir aqui na frente: o conserto do CD nunca foi executado, e agora vai ser provado numa release que carrega também uma migração e três mudanças de tela. Se a conferência final do CD reprovar, o diagnóstico tem quatro causas candidatas em vez de uma. Era exatamente isso que a recomendação existia para evitar.

O raciocínio inteiro fica abaixo, sem corte.

O que se recomendava em 2026-09-23: soltar só com o #938¶

Recomendação: (A) — soltar a v0.9.1 só com o #938. O #939 fica para a release seguinte.

O #939 está aberto (quality-gates ainda em execução, conferido em 2026-09-23) e carrega as três mudanças aprovadas da tela de tokens — sem expiração oferecido, motivo na revogação, painel de uso — mais a migração 20260923120000_motivo_da_revogacao_do_token, aditiva.

As seis razões, da mais forte para a mais fraca¶

1. O conserto do CD é o instrumento que valida toda release futura, e está não provado. Nenhuma execução rodou com ele. Provar um instrumento é exercício de isolar variável: se a carga for só correção, um vermelho na próxima execução tem uma causa candidata. Com migração e três mudanças de tela juntas, o vermelho fica ambíguo — falhou a comparação, a migração, a troca de imagem, ou o deploy demorou? Diagnóstico ambíguo em janela de produção custa mais que uma janela extra.

2. O que o #938 conserta está em produção errado agora. Hoje a produção tem janela fixa — que deixa passar o dobro — e cinco causas de recusa colapsadas numa. Os dois consertos estão prontos. Adiá-los por um trabalho de tela é adiar controle de segurança por conveniência de empacotamento, e a razão de um não tem nada a ver com a do outro.

3. O #939 não tem aceitação registrada, e a tela dele tem régua. A conferência item a item da estrutura aprovada do PROMPT.md contra a tela entregue, com captura ao lado e a conferência do QA como evidência, não foi feita. Juntar os dois cria pressão para aceitar a tela dentro da janela de deploy — e a regra desta casa é que a tela implementada é exatamente a tela aprovada. Uma release não é lugar para apressar essa conferência.

4. O CI do #939 ainda não fechou. Pré-condição de delivery não atendida hoje. Em (B), o momento da release passa a depender de um evento futuro de duração desconhecida, e o item que tem urgência própria — o CD vermelho — fica refém dele.

5. O custo de (A) é uma janela de deploy a mais, e ela é barata. Sem migração, o delivery é troca de imagem: nada a restaurar, nada a reverter além de reapontar a tag anterior.

6. O rollback fica mais simples. Migração aditiva não perde dado no rollback — isso é verdade e está medido no #939 —, mas rollback com esquema envolvido ainda exige ordenar imagem e migração. Nesta release não há o que ordenar.

O que (A) custa, e fica escrito¶

Custo	Tamanho
duas conferências de CD, duas notas de release, dois back-merges	real, e pequeno
o painel de uso e o motivo da revogação ficam mais um ciclo fora do ar	o painel fecha o item 6 do plano de correções, e quem opera continua consultando `api_access_reads` à mão
sem expiração continua indisponível na tela	quem precisa de token sem prazo continua escolhendo um prazo e renovando

Nenhum dos três é risco de segurança nem defeito em produção. São valor adiado por um ciclo curto — e o ciclo é curto porque esta release é pequena.

O que a release seguinte carrega, se (A) for confirmada¶

O #939 vira v0.10.0, e MINOR desta vez é o grau certo: três coisas que quem usa passa a conseguir fazer — escolher um token sem prazo, dizer por que revogou, e ver o que a credencial andou lendo —, mais uma migração aditiva. Ela exige o que esta não exige: o registro de aceitação da tela contra o protótipo aprovado, e o ensaio de restauração em dia antes da janela, por regra e não por risco.

A evidência, executada nesta avaliação¶

Não é a declarada no PR. Foi executada agora, em árvore limpa da origin/development (e9cb31e), num worktree separado, para que o resultado não carregue nada do #939:

mix test test/the_band_web/api/motivo_da_recusa_test.exs \
         test/the_band_web/api/registro_e_limite_test.exs \
         test/the_band/tenants/api_tokens_test.exs

Código de saída: 0 · 43 testes, todos passando. E a saída do log, que é a evidência direta do SC-004 — as cinco causas nomeadas, uma a uma, com o request_id que liga cada linha à requisição:

[warning] api: credencial recusada · motivo=malformado     request_id=GNgcMjs0D2peU7QAAfjB
[warning] api: credencial recusada · motivo=inexistente    request_id=GNgcMjvdev9eU7QAAfjh
[warning] api: credencial recusada · motivo=segredo_errado request_id=GNgcMjv54NteU7QAAfkB
[warning] api: credencial recusada · motivo=revogado       request_id=GNgcMjwBSDNeU7QAAfkh
[warning] api: credencial recusada · motivo=expirado       request_id=GNgcMjwH6CpeU7QAAflB

A reavaliação que proponho ao papel¶

Critério	Fase no registro do sprint 033	Fase proposta	Evidência
SC-004 — 100% das recusas com o motivo real recuperável no log interno, razões distintas	não conforme	conforme	a execução acima: cinco motivos distintos, cada um com `request_id`
SC-003 — inexistente, revogado e expirado com respostas byte a byte idênticas	conforme	segue conforme	`motivo_da_recusa_test.exs` passa na mesma execução; o conserto do SC-004 não o quebrou, e é esse o risco que ele tinha
SC-011 — sob limite excedido por um token, outro recebe `200`	conforme	segue conforme	`registro_e_limite_test.exs` passa com a janela nova
SC-007 — proveniência e limitações em 100% dos objetos de medida	não conforme	segue não conforme	nada nesta release toca isso; nasce na 062, com `KnowledgeBase.measurement/1`

O que essa evidência não é. Os asserts foram escritos por quem implementou; o que executei foi a suíte deles, e o que li de forma independente foi a saída do log. Isso é mais forte que a afirmação de quem implementou e mais fraco que uma conferência de terceiro. A distinção fica aqui em vez de virar "conforme" liso.

O registro do sprint 033 não foi alterado por este documento. A mudança de fase do SC-004 é proposta; quem a confirma é sro.product_owner, e a confirmação pertence àquele arquivo.

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

O que	Estado
~~as três mudanças da tela de tokens~~	carregadas — o #939 foi mergeado em 2026-09-24 e entrou nesta release
~~a migração do motivo da revogação~~	carregada, e é aditiva
o conserto do botão `Copy value`	no #941, aberto. Se não entrar antes, esta release vai ao ar com um botão que não copia — que é o estado de produção hoje, e não uma regressão
as guardas da régua, e o conserto do SC-013	no #942, aberto. São teste: não mudam produção, mudam o que a suíte consegue reprovar
a aceitação da tela item a item	não aconteceu antes do merge, e era pré-condição escrita. As conferências de QA e Design rodaram depois, e acharam 11 reprovações de régua e 9 divergências contra o protótipo
proveniência nas medidas da API (SC-007)	continua não conforme; depende da 062 e de `KnowledgeBase.measurement/1`, que não existe
a versão e as novidades anunciadas na aplicação	não existe superfície: há a rota `/version`, que é endpoint e não página. Ver O momento do delivery
o aviso de vencimento por e-mail	adiado por decisão em 2026-09-23; a plataforma não envia e-mail nenhum — nenhum `Mailer`, nenhuma variável de SMTP
retenção do registro de leitura	decidida em 2026-09-23 — indefinida, registrada em `api.access.thresholds`. Não há poda, e isso é escolha, não descuido
o servidor MCP	o #935 é plano; nenhum servidor sobe
teto de concorrência	o limite é por taxa, não por chamadas simultâneas. Medido em produção: sequencialmente não se alcança o limite — só com paralelismo
a revisão independente	não ocorreu. Ver as lacunas

Os três riscos que toda release mede¶

Risco	Medida	Resultado
migração destrutiva	`git diff --name-only origin/main..origin/development -- priv/repo/migrations/`	uma, `20260923120000_motivo_da_revogacao_do_token` — e ela é aditiva: `add` de duas colunas nulas em `api_access_tokens`. O rollback as remove e não perde nada além delas. Ida e volta executadas
variável obrigatória nova	diff de `.env.example`, `docker-compose.yml` e `config/runtime.exs`	nenhuma. Nada a configurar antes do merge
mudança em tela em uso	diff filtrado por `.heex` e `live/`	três, em `/api-tokens`: o prazo sem expiração no formulário, a cláusula e a nota na revogação, e o painel de uso na linha. Quem administra vai notar sem ter pedido

A tabela acima foi corrigida em 2026-09-24. Ela dizia "nenhuma migração" e "nenhuma tela de produção" — as duas afirmações eram verdadeiras quando a carga era só o #938, e deixaram de ser no instante em que ele foi mergeado. Um risco medido contra a carga errada é pior que risco não medido, porque tem a forma de uma medida.

O que isso obriga que a versão anterior desta nota dispensava: o ensaio de restauração em dia antes da janela — por regra, já que há migração, e não por risco, já que ela é aditiva.

O momento do delivery¶

Três perguntas antes do merge. Duas podem ser respondidas; a terceira não.

Pergunta	Resposta em 2026-09-24
a aceitação está confirmada pelo papel?	pendente — e agora são duas: a reavaliação do SC-004, proposta acima, e a aceitação da tela item a item, que era pré-condição e não aconteceu antes do merge
o CI está verde no PR de release?	a medir
a página anuncia esta versão?	não, e a superfície não existe

A terceira pergunta, e a dispensa que se desfez sozinha¶

A regra é de 2026-09-09: a página do The Band sempre carrega a versão da aplicação em produção e as funcionalidades novas daquela versão. A v0.7.0 saiu com dispensa explícita, e naquela dispensa está escrito que "a dispensa não se repete: a v0.8.0 não sai sem isto". Saiu. A v0.9.0 saiu.

A versão anterior desta nota propunha a dispensa pela terceira vez, e o argumento era este: "esta release não entrega funcionalidade nova a quem usa… nenhuma tela muda debaixo de ninguém". E fechava dizendo, com todas as letras, que a v0.10.0 não teria essa saída.

Esta é a v0.10.0. O argumento da dispensa caiu pela própria frase que o escrevia.

O que existe hoje: a rota /version, que devolve o número puro do mix.exs. É endpoint, não página: serve ao CD, e não a quem usa.

O que está em jogo agora é diferente das três vezes anteriores. Esta release muda a tela de tokens debaixo de quem a usa: quem abrir /api-tokens amanhã vê uma opção de prazo que não existia, um campo obrigatório na revogação que não existia, e um painel novo na linha. Nada na aplicação diz de onde isso veio. A regra nasceu exatamente para este caso, e é a primeira vez em quatro releases que ela está no seu caso.

Não proponho dispensa. Proponho que quem decide o delivery decida isto explicitamente, e que a decisão fique escrita aqui com o nome de quem a tomou. Duas saídas são legítimas — soltar assim mesmo, com a lacuna declarada, ou segurar até a superfície existir —, e uma terceira não é: repetir a palavra "dispensa" pela quarta vez como se fosse o mesmo caso.

O item continua aberto: docs/backlog/a-versao-em-producao-na-pagina.md. Quatro releases, zero cumprimentos. Ou ele entra num sprint com data, ou a regra é revista por quem a estabeleceu.

As lacunas que embarcam declaradas¶

Nenhuma delas é fechada por esta release, e nenhuma deve ser marcada como cumprida por nenhum merge.

Lacuna	Classificação exata	O que falta
revisão independente do desenho da API e da avaliação de segurança	revisão não ocorreu	quatro tentativas por agente falharam em 21 e 22 de setembro — duas travaram, duas foram bloqueadas por ferramenta indisponível. Merge não é revisão, e CI verde não é revisão
o #938 foi mergeado sem revisor sequer pedido	medido: `reviewRequests` e `reviews` vazios	o PR nasce com revisor solicitado à equipe `the-band` e ligado ao projeto. Não foi feito, e o resíduo não se recupera: não se pede revisão de PR mergeado
o #939 foi mergeado sem revisor pedido, e sem a aceitação da tela	medido: `reviewRequests` vazio no momento do merge	era pré-condição escrita para a v0.10.0, e a v0.10.0 é esta. As conferências de QA e Design rodaram depois do merge e acharam 11 reprovações de régua e 9 divergências contra o protótipo. Nenhuma foi aceita nem recusada formalmente
o botão `Copy value` não copia, em produção desde a v0.8.0	medido: `JS.dispatch("the_band:copy")` tem uma ocorrência no repositório, a que dispara	conserto no #941, aberto. Se não entrar, esta release vai ao ar com ele — não é regressão, é o estado de hoje
a guarda do SC-013 media nada	provado por injeção: hash em `data-*`, 84 testes verdes	conserto no #942, aberto. É teste: não muda produção
29 dos 70 itens da régua sem guarda	contado pelo papel de QA	três padrões: a conta do fixture nunca tem elo de pessoa, nenhum teste monta token usado/vencido/de conta desativada, e a tela das seis recusas não tem uma linha de asserção
o token de produção usado nas medições passou por um proxy que intercepta TLS	~~por revogar~~ revogado em 2026-09-24	ato da pessoa mantenedora, declarado por ela e não medido: pela SC-003 um token revogado e um inexistente respondem igual. Enquanto não foi revogado, existia uma credencial de produção que já trafegou por intermediário. Conferido no painel de uso: última leitura em 2026-09-23 19:24, dentro das medições, e nenhuma depois
o 120 do limite é proposta, não medida	declarado em `api.access.thresholds`	não há uso real para medir contra. Quando houver, o número muda em um lugar só
a causa dos dois testes instáveis	desconhecida	seis execuções da suíte não os reproduziram; o item foi rebaixado para baixa, com diagnóstico acrescentado. Raro não é explicado

A do proxy tem ordem de precedência sobre as outras, e por isso fica dita separada: é a única que representa exposição ativa hoje, e a única cujo fechamento não depende de ninguém além de quem mantém.

O que o CD fez — e a pergunta desta release está respondida¶

Execução 35978970522, 2026-09-24 09:04Z, sobre 679c2d7: success.

É a primeira execução verde do CD em três releases. As duas anteriores — v0.8.0 e v0.9.0 — terminaram failure com o deploy funcionando, porque a conferência final comparava o número puro que a rota devolve com o nome da tag, que leva o v.

Medido logo depois, contra a produção:

curl -s https://theband.5.189.161.85.sslip.io/version
0.9.1        · HTTP 200

O conserto está provado. E vale dizer o que essa prova custou em clareza: a recomendação desta nota era soltar só o #938, para que um vermelho tivesse uma causa candidata. A release saiu com quatro — comparação, migração, troca de imagem, tempo de implantação. Deu verde, então a ambiguidade não cobrou nada desta vez; se tivesse dado vermelho, o diagnóstico começaria por eliminação.

O que o verde NÃO prova: que a migração rodou como esperado, que as três mudanças de tela aparecem, e que o botão Copy value — que não copia nada desde a v0.8.0 — continua não copiando. O CD confere a versão, e só.

O que se observou depois¶

A medir, e nesta ordem:

a aceitação em produção — as três mudanças da tela contra a régua, item a item. Ela não aconteceu antes do merge, e era pré-condição escrita;
o botão Copy value, abrindo a tela. É o único defeito desta lista que faz alguém perder uma credencial sem ver um erro;
a coluna state, que imprime "ativo" em português numa tela em inglês;
as duas colunas novas em api_access_tokens, conferindo que a migração passou.