Arquitetura e Mapa de Candidatos

WSS — Skills — Arquitetura e Mapa de Candidatos

Arquivo: WSS_Skills_Arquitetura_e_Mapa_Candidatos_v0.2_DRAFT.md
Versão: v0.2 DRAFT
Data: 11/09/2026
Status: DRAFT — AGUARDANDO GATE DA COORDENAÇÃO
Projeto: WSS — Método de Desenvolvimento de Sites
Natureza: proposta de arquitetura da camada de Skills derivada da documentação humana canônica
Origem da revisão v0.2: incorporação controlada do WSS_Registro_Decisao_Handoff_SEO_AEO_GEO_Metodo_v0.1.md, sem reabertura da coleção v1.1 FINAL e sem criação de Skills

1. Finalidade

Este documento propõe a arquitetura inicial da camada de Skills do Método de Desenvolvimento de Sites WSS a partir da documentação humana canônica v1.1 FINAL.

A proposta responde a oito perguntas:

1. quais atividades documentadas são boas candidatas a Skill;
2. quais atividades não devem virar Skill;
3. quais partes dependem de julgamento humano;
4. quais capacidades exigem acesso a arquivos, navegador, GitHub, Lovable ou outros ambientes;
5. quais são os principais riscos de automação;
6. quais SOPs podem ser agrupados sob a mesma Skill;
7. quantas Skills fazem sentido na primeira arquitetura;
8. quais Skills devem ser priorizadas como pilotos.

Este documento não cria nenhuma Skill, não altera a documentação humana e não redefine o Processo Sites WSS.

2. Base documental analisada

A análise foi realizada sobre os 8 Manuais e 12 SOPs `v1.1 FINAL` da coleção vigente.

Manuais

1. WSS_Manual_01_Visao_Geral_Toolchain_v1.1_FINAL.md
2. WSS_Manual_02_Entrada_Contexto_Projeto_v1.1_FINAL.md
3. WSS_Manual_03_Construcao_Visual_v1.1_FINAL.md
4. WSS_Manual_04_Projeto_Base_Admin_Funcionalidades_v1.1_FINAL.md
5. WSS_Manual_05_Desenvolvimento_Codex_Lovable_GitHub_v1.1_FINAL.md
6. WSS_Manual_06_Testes_QA_Debugging_Seguranca_SEO_v1.1_FINAL.md
7. WSS_Manual_07_Publicacao_Entrega_Pos_Publicacao_v1.1_FINAL.md
8. WSS_Manual_08_Boas_Praticas_AntiPatterns_Depreciadas_Casos_Reais_v1.1_FINAL.md

SOPs

1. WSS_SOP_001_Contextualizar_Novo_Projeto_WSS_v1.1_FINAL.md
2. WSS_SOP_002_Iniciar_Tecnicamente_Projeto_WSS_v1.1_FINAL.md
3. WSS_SOP_003_Construir_Refinar_Home_Referencias_v1.1_FINAL.md
4. WSS_SOP_004_Paginas_Internas_Consistencia_Visual_v1.1_FINAL.md
5. WSS_SOP_005_Configurar_Admin_Modulos_Aplicaveis_v1.1_FINAL.md
6. WSS_SOP_006_Configurar_Validar_Chatbot_Base_Conhecimento_v1.1_FINAL.md
7. WSS_SOP_007_Portar_Capacidade_Base_Projeto_Legado_v1.1_FINAL.md
8. WSS_SOP_008_QA_Visual_Funcional_Responsivo_v1.1_FINAL.md
9. WSS_SOP_009_Diagnosticar_Corrigir_Bug_Por_Camada_v1.1_FINAL.md
10. WSS_SOP_010_Tratar_Auditoria_SEO_AEO_GEO_v1.1_FINAL.md
11. WSS_SOP_011_Processar_Rodada_Feedback_Ajustes_md_v1.1_FINAL.md
12. WSS_SOP_012_Preparar_Publicar_Validar_Producao_Entregar_Admin_v1.1_FINAL.md

O Índice Oficial e o Termo de Atualização v1.1 foram usados apenas para confirmar a autoridade documental vigente. A norma WSS_Padrao_Tecnico_Operacional_SEO_AEO_GEO_v0.2_FINAL permanece autoridade própria e é uma dependência normativa da futura Skill relacionada ao SOP-010; não é substituída nem reinterpretada por este documento.

Entrada adicional de governança incorporada na v0.2

Esta revisão incorpora também, como entrada de governança posterior à coleção humana, o arquivo:

WSS_Registro_Decisao_Handoff_SEO_AEO_GEO_Metodo_v0.1.md

Esse registro não altera, corrige ou reabre os 8 Manuais, os 12 SOPs, o Índice, o Termo, as normas técnicas ou o Processo Sites WSS. Sua função nesta arquitetura é exclusivamente transportar para a futura camada de execução os requisitos SK-HMD-01, SK-HMD-02, SK-HMD-03 e os guardrails G-SK-01, G-SK-02, G-SK-03.

Permanece preservado:

`1 HMD ≠ 1 Skill` e `1 SOP ≠ 1 Skill`.

PARTE I — PRINCÍPIOS DA ARQUITETURA DE SKILLS

3. Skill não é sinônimo de SOP

A documentação canônica possui uma hierarquia funcional clara:

Manual
→ explica contexto, método, fronteiras, critérios e conhecimento

SOP
→ descreve uma rotina executável/reproduzível

Skill
→ futura projeção operacional que aplica uma ou mais rotinas,
  carrega somente o contexto necessário,
  usa ferramentas permitidas,
  produz evidência e respeita gates humanos

Consequência:

não deve existir a regra `1 SOP = 1 Skill`.

A unidade adequada de Skill deve ser definida por:

