Woo Guard

Você está revisando código gerado ou alterado do WooCommerce antes que ele seja publicado. Aplique as regras abaixo como uma verificação de segurança após a primeira etapa de implementação. O WooCommerce é uma plataforma em constante mudança — o armazenamento de pedidos mudou de motores, o checkout mudou de frameworks — e o código escrito de memória tem como alvo o WooCommerce de três anos atrás. Com dinheiro em jogo, "funciona na minha loja de demonstração" não é um padrão.

Essas regras existem porque agentes de IA produzem código WooCommerce com falhas sistemáticas: leitura de meta de pedido através de get_post_meta() (quebrado em lojas HPOS), produtos atualizados por escritas diretas de meta que pulam tabelas de consulta e hooks, checkout validado apenas em JavaScript, preços calculados em floats e woocommerce_* hooks registrados antes de confirmar que o WooCommerce está ativo.

Quando Usar

Use esta habilidade ao revisar código gerado ou alterado do WooCommerce — extensões, integrações de pagamento e envio, personalizações de checkout e lógica de pedidos/produtos — antes que ele seja publicado. Ative-a reativamente após um agente escrever ou modificar hooks do WooCommerce, lógica HPOS ou fluxos de checkout.

Como usar esta habilidade

Modo de verificação de segurança (recomendado): após o código do WooCommerce ter sido gerado ou editado, aplique as regras ao diff ou aos arquivos de destino, e então execute a auto-verificação antes da entrega.

Modo em tempo real (explícito): quando o usuário invoca esta habilidade antes de escrever código WooCommerce, aplique as mesmas regras durante a escrita, e então execute a auto-verificação antes da entrega.

Modo de revisão (o usuário pede para você revisar ou auditar código WooCommerce): percorra references/review-checklist.md e produza um relatório estruturado de descobertas. Não edite o código no modo de revisão a menos que seja solicitado.

Nível de segurança — estas regras se aplicam a todo código WooCommerce, com a máxima severidade, pois há dinheiro em jogo:

• Escape de toda saída com a função esc_* correta para o contexto.
• wp_unslash() e então sanitize todos os dados de requisição antes que eles toquem a lógica.
• Verificação de capacidade mais nonce em cada mudança de estado.
• $wpdb->prepare() para cada consulta contendo uma variável.

Se o wp-guard estiver instalado, execute-o em conjunto para a camada completa do WordPress.

Adapte-se ao projeto primeiro

1. Leia as instruções do agente do projeto e o intervalo de versão declarado do WooCommerce para a extensão. As convenções do projeto prevalecem em caso de conflito.
2. Determine o modo de armazenamento de pedidos que este código deve suportar: HPOS, posts legados, ou ambos (a suposição padrão é ambos).
3. Determine o checkout em uso: Blocos/Store API, checkout com shortcode legado, ou ambos. Hooks para um não disparam no outro.
4. Verifique se a atividade do WooCommerce está protegida: verificações de recursos ou class_exists( 'WooCommerce' ) antes de qualquer chamada wc_* ou hook woocommerce_*.

As Regras

Dados de pedidos e produtos — devem ser corrigidos

1. Pedidos não são posts. Acesse pedidos apenas através da API CRUD: wc_get_order(), wc_get_orders(), $order->get_meta(), $order->update_meta_data() + $order->save(). Proibido em dados de pedidos: get_post_meta(), update_post_meta(), WP_Query/get_posts() com post_type => shop_order, e joins diretos de $wpdb em postmeta. Estes funcionam em lojas legadas e quebram silenciosamente em lojas HPOS. Detalhes: references/hpos-and-crud.md.

2. Objetos CRUD, getters/setters, então salve. Produtos, clientes e cupons passam por seus objetos CRUD (wc_get_product(), setters, ->save()). Escritas diretas de meta pulam a sincronização da tabela de consulta, pulam os hooks em que outras extensões confiam e pulam a invalidação de cache. Mudanças de estoque seguem a semântica de wc_update_product_stock(); mudanças de estado de pedido através de $order->update_status() — que disparam os e-mails e hooks que a loja espera.

3. Declare compatibilidade de recursos. Qualquer extensão que toque em pedidos declara compatibilidade com HPOS (FeaturesUtil::declare_compatibility( 'custom_order_tables', … )); qualquer extensão que toque em checkout declara compatibilidade com cart_checkout_blocks (ou incompatibilidade, francamente). Uma declaração ausente mostra a todos os proprietários de lojas um banner de aviso com o nome do seu plugin.

Checkout e dinheiro — devem ser corrigidos

4. Validação de checkout é no lado do servidor. Valide em woocommerce_checkout_process (legado) ou através de esquemas de extensão da Store API (Blocos). A validação em JavaScript é UX, nunca segurança. Saiba qual checkout a loja executa e conecte ambos quando a extensão reivindicar compatibilidade geral.

…