Wiki Schema

Contrato operacional do vault do Oningume Guneta.

Camadas

• raw/: evidências imutáveis. Nunca reescrever uma fonte existente.
• wiki/: conhecimento compilado e navegável. Atualizar páginas existentes antes de criar duplicatas.
• schema/: contrato operacional e registros canônicos.
• templates/: modelos para páginas novas.

O framework de referência completo está em llm-wiki-karpathy.

Tipos de página

Tipo	Local	Campos obrigatórios
player	wiki/players/<player-slug>.md	type, display_name, player_slug, riot_id, riot_id_aliases, <role>_skill/<role>_confidence/<role>_matches para `top
match	wiki/matches/<match-id>.md	type, match_id, analyzed, date, patch, queue, result, raw_sources, players, teams, last_reviewed
team	wiki/teams/<sorted-player-slugs>.md	type, team_slug, players, matches_observed, win, loss, last_reviewed
matchup	wiki/matchups/<stable-slug>.md	type, matchup_slug, scope, matches_observed, last_reviewed
synthesis	wiki/syntheses/<stable-slug>.md	type, synthesis_slug, scope, last_reviewed
report	wiki/reports/<stable-slug>.md	type, report_slug, scope, last_reviewed
riot_api_reference	wiki/riot-api/<stable-slug>.md	type, reference_slug, scope, sources, source_checked_at, last_reviewed
raw_match_report	raw/matches/<match-id>/report.md	type, match_id, recorded_at, source_kind

Usar TBD para identificadores técnicos desconhecidos. Usar null para rating sem evidência.

Novas páginas de partida começam com analyzed: false. Alterar para true
somente depois de compilar o payload completo, revisar as evidências e preencher
a análise estruturada.

Identidade de players

O registro canônico de players é PLAYER_REGISTRY.

• player_slug é legível, estável, minúsculo, sem acentos e nunca deve ser reutilizado.
• Riot ID usa game_name e tag_line.
• Não usar summonerName como identidade principal.
• puuid e summoner_id entram apenas quando obtidos de fonte confiável.

Times canônicos

Duplas, trios, quartetos e composições completas vivem em wiki/teams/.

• Ordenar player_slug alfabeticamente.
• Separar slugs com hífen.
• Não usar prefixos como team-, duo- ou trio-.
• A mesma composição sempre resolve para o mesmo arquivo.

Exemplo: fuji, goia, dab vira teams/dab-fuji-goia.md.

Wikilinks

Usar links internos no formato wiki sempre que uma entidade relacionada existir ou merecer uma página própria:

• players;
• partidas;
• times;
• matchups;
• champions;
• sínteses;
• relatórios;
• fontes brutas.

Evitar texto simples repetido quando um link puder conectar a evidência ao conhecimento compilado.

Tipos de evidência

Toda conclusão relevante deve ser distinguida:

Tipo	Uso
observation	Fato verificável em fonte bruta, placar, replay, screenshot ou API persistida.
player_report	Relato de um player ou do grupo; registrar autoria e contexto quando disponíveis.
hypothesis	Interpretação do agente que ainda exige validação por mais evidências.

Não promover player_report ou hypothesis a fato objetivo sem evidência adicional.

Confiança

Usar escala numérica de 0.00 a 1.00:

Intervalo	Interpretação
0.00	Sem confiança ou sem evidência.
0.01 a 0.39	Sinal fraco; hipótese inicial.
0.40 a 0.69	Evidência parcial ou padrão ainda limitado.
0.70 a 0.89	Padrão consistente em múltiplas evidências.
0.90 a 1.00	Evidência objetiva forte ou padrão amplamente confirmado.

Para roles de player usamos propriedades planas (Obsidian Properties não aceita objetos aninhados). Para cada role em top|jungle|mid|adc|sup:

• <role>_skill: avaliação de habilidade (0 a 1); null enquanto não houver evidência suficiente.
• <role>_confidence: confiança na avaliação (0 a 1).
• <role>_matches: volume de partidas relevantes observadas naquela role.

Exemplo: adc_skill: 0.62, adc_confidence: 0.55, adc_matches: 7.

Seções geradas

Quando uma página tiver os marcadores abaixo, atualizar somente o conteúdo entre eles:

<!-- BEGIN GENERATED -->
<!-- END GENERATED -->

Preservar qualquer anotação fora desses marcadores, especialmente ## Notas manuais.

Checklist de ingestão

1. Confirmar que a fonte foi persistida em raw/ sem sobrescrever arquivos existentes.
2. Registrar origem, data e patch quando aplicáveis.
3. Validar os players pelo PLAYER_REGISTRY.
4. Criar ou atualizar a página compilada da partida.
5. Separar observation, player_report e hypothesis.
6. Atualizar páginas afetadas de players, times, matchups e sínteses.
7. Citar fontes raw com wikilinks.
8. Acrescentar uma entrada append-only em log.

Quando atualizar páginas

Página	Atualizar quando
Player	Nova evidência altera role, pool, força, fraqueza, hipótese ou confiança.
Team	Uma composição reaparece ou surge aprendizado reutilizável sobre sua sinergia.
Matchup	Surge aprendizado reutilizável; não criar página vazia para toda combinação possível.
Synthesis	Uma nova evidência muda prioridade, padrão recorrente ou lacuna relevante.
Report	Existe uma entrega específica para revisão ou decisão do time.

Checklist de lint

• Nenhuma fonte existente em raw/ foi reescrita.
• Todo player possui player_slug único e frontmatter obrigatório.
• Todo time usa slugs válidos em ordem alfabética.
• Ratings não nulos citam evidências e possuem confiança.
• Conclusões distinguem observation, player_report e hypothesis.
• Wikilinks importantes resolvem para páginas existentes ou pendências explícitas.
• Páginas compiladas citam fontes raw relevantes.
• Seções manuais foram preservadas.
• log recebeu entrada para mudanças relevantes.

Escopo atual

A fundação não implementa Riot API, credenciais, triggers, agendamentos ou ratings automáticos. Essas etapas entram somente após validação manual do schema.