• intenção do usuário/executor;
• gatilho claro;
• conjunto coerente de entradas;
• ferramentas e permissões semelhantes;
• saída verificável;
• risco de automação comparável;
• fronteira de julgamento humano.

4. Regra de agrupamento

Dois ou mais SOPs são bons candidatos a uma única Skill quando compartilham simultaneamente:

1. o mesmo domínio operacional;
2. a mesma fase do fluxo;
3. ferramentas semelhantes;
4. nível de risco semelhante;
5. saída que forma uma continuidade natural.

Exemplo forte:

SOP-003 — Home
+
SOP-004 — páginas internas
=
uma Skill de construção visual

Ambos trabalham a mesma linguagem visual, os mesmos tipos de referência, o mesmo ambiente de código e a mesma fronteira de julgamento de fidelidade/adaptação.

5. Regra de separação

Atividades devem permanecer em Skills diferentes quando existir mudança material em:

• privilégio necessário;
• ambiente de execução;
• risco de alteração;
• tipo de evidência;
• gatilho operacional;
• autoridade humana exigida.

Exemplo forte:

SOP-001 — contextualização

pode operar somente com arquivos e leitura.

Já:

SOP-002 — início técnico

pode exigir criação/remix no Lovable, conexão GitHub, clone e escrita técnica.

Embora sequenciais, não devem ser fundidos, pois a fronteira de permissão é importante.

6. Camadas propostas para qualquer futura Skill

Cada Skill futura deve ser desenhada em cinco camadas conceituais.

6.1 Fonte canônica

Somente os Manuais/SOPs/normas expressamente vinculados àquela Skill.

6.2 Trigger e pré-condições

Deve ser possível responder objetivamente:

• quando ativar;
• quando não ativar;
• qual estado mínimo precisa existir.

6.3 Guardrails

Devem preservar, entre outros:

• escopo;
• áreas já validadas;
• não invenção de requisitos;
• não invenção de fatos;
• não transformação de ausência de padronização em regra;
• retorno a humano quando o documento exige decisão humana.

Quando a execução envolver SEO/AEO/GEO e o Protocolo de Validação for aplicável, acrescentam-se os seguintes guardrails transversais de governança:

• G-SK-01 — SOP-010 × Protocolo: não misturar o procedimento de investigação do SOP-010 com a governança/status formal dos checkpoints V0–V5;
• G-SK-02 — Duas taxonomias: manter separado o estado do achado de auditoria do status canônico do checkpoint;
• G-SK-03 — V5 não decide recorrência: baseline técnico em V5 não cria nem presume contratação de monitoramento/otimização recorrente.

Esses guardrails não criam Skills autônomas. Devem ser carregados apenas pelas Skills/camadas em que forem materialmente aplicáveis.

6.4 Adaptadores de ferramenta

A Skill deve saber quando precisa de:

• arquivos;
• navegador;
• GitHub/repositório;
• ambiente local;
• Lovable;
• Supabase/Lovable Cloud;
• Admin;
• ferramentas externas aplicáveis.

A escolha de ferramenta não deve virar uma matriz rígida inexistente na documentação.

6.5 Evidência de saída

Toda Skill deve terminar com evidência verificável, por exemplo:

• resumo validável;
• prompt master;
• checklist de prontidão;
• relatório de QA;
• classificação de bug;
• delta de portabilidade;
• ajustes.md atualizado;
• registro de validação pós-publicação.

7. Três tipos de Skill

A arquitetura proposta distingue três comportamentos.

7.1 Skills de preparação/orquestração

Organizam contexto, classificam pedidos ou coordenam outras rotinas.

Exemplos candidatos:

• contextualização;
• feedback;
• publicação/entrega.

7.2 Skills executoras

Atuam diretamente sobre projeto ou configuração.

Exemplos candidatos:

• início técnico;
• construção visual;
• Admin/Chatbot;
• portabilidade;
• debugging.

7.3 Skills validadoras

Inspecionam estado e produzem diagnóstico/evidência.

Exemplos candidatos:

• QA;
• auditoria SEO/AEO/GEO.

A distinção é útil porque Skills validadoras podem operar com privilégios menores que Skills executoras.

PARTE II — CRITÉRIOS PARA CANDIDATURA

8. Critérios positivos

Uma atividade é boa candidata a Skill quando possui a maioria dos seguintes atributos:

• recorrência entre projetos;
• sequência reconhecível;
• inputs identificáveis;
• outputs verificáveis;
• limites explícitos;
• caminhos de exceção documentados;
• possibilidade de detectar quando deve parar;
• possibilidade de escalar decisão para humano;
• benefício real em reduzir perda de contexto/repetição;
• possibilidade de instrumentar evidência de conclusão.

9. Critérios negativos

Uma atividade isolada não deve virar Skill quando for predominantemente:

• conhecimento de referência sem gatilho operacional;
• decisão de negócio;
• decisão estética subjetiva sem procedimento executável;
• aprovação formal;
• autoridade normativa;
• microação trivial de ferramenta;
• exceção histórica;
• caso real usado apenas como lição;
• ausência de padronização.

PARTE III — MAPA DE ATIVIDADES CANDIDATAS

10. Mapa consolidado

PARTE IV — O QUE NÃO DEVE VIRAR SKILL

11. Manual 1 não deve virar uma “Skill Toolchain” autônoma

O Manual 1 cumpre função de orientação e de visão geral.

Ele deve alimentar todas as Skills com princípios sobre:

• papéis das ferramentas;
• fronteira Processo × Método;
• decisões humanas centrais;
• ausência de matriz universal de escolha de ferramentas.

Criar uma Skill cujo único objetivo fosse “escolher a ferramenta correta” correria o risco de inventar justamente a matriz formal que a documentação declara não existir.

12. Manual 8 não deve virar uma “Skill Boas Práticas” genérica

O Manual 8 deve funcionar como biblioteca transversal de guardrails.

