From 6cd00f479756737c306a3548dfb790c79032eee4 Mon Sep 17 00:00:00 2001 From: Francisco Solla Date: Tue, 18 Aug 2026 11:29:22 -0300 Subject: [PATCH] =?UTF-8?q?plan(OPS58):=20atualizar=20artigos=20de=20produ?= =?UTF-8?q?=C3=A7=C3=A3o=20com=20novos=20posts=20do=20jorgesolla.com.br?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/plans/ops58-sincronizar-posts-prod.md | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 docs/plans/ops58-sincronizar-posts-prod.md diff --git a/docs/plans/ops58-sincronizar-posts-prod.md b/docs/plans/ops58-sincronizar-posts-prod.md new file mode 100644 index 00000000..b3d704d1 --- /dev/null +++ b/docs/plans/ops58-sincronizar-posts-prod.md @@ -0,0 +1,72 @@ +# OPS58 — Atualizar artigos de produção com os novos posts do jorgesolla.com.br + +Status: planejado +Atualizado em: 2026-08-18 +Issue: #43 +Priority: P1 +Model: composer-2.5 +Impeccable: A — N/A (sem mudança de UI; conteúdo/operação) +Rascunho UI: N/A — sem UI +Appetite: ~0,5 dia (execução no homeserver + runbook) +Responsável: — + +## Intenção + +O site em produção (jorgesolla1313.com.br, homeserver) não reflete os artigos novos publicados no site original jorgesolla.com.br (WordPress). O seed `pnpm db:seed:posts` já existe e é idempotente por slug, mas só foi executado contra bancos locais — o DB de produção nunca recebeu uma rodada. Resultado visível: a home "Últimas notícias", `/artigos`, as páginas de artigo e a seção "Acompanhe de perto" da home de campanha (S1) ficam congelados no lote antigo, em plena janela eleitoral. + +O item roda o sync de posts em produção (uma vez, com runbook documentado) — não constrói ferramenta nova: a ferramenta existe, a execução em prod é que nunca foi feita nem registrada. + +## Persona e fluxo + +- **Persona / contexto:** equipe do mandato/campanha que publica no WordPress original e espera o mesmo conteúdo no site da campanha, sem recadastro manual artigo a artigo. +- **Job principal:** ver os artigos novos do jorgesolla.com.br aparecerem em jorgesolla1313.com.br com capas carregando. +- **Fluxo desejado:** artigo publicado no WP → alguém roda o sync (runbook) → posts novos criados (idempotente por slug, sem duplicar) → capas servidas do bucket → cache `posts` bustado → home/artigos/seção de campanha atualizados. +- **Anti-goals de produto:** não virar sync bidirecional nem replicador de edits; não tocar PII; não alterar contrato público de URL (`/[type]/[category]/[slug]`, `/api/media/file/...`); não sobrescrever posts existentes. + +## Objetivo e aceite + +- Todos os artigos do jorgesolla.com.br ainda ausentes em produção são criados como notícias publicadas; os já existentes permanecem intocados (sem duplicata). +- As capas dos artigos novos carregam (200 em `/api/media/file/...` — objeto no bucket de prod, não disco local). +- Após o bust de cache, as páginas públicas (home, `/artigos`, artigo, seção de campanha) exibem os artigos novos. +- O procedimento fica documentado como runbook (pre-flight → execução → verificação), no padrão do OPS52-media, para a próxima execução ser cópia-e-cola. +- Guardrails de produto: execução no homeserver com o env do stack (`S3_*` de prod → capas caem no bucket certo); `ALLOW_REMOTE_DB=true` explícito (fail-closed mantido); seed create-only — nunca edita/sobrescreve conteúdo existente. + +## Dados (intenção) + +- **Vou apresentar dados?** Não — o item sincroniza conteúdo editorial; não há métrica ou KPI novo na superfície. +- Contagem de artigos criados/ignorados é relatório operacional do runbook (verificação de execução), não dado de produto. + +## Direção no codebase (hipótese) + +- **Áreas prováveis:** `scripts/seed-posts.mjs` (existe — fetch ao vivo do WP, taxonomy hardcoded, idempotente por slug, guard local com `ALLOW_REMOTE_DB=true`, upload de capa pelo storage configurado) e `scripts/lib/wpArticles.mjs`; endpoint `POST /api/revalidate?tag=posts` (`REVALIDATE_SECRET`) para o bust de cache; homeserver (`~/stack/teqo-1313.env`, rede do compose). +- **Precedente a olhar:** `docs/plans/ops52-media-recuperar-arquivos-impl.md` — mesmo padrão de execução no homeserver (env do stack, `ALLOW_REMOTE_DB=true`, pre-flight → exec → verify; firewall/extra_hosts já resolvidos na OPS52-media). +- **Risco de acoplamento:** o Postgres de prod não é exposto ao host (E4 da OPS52-media) — o seed roda **no homeserver**, dentro da rede do compose, não da workstation. Rodar contra o DB de prod sem as `S3_*` de prod criaria capas no disco local e quebraria 500 em produção: o ambiente do stack é obrigatório, não opcional. + +## Dependências + +- Nenhuma dura. Precedente suave: OPS52-media (executada em 2026-08-18 — capas e conectividade container→Garage resolvidas). + +## Fora de escopo + +- **Automação agendada do sync** (cron/Action) — decisão futura quando a frequência de publicação justificar. +- **Propagar edits do WordPress** para posts já seedados — o seed é create-only; atualização de conteúdo é item separado. +- **Expandir a taxonomy hardcoded** (`CLASSIFICATION` no seed) — manutenção contínua; slugs novos caem em `politica` com warning registrado no runbook. +- **Imagens inline do corpo** — por contrato do seed, só a capa vira media; corpo é texto/links. + +## Rabbit holes de produto + +- **"Sync completo (upsert)".** Se alguém "só completar" o seed para refletir edits do WP, explode em diff de richText + migração de conteúdo. **Corte neste item:** manter create-only; edits são outro item. +- **"Automatizar já".** Infra nova (agendador no homeserver, log, alerta) para uma frequência que ainda não dói. **Corte neste item:** runbook manual; automação quando a cadência justificar. + +## Questões em aberto (produto) + +- **Execução one-off manual ou automação agendada?** **Opções:** A) runbook manual no homeserver (padrão OPS52-media); B) cron no homeserver; C) Action de CI. **Recomendação:** A — a cadência de publicação ainda cabe em execução manual com runbook; automação vira item quando doer. _(assumido — validar)_ +- **Slugs novos fora da taxonomy: aceitar default `politica` ou bloquear o sync?** **Opções:** A) aceitar default + warning e registrar os slugs no runbook para classificação posterior; B) abortar até classificar. **Recomendação:** A — mantém o sync desbloqueado; a classificação é manutenção do seed, não gate de conteúdo. +- **Edits pós-publicação no WP devem refletir em prod?** **Opções:** A) não — create-only (contrato atual); B) upsert completo em item separado. **Recomendação:** A neste item; B vira follow-up se a equipe editar artigos já publicados com frequência. _(assumido — validar)_ + +## Referências + +- `AGENTS.md` — "Seeding news content (`pnpm db:seed:posts`)" e "Revalidating after a manual/direct DB change" +- `docs/plans/ops52-media-recuperar-arquivos-impl.md` — runbook do homeserver (precedente de execução) +- `scripts/seed-posts.mjs`, `scripts/lib/wpArticles.mjs`, `scripts/assert-local-database.mjs` +- `src/app/(frontend)/api/revalidate/route.ts` — bust de cache (`posts`)