ccfa60c1f2
O sintoma primário da Issue (deadlock do waitForChecks no próprio pending) já tinha sido entregue pelo OPS61. O secundário — o rollup `checks` reportava SUCCESS com um shard de e2e vermelho porque o Forgejo 9.0.3 reporta o resultado do ÚLTIMO shard como o parent de matrix no `needs` (runs 604/607/610; o `needs.<job>.results` do GitHub não existe neste runner) — foi eliminado estruturalmente pelo OPS62 (mergeado durante a execução): ci-pr.yml e ci.yml viraram jobs únicos sequenciais, sem matrix/shard, e o status do job `checks` já é o veredito honesto da cascata. O que este item entrega: (a) teste-pino no waitForChecks (cenário run 607: rollup verde + shard vermelho → o CLI LANÇA "Checks falharam" — nunca confia no rollup sozinho; invariante de defesa válido e que pegaria qualquer matrix que volte); (b) docs honestas (agent-pr-workflow.mdc, AGENT-OPS.md) com a narrativa do parent de matrix e da eliminação estrutural pelo OPS62. O script ci-rollup-check.mjs e os edits de workflow planejados foram descartados no gate (redundantes pós-OPS62). Unit 2392 verdes; gates locais ok.
2 KiB
Recently resolved (2026-08-18): OPS64 — o safety net ready-automerge deixa de se auto-bloquear e o gate do merge fica estruturalmente honesto. O sintoma primário da Issue (deadlock: o waitForChecks contava o próprio status pending do job → timeout 30 min → merge nunca acontecia) já tinha sido entregue pelo OPS61 (filtro do próprio contexto + gate do rollup + PAT; provado vivo: runs 710/712 mergearam os PRs #67/#70). O secundário — o rollup checks reportava SUCCESS com um shard de e2e vermelho porque o Forgejo 9.0.3 reporta o resultado do último shard como o resultado do parent de matrix no contexto needs (runs 604/607/610: e2e (1) vermelho + e2e (2) verde → checks verde; o needs.<job>.results do GitHub não existe neste runner) — foi eliminado estruturalmente pelo OPS62 (mergeado em main durante a execução deste item): o ci-pr.yml e o ci.yml viraram jobs únicos sequenciais (sem matrix, sem shards), então o status do job checks já é o veredito honesto da cascata inteira. Este item entregou o que restava de valor: (a) teste-pino no waitForChecks (forgejoApi.unit.spec.ts, cenário run 607) — o CLI nunca confia no rollup sozinho: varre os statuses individuais e lança "Checks falharam" com rollup verde + shard vermelho (invariante de defesa que continua válido e pegaria qualquer matrix que volte); (b) docs honestas (agent-pr-workflow.mdc, AGENT-OPS.md) registrando o veredito do rollup, o pin do CLI e a eliminação estrutural do bug pelo OPS62. O script ci-rollup-check.mjs e os edits de workflow planejados foram descartados na execução (redundantes pós-OPS62 — decisão do gate com o humano; os workflows em main são os do OPS62, intocados). Sem migration/access/Consent/UI/schema. Verificação: unit 2360 verdes; lint/format/typecheck/knip/cycles no gate local; a própria PR prova o ciclo (o ready-automerge mergea no fim). Impl plan: docs/plans/ops64-forgejo-pr-automerge-waitforchecks-impl.md.