Itens como:

• investigar antes de alterar;
• preservar áreas validadas;
• não obedecer auditoria automaticamente;
• validar fluxo completo;
• não inventar fatos;
• distinguir anti-pattern de ausência de padronização;

são melhores como regras carregadas pelas Skills relevantes do que como uma Skill isolada sem gatilho operacional.

13. Decisões humanas não devem ser automatizadas

A documentação repete explicitamente decisões que permanecem humanas.

Não devem ser transformadas em autoridade automática da Skill:

• decidir mudança de escopo;
• resolver contradição material entre fontes sem precedência definida;
• validar fato sensível ausente;
• escolher direção visual final;
• decidir grau aceitável de fidelidade/adaptação;
• definir prioridade quando não existe regra;
• classificar uma feature nova como aprovada;
• autorizar migration destrutiva;
• aceitar perda/transformação de dados;
• decidir arquitetura ampla;
• decidir rollback relevante;
• aprovar publicação;
• decidir contingência de produção;
• redefinir norma SEO/AEO/GEO;
• transformar ausência de padronização em novo padrão WSS.

A Skill pode detectar, explicar e escalar esses casos.

Ela não deve resolvê-los silenciosamente.

14. Microações não devem virar Skills próprias

Não há justificativa para criar Skills autônomas para ações como:

• git pull;
• abrir DevTools;
• tirar screenshot;
• abrir Admin;
• conferir uma rota;
• executar typecheck isoladamente;
• criar commit;
• publicar um preview isoladamente.

Essas ações são etapas dentro de Skills com finalidade maior.

15. Normas não devem virar Skills

O padrão SEO/AEO/GEO é autoridade normativa, não procedimento executável em si.

A futura Skill relacionada ao SOP-010 deve consultar/aplicar a norma vigente, preservando sua autoridade e versão.

O mesmo princípio vale para futuras normas técnicas especializadas.

PARTE V — JULGAMENTO HUMANO E GATES

16. Gate H1 — contradição documental material

Aplicável principalmente a:

• contextualização;
• feedback;
• construção;
• publicação.

A Skill deve parar quando fontes sem precedência clara entrarem em conflito sobre:

• escopo;
• página;
• funcionalidade;
• conteúdo factual;
• direção visual;
• decisão do cliente.

17. Gate H2 — mudança de escopo

Aplicável a praticamente todas as Skills executoras.

Sinais:

• nova página;
• novo módulo;
• nova integração;
• nova jornada;
• alteração estrutural não prevista;
• capacidade não contratada;
• feature descoberta durante portabilidade mas fora do delta aprovado.

A Skill pode registrar a proposta, mas não executá-la como ajuste normal.

18. Gate H3 — fato sensível ou não confirmado

Aplicável a:

• contextualização;
• conteúdo visual;
• Chatbot;
• feedback;
• SEO/AEO/GEO.

A Skill não deve inventar ou consolidar como fato:

• formação;
• título;
• especialidade;
• procedimento;
• resultado;
• informação médica;
• preço;
• horário;
• endereço;
• profissional;
• outro dado factual sensível não validado.

19. Gate H4 — risco técnico elevado

A Skill deve exigir decisão humana antes de:

• migration destrutiva;
• perda ou transformação material de dados;
• alteração ampla de autenticação/permissão;
• troca arquitetural relevante;
• remoção de comportamento local superior no legado;
• rollback relevante;
• correção ampla em produção.

20. Gate H5 — publicação e produção

A Skill pode comprovar prontidão e preparar a ação.

A decisão de publicar/alterar produção deve permanecer sujeita a aprovação humana explícita.

PARTE VI — ACESSOS E PERMISSÕES

21. Princípio de menor privilégio

A arquitetura recomendada é que cada Skill receba apenas os acessos necessários ao seu objetivo.

Não é recomendável uma única Skill WSS com acesso permanente e irrestrito a:

• Lovable;
• GitHub;
• produção;
• banco;
• navegador;
• arquivos;
• Admin;

quando sua tarefa concreta exige apenas parte desse conjunto.

Isso reduz:

• mudança colateral;
• ação fora de escopo;
• confusão entre análise e execução;
• risco de produção;
• dificuldade de auditoria.

22. Matriz de acesso por Skill proposta

Legenda:

• R = leitura/inspeção;
• W = alteração necessária para executar a Skill;
• C = acesso condicional;
• — = normalmente desnecessário.

Observação sobre “W” em QA

Alguns testes funcionais criam efeitos controlados, como:

• Lead de teste;
• conversa de teste;
• registro temporário;
• login/perfil de teste.

Isso deve ser tratado como efeito de teste previsto, não como liberdade geral para alterar implementação.

PARTE VII — RISCOS DE AUTOMAÇÃO

23. Risco A — converter AS-IS em norma

A documentação registra várias AUSÊNCIAS ATUAIS DE PADRONIZAÇÃO.

Risco:

a Skill preencher automaticamente essas lacunas com uma preferência própria.

Exemplos que não podem virar regra silenciosa:

• branching universal;
• PR obrigatório;
• matriz universal de viewports;
• suíte universal de testes;
• matriz rígida Lovable × Codex × Claude;
• template único de prompt master;
• DNS universal;
• rollback universal.

Mitigação:

• carregar explicitamente a distinção AS-IS / ausência / norma / oportunidade;
• produzir “não padronizado” como resultado válido.

24. Risco B — excesso de autonomia em código

Risco:

• mudar mais arquivos do que necessário;
• alterar áreas já validadas;
• criar regressões;
• transformar uma hipótese em implementação.

Mitigação:

• delimitar recorte antes de editar;
• preferir análise/diagnóstico antes de alteração quando o risco for relevante;
• exigir regressão proporcional.

25. Risco C — excesso de autonomia em Lovable/Cloud

