Sistema de redacção modular — guia de manutenção

Versão: 1.0.0

1. Objectivo

Permitir que equipas Legal, Produto e Engineering alterem uma cláusula, uma política ou um anexo sem reescrita total, mantendo coerência e rastreabilidade.

2. Regras de escrita

2.1. IDs estáveis

Cada documento tem document_id imutável (ex.: PLAY258-TGU). As versões mudam; o ID não.

2.2. Referências cruzadas

Usar links relativos entre ficheiros em docs/legal/ e, na publicação web, URLs canónicas.

Modelo: «Nos termos da Política de Privacidade (PLAY258-PP) na versão então vigente…»

2.3. Evitar duplicação

2.4. Blocos opcionais

Usar secções claramente tituladas «Aplica-se apenas a Moçambique» (ou outra jurisdição concreta) para cláusulas condicionais sem misturar com o núcleo.

2.5. Placeholders

Manter lista única de placeholders no 00-RESUMO-EXECUTIVO.md ou em ficheiro PLACEHOLDERS.md futuro; grep no CI para bloquear release sem preenchimento crítico.

3. Fluxo de alteração (sugerido)

  1. Ticket com: documento(s), tipo de mudança (matriz), públicos.
  2. Draft em branch legal/....
  3. Revisão Legal + DPO + Product (se UX de consentimento).
  4. Bump de versão semântica + entrada em CHANGELOG.md.
  5. Deploy documentação estática + notificações conforme matriz.
  6. Feature flag de «aceite obrigatório» na app se necessário.

4. Coerência terminológica

Glossário fixo: Operador, Serviço, Conta, Conteúdo do Utilizador, Processador de pagamentos, nomes dos quatro públicos.

5. Traduções

Ficheiros en/PLAY258-TGU.md espelhados; mesma estrutura de secções; version sincronizada; effective_date igual.

6. Testes de produto

Checklist antes de publicar:

Guia interno.