fix(ci): bot marca `pronto-pra-merge` em vez de mergear sozinho by rubenmarcus · Pull Request #412 · corosolto/client

rubenmarcus · 2026-08-21T23:10:29Z

Empilhado sobre o #411 (fase 3) → #409 (fase 2) → #408 (fase 1). Última das quatro.

Summary

o passo que chamava gh pr merge --squash --auto passa a aplicar a etiqueta pronto-pra-merge e comentar por que o PR está pronto;
a etiqueta sai quando o PR deixa de ser elegível, para não virar carimbo velho;
régua AF4: nenhum workflow do repositório pode chamar gh pr merge.

Evidência

A intenção declarada dos bots é autocorreção e autorrevisão para deixar o PR pronto — não fechar o assunto. Mas o csbrasil-bot-automerge fazia exatamente isto:

subprocess.run(['gh', 'pr', 'merge', os.environ['PR_NUMBER'],
                '--squash', '--delete-branch', '--auto'], check=True)

E era a única coisa que um bot deste repositório fazia sozinho — nos 29 PRs auditados nenhum bot jamais commitou um conserto. A capacidade que faltava não existia; a que sobrava era a de fechar o assunto sem ninguém olhar.

A AF4 ignora linha de comentário de propósito, para que o comentário que explica por que a chamada saiu possa citá-la. O mutante automerge-volta recoloca a chamada e reprova.

Fora do alcance deste repositório

O Esbirro repetiu o mesmo alerta de bundle-em-dia a cada 30 minutos por 17 horas na issue #393 sem nunca agir — a versão citada mudou de alpha.163 para alpha.172 no meio, ou seja, o incidente mudou e o alerta não. Ele vive em game3/bots/vigia-prod/plantao.mjs, outro repositório. Dar ação a ele (disparar o purge de edge que o prod-watch já sabe fazer, em vez de comentar de novo) é trabalho de lá.

Risk

low - docs/tooling/text only
medium - UI/site/runtime path touched
high - gameplay/render/backend/anti-cheat touched

Tira uma capacidade do bot, não adiciona. Nenhum arquivo do jogo.

Validation

npm run check:fast - 60/60
eval:autofix com AF4 + o mutante automerge-volta
ensure_labels.py --selftest com a etiqueta nova
YAML valida

Limite declarado

Não mexe no check_automerge.py — o critério de elegibilidade continua o mesmo; só o que se faz com a resposta mudou.

Bot notes

ok to label safe-automerge
needs needs-staging
needs needs-human-gameplay
needs needs-human-backend

🤖 Generated with Claude Code

A intenção declarada dos bots é autocorreção e autorrevisão para deixar o PR PRONTO - não fechar o assunto. Só que o `csbrasil-bot-automerge` chamava `gh pr merge --squash --delete-branch --auto`, e era a ÚNICA coisa que um bot deste repositório fazia sozinho: justamente a que não devia. O passo agora aplica a etiqueta `pronto-pra-merge` e comenta por que o PR está pronto. Quando o PR deixa de ser elegível, a etiqueta sai - senão ela vira um carimbo velho que ninguém confere. O botão de merge continua humano. A AF4 estende a régua do autofix para o repositório inteiro: nenhum workflow pode chamar `gh pr merge`. Ela ignora linha de comentário de propósito, para que o comentário que explica por que a chamada saiu possa citá-la. O mutante `automerge-volta` recoloca a chamada e reprova. Fora do alcance deste repositório: o Esbirro, que repetiu o mesmo alerta de `bundle-em-dia` a cada 30 minutos por 17 horas na issue #393 sem nunca agir, vive em `game3/bots/vigia-prod/plantao.mjs`. Dar ação a ele é trabalho de lá. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Agent: Claude Code

vercel · 2026-08-21T23:10:35Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
csbrasil	Ready	Preview	Aug 21, 2026 11:11pm

csbrasil-BOT · 2026-08-21T23:10:49Z

csbrasil-bot classification

Note

@rubenmarcus abriu 3 arquivo(s) · +37 −4, base feat/autofix-com-lista-de-permissao.

O que mudou

área	arquivos	+	−	amostra
🤖 CI	2	+17	−3	`csbrasil-bot-automerge.yml`, `ensure_labels.py`
🧪 arnês	1	+20	−1	`autofix-check.mjs`

Labels

label	por quê
`target:main`	vai direto pra `main`, sem fila de integração

estraga-codigo

Palhaço Mal · revisor da casa · 🤡

mapa da mudança