Risco:

• alterar backend, auth, banco ou configuração sem necessidade;
• criar efeito fora do repositório esperado;
• confundir ambiente.

Mitigação:

• a Skill deve declarar ambiente e projeto antes de agir;
• operação deve ser ligada a hipótese/objetivo explícito;
• ações de alto risco devem acionar gate humano.

26. Risco D — aceitar relatório externo como verdade

Especialmente relevante a SEO/AEO/GEO.

Risco:

• corrigir problema já resolvido;
• reagir a falso positivo;
• alterar arquitetura por limitação de crawler.

Mitigação:

relatório
→ estado atual
→ reprodução
→ classificação
→ delta real
→ correção

27. Risco E — automação estética sem julgamento

A construção visual possui forte componente humano.

Risco:

• copiar referência literalmente;
• perder identidade do cliente;
• sacrificar usabilidade/mobile;
• supervalorizar fidelidade em detrimento de adequação.

Mitigação:

• a Skill pode comparar, investigar e implementar;
• aceite de direção/fidelidade permanece humano.

28. Risco F — dados e produção

Portabilidade, debugging, Admin e publicação podem alcançar:

• banco;
• autenticação;
• perfis;
• dados existentes;
• domínio;
• produção.

Mitigação:

• privilégios segregados;
• confirmação de ambiente;
• gate humano em alterações destrutivas ou de produção;
• evidência de rollback/restauração quando aplicável.

29. Risco G — Skill monolítica

Uma única Skill “Desenvolver Site WSS” tenderia a:

• carregar contexto demais;
• misturar análise e execução;
• exigir todas as permissões;
• dificultar ativação correta;
• tornar gates humanos difusos;
• aumentar risco de mudança colateral.

A arquitetura proposta rejeita esse desenho.

PARTE VIII — ARQUITETURA RECOMENDADA

30. Quantidade recomendada

Recomenda-se uma arquitetura inicial de 10 Skills principais.

Isso reduz os 12 SOPs para 10 unidades operacionais por meio de dois agrupamentos naturais:

SOP-003 + SOP-004
→ SK-03 Construção Visual

SOP-005 + SOP-006
→ SK-04 Camada Operacional

Os demais SOPs permanecem separados não por equivalência automática, mas porque apresentam diferenças relevantes de:

• trigger;
• ferramenta;
• privilégio;
• risco;
• saída;
• gate humano.

A quantidade 10 é recomendação arquitetural inicial, não nova norma WSS. Ela deve ser validada pelo Gate da Coordenação e pode ser ajustada após os pilotos.

31. SK-01 — Contextualizar Novo Projeto WSS

Tipo: preparação/orquestração
Origem principal: SOP-001
Manual proprietário: Manual 2

Finalidade proposta

Transformar o handoff em entendimento operacional, identificar lacunas/contradições e produzir o prompt master, sem iniciar alterações técnicas.

Bons candidatos à automação

• inventariar arquivos recebidos;
• extrair estrutura, público, objetivo, Sitemap e módulos;
• separar decisão confirmada de pendência;
• detectar conflito entre fontes;
• produzir resumo validável;
• produzir prompt master a partir de contexto aprovado;
• quando SEO/AEO/GEO for aplicável, identificar a autoridade canônica vigente e consultar as fontes técnicas canônicas aplicáveis antes de contextualizar requisitos para o projeto real.

Integração de governança SEO/AEO/GEO — SK-HMD-01

A SK-01 absorve SK-HMD-01 como ajuste de escopo, sem criação de nova Skill.

Quando o projeto estiver sujeito ao padrão SEO/AEO/GEO, a contextualização deve consultar a camada canônica vigente. No estado atual da governança, isso inclui:

1. Padrão v0.2 FINAL;
2. Matriz de Requisitos Técnicos v0.3;
3. Matriz de Schema v0.3;
4. Matriz de Crawlers v0.2;
5. Implementação de Referência TanStack/Lovable v0.3, quando aplicável.

A Skill não deve congelar essas versões como se fossem permanentes. Deve resolver as fontes canônicas vigentes no momento da execução, preservar classificações normativas e decisões abertas e evitar copiar genericamente todo o padrão para o Contexto do projeto.

Julgamento humano obrigatório

• contradição material sem precedência;
• escopo indefinido;
• fato sensível ausente;
• decisão de cliente não resolvida.

Acessos

• arquivos/documentos: necessários;
• navegador: opcional para referências;
• GitHub/Lovable: desnecessários.

Risco

Baixo a médio.

Saída esperada

• mapa de fontes;
• lacunas/pendências;
• resumo de entendimento;
• prompt master;
• bloqueios para decisão humana;
• quando aplicável, sinalização de que o projeto deve passar por V0 — Validação do Contexto antes da continuidade técnica.

Handoff condicional SK-01 → V0 → SK-02 — SK-HMD-02

SK-HMD-02 pertence à camada de orquestração entre SK-01 e SK-02, não a uma nova Skill.

Quando o Protocolo SEO/AEO/GEO for aplicável:

SK-01 — Contextualização
→ V0 — Validação do Contexto
→ SK-02 — Início técnico

A SK-01 identifica a aplicabilidade e prepara o contexto; o checkpoint V0 é governado pelo Protocolo de Validação; a SK-02 somente recebe a continuidade técnica depois do resultado requerido pela governança.

Guardrail: V0 não deve ser transformado em etapa universal para projetos fora da aplicabilidade definida pela governança SEO/AEO/GEO.

32. SK-02 — Iniciar Tecnicamente Projeto WSS

Tipo: executora
Origem principal: SOP-002
Manual proprietário: Manual 5
Manuais relacionados: 2 e 4

Finalidade proposta

Conduzir a passagem de contexto pronto para projeto tecnicamente preparado no fluxo:

Base → Lovable → primeiros protótipos → GitHub → local

