FSWP Plugin Developer
Fundacional (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).
Executa um PRD aprovado (fswp-architect). Prefixo, alvo de distribuição, superfície de funcionalidades e nível de JS já estão decididos; não pergunte novamente. Para cada etapa, carregue a skill de domínio para o procedimento geral e a referência desta skill para profundidade interna, modelos e regras mais rigorosas. Precedência: fswp-developer/references/precedência.md.
Para alterações em um plugin existente, use fswp-maintainer; ele chama de volta aqui apenas para padrões de estrutura.
Camadas
1 BOOTSTRAP plugin-slug.php, uninstall.php, includes/class-plugin.php (sem lógica de negócio)
2 LIFECYCLE Activator / Deactivator (hook de ativação, dbDelta, verificação de upgrade)
3 DOMAIN CPTs, tabelas, rotas REST, cron: apenas o que o PRD lista
4a ADMIN UI nativo wp-admin por padrão; @wordpress/components para uma tela React;
React SPA + Tailwind + TanStack Query + Zustand apenas para admin tipo aplicativo
4b PUBLIC UI Atomic Framework (fornecido pelo usuário), vanilla JS por padrão, Alpine opt-in
Admin nunca usa Atomic Framework ou classes Alpine. Nunca crie classes de funcionalidades não utilizadas.
Fluxo de Trabalho
| Etapa | Ação | Referência interna | Skill de domínio |
|---|---|---|---|
| 1 Scaffold | Derivar slug, prefixo, nomes de classes, domínio de texto; executar scripts/scaffold_plugin.py --help primeiro. Passar --plugin-uri e --author-uri apenas se forem reais (a linha é descartada caso contrário, nunca um domínio placeholder). Execute fswp-qa-engineer/scripts/run_gate.sh <dir> <min-php> --fix imediatamente após o scaffold: os modelos carregam placeholders {{...}} que o formatador não pode reorganizar com segurança antes da substituição. | architecture.md | nenhum |
| 2 Bootstrap + ciclo de vida | Bootstrap declara o cabeçalho, carregamento automático e passa o controle para a classe principal | architecture.md | nenhum |
| 3 Segurança | Linha de base completa em cada arquivo, em qualquer tamanho de plugin | fswp-security-engineer | fswp-security-engineer |
| 4 Domínio | CPTs, tabelas (dbDelta, versões de esquema), REST, cron | data-cpt.md, rest-cron.md | fswp-api-developer; fswp-performance-engineer quando o PRD precisar |
| 5 Blocos (se estiver no PRD) | Blocos personalizados, padrões, Interactivity | nenhum | fswp-block-developer |
| 6 UI Admin | Settings API, WP_List_Table, Dashicons; escalar apenas conforme checklist | admin-ui.md, modern-app-stack.md | nenhum |
| 7 Saída pública | Perguntar ao usuário pelos arquivos atuais do Atomic Framework primeiro; enfileiramento condicional dentro do callback | frontend-output.md | nenhum |
| 8 i18n + distribuição | Toda string PHP e JS; readme; licença; versionamento | i18n-distribution.md | fswp-release-manager para WordPress.org |
Pare ao final da etapa 8 e passe para fswp-qa-engineer.
Estrutura de add-on
Quando fswp-maintainer executa no modo add-on, ele reutiliza as etapas 1-3 e 8 daqui. As regras extras de add-on (detecção de host, Requires Plugins, ordem de carregamento, ausência graciosa) estão em fswp-maintainer.
Padrões (cada construção, cada iteração)
references/standards.md governa a disciplina de versionamento/changelog, a decisão da pilha de tecnologia, os metadados obrigatórios do projeto (nunca invente um valor ausente), a documentação por funcionalidade em docs/, o padrão de qualidade de código e a disciplina de código mínimo (ordem de decidir-antes-de-escrever, correções de causa raiz, marcadores shortcut:). Leia antes da primeira construção e antes de qualquer iteração em um plugin existente — não é uma etapa única de configuração.
Postura de segurança
Nunca reduzida para plugins pequenos: verificações de capacidade em cada ação privilegiada, nonces em cada mudança de estado, sanitizar entrada e escapar saída, $wpdb->prepare() em cada consulta, um permission_callback real em cada rota REST, ciclo de vida seguro, nenhum segredo em texto simples. Regras completas: fswp-security-engineer.
Nível Alpine
Nunca inferido. Selecionado apenas pelo checklist de 5 pontos em references/frontend-output.md, e apenas após o usuário confirmar explicitamente ter visto qual verificação o acionou e qual é a alternativa vanilla.
Atomic Framework (fornecido pelo usuário, não empacotado)
É um produto mantido separadamente; uma cópia empacotada ficaria desatualizada. Sempre que a construção incluir frontend, peça os arquivos atuais afw-tokens.css, afw-components.css, afw-foundation-logics.js (mais alpine.min.js, alpine-loader.js, alpine-components.js apenas se o nível Alpine foi confirmado). O scaffold os copia via --foundation-dir e para com um lembrete se estiver faltando.
Dependências
Tudo, exceto o Atomic Framework (Tier 2 @wordpress/*, pilha Tier 3), é resolvido em latest do seu registro oficial no momento do scaffold, depois fixado: confirme o arquivo de bloqueio e registre as versões resolvidas no README. Latest-at-scaffold mais um arquivo de bloqueio confirmado satisfaz a regra de fonte reproduzível do WordPress.org. Exceção: um limite de compatibilidade declarado pelo usuário. Detalhes: references/modern-app-stack.md.
Entregar
{plugin-slug}.zip instalável (pasta do plugin na raiz do zip) mais readme.txt e/ou README.md privado com etapas de instalação reais, e um breve resumo: prefixo e decisões de funcionalidades, etapas manuais ainda pendentes (chaves de API, intervalo de cron, configurações iniciais). A saída compilada é enviada com sua fonte (references/modern-app-stack.md).
Incluído
scripts/scaffold_plugin.py:--features cpt,db,rest,cron,admin,frontend(qualquer subconjunto),--js-tier vanilla|alpine,--admin-tier native|react|app,--distribution wporg|private|both,--plugin-uri,--author-uri,--foundation-dir,--zip.assets/templates/: esqueleto do plugin com placeholders{{PREFIX}},{{Prefix}},{{prefix}},{{PLUGIN_NAME}},{{plugin-slug}}.