O RUN do builder encadeia gerador de importMap e next build com '&&', mas
prefixos de shell (VAR=x cmd1 && cmd2) valem só para o primeiro comando.
Com o OPS99, NEXT_OUTPUT_STANDALONE=1 e NODE_OPTIONS ficaram presos no
gerador: o next build rodou sem output standalone e o stage runner falhou
no COPY de /app/.next/standalone (run 34701266297, pós-#953 — o #953 já
corrigiu o importmap sem react-server e o falso verde do stale run).
Cada comando passa a declarar seu próprio env, e o guard de invariantes do
Dockerfile em tests/unit/deployScript.unit.spec.ts ganha o pin do escopo
(flags no lado do next build). Inclui post-mortem e changelog.
OPS99 passou a rodar 'pnpm exec payload generate:importmap' no builder do
Dockerfile sem --conditions=react-server; o server-only resolve para o
módulo que lança e TODO build Docker falha — desde a OPS99 (27/08 19:05
UTC) nenhum deploy real aconteceu e a prod ficou no commit 4d6533c04.
Agora o builder chama 'pnpm generate:importmap' (o script dono das flags,
mesmo usado no predev).
O guard de stale run (main avançou durante o verify) fazia 'exit 0' e o
job reportava sucesso sem deployar (run 34675436246); agora falha com
fatal, sem falso verde.
Testes: unit guarda a linha do Dockerfile (script canônico) e os dois
pontos do guard de stale; build standalone de main validado localmente.
- font: espera a família primária (check falhava pela fallback do next/font)
- load de assets/fonte separado do redraw (sem flicker/live-region por tecla)
- pan/zoom com updates funcionais; photoSize memoizado
- foco volta ao tile do catálogo ao fechar (trigger da home desmonta)
- copy de privacidade centralizada; tile deriva dims/cor do modelo
- aria do input de arquivo sem colidir com o botão; +2 unit tests
Home ganha a seção Faça parte com os três modelos e a rota /cards
concentra catálogo + compositor client-side (dialog desktop, bottom
drawer mobile): nome no slot medido do mestre com Brexter 700 e foto
full-bleed sob o overlay oficial (pan/zoom clampados), download PNG
sem conta e sem enviar nome/foto. Núcleo puro em src/lib/card* com
unit tests; e2e cobre home→deep-link, nome→PNG real, erro fail-closed,
foto e drawer mobile. Sem migration/PII.
A fixture B196 'chassis elsewhere' criava 5 atividades com startAt fixo em 2026-09-01. A aba default de /campanha/atividades (proximos) filtra status=confirmado e startAt >= now, então a partir de 02/09 a lista virou empty state, o scrollport perdeu overflow e a assert scrollHeight - clientHeight > 0 falhou nas 3 retries do verify do deploy de 2026-09-11 (run 34652323456), bloqueando o job de deploy.
Deriva o startAt de hoje (+7 dias, tempo civil da Bahia) como os specs de agenda já fazem, dá ao poll do scrollport o orçamento de 30s da classe de latência B196 documentada no arquivo, e adiciona guard ESLint (no-restricted-syntax escopado a tests/e2e) que bane ISO literal em propriedades start*/end*/date* de fixture — pinado em eslintConventions.unit.spec.ts.
Post-mortem do bug-fix com as duas causas-raiz (host fbcdn fora do
allowlist + search:'' do pattern new URL), o pré-requisito do teste de
calendário, a verificação local e as prevenções baratas implementadas e
deferidas.
O calendário abre no mês corrente e os fixtures (e o startAt submetido)
são de agosto/2026: desde 01/09 o teste 'troca dia no calendário' não
encontra o dia 15 de agosto e derruba a suíte unit full — que é o que o
gate e o CI rodam hoje (o wrapper changed cai no full). Relógio fixo no
mês do fixture torna o teste determinístico.
As mídias da Graph API passaram a vir de *.fbcdn.net
(instagram.<pop>.fna.fbcdn.net), host fora do images.remotePatterns — o
otimizador respondia 400 e toda capa do Instagram quebrava. O pattern em
new URL() também pina search:'' e rejeitaria as URLs assinadas mesmo com o
host certo; agora são objetos planos (cdninstagram + fbcdn).
O título do card ganha line-clamp-3 (subtítulo, line-clamp-2) para a
legenda do Instagram não esticar o bento.
Testes: guard unitário do allowlist com URLs assinadas reais casadas pelo
matcher do próprio Next + seam parser→allowlist; e2e com legenda longa no
stub e asserção de -webkit-line-clamp; manifest de e2e afetado passa a
mapear o board de conteúdos para o spec frontend.
- Add logging to readGoogleServiceAccountCredentials for missing/malformed env
- Add logging to runCampaignCalendarSync when sync is skipped
- Add logging to ensureGoogleCalendarPushChannel for channel status/errors
- Add logging to runSyncPass for sync outcomes (only when changes occur)
- Add logging to error catch blocks for better error tracking
- Use payload.logger where available, console.warn for env-only context
- All logs use consistent [GoogleCalendarSync] prefix
- Logging is conditional to reduce noise in production
Fecha o registro do post-mortem: PRs #926/#927/#929, deploy manual verde
(verify 19m + deploy 16m), /admin/login renderizando em produção com 0
erros de console na verificação read-only via browser — confirmação final
do humano pendente. Changelog do desbloqueio estrutural do deploy
(override sharp → binários via npm registry).
Generate the Payload importMap at build time (Dockerfile) and dev time
(predev hook) with dummy S3_* envs, eliminating the class of bugs where
the admin goes blank because the S3ClientUploadHandler entry is missing
(OPS69/OPS72/OPS73).
Changes:
- Dockerfile: add pnpm generate:importmap with dummy S3_* envs before next build
- scripts/predev-importmap.mjs: predev hook that generates importMap if missing or stale
- Delete scripts/check-importmap-s3.mjs (guard no longer needed)
- Delete tests/unit/importMapS3UploadHandler.unit.spec.ts (unit pin no longer needed)
- Remove check-importmap-s3.mjs step from CI workflows
- Add importMap.js to .gitignore (build artifact, not committed)
- Update AGENTS.md with new contract
Closes#928
O pnpm install da camada deps do Dockerfile falha no homeserver porque o
postinstall do sharp@0.32.6 (dependência do @imgly/background-removal-node,
usado só pelo script local resize-images) baixa o libvips de
objects.githubusercontent.com, que não conclui downloads a partir do
homeserver (3 deploys falhos: 'sharp: Installation error: Request timed
out'). O cache do BuildKit já não esconde o problema: o builder prune do
pós-deploy limpa a camada deps a cada deploy bem-sucedido.
O override força o sharp transitivo para 0.34.2 (versão direta do app):
a partir do 0.33 os binários vêm de pacotes do npm registry
(@img/sharp-libvips-*), que o homeserver alcança — o install deixa de
depender de github releases. Lockfile regenerado: sai sharp@0.32.6 e toda
a subárvore prebuild-install (tar-fs, simple-get, bare-*, ...); imgly passa
a resolver sharp 0.34.2 (symlink conferido). Smoke do script
resize-images (import + processamento webp) verde; format/lint/tsc/unit
pin/guard do importMap verdes.
O deploy de fea6c645 falhou 2x: a mudança do script generate:importmap
em package.json invalidou a cache da camada deps do Dockerfile no
homeserver, e o pnpm install re-rodou do zero — o postinstall do
sharp@0.32.6 (transitivo) estourou o timeout baixando o libvips de
objects.githubusercontent.com ('sharp: Installation error: Request
timed out'; o git fetch de github.com funciona — o release vai por
outro hostname da CDN). Produção intocada (falha pré compose swap).
Reverte package.json ao byte do estado cacheado (a9f0c61e) — o install
nem roda. Remove o wrapper generate-importmap.mjs (desligado vira dead
code); proteção do importMap fica com o guard CI+deploy + pin unit +
contrato. Hardening do deps documentado no post-mortem (retry do
install / libvips via apk / proxy), changelog do follow-up incluído.
O importMap commitado perdeu a entrada do handler S3 no 1c865bd8
(regenerado sem as envs S3_*): com S3_* em prod, getFromImportMap
retorna undefined e a raiz do Payload não monta — tela branca, zero
erros de console, invisível no loop local (storage local em dev/test).
Fix da causa: regeneração com S3_* dummy (+2 linhas). Prevenção no
mesmo PR — o guard planejado no OPS69 (depends #77/#87) que nunca
existiu: pin unit, guard CI+deploy que regenera com envs dummy e falha
em divergência, wrapper do generate:importmap que injeta as envs, e
contrato compartilhado da chave. Post-mortem + changelog incluídos.
O dispatch manual do C139 montava new FormData(form) sem o submitter;
os botões de transição (name=status value=aprovada|rejeitada|…) nunca
viajavam e transitionDemandFormAction rejeitava toda decisão por status
vazio. submitterFrom (cast honesto nativeEvent as SubmitEvent) + segundo
arg do construtor nos handlers de transição e custo; C139 intacto.
Teste unit novo pina o glue FormData→status (SubmitEvent real, não
fireEvent.submit). E2e 'advisor opens a demand and decides it' verde
local (isolado e em runs de arquivo inteiro).