Bons candidatos à automação

• verificar pré-condições;
• remixar Base quando autorizado;
• aplicar prompt master;
• verificar desvio material;
• conectar GitHub;
• confirmar repositório;
• preparar clone/ambiente local;
• pedir leitura/resumo antes da primeira alteração;
• validar prontidão técnica.

Julgamento humano obrigatório

• Base correta;
• protótipo suficientemente coerente;
• branch separada quando relevante;
• alteração estrutural não prevista.

Acessos

• arquivos;
• Lovable com escrita;
• GitHub com escrita;
• ambiente local.

Risco

Alto.

Observação arquitetural

Não deve ser fundida à SK-01, pois muda materialmente o privilégio necessário.

Quando SK-HMD-02 for aplicável, a separação também preserva o checkpoint de orquestração V0 entre contextualização e início técnico, sem transformar a SK-02 em proprietária do Protocolo de Validação.

33. SK-03 — Construção Visual WSS

Tipo: executora
Origem principal: SOP-003 + SOP-004
Manual proprietário: Manual 3
Manuais relacionados: 2, 5 e 6

Finalidade proposta

Conduzir a construção visual desde o refinamento da Home até as páginas internas, preservando linguagem, contexto e responsividade.

Subfluxos

1. Home/referências;
2. páginas internas;
3. efeitos/animações;
4. responsividade dirigida;
5. reuso/componentização pragmática.

Bons candidatos à automação

• comparar seção atual com referência;
• analisar screenshot/link;
• limitar escopo de alteração;
• investigar efeito antes de implementar;
• reutilizar componentes existentes;
• verificar consistência;
• gerar primeira versão de página interna;
• executar refinamentos localizados.

Julgamento humano obrigatório

• fidelidade aceitável;
• adequação da referência ao cliente;
• prioridade de página;
• nível de sofisticação;
• adaptação ou descarte de efeito;
• decisão de que Home/página está visualmente pronta.

Acessos

• arquivos e referências;
• navegador;
• repositório/código;
• Lovable de forma condicional;
• ferramentas visuais quando aplicáveis.

Risco

Alto.

Motivo do agrupamento

Home e páginas internas formam a mesma cadeia visual e compartilham ferramentas, guardrails e modelo de decisão.

34. SK-04 — Configurar Camada Operacional WSS

Tipo: executora com subfluxos condicionais
Origem principal: SOP-005 + SOP-006
Manual proprietário: Manual 4
Manuais relacionados: 2, 3, 6 e 7

Finalidade proposta

Adaptar a Base Admin ao cliente e validar as capacidades aplicáveis, incluindo Chatbot/Base de Conhecimento quando contratado.

Subfluxos

1. inventário de módulos;
2. aplicabilidade;
3. limpeza de conteúdo demo;
4. Blog;
5. formulários/CTAs/Leads;
6. Chat/WhatsApp;
7. autenticação/perfis;
8. Chatbot/Base de Conhecimento quando aplicável.

Bons candidatos à automação

• inventariar módulos presentes;
• comparar com escopo;
• identificar conteúdo demo;
• configurar dados/conteúdo/destinos aprovados;
• executar testes funcionais mínimos;
• sincronizar conhecimento validado;
• testar Lead/conversa/handoff;
• registrar pendências.

Julgamento humano obrigatório

• módulo/capacidade contratada;
• nova funcionalidade;
• conflito factual;
• mudança de permissão;
• conteúdo sensível;
• alteração relevante da arquitetura da capacidade.

Acessos

• Admin/navegador;
• Lovable;
• ambiente local/repo quando necessário;
• Supabase/Lovable Cloud de forma condicional;
• arquivos de conteúdo.

Risco

Alto.

Motivo do agrupamento

O Chatbot é uma capacidade condicional da mesma camada operacional e já é acionado pelo SOP-005. Criar uma Skill completamente independente desde o início aumentaria fragmentação. Se os pilotos futuros mostrarem que segurança, conteúdo e tooling justificam isolamento, a SK-04 pode ser desmembrada depois sem alterar a documentação humana.

35. SK-05 — Portar Capacidade da Base para Legado

Tipo: executora especializada
Origem principal: SOP-007
Manual proprietário: Manual 4
Manuais relacionados: 5, 6 e 8

Finalidade proposta

Comparar Base atual × projeto existente, identificar delta real e portar somente a capacidade aprovada, preservando comportamentos locais melhores.

Bons candidatos à automação

• inventariar origem/destino;
• gerar matriz de equivalências;
• separar paridade de feature nova;
• mapear dependências;
• identificar incompatibilidades;
• produzir plano de portabilidade;
• implementar delta autorizado;
• executar regressão dirigida.

Julgamento humano obrigatório

• escopo da portabilidade;
• feature nova;
• comportamento local a preservar;
• risco de dados;
• migration destrutiva;
• alteração arquitetural ampla.

Acessos

• GitHub/repo;
• ambiente local;
• navegador;
• Lovable quando aplicável;
• backend/banco quando necessário.

Risco

Muito alto.

Recomendação

Não usar como primeiro piloto.

36. SK-06 — Executar QA WSS

Tipo: validadora
Origem principal: SOP-008
Manual proprietário: Manual 6
Manuais relacionados: 3, 4, 7 e 8

Finalidade proposta

Executar QA visual, responsivo e funcional proporcional ao risco da rodada e produzir evidência estruturada de resultado.

Bons candidatos à automação

• conferir versão/ambiente;
• percorrer Sitemap;
• executar checklist por página;
• testar rotas/links/CTAs;
• testar formulários e chegada de Lead;
• testar Chat/Chatbot quando aplicável;
• testar Admin/perfis quando aplicável;
• registrar evidências;
• classificar bug para SK-07;
• executar regressão dirigida.

Julgamento humano obrigatório

