wp-build

Estágio 3: Construção

Objetivo: o site roda localmente. Itens reais são renderizados por funções do núcleo. Consultas são salvas, encaminhadas e depois purgadas. Os testes estruturais estão verdes.

Leia primeiro: o AGENTS.md do projeto, depois references/architecture.md.

Passos

1. Site local. Siga a seção "Primeira execução" do README.md do projeto. Depois verifique: ddev wp eval 'echo wp_get_environment_type();' deve imprimir local. Se não imprimir, veja references/local-env.md. Até imprimir local, o site pensa que está em produção: pode ser indexado e pode enviar e-mails para clientes reais.
2. Renomeie o tipo de conteúdo de exemplo. Faça isso antes de existir conteúdo. <prefixo>_offer se torna a palavra do negócio (tour, serviço, curso): o tipo de post, o slug de reescrita e os rótulos em modules/content.php, além dos nomes das funções (_get_offers, _render_offer_card), do arquivo parts/offer-card.php e dos testes. Nomes de tipos de post têm limite de 20 caracteres.
3. Modele o conteúdo. Encontre cada campo que o resumo do projeto precisa. Registre cada um como meta de post com um callback de sanitização e um callback de autorização. Preços são números em meta. 0 significa "sob consulta", nunca "grátis". Se os editores precisarem de telas de campos mais ricas, adicione ACF (grátis) por cima, mas leia os valores apenas através de funções do núcleo.
4. Arquivos de dados → gerador (quando o proprietário fornecer muitos itens):
   • mantenha um arquivo Markdown ou JSON por item em docs/data/<tipo>/;
   • escreva um script WP-CLI idempotente que cria ou atualiza posts a partir desses arquivos;
   • dê a ele uma opção --dry-run;
   • execute-o com ddev wp eval-file - < scripts/<nome>.php. Os arquivos são a verdade revisável; o banco de dados é a cópia.
5. Templates chamam uma função do núcleo por seção.
   • O layout vive no tema: templates, parts/, sobreposições de skin.
   • Dados, consultas, preços, frases de política e formulários vêm do núcleo.
   • Proteja cada chamada com function_exists(), para que um template nunca gere erro fatal se o plugin estiver ausente.
6. Consultas. Mantenha o pipeline em modules/enquiry.php (references/forms-and-leads.md).
   • Adicione campos em três lugares juntos: o formulário, o manipulador e a caixa de detalhes.
   • Defina a caixa de entrada e o remetente em constantes do wp-config.php, nunca no código.
7. Texto de política (termos, depósitos, cancelamento): coloque-o no núcleo como uma função (por exemplo <prefixo>_policy( 'cancellation' )). Os templates imprimem essa função, e um teste falha se um template codificar manualmente uma frase de política.
8. Novo módulo? Adicione um arquivo em modules/, uma linha require_once no bootstrap, e atualize tests/structure/core.spec.ts no mesmo commit.
9. Verifique e faça commit.
   • Execute npm run test:structure e npm run lint:php (0 erros).
   • Peça ao agente wp-rules-reviewer para revisar o diff.
   • Faça commit (Commits Convencionais).

Portão (marque em SITE_STATUS.md)

• wp_get_environment_type() = local
• Plugin principal e tema filho ativos; skin carrega
• Itens reais renderizados por funções do núcleo; sem cartões, preços ou slugs codificados manualmente
• Consulta: salva → enviada por e-mail → retentativa → purgada; testada de ponta a ponta no Mailpit
• Testes estruturais verdes; PHPCS 0 erros

Nunca

• Lógica de negócios, WP_Query, preços, chamadas pll_* ou texto de política no tema.
• $_POST ou $_GET brutos sem wp_unslash + uma função de sanitização; saída sem esc_*.
• Chaves de API ou endpoints de terceiros em HTML ou JS. Encaminhe do servidor.
• Alternar módulos de plugin com wp option update bruto. Use a interface própria do plugin ou CLI, depois verifique novamente cada página que ele afeta.
• Funções, opções, hooks, chaves de meta ou nonces sem prefixo.