CI (2): csbrasil-bot-automerge.yml, ensure_labels.py
arnês (1): autofix-check.mjs

Tip

Risco BAIXO · nota 10/10 ▓▓▓▓▓▓▓▓▓▓

nada aqui que quebre amanhã. amanhã é outro diff

Revisão de bot — fio não resolvido TRAVA o merge (a main exige conversa resolvida). Resolve ou refuta.

— maquiagem de verde por cima de vermelho eu desenmascaro no primeiro golpe de vista 🤡

…ergear (#411) * feat(ci): autofix conserta o mecânico, com lista de permissão e sem mergear MEDIDO nos últimos 29 PRs: nenhum bot deste repositório jamais commitou um conserto. Quem conserta é sempre uma pessoa. O #405 está vermelho por `DOCS1: documentação DESATUALIZADA`, cujo conserto é `npm run docs` mais um commit - trabalho sem julgamento nenhum que hoje devolve o PR para o autor. O autofix roda em `pull_request_target`, o único gatilho que enxerga secret em PR de fork (é a mesma regra que a WSEC1 passou a guardar), regenera os blocos derivados e empurra o commit. A TRAVA é o que torna isso aceitável: `autofix_allowlist.py` só libera arquivo GERADO, e o commit sai da saída dela - nunca de um `git add -A`. Encostou em qualquer outro caminho, o bot aborta e comenta. Sem a lista, o primeiro conserto errado reescreve o mapa de um colaborador e ninguém repara; com ela, o pior caso é regenerar uma doc que já era derivada. `.github/` está entre os PROIBIDOS de propósito: um bot que edita o workflow que o governa amplia a própria permissão num commit. E as ferramentas que rodam são restauradas da BASE antes de executar - PR nenhum reescreve o gerador e faz o bot executar o que ele mandar. Duas saídas sem push, porque vermelho que o autor não entende é o dano que este trabalho inteiro está atacando: fork com "allow edits by maintainers" desligado recebe o comando por comentário, e sem `CSBRASIL_BOT_TOKEN` o job avisa e sai verde em vez de reprovar. A régua AF1/AF2/AF3 guarda as três condições - escrita só depois da trava, lista sem caminho de código, e o bot NÃO mergeia (deixar pronto e fechar são coisas diferentes). Os quatro mutantes mordem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Agent: Claude Code * fix(ci): bot marca `pronto-pra-merge` em vez de mergear sozinho (#412) A intenção declarada dos bots é autocorreção e autorrevisão para deixar o PR PRONTO - não fechar o assunto. Só que o `csbrasil-bot-automerge` chamava `gh pr merge --squash --delete-branch --auto`, e era a ÚNICA coisa que um bot deste repositório fazia sozinho: justamente a que não devia. O passo agora aplica a etiqueta `pronto-pra-merge` e comenta por que o PR está pronto. Quando o PR deixa de ser elegível, a etiqueta sai - senão ela vira um carimbo velho que ninguém confere. O botão de merge continua humano. A AF4 estende a régua do autofix para o repositório inteiro: nenhum workflow pode chamar `gh pr merge`. Ela ignora linha de comentário de propósito, para que o comentário que explica por que a chamada saiu possa citá-la. O mutante `automerge-volta` recoloca a chamada e reprova. Fora do alcance deste repositório: o Esbirro, que repetiu o mesmo alerta de `bundle-em-dia` a cada 30 minutos por 17 horas na issue #393 sem nunca agir, vive em `game3/bots/vigia-prod/plantao.mjs`. Dar ação a ele é trabalho de lá. Agent: Claude Code Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

* fix(ci): quem bloqueia o PR é o build do CI, não a Vercel MEDIDO nos últimos 29 PRs: a Vercel reprovou 13 dos 14 PRs vindos de fork, sempre com `Authorization required to deploy.` - proteção de fork da própria Vercel, que nenhum commit do colaborador resolve. Nos PRs de casa o vermelho era build de verdade, uma vez porque o `fetch-decals.sh` não baixou o acervo (196 de 197 decalques faltando) num soluço de rede. O `ci.yml` já constrói o site em `pull_request`: o portão que importa existe e é esse. A régua nova guarda as três condições que deixam a Vercel sair do caminho crítico sem perder cobertura: DG1 o CI constrói no PR - sem isso, tirar a Vercel do bloqueio deixaria o PR sem nenhuma prova de que o site compila; DG2 nenhum `curl` do caminho do build corre sem `--retry`. `set -e` mais curl sem retry transforma soluço de rede em PR vermelho, e o autor não tem o que consertar - mesmo dano do portão que não pode medir; DG3 a etiqueta que autoriza o preview de fork é criada por quem depende dela. A DG3 achou código morto: o job `preview` do preview-bot já sabe publicar pela CLI da Vercel depois de conferir permissão do ator e SHA aprovado, mas dispara em `labeled` com `preview-autorizado` - e essa etiqueta NUNCA existiu no repositório. O bot pedia um rótulo que ninguém tinha como aplicar. Agora o próprio workflow a cria. Os dois ajustes que sobram são de painel da Vercel e não cabem no repositório; ficaram escritos no PROD-READINESS.md, com o que medir. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Agent: Claude Code * feat(ci): autofix conserta o mecânico, com lista de permissão e sem mergear (#411) * feat(ci): autofix conserta o mecânico, com lista de permissão e sem mergear MEDIDO nos últimos 29 PRs: nenhum bot deste repositório jamais commitou um conserto. Quem conserta é sempre uma pessoa. O #405 está vermelho por `DOCS1: documentação DESATUALIZADA`, cujo conserto é `npm run docs` mais um commit - trabalho sem julgamento nenhum que hoje devolve o PR para o autor. O autofix roda em `pull_request_target`, o único gatilho que enxerga secret em PR de fork (é a mesma regra que a WSEC1 passou a guardar), regenera os blocos derivados e empurra o commit. A TRAVA é o que torna isso aceitável: `autofix_allowlist.py` só libera arquivo GERADO, e o commit sai da saída dela - nunca de um `git add -A`. Encostou em qualquer outro caminho, o bot aborta e comenta. Sem a lista, o primeiro conserto errado reescreve o mapa de um colaborador e ninguém repara; com ela, o pior caso é regenerar uma doc que já era derivada. `.github/` está entre os PROIBIDOS de propósito: um bot que edita o workflow que o governa amplia a própria permissão num commit. E as ferramentas que rodam são restauradas da BASE antes de executar - PR nenhum reescreve o gerador e faz o bot executar o que ele mandar. Duas saídas sem push, porque vermelho que o autor não entende é o dano que este trabalho inteiro está atacando: fork com "allow edits by maintainers" desligado recebe o comando por comentário, e sem `CSBRASIL_BOT_TOKEN` o job avisa e sai verde em vez de reprovar. A régua AF1/AF2/AF3 guarda as três condições - escrita só depois da trava, lista sem caminho de código, e o bot NÃO mergeia (deixar pronto e fechar são coisas diferentes). Os quatro mutantes mordem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Agent: Claude Code * fix(ci): bot marca `pronto-pra-merge` em vez de mergear sozinho (#412) A intenção declarada dos bots é autocorreção e autorrevisão para deixar o PR PRONTO - não fechar o assunto. Só que o `csbrasil-bot-automerge` chamava `gh pr merge --squash --delete-branch --auto`, e era a ÚNICA coisa que um bot deste repositório fazia sozinho: justamente a que não devia. O passo agora aplica a etiqueta `pronto-pra-merge` e comenta por que o PR está pronto. Quando o PR deixa de ser elegível, a etiqueta sai - senão ela vira um carimbo velho que ninguém confere. O botão de merge continua humano. A AF4 estende a régua do autofix para o repositório inteiro: nenhum workflow pode chamar `gh pr merge`. Ela ignora linha de comentário de propósito, para que o comentário que explica por que a chamada saiu possa citá-la. O mutante `automerge-volta` recoloca a chamada e reprova. Fora do alcance deste repositório: o Esbirro, que repetiu o mesmo alerta de `bundle-em-dia` a cada 30 minutos por 17 horas na issue #393 sem nunca agir, vive em `game3/bots/vigia-prod/plantao.mjs`. Dar ação a ele é trabalho de lá. Agent: Claude Code Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

… pode ter (#408) * fix(ci): classify não reprova PR de fork por secret que o gatilho não pode ter MEDIDO nos últimos 29 PRs: `classify` vermelho em 11 dos 14 vindos de FORK e em 0 dos 15 de casa. A causa não era o código de ninguém. Num PR de fork, os gatilhos `pull_request_review` e `pull_request_review_comment` rodam SEM os secrets do repositório - regra do GitHub - e o guard de identidade saía com erro. A prova é o mesmo PR, o mesmo commit, dois runs: `pull_request_target` fecha em 22s com sucesso e aplica o rótulo; `pull_request_review` morre em 4s com `GH_TOKEN` vazio. O rótulo estava certo o tempo todo; o vermelho que o colaborador via era de um run que nunca teve chance. Mesma regra que o #402 deu ao portão de autoria em clone raso: portão que não pode medir não vota. O job ganha um `if:` que o restringe aos gatilhos que enxergam secret. Para não perder o motivo pelo qual os gatilhos de review existem - reclassificar DEPOIS que o CodeRabbit comenta, o defeito da #240 - entra um sweep de meia em meia hora que roda no contexto base e reclassifica os PRs abertos por `workflow_dispatch`, caminho que tem token. O classify já dedupe rótulo e comentário, então repetir não polui o PR. A régua nova (WSEC1) varre os 14 workflows e reprova a combinação que causou isto: guard de secret junto de gatilho cego, sem `if:` que exclua o caso de fork. Os dois mutantes mordem - tirar o `if:` do classify e pôr um gatilho cego no preview-bot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Agent: Claude Code * fix(ci): quem bloqueia o PR é o build do CI, não a Vercel (#409) * fix(ci): quem bloqueia o PR é o build do CI, não a Vercel MEDIDO nos últimos 29 PRs: a Vercel reprovou 13 dos 14 PRs vindos de fork, sempre com `Authorization required to deploy.` - proteção de fork da própria Vercel, que nenhum commit do colaborador resolve. Nos PRs de casa o vermelho era build de verdade, uma vez porque o `fetch-decals.sh` não baixou o acervo (196 de 197 decalques faltando) num soluço de rede. O `ci.yml` já constrói o site em `pull_request`: o portão que importa existe e é esse. A régua nova guarda as três condições que deixam a Vercel sair do caminho crítico sem perder cobertura: DG1 o CI constrói no PR - sem isso, tirar a Vercel do bloqueio deixaria o PR sem nenhuma prova de que o site compila; DG2 nenhum `curl` do caminho do build corre sem `--retry`. `set -e` mais curl sem retry transforma soluço de rede em PR vermelho, e o autor não tem o que consertar - mesmo dano do portão que não pode medir; DG3 a etiqueta que autoriza o preview de fork é criada por quem depende dela. A DG3 achou código morto: o job `preview` do preview-bot já sabe publicar pela CLI da Vercel depois de conferir permissão do ator e SHA aprovado, mas dispara em `labeled` com `preview-autorizado` - e essa etiqueta NUNCA existiu no repositório. O bot pedia um rótulo que ninguém tinha como aplicar. Agora o próprio workflow a cria. Os dois ajustes que sobram são de painel da Vercel e não cabem no repositório; ficaram escritos no PROD-READINESS.md, com o que medir. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Agent: Claude Code * feat(ci): autofix conserta o mecânico, com lista de permissão e sem mergear (#411) * feat(ci): autofix conserta o mecânico, com lista de permissão e sem mergear MEDIDO nos últimos 29 PRs: nenhum bot deste repositório jamais commitou um conserto. Quem conserta é sempre uma pessoa. O #405 está vermelho por `DOCS1: documentação DESATUALIZADA`, cujo conserto é `npm run docs` mais um commit - trabalho sem julgamento nenhum que hoje devolve o PR para o autor. O autofix roda em `pull_request_target`, o único gatilho que enxerga secret em PR de fork (é a mesma regra que a WSEC1 passou a guardar), regenera os blocos derivados e empurra o commit. A TRAVA é o que torna isso aceitável: `autofix_allowlist.py` só libera arquivo GERADO, e o commit sai da saída dela - nunca de um `git add -A`. Encostou em qualquer outro caminho, o bot aborta e comenta. Sem a lista, o primeiro conserto errado reescreve o mapa de um colaborador e ninguém repara; com ela, o pior caso é regenerar uma doc que já era derivada. `.github/` está entre os PROIBIDOS de propósito: um bot que edita o workflow que o governa amplia a própria permissão num commit. E as ferramentas que rodam são restauradas da BASE antes de executar - PR nenhum reescreve o gerador e faz o bot executar o que ele mandar. Duas saídas sem push, porque vermelho que o autor não entende é o dano que este trabalho inteiro está atacando: fork com "allow edits by maintainers" desligado recebe o comando por comentário, e sem `CSBRASIL_BOT_TOKEN` o job avisa e sai verde em vez de reprovar. A régua AF1/AF2/AF3 guarda as três condições - escrita só depois da trava, lista sem caminho de código, e o bot NÃO mergeia (deixar pronto e fechar são coisas diferentes). Os quatro mutantes mordem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Agent: Claude Code * fix(ci): bot marca `pronto-pra-merge` em vez de mergear sozinho (#412) A intenção declarada dos bots é autocorreção e autorrevisão para deixar o PR PRONTO - não fechar o assunto. Só que o `csbrasil-bot-automerge` chamava `gh pr merge --squash --delete-branch --auto`, e era a ÚNICA coisa que um bot deste repositório fazia sozinho: justamente a que não devia. O passo agora aplica a etiqueta `pronto-pra-merge` e comenta por que o PR está pronto. Quando o PR deixa de ser elegível, a etiqueta sai - senão ela vira um carimbo velho que ninguém confere. O botão de merge continua humano. A AF4 estende a régua do autofix para o repositório inteiro: nenhum workflow pode chamar `gh pr merge`. Ela ignora linha de comentário de propósito, para que o comentário que explica por que a chamada saiu possa citá-la. O mutante `automerge-volta` recoloca a chamada e reprova. Fora do alcance deste repositório: o Esbirro, que repetiu o mesmo alerta de `bundle-em-dia` a cada 30 minutos por 17 horas na issue #393 sem nunca agir, vive em `game3/bots/vigia-prod/plantao.mjs`. Dar ação a ele é trabalho de lá. Agent: Claude Code Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> --------- Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> * Merge da main (alpha.175) na pilha de CI, e liga o que ela citava sem definir Dos 8 arquivos em conflito, 7 eram gerados. O único de verdade era o package.json - e ele quase me pegou: resolvendo pela linha do `check:`, fiquei com a lista de um lado e PERDI as DEFINIÇÕES do outro. `eval:wfsecret`, `eval:deploygate` e `eval:autofix` viraram nome órfão de uma vez. Um nome órfão mata o npm em "missing script" e TODOS os passos depois dele param de rodar - o portão pararia no meio sem ninguém perceber. Foi o segundo caso do dia: o #372 citava `eval:gelo` no `check:fast` sem nunca ter definido o script, com a régua existindo em disco e desligada. Conflito de `package.json` é o mais comum que existe aqui, porque todo PR que acrescenta régua mexe na mesma linha - então isto vai se repetir. Daí a PI: todo passo citado nos dois portões tem de estar definido (PI1) e toda régua tem de apontar para arquivo que existe (PI2). 97 citações conferidas. Os dois mutantes mordem, e ela reprova o #372 de verdade, não só o caso sintético. As três réguas desta pilha também receberam o padrão do #416, que entrou na main depois delas: prova que não morde é vermelho, não aviso. Agent: Claude Opus 5 (Claude Code) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Commit-grande: merge da main na pilha de CI — 21 dos 24 arquivos são bloco gerado re-derivado Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> --------- Signed-off-by: rubenmarcus <rubenmarcus.dev@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

csbrasil-BOT assigned rubenmarcus Aug 21, 2026

csbrasil-BOT added the target:main PR apontando para a branch main label Aug 21, 2026

vercel Bot deployed to Preview August 21, 2026 23:11 View deployment

estraga-codigo reviewed Aug 21, 2026

View reviewed changes

rubenmarcus merged commit 3fcb9bf into feat/autofix-com-lista-de-permissao Aug 21, 2026
16 checks passed

rubenmarcus mentioned this pull request Aug 21, 2026

feat(ci): autofix resolve conflito de arquivo gerado e para no de código #414

Merged

11 tasks

Navigation Menu

Uh oh!

fix(ci): bot marca `pronto-pra-merge` em vez de mergear sozinho - #412

fix(ci): bot marca `pronto-pra-merge` em vez de mergear sozinho#412
rubenmarcus merged 1 commit into
feat/autofix-com-lista-de-permissaofrom
fix/deixar-pronto-nao-e-mergear

rubenmarcus commented Aug 21, 2026

Uh oh!

vercel Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

csbrasil-BOT commented Aug 21, 2026 •

edited

Loading

Uh oh!

estraga-codigo left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

rubenmarcus commented Aug 21, 2026

Summary

Evidência

Fora do alcance deste repositório

Risk

Validation

Limite declarado

Bot notes

Uh oh!

vercel Bot commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

csbrasil-BOT commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

csbrasil-bot classification

O que mudou

Labels

Uh oh!

estraga-codigo left a comment

Choose a reason for hiding this comment

mapa da mudança

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vercel Bot commented Aug 21, 2026 •

edited

Loading

csbrasil-BOT commented Aug 21, 2026 •

edited

Loading