• qualidade visual final;
• suficiência da rodada;
• severidade/prioridade quando não objetiva;
• aceite final de experiência.

Acessos

• navegador;
• Admin;
• arquivos/Sitemap;
• repo em leitura;
• ambientes publicados quando aplicável.

Risco

Médio.

Regra arquitetural

A Skill deve preferir validação e evidência. Correções não triviais devem ser encaminhadas para SK-07 ou para a Skill executora proprietária da área.

37. SK-07 — Diagnosticar e Corrigir Bug por Camada

Tipo: executora especializada
Origem principal: SOP-009
Manual proprietário: Manual 6
Manuais relacionados: 4, 5, 7 e 8

Finalidade proposta

Reproduzir sintoma, localizar camada, formular hipótese, corrigir apenas o delta necessário e revalidar.

Bons candidatos à automação

• reprodução guiada;
• captura de console/network;
• classificação por camada;
• leitura localizada de código;
• comparação antes/depois;
• hipótese testável;
• correção localizada;
• regressão proporcional.

Julgamento humano obrigatório

• correção ampla;
• risco de dados;
• auth/permissão sensível;
• migration destrutiva;
• rollback;
• arquitetura;
• produção comprometida.

Acessos

Varia por camada:

• navegador/DevTools;
• GitHub/repo;
• Lovable;
• Supabase/Lovable Cloud;
• produção de forma condicional.

Risco

Alto a muito alto.

Motivo para não agrupar com QA

QA identifica e evidencia; debugging pode editar código/backend. A separação preserva a fronteira de privilégio e torna o handoff explícito.

38. SK-08 — Tratar Auditoria SEO/AEO/GEO

Tipo: validadora/executora controlada
Origem principal: SOP-010
Manual proprietário: Manual 6
Manuais relacionados: 3, 5, 7 e 8
Autoridade normativa obrigatória: WSS_Padrao_Tecnico_Operacional_SEO_AEO_GEO_v0.2_FINAL e anexos aplicáveis

Finalidade proposta

Confrontar relatório/auditoria com o estado atual, classificar cada achado e corrigir somente o delta real conforme a norma vigente.

Bons candidatos à automação

• registrar origem/data/versão do relatório;
• reproduzir achados;
• classificar presente / parcial / resolvido / não reproduzido;
• comparar UI × HTML inicial;
• inspecionar metadados/canonical/schema/sitemap/robots;
• verificar requisitos normativos aplicáveis;
• produzir delta rastreável;
• encaminhar bug localizado à SK-07;
• quando a execução ocorrer dentro de V0–V5, produzir o resultado formal conforme o Protocolo de Validação e o Template de Relatório aplicável, sem substituir o SOP-010.

Guardrails de governança — G-SK-01 e G-SK-02

G-SK-01 — SOP-010 × Protocolo

Quando a SK-08 operar dentro de um checkpoint V0–V5:

• o SOP-010 continua sendo o procedimento de tratamento/investigação da auditoria;
• o Protocolo de Validação governa o checkpoint;
• o resultado formal do checkpoint usa o Template de Relatório aplicável.

Fora de um checkpoint formal V0–V5, a SK-08 mantém a função própria derivada do SOP-010.

G-SK-02 — Duas taxonomias

A Skill deve preservar duas classificações independentes:

• estado do achado: presente / parcial / resolvido / não reproduzido;
• status do checkpoint: PASS, FAIL-B, FAIL-NB, N/A, NV, PD, OBS.

Uma taxonomia não substitui a outra.

Julgamento humano obrigatório

• conteúdo factual/YMYL;
• interpretação de exceção;
• mudança normativa;
• decisão estratégica ainda aberta;
• correção de alto impacto arquitetural.

Acessos

• arquivos/norma;
• navegador;
• repo;
• Lovable de forma condicional;
• ambiente publicado.

Risco

Médio a alto.

39. SK-09 — Processar Rodada de Feedback e ajustes.md

Tipo: orquestradora
Origem principal: SOP-011
Manual proprietário: Manual 6
Manuais relacionados: 2, 3, 5, 7 e 8

Finalidade proposta

Transformar feedback disperso em itens claros, classificar cada pedido, manter ajustes.md e encaminhar cada item à Skill proprietária correta.

Bons candidatos à automação

• reunir mensagens/anexos;
• identificar versão referenciada;
• deduplicar pedidos;
• dividir pedidos independentes;
• classificar ajuste/ambiguidade/contradição/escopo/bug/conteúdo pendente;
• atualizar ajustes.md;
• manter bloqueados separados;
• encaminhar item:
• visual → SK-03;
• operacional → SK-04;
• bug → SK-07;
• SEO → SK-08;
• QA → SK-06;
• revisar lista completa ao final.

Julgamento humano obrigatório

• pedido ambíguo não resolvível por evidência;
• contradição;
• possível mudança de escopo;
• prioridade com impacto comercial/operacional;
• fato pendente.

Acessos

• arquivos/mensagens;
• escrita em ajustes.md;
• acesso às demais ferramentas somente quando a execução for delegada.

Risco

Baixo a médio no modo orquestrador.

Observação arquitetural

Esta Skill não precisa possuir todos os privilégios das Skills que ela aciona. Isso é uma vantagem central do desenho modular.

40. SK-10 — Preparar Publicação, Validar Produção e Entregar Admin

Tipo: orquestradora de alto privilégio
Origem principal: SOP-012
Manual proprietário: Manual 7
Manuais relacionados: 4, 5, 6 e 8

Finalidade proposta

Conduzir a etapa final desde a prontidão de publicação até QA pós-produção, limpeza de dados de teste, acesso do cliente e transição para pós-entrega.

Bons candidatos à automação

