fswp-maintainer

FSWP Maintainer

Fundamental (sempre aplicado): fswp-developer/references/lean-coding.md (escreva menos, reutilize primeiro), fswp-developer/references/coding-standards.md (padrões de codificação, documentação, i18n, acessibilidade), e fswp-security-engineer (entrada, saída, autorização).

O código existente é a especificação. Executa um resumo de mudança aprovado do fswp-architect (que já executou detect_wp_project.py). Siga as próprias convenções do projeto, a menos que sejam inseguras; modelos de casa são para novos projetos, não para reescrever o estilo de outra pessoa.

Modo A: Atualizar um plugin ou tema existente

1. Leia primeiro. Leia os arquivos que a mudança afeta, seus chamadores e seus testes. Observe o prefixo, a nomenclatura, o estilo de tratamento de erros e como as configurações e dados são armazenados.
2. Reproduza. Para um bug, anote as etapas e o resultado observado; confirme a falha antes de alterar qualquer coisa. Para uma funcionalidade, declare a verificação de aceitação.
3. A menor mudança que funciona. Corrija a causa no código compartilhado, não em um único local de chamada. Não reformate código não tocado; diffs ruidosos escondem mudanças reais e quebram o histórico de alterações.
4. Proteja a superfície pública. Nomes de hooks, nomes de funções e classes, chaves de opções, chaves de meta, rotas e formas REST, atributos de shortcodes e substituições de modelos são contratos. Para alterar um, deprecie primeiro: mantenha o antigo funcionando, chame _deprecated_function() / _deprecated_hook() (ou _deprecated_argument()), documente a substituição e remova não antes de uma versão major posterior.
5. Caminho de atualização. Se dados ou esquema mudarem: aumente uma versão de opção armazenada, execute uma migração ao carregar (não apenas na ativação), torne-a idempotente e teste a atualização a partir dos dados da versão anterior sem reativar.
6. Compatibilidade. Respeite os requisitos declarados Requires at least e Requires PHP; proteja funções mais novas com function_exists()/verificações de versão ou aumente o mínimo deliberadamente e informe.
7. Passagem de segurança no código tocado (fswp-security-engineer): uma correção de bug não deve adicionar um novo ponto de entrada sem autorização, nonce, sanitização e escape.
8. Versão e changelog. Correção = patch, funcionalidade = minor, quebra = major. Atualize a versão do plugin/tema, a constante, a tag Stable tag do readme.txt e o changelog juntos.
9. Entregue como um patch ou diff para o repositório em que o usuário trabalha, ou um zip quando eles implantarem arquivos. Inclua o resultado da lista de verificação de paridade.

Temas: prefira um tema filho ou alterações em theme.json/variação de estilo em vez de editar um tema pai que recebe atualizações. Edições diretas em um tema pai e edições em arquivos de plugins de terceiros são perdidas na próxima atualização.

Modo B: Complemento para um produto que você não possui

Um complemento é um plugin separado (ou uma pequena camada de tema) que estende um hospedeiro. Estruture-o com fswp-plugin-developer (etapas 1-3 e 8), e então aplique estas regras:

1. Estenda através da API pública do hospedeiro. Use ações, filtros, registros e rotas REST documentados. Nunca edite arquivos do hospedeiro e evite chamar internos marcados como privados ou não documentados; se for necessário, isole a chamada em uma classe adaptadora e proteja-a.
2. Declare a dependência. Adicione Requires Plugins: slug-do-hospedeiro no cabeçalho quando o hospedeiro estiver no WordPress.org (WordPress 6.5 e posteriores impõem isso). Também detecte em tempo de execução: verifique por uma classe, função ou constante, ou uma constante de versão, não o caminho do arquivo do plugin.
3. Carregue no momento certo. Inicialize em plugins_loaded (ou no próprio hook de prontidão do hospedeiro) após confirmar que o hospedeiro existe; registre nos hooks de registro do hospedeiro, não antes.
4. Falhe de forma silenciosa e clara. Hospedeiro ausente ou muito antigo: não faça mais nada, mostre um aviso administrativo explicando o que é necessário e nunca cause um erro fatal.
5. Faixa de versão. Declare as versões do hospedeiro suportadas no readme e no plano. Teste a mais baixa e a mais nova suportada.
6. Declarações de compatibilidade. Alguns hospedeiros exigem que você declare suporte a funcionalidades. Exemplo: WooCommerce espera que extensões declarem compatibilidade com High-Performance Order Storage e o carrinho e checkout baseados em blocos. Leia a documentação do desenvolvedor do hospedeiro para as chamadas de declaração atuais.
7. Propriedade dos dados. Armazene seus dados sob seu próprio prefixo; não escreva nas tabelas ou opções do hospedeiro. A desinstalação remove apenas seus dados.
8. Licenciamento e nomenclatura. Siga as regras de marca e marca registrada do hospedeiro para nomes; use um estilo descritivo "para X" em vez de sugerir que é oficial.

Verificar

Entregue para fswp-qa-engineer com a lista de paridade do resumo de mudança e a tabela de compatibilidade como fonte de cenário. references/safe-change-checklist.md é a lista rápida de pré-entrega.