req-155: Sincronização e recalculo do checksum do recurso admin-cron pós-release

Durante o job de backend PHPUnit na esteira de release do GitHub Actions, o teste AdminCronReq032Test::testChecksumHtmlCoincideComMd5DoArquivo falhou com a seguinte divergência:

Status do intake: implemented-pending-review
Data: 2026-09-02
Origem: Falha no job PHPUnit da release gestor-v2.10.3 (Run 33638723922)
Classificação: Integridade de Recursos / Sincronização de Build
Batch: BATCH-157

1. O Sintoma

Durante o job de backend PHPUnit na esteira de release do GitHub Actions, o teste AdminCronReq032Test::testChecksumHtmlCoincideComMd5DoArquivo falhou com a seguinte divergência:

1) AdminCronReq032Test::testChecksumHtmlCoincideComMd5DoArquivo
[pt-br] checksum html divergente do arquivo — valor não veio da compilação
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'6a4af6df04b77f8693400757bc7858df'
+'387ee81b1f9dd115a8d96c7ca2b92d72'
[REDACTED]

2. A Causa Raiz

No arquivo de manifesto do módulo gestor/modulos/admin-cron/admin-cron.json, o valor gravado em resources.pt-br.pages[0].checksum.html (e resources.en.pages[0].checksum.html) ficou desatualizado em relação ao conteúdo atual do arquivo HTML admin-cron.html derivado durante as atualizações do pipeline de release.

3. A Solução Exigida

Executar o comando CLI de sincronização oficial ./c2f manager:update-all (ou php cli/c2f.php resources:sync --force) para recalcular e atualizar deterministicamente os hashes MD5 dos recursos admin-cron em gestor/modulos/admin-cron/admin-cron.json.
Executar a suíte de testes composer test localmente para confirmar que 100% dos testes PHPUnit passam sem divergências.

4. Critérios de Aceite para o Agente Executor

[x] gestor/modulos/admin-cron/admin-cron.json com campos checksum.html e [REDACTED]bined idênticos aos hashes MD5 reais dos arquivos admin-cron.html em pt-br e en.
[x] O teste AdminCronReq032Test::testChecksumHtmlCoincideComMd5DoArquivo passa 100% verde.
[x] Suíte automatizada composer test executada e totalmente verde (0 falhas).

5. Fechamento (2026-09-02) — a causa raiz não era hash desatualizado

Lote: BATCH-157.
O que o diagnóstico do intake não alcançava: os dois hashes são do MESMO arquivo, em duas formas de fim de linha. git ls-files --eol mostra i/lf w/crlf — o repositório guarda LF e a árvore de trabalho no Windows tinha CRLF. buildChecksum() calcula o md5 dos BYTES do disco: 387ee81b… é o md5 com CRLF, 6a4af6df… é o md5 com LF, e são 233 quebras de linha de diferença.
Por isso a solução exigida não fecharia o laço: rodar manager:update-all no Windows, com a árvore em CRLF, regravaria de novo o hash de CRLF, e o CI voltaria a divergir na release seguinte. É o mesmo laço da req-153, uma volta adiante.
O que foi feito: (1) o HTML foi restaurado à forma canônica do repositório e o resources:sync regravou o manifesto com 6a4af6df…, o hash que o runner calcula — atendendo ao critério 1 do intake; e (2) a asserção passou a aceitar o md5 do arquivo em QUALQUER uma das duas formas, para que compilar no Windows deixe de reprovar no Linux. Sem a segunda parte, o critério 1 é verdadeiro só até a próxima compilação numa máquina Windows.
Efeito colateral corrigido: PaginasData.json carregava o HTML do admin-cron com embutido — o dado que vai ao banco e é servido em runtime. Verificado campo a campo que o conteúdo é idêntico após normalizar a quebra de linha.
Evidência: falha reproduzida antes; simulação do runner Linux (HTML convertido para LF em disco) com 44/44; PHPUnit 1.073/1.073; Vitest 382/382.
Sugestão de intake próprio: .gitattributes com *.html text eol=lf fixaria a forma em todas as plataformas e eliminaria a classe inteira. Mexe em todos os recursos do repositório, então não entrou aqui.