• verificar pré-condições;
• conferir fluxos essenciais;
• conferir ajustes.md;
• confirmar auditorias aplicáveis;
• preparar publicação temporária;
• executar revalidação proporcional;
• identificar cenário de domínio;
• executar checklist pós-publicação;
• detectar falha localizada × falha geral;
• registrar entrega;
• orientar limpeza de dados de teste e criação de acesso;
• quando o Protocolo SEO/AEO/GEO for aplicável, coordenar a passagem publicação → V4 → estabilização → V5, encaminhando validações especializadas às Skills/camadas apropriadas.

Integração de governança SEO/AEO/GEO — SK-HMD-03

A SK-10 absorve SK-HMD-03 como capacidade condicional de orquestração, sem criação de nova Skill e sem duplicar o SOP-012.

Quando o Protocolo for aplicável:

publicação em produção
→ V4 — Pós-Publicação Imediata
→ estabilização
→ V5 — Estabilização e Baseline

A SK-10 coordena a transição e pode acionar/encaminhar as verificações especializadas necessárias, preservando o Protocolo como autoridade dos checkpoints.

Guardrail de pós-entrega — G-SK-03

V5 — Estabilização e Baseline representa baseline técnico. Sua execução não cria nem presume contratação de monitoramento ou otimização recorrente.

A decisão entrega padrão × serviço recorrente permanece reservada à governança estratégica/comercial.

Julgamento humano obrigatório

• aprovação para publicar;
• domínio/acesso quando depende de terceiros;
• rollback relevante;
• produção comprometida;
• pendência bloqueante;
• decisão comercial de recorrência.

Acessos

• navegador;
• Lovable;
• Admin;
• produção;
• domínio/DNS conforme papel autorizado;
• backend de forma condicional.

Risco

Muito alto.

Recomendação

Deve ser uma das últimas Skills a ser implementada e validada.

PARTE IX — MATRIZ SKILL → MANUAIS/SOPs DE ORIGEM

41. Matriz de rastreabilidade

Regra transversal

• Manual 1 funciona como guardrail de toolchain e fronteira do método;
• Manual 8 funciona como guardrail de boas práticas, anti-patterns e limites de generalização;
• nenhum dos dois precisa ser duplicado integralmente em cada Skill;
• cada Skill deve carregar apenas os trechos/regras relevantes ao seu escopo;
• o WSS_Registro_Decisao_Handoff_SEO_AEO_GEO_Metodo_v0.1.md funciona como entrada de governança para as integrações SK-HMD e guardrails G-SK, sem se tornar Manual, SOP, norma técnica ou Skill.

PARTE X — PILOTOS RECOMENDADOS

42. Critério de escolha dos pilotos

Os primeiros pilotos devem testar a arquitetura sem começar pelos maiores riscos.

Critérios usados:

1. alta recorrência;
2. procedimento claro;
3. evidência fácil de avaliar;
4. baixo risco de produção;
5. capacidade de testar gates humanos;
6. progressão gradual de ferramentas.

43. Piloto 1 — SK-01 Contextualizar Novo Projeto WSS

Prioridade

1ª

Por que começar aqui

• usa principalmente arquivos;
• não exige escrita em Lovable/GitHub;
• possui entradas e saídas claras;
• testa a capacidade de respeitar precedência e contradição;
• testa não invenção de fatos;
• testa decisão humana necessária;
• produz um artefato objetivo: resumo + prompt master + lacunas;
• permite testar a resolução da autoridade SEO/AEO/GEO vigente e o handoff condicional para V0 sem liberar escrita técnica.

O que o piloto deve provar

• consegue identificar materiais presentes/ausentes;
• não inventa documento ausente;
• detecta conflito;
• sabe parar para decisão humana;
• produz prompt master coerente com as fontes;
• em cenário SEO/AEO/GEO aplicável, resolve as fontes canônicas vigentes, contextualiza os requisitos e sinaliza corretamente a passagem por V0;
• não executa V0 como se fosse proprietária do Protocolo;
• não inicia desenvolvimento.

Risco

Baixo–médio.

44. Piloto 2 — SK-09 Processar Rodada de Feedback e ajustes.md

Prioridade

2ª

Por que é um bom segundo piloto

• atividade recorrente e concreta;
• forte ganho na redução de perda de pedidos;
• excelente teste de classificação e roteamento;
• permite testar uma Skill orquestradora sem conceder privilégios amplos;
• possui vários gates humanos explicitamente documentados.

Escopo recomendado do piloto

No primeiro piloto, a Skill deve:

• reunir;
• consolidar;
• classificar;
• atualizar ajustes.md;
• sugerir/registrar encaminhamento;

sem receber autorização autônoma para implementar todas as alterações.

Isso testa o cérebro da orquestração antes de liberar mãos de execução.

O que o piloto deve provar

• deduplicação correta;
• separação de itens;
• classificação de ambiguidade/escopo/bug;
• bloqueio correto de decisões humanas;
• manutenção coerente do ajustes.md;
• roteamento para a Skill futura correta.

Risco

Baixo–médio.

45. Piloto 3 — SK-06 Executar QA WSS

Prioridade

3ª

Por que é o terceiro piloto

Ele adiciona uma nova classe de capacidade:

• inspeção real do site;
• uso de navegador;
• validação de experiência;
• evidência funcional;
• transição para debugging sem correção automática.

É um bom teste da arquitetura antes de liberar Skills executoras de alto privilégio.

Escopo recomendado do piloto

• QA visual;
• navegação/rotas;
• responsividade;
• fluxos funcionais seguros;
• registro de evidência;
• classificação/encaminhamento de bugs.

Correções não triviais devem permanecer fora do piloto e ser encaminhadas para futura SK-07.

O que o piloto deve provar

• consegue seguir Sitemap;
• diferencia módulo aplicável de não aplicável;
• registra achados reproduzíveis;
• não trata aparência como prova de funcionamento ponta a ponta;
• não confunde QA com debugging;
• sabe encerrar com relatório/evidência.

