Fonte Canônica de Habilidades e Auditoria de Game Core — V1.0

Status: norma obrigatória de integração para o ecossistema The Last Wind: Your Journey (TLW): Site, ERYON, Game Core, editores automatizados e agentes de IA.

1. Princípio de autoridade

O banco Supabase oficial do TLW é a fonte de verdade das regras e das habilidades. O catálogo de uma subclasse NÃO é equivalente a executar SELECT ... FROM public.habilidades WHERE subclasse_id = .... Esse filtro retorna apenas as habilidades cadastradas diretamente na subclasse e omite concessões por public.progressao_habilidades, inclusive habilidades provenientes de outras classes/subclasses e registros compartilhada=true.

Para descobrir todas as habilidades efetivamente oferecidas pela progressão de uma subclasse publicada, o procedimento canônico é:

SELECT public.obter_catalogo_canonico_subclasse('<slug-da-classe>','<slug-da-subclasse>');

Esta consulta retorna: contrato, status='validado', quantidades, assinatura, e habilidades[] com ID original, slug, nível de concessão efetivo, nível original da habilidade, versão, origem do vínculo (direta/progressao) e conteúdo mecânico. O resultado reconcilia o RPC oficial public.obter_classe_completa com os vínculos independentes do catálogo e lança erro em divergências: não substituir esse erro por um fallback de consulta parcial.

A função public.obter_classe_completa('<slug-da-classe>') continua sendo a leitura oficial ampla de uma classe; sua resposta distribui habilidades da subclasse entre subclasses[].habilidades e subclasses[].habilidades_compartilhadas. Quem consumir esse RPC diretamente precisa reconciliar AMBOS os conjuntos. A nova função unificada evita essa omissão. Uma habilidade compartilhada pode reaparecer em níveis de progressão distintos; distinguir concessões pelo par habilidade_id + nivel_de_concessao, sem deduplicar apenas pelo ID. Ao mesmo tempo, não executar duas vezes automaticamente um efeito porque ele aparece em uma progressão repetida: seguir sua própria regra.

2. Catálogo versus habilidades de um personagem

O catálogo por subclasse responde quais opções fazem parte da progressão oficial, não quais habilidades um personagem particular escolheu, aprendeu ou tem atualmente disponíveis. Para execução de ações de personagens, considerar fichas, escolhas, progressão efetivamente concluída, personagens_habilidades, os RPCs oficiais de personagem e as permissões de acesso. Não conceder habilidades automaticamente só porque pertencem ao catálogo de uma subclasse, salvo regra explícita (por exemplo, uma especialização recebida automaticamente se a Ultimate correta foi escolhida).

3. Validação obrigatória de Game Core / ERYON

Antes de declarar que todas as habilidades de uma subclasse foram convertidas, validadas ou implementadas no Game Core, executar a auditoria interna com acesso autorizado:

SELECT jogo.auditar_cobertura_game_core_subclasse('<slug-da-classe>','<slug-da-subclasse>');

A auditoria usa o inventário canônico, compara habilidades distintas com jogo.core_conteudo, verifica ausência, versão divergente, alteração da fonte e dependência de regra global. Retorna cobertura_completa, pendencias[], contratos_sincronizados e assinatura_catalogo. Se cobertura_completa=false, fica PROIBIDO afirmar que o Game Core da subclasse está completo, pronto para homologação total ou plenamente funcional. Corrigir cada pendência antes de declarar cobertura integral. Não inventar uma implementação baseada em uma lista parcial.

A auditoria de cobertura não substitui testes de execução, permissões, comportamento no VTT, validação de personagem, QA e testes pós-publicação. Se o Core for entregue por etapas, identificar explicitamente que a cobertura é parcial, listar as habilidades ainda não implementadas e manter o bloqueio de aceitação integral.

4. Contrato entre agentes e publicações

Todo agente de IA, ferramenta de implantação, importador de conteúdo e fluxo de criação/atualização do ERYON deve:

1. identificar os slugs de classe/subclasse no banco oficial;
2. obter e utilizar o catálogo canônico antes de planejar, listar, compilar ou homologar habilidades;
3. registrar a assinatura do catálogo e confrontar a lista planejada/compilada com a lista oficial (IDs e níveis de concessão);
4. usar dados oficiais do próprio registro original para regras e custos, sem copiar regras de habilidade semelhante;
5. distinguir claramente conteúdo compilado, parcialmente implementado, dependente do Mestre e não implementado;
6. executar a auditoria do Game Core e bloquear a alegação de cobertura completa enquanto houver pendências;
7. revalidar após mudanças de regras, progressão, conteúdo, integração ou publicação;
8. não usar GitHub, resultados de outro agente, listas manuais ou a memória de uma conversa como fonte primária que prevaleça sobre o Supabase.

5. Caso de regressão obrigatório

Brutalista (Guerreiro): conferir não somente seus registros com subclasse_id=4, mas também as concessões de progressão de Fúria (habilidade original do Bárbaro, concedida no Nível 7 do Brutalista) e O Último Ato (habilidade original do Juramento da Força, concedida no Nível 11 do Brutalista). Usar seus IDs e versões originais — nunca duplicar a habilidade como uma cópia local. A contagem é dinâmica e não deve ser fixada permanentemente em 13, embora essa seja a contagem constatada na publicação desta norma.

Também testar subclasses com habilidades compartilhadas repetidas em níveis diferentes (ex.: Avanço Mágico), preservando todas as concessões legítimas.

6. Limitações e implantação

Esta norma e os RPCs vivem no Supabase e são reutilizáveis entre sessões e agentes conectados. Contudo, o banco não controla automaticamente um agente externo que ignore este contrato ou um frontend que utilize consultas diretas. O ERYON e os demais consumidores devem integrar os novos RPCs e adicionar as respectivas validações bloqueantes ao carregamento/compilação e à homologação. Até essa integração ocorrer, a auditoria detecta a divergência, mas não impede por si só que um código externo continue consumindo dados incompletos.

Regra de segurança de implantação: não bloquear usuários atuais, revogar acessos de leitura, modificar dados permanentes de personagem nem reescrever contratos executáveis automaticamente apenas para forçar concordância. Separar diagnóstico, correção e homologação.