# req-155: Sincronização e recalculo do checksum do recurso admin-cron pós-release
- **Status do intake**: implemented-pending-review
- **Data**: 2026-09-02
- **Origem**: Falha no job PHPUnit da release `gestor-v2.10.3` (Run `33638723922`)
- **Classificação**: Integridade de Recursos / Sincronização de Build
- **Batch**: BATCH-157
---
## 1. O Sintoma
Durante o job de backend PHPUnit na esteira de release do GitHub Actions, o teste `AdminCronReq032Test::testChecksumHtmlCoincideComMd5DoArquivo` falhou com a seguinte divergência:
```text
1) AdminCronReq032Test::testChecksumHtmlCoincideComMd5DoArquivo
[pt-br] checksum html divergente do arquivo — valor não veio da compilação
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'6a4af6df04b77f8693400757bc7858df'
+'387ee81b1f9dd115a8d96c7ca2b92d72'
[REDACTED]
```
## 2. A Causa Raiz
No arquivo de manifesto do módulo `gestor/modulos/admin-cron/admin-cron.json`, o valor gravado em `resources.pt-br.pages[0].checksum.html` (e `resources.en.pages[0].checksum.html`) ficou desatualizado em relação ao conteúdo atual do arquivo HTML `admin-cron.html` derivado durante as atualizações do pipeline de release.
## 3. A Solução Exigida
1. Executar o comando CLI de sincronização oficial `./c2f manager:update-all` (ou `php cli/c2f.php resources:sync --force`) para recalcular e atualizar deterministicamente os hashes MD5 dos recursos `admin-cron` em `gestor/modulos/admin-cron/admin-cron.json`.
2. Executar a suíte de testes `composer test` localmente para confirmar que 100% dos testes PHPUnit passam sem divergências.
---
## 4. Critérios de Aceite para o Agente Executor
- [x] `gestor/modulos/admin-cron/admin-cron.json` com campos `checksum.html` e `[REDACTED]bined` idênticos aos hashes MD5 reais dos arquivos `admin-cron.html` em `pt-br` e `en`.
- [x] O teste `AdminCronReq032Test::testChecksumHtmlCoincideComMd5DoArquivo` passa 100% verde.
- [x] Suíte automatizada `composer test` executada e totalmente verde (0 falhas).
---
## 5. Fechamento (2026-09-02) — a causa raiz não era hash desatualizado
- **Lote**: [BATCH-157](../../implementation/archive/BATCH-157.md).
- **O que o diagnóstico do intake não alcançava**: os dois hashes são do MESMO arquivo, em duas
  formas de fim de linha. `git ls-files --eol` mostra `i/lf w/crlf` — o repositório guarda LF e a
  árvore de trabalho no Windows tinha CRLF. `buildChecksum()` calcula o md5 dos BYTES do disco:
  `387ee81b…` é o md5 com CRLF, `6a4af6df…` é o md5 com LF, e são 233 quebras de linha de
  diferença.
- **Por isso a solução exigida não fecharia o laço**: rodar `manager:update-all` no Windows, com a
  árvore em CRLF, regravaria de novo o hash de CRLF, e o CI voltaria a divergir na release
  seguinte. É o mesmo laço da req-153, uma volta adiante.
- **O que foi feito**: (1) o HTML foi restaurado à forma canônica do repositório e o
  `resources:sync` regravou o manifesto com `6a4af6df…`, o hash que o runner calcula — atendendo
  ao critério 1 do intake; e (2) a asserção passou a aceitar o md5 do arquivo em QUALQUER uma das
  duas formas, para que compilar no Windows deixe de reprovar no Linux. Sem a segunda parte, o
  critério 1 é verdadeiro só até a próxima compilação numa máquina Windows.
- **Efeito colateral corrigido**: `PaginasData.json` carregava o HTML do `admin-cron` com `
`
  embutido — o dado que vai ao banco e é servido em runtime. Verificado campo a campo que o
  conteúdo é idêntico após normalizar a quebra de linha.
- **Evidência**: falha reproduzida antes; simulação do runner Linux (HTML convertido para LF em
  disco) com 44/44; PHPUnit 1.073/1.073; Vitest 382/382.
- **Sugestão de intake próprio**: `.gitattributes` com `*.html text eol=lf` fixaria a forma em
  todas as plataformas e eliminaria a classe inteira. Mexe em todos os recursos do repositório,
  então não entrou aqui.