atpares docs

Appearance

Publicação de blogs em Git ​

Contrato do adaptador ​

Cada projeto configura repositório, branch, pastas permitidas, serializador de conteúdo, serializador de metadados, URL pública e mecanismo de observar o deploy. O pacote interno contém contentId, versionId, slug, título, descrição, idioma, corpo Markdown, categoria, datas, relacionados, destino de CTA e ativos.

Esses campos são o contrato interno proposto. Não significam que todos precisam estar no frontmatter. O adaptador valida o schema real do site. Caminhos são normalizados e limitados às pastas cadastradas; impedir path traversal e escrita arbitrária de arquivos.

Contrasync existente ​

Corpo em src/blog/content/<slug>.md. Registro em src/blog/constants/posts.ts, array BLOG_POSTS. Campos observados: slug, title, description, keyword, category, publishedAt, readingMinutes, related e cta. Resolver o tipo e o catálogo de CTAs reais antes de implementar o serializador.

Atualizar Markdown e registro no mesmo commit. Preferir edição estruturada do registro TypeScript, com parsing e validação, evitando substituição textual frágil. Não exigir migração para frontmatter. Verificar também o carregador, os locales e os destinos de CTA durante a implementação.

Nos outros três sites, começar com Markdown e metadados serializáveis conforme a escolha de cada blog. Não existe blog implementado pelo atpares até agora.

Sequência ​

  1. Validar conteúdo, arquivos, links e versão aprovada.
  2. Ler revisão atual da branch e verificar colisão de slug e contentId.
  3. Preparar diff restrito a conteúdo, metadados e mídia esperados.
  4. Executar validação e build do site em ambiente isolado.
  5. Criar commit com operação idempotente e controle de concorrência.
  6. Acompanhar deploy correspondente ao commit exato.
  7. Conferir URL final, conteúdo esperado e disponibilidade da mídia.
  8. Marcar published e liberar peças sociais dependentes.

Conflito concorrente exige reler a branch e reaplicar apenas o pacote, sem sobrescrever alterações de terceiros. Falha de deploy mantém estado failed ou processing conforme evidência, nunca published. Identificar deploy de outro commit não confirma esta publicação.

Correções ​

Atualização mantém slug quando possível e preserva data original. Mudança de URL exige redirecionamento configurado no site. Reversão é um novo commit restrito à publicação afetada, sem reset destrutivo da branch. Publicações sociais já emitidas precisam de ação específica por canal se o destino deixar de funcionar.