Arquitetura documental recomendada — Play258
Versão: 1.0.0
Relaciona-se com: README.md, 09-MODULARIDADE-E-MANUTENCAO.md
1. Princípios de desenho
- Camada geral + anexos por público: regras comuns em um núcleo único (Termos Gerais + Política de Privacidade); particularidades em anexos referenciados, evitando duplicação contraditória.
- Políticas satélite: temas transversais (cookies, moderação, denúncias, retenção) em documentos autónomos para actualização frequente sem reabrir os TGUs completos.
- Versionamento semântico por documento (
MAJOR.MINOR.PATCH) e ID de pacote global para releases coordenados. - Trilha de auditoria: changelog human-readable + registo técnico de aceitação quando a lei ou o risco o exigirem.
- Notificação segmentada: alterações que só afectam um público disparam comunicação direccionada a esse público (ver 04-POLITICA-ALTERACOES-VERSIONAMENTO.md).
2. Mapa de documentos
PLAY258-LEGAL
├── 02-TERMOS-GERAIS-USO.md ← contrato-base com todos os utilizadores
├── 03-POLITICA-PRIVACIDADE.md ← tratamento de dados (base legal, direitos)
├── POLITICA-COOKIES.md ← cookies, pixels, SDKs de analytics
├── POLITICA-CONTEUDO-E-PI.md ← uploads, DMCA-style notices, licenciamento
├── ANEXO-A-ARTISTAS.md
├── ANEXO-B-RADIOS.md
├── ANEXO-C-OUVINTES.md
├── ANEXO-D-ORGANIZACOES.md
├── 04-POLITICA-ALTERACOES-VERSIONAMENTO.md
├── 05-POLITICA-MODERACAO-SUSPENSAO.md
├── 06-POLITICA-DENUNCIAS-RECURSO.md
└── 07-POLITICA-RETENCAO-DADOS.md
3. Hierarquia normativa (em caso de conflito)
- Disposição legal imperativa da jurisdição aplicável (não derrogável por contrato).
- Acordo comercial específico assinado entre o Operador e a Rádio ou Organização (se existir).
- Anexo específico do público (Artista, Rádio, Ouvinte, Organização).
- Termos Gerais de Uso e Política de Privacidade.
- Políticas satélite (interpretação complementar).
Cláusula modelo nos TGUs: «Em caso de conflito entre estes Termos e um anexo específico do seu perfil, prevalece o anexo naquilo que for mais específico para o seu perfil, salvo disposição legal em contrário ou acordo escrito que disponha diferente.»
4. Por que esta arquitectura serve ao Play258
| Necessidade do produto | Como a arquitectura responde |
|---|---|
| Múltiplos actores (4 públicos) com obrigações distintas | Anexos por perfil + TGUs comuns |
| Pagamentos, mensagens e dados sensíveis | Privacidade central + anexo de retenção + segregação por finalidade |
| Conteúdo musical e campanhas (PI + publicidade) | Política de Conteúdo e PI separada, referenciada nos TGUs e nos anexos |
| Alterações frequentes (API, moderação, cookies) | Políticas satélite versionadas; matriz de notificação |
| App + web + playout | Mesmos documentos canónicos (URL única); deep links por canal |
| Compliance e auditoria | Changelog, classificação de alterações, registo de aceites |
5. Encadeamento obrigatório no produto
- Registo / criação de conta: link para TGUs + Privacidade + (se aplicável) Cookies; checkbox de aceitação onde a lei exigir.
- Anexos: aceite explícito ou referência inequívoca no fluxo de onboarding de Artista, Rádio, Organização; Ouvinte quando usar funcionalidades específicas (ex.: pagamentos).
- Pagamentos: resumo das condições relevantes + link para TGUs e Política de Privacidade.
- Playout / licença de software: EULA ou cláusulas de licença de software podem ser documento adicional; devem referenciar os TGUs da plataforma para dados e conta.
6. Metadados por ficheiro (recomendado)
Cada documento deve incluir no topo (YAML ou tabela):
document_id(ex.:PLAY258-TGU)versioneffective_datelast_review_dateaudiences(lista:all|artist|station|listener|organization)language
7. Responsável interno
Designar owner (Legal/Product) e revisor técnico (Segurança/DPO) para cada release do pacote.
Documento de apoio — integrar com processos internos de release.