Arquitetura da Documentação

Este arquivo define como o cânone de EVRYM é organizado, escrito, ligado e mantido.

A documentação funciona como uma rede de páginas. Cada indivíduo, lugar, evento, povo, entidade, regra ou conceito reutilizado possui um destino estável; outros textos apontam para esse destino em vez de repetir sua definição.

1. fonte oficial

Markdown (.md) é a fonte oficial do cânone.
DOCX, PDF, ZIP, apresentações e outros formatos são exportações ou snapshots.
Um fato só é considerado cânone vigente quando estiver em canon.
previous-sources, previous-versions e work nunca tornam um conteúdo canônico por simples presença.

2. estrutura do Drive

Evrym/
├── canon/
├── previous-sources/
├── previous-versions/
├── exports/
└── work/
    ├── migration/
    ├── merge/
    ├── decisions/
    └── generated/

canon contém apenas a fonte vigente. previous-sources guarda rascunhos e versões de desenvolvimento que podem inspirar ou explicar decisões. previous-versions guarda snapshots anteriormente oficiais. exports recebe artefatos derivados. work recebe migrações, merges, decisões em aberto e arquivos gerados automaticamente.

3. estrutura do cânone

canon/
├── index.md
├── architecture.md
├── cosmology/
├── history/
├── peoples/
├── world/
├── entities/
├── conditions/
├── magic/
├── society/
├── tower/
└── rules/

Pastas e nomes técnicos são em inglês; o texto do cânone pode permanecer em português e usar os nomes próprios do mundo.

4. nomes técnicos

Nomes de arquivos devem ser:

em inglês;
minúsculos;
curtos e estáveis;
uma palavra quando possível;
sem espaços e sem _;
com hífen (-) quando possuírem mais de uma palavra.

Exemplos:

war.md
ether.md
void.md
great-rupture.md
central-continent.md
eastern-rift.md
first-battle.md
first-seal.md

O nome técnico não precisa acompanhar o nome ficcional. central-continent.md pode continuar estável mesmo que o Continente Central receba posteriormente um nome próprio.

5. identidade e aliases

Cada página canônica começa com metadados mínimos:

---
id: central-continent
type: place
name: Nome Canônico
aliases:
  - Continente Central
status: canon
completeness: partial
perspective: author
---

id é técnico e estável.
name é o nome principal exibido.
aliases reúne nomes alternativos, títulos, nomes históricos e designações genéricas.
status informa validade canônica: canon para conteúdo vigente e deprecated somente para páginas preservadas por compatibilidade histórica.
completeness informa cobertura editorial: complete quando a página já cobre o núcleo necessário e partial quando fatos nela são válidos, mas a página ainda pode receber conteúdo. partial não torna os fatos provisórios.
perspective distingue verdade autoral (author) de crença/documento interno do mundo (inworld).

6. páginas próprias

Devem tender a possuir página própria quando forem reutilizados ou tiverem identidade própria:

indivíduos;
lugares;
eventos;
povos e linhagens;
facções;
entidades singulares;
estruturas ou artefatos únicos;
condições e fenômenos centrais;
conceitos cosmológicos.

Um detalhe pequeno pode começar como seção e ser promovido a arquivo quando passar a ser referenciado por vários textos.

7. links nominais

Todo nome ou termo canônico pode e preferencialmente deve ser linkado em todas as ocorrências relevantes.

A [Energia](cosmology/energy.md) entrou em conflito com
[Forma](cosmology/form.md) e [Fluxo](cosmology/flux.md).

Nomes alternativos apontam para o mesmo arquivo:

[Continente Central](world/central-continent.md)
[Nome próprio futuro](world/central-continent.md)

8. referências sobrescritas

Quando duas afirmações possuem relação causal, histórica, comparativa ou conceitual que não cabe em um nome linkado, usa-se uma referência sobrescrita que é também um link.

A intervenção geográfica interrompeu corredores militares, mas isolou
populações que não participavam diretamente do conflito
[ᵃ](history/great-rupture.md).

As letras seguem ᵃ, ᵇ, ᶜ, ᵈ e reiniciam a cada parágrafo. Uma referência sobrescrita não deve repetir um link nominal que já explica sozinho a relação.

9. dono do conceito

Cada fato possui um dono. Outros arquivos podem resumir o mínimo necessário e apontar para ele, mas não criar uma segunda definição independente.

Exemplos:

conceito	dono
natureza do Vazio	`cosmology/void.md`
Grande Ruptura	`history/great-rupture.md`
Fenda do Oriente	`world/eastern-rift.md`
Tratado de Aion	`history/treaty.md`
Torre-Prisão	`tower/tower.md`

10. regras estáveis

Regras universais mantêm identificadores permanentes como R1, R2, R56.

A definição da regra mora no arquivo dono do conceito, não em uma segunda cópia. rules/index.md é apenas um índice para essas âncoras.

<a id="example-rule"></a>
### RXX — exemplo de regra

A ruptura do primeiro grande selo não provoca libertação geral dos aprisionados.

11. verdade autoral e crença interna

Uma afirmação pode ser canônica como crença sem ser verdadeira sobre o universo.

perspective: author registra a estrutura verdadeira conhecida pelo autor.

perspective: inworld registra mito, propaganda, religião, tradição, documento ou interpretação interna.

12. aberto não é cânone

Questões que o autor ainda não decidiu ficam em work/decisions e não em canon.

O cânone pode registrar que um fato é desconhecido pelos habitantes; não deve registrar como fato que o autor ainda não decidiu algo.

13. referências bidirecionais

Relações fortes devem ser navegáveis nos dois sentidos sempre que isso ajudar a leitura, sem duplicar a definição. O dono continua único.

14. alteração de um fato

Ao alterar um fato canônico:

editar primeiro o arquivo dono;
localizar páginas que o referenciam;
revisar consequências;
atualizar links, aliases e referências contextuais;
validar a rede;
registrar a decisão de merge quando a mudança vier de fonte antiga.

15. validação

Antes de uma consolidação:

nenhum link canônico pode estar quebrado;
links do cânone não devem depender de work ou previous-sources;
arquivos gerados não devem ser editados como fonte;
fatos abertos não podem ser promovidos silenciosamente;
páginas vazias devem ser marcadas como incompletas ou retiradas do cânone.

Esse é o contrato documental vigente de EVRYM.

R46

Nenhum conceito deve existir apenas para explicar muitos outros; cada regra deve possuir responsabilidade limitada e clara.

histórico editorial

work/history/decisions.md registra decisões aceitas do projeto.

Esse histórico não é lore e não deve ser referenciado pelo cânone. Sua função é permitir reconstruir por que uma regra existe, quando foi consolidada e qual decisão posterior a substituiu.

Uma decisão removida do cânone não deve ser apagada do histórico: deve ser marcada como superseded.