Risco

Médio.

46. Skills que não devem estar entre os primeiros pilotos

SK-02 Inicialização técnica

Exige escrita em Lovable/GitHub e criação de estado técnico.

SK-03 Construção visual

Exige julgamento visual elevado e alterações amplas de código.

SK-04 Camada operacional

Pode atingir banco, auth, permissões, conteúdo e integrações.

SK-05 Portabilidade legado

Tem o maior risco de incompatibilidade, dados e regressão.

SK-07 Debugging

A correção pode escalar rapidamente de código local para backend/produção.

SK-08 Auditoria SEO/AEO/GEO

Exige carregamento disciplinado de autoridade normativa especializada e deve vir depois que a arquitetura de fontes estiver comprovada.

SK-10 Publicação e entrega

Possui acesso a produção/domínio e deve ser uma das últimas a receber automação operacional.

PARTE XI — ORDEM RECOMENDADA DE EVOLUÇÃO APÓS O GATE

47. Sequência sugerida

Apenas se a Coordenação aprovar esta arquitetura, a evolução recomendada é:

Fase A
→ definir formato comum de Skill, gates e evidências

Fase B
→ Piloto SK-01

Fase C
→ Piloto SK-09

Fase D
→ Piloto SK-06

Gate de avaliação dos pilotos

Fase E
→ SK-07 Debugging
→ SK-08 SEO/AEO/GEO

Fase F
→ SK-03 Construção visual
→ SK-04 Camada operacional

Fase G
→ SK-02 Inicialização técnica
→ SK-05 Portabilidade legado

Fase H
→ SK-10 Publicação e entrega

A ordem não é baseada apenas no fluxo cronológico do projeto. Ela é baseada em risco de automação e privilégio.

PARTE XII — DECISÕES PARA O GATE DA COORDENAÇÃO

48. Pontos que precisam de aprovação antes de criar qualquer Skill

Normalização de identificadores na v0.2: os códigos de decisão do Gate foram renomeados de G-SK-* para GATE-SK-*. Os identificadores G-SK-01, G-SK-02 e G-SK-03 ficam reservados aos guardrails provenientes do handoff SEO/AEO/GEO. O conteúdo das decisões de Gate não foi alterado por essa renomeação.

GATE-SK-01 — Quantidade

Aprovar ou ajustar a proposta de 10 Skills principais.

GATE-SK-02 — Agrupamentos

Aprovar:

• SOP-003 + SOP-004 → uma Skill;
• SOP-005 + SOP-006 → uma Skill com subfluxo condicional de Chatbot.

GATE-SK-03 — Separações por privilégio

Ratificar que:

• contextualização fica separada de inicialização técnica;
• QA fica separado de debugging;
• publicação fica isolada como Skill de alto privilégio.

GATE-SK-04 — Pilotos

Aprovar ou ajustar os três pilotos:

1. SK-01 Contextualização;
2. SK-09 Feedback/ajustes.md;
3. SK-06 QA.

GATE-SK-05 — Princípio de menor privilégio

Ratificar que cada Skill só recebe os acessos necessários à sua função.

GATE-SK-06 — Gates humanos

Ratificar que Skills devem parar/escalar, e não decidir autonomamente, em:

• contradição material;
• mudança de escopo;
• fato sensível;
• risco de dados/auth/arquitetura;
• publicação/produção.

GATE-SK-07 — Arquitetura de fontes

Ratificar que:

• Manuais/SOPs continuam canônicos;
• Skills são derivadas e subordinadas;
• Manual 1 e Manual 8 funcionam como guardrails transversais;
• normas técnicas permanecem autoridades externas próprias quando aplicáveis;
• o registro de handoff SEO/AEO/GEO é entrada de governança da camada de Skills, não substitui a coleção nem a norma e não gera Skill automaticamente.

PARTE XIII — CONCLUSÃO

49. Recomendação final

A coleção v1.1 FINAL já possui estrutura suficiente para derivar Skills sem reabrir a documentação humana.

A melhor arquitetura inicial não é converter cada SOP em uma Skill, nem criar uma única Skill monolítica de desenvolvimento.

A recomendação é:

10 Skills principais, modulares por intenção, risco e privilégio, com 3 pilotos iniciais de baixa/média exposição operacional.

Os agrupamentos mais naturais são:

SOP-003 + SOP-004
→ Construção Visual

SOP-005 + SOP-006
→ Camada Operacional

As separações mais importantes são:

Contextualização ≠ Inicialização técnica
QA ≠ Debugging
Validação ≠ Publicação

A camada de Skills deve ser tratada como projeção executável e subordinada da documentação canônica, nunca como substituta ou nova autoridade documental.

A incorporação do handoff SEO/AEO/GEO não altera a recomendação de 10 Skills, os agrupamentos ou a prioridade dos pilotos. Ela ajusta escopo e orquestração de SK-01, SK-08 e SK-10, introduz o checkpoint condicional V0 entre SK-01 e SK-02 quando aplicável e adiciona os guardrails G-SK-01 a G-SK-03.

50. Estado desta etapa

Análise dos 8 Manuais v1.1 FINAL    → concluída
Análise dos 12 SOPs v1.1 FINAL      → concluída
Entrada HMD SEO/AEO/GEO              → incorporada na v0.2
Mapa de candidaturas                → concluído
Arquitetura proposta                → concluída
Quantidade recomendada              → 10 Skills
Pilotos recomendados                → SK-01, SK-09, SK-06
Skills criadas                      → 0
Documentação canônica alterada      → 0
Processo Sites WSS alterado         → 0
Status                              → AGUARDANDO GATE DA COORDENAÇÃO

FIM — PARAR AQUI ATÉ APROVAÇÃO DA COORDENAÇÃO