Política de Alterações, Versionamento e Notificações — Play258
ID: PLAY258-CHANGE | Versão: 1.0.0 | Vigência: 05-04-2026
Audiência base: all (com notificações segmentadas conforme §5)
1. Objectivo
Definir como o Operador altera documentos legais e de política, como versiona, mantém histórico, classifica mudanças, determina novo aceite vs simples aviso, e notifica cada público (Artistas, Rádios, Ouvintes, Organizações) de forma proporcional — inspirado em práticas de grandes plataformas tecnológicas, adaptado ao ecossistema Play258.
2. Documentos abrangidos
Todos os ficheiros listados no README legal, incluindo TGUs, Privacidade, Cookies, PI, Anexos A–D, Moderação, Denúncias, Retenção.
3. Versionamento
3.1. Formato semântico por documento
MAJOR.MINOR.PATCH
| Incremento | Quando |
|---|---|
| MAJOR | Alteração material que reduz direitos, aumenta obrigações substancialmente, muda objecto do contrato, ou exige novo consentimento legal. |
| MINOR | Acréscimo de secção relevante, nova finalidade de dados, novo subcontratante crítico, ou mudança operacional significativa. |
| PATCH | Correcções editoriais, clarificações sem efeito jurídico novo, ajustes de links, typos, tradução. |
3.2. ID de pacote legal (release coordenado)
Para alinhar comunicação de marketing e produto: PLAY258-LEGAL-YYYY-MM + tag Git opcional (legal/v1.0.0).
3.3. Histórico obrigatório
- Changelog público (§8) em https://play258.com/legal/changelog.
- Repositório: ficheiros em
docs/legal/com histórico Git. - Registo interno: ticket de release com: documentos alterados, classificação, públicos afectados, data de vigência, necessidade de aceite.
4. Classificação de alterações
4.1. Material
Afecta direitos/deveres essenciais (ex.: novos usos invasivos de dados, partilha com novas categorias de destinatários, limitação de responsabilidade mais restritiva, mudança de foro/le aplicável quando permitido, novas taxas obrigatórias).
- Novo aceite: frequentemente sim (onde legalmente exigido ou como boa prática contratual).
- Notificação: todos os públicos afectados.
4.2. Relevante (não material)
Afecta operações ou privacidade de forma moderada (ex.: novo cookie analytics não estritamente necessário, prazo de retenção alargado dentro de intervalo já comunicado, novo canal de suporte).
- Novo aceite: conforme lei (consentimento) ou aviso com oposição.
- Notificação: públicos afectados + aviso geral no site.
4.3. Regulatória
Adequação a lei nova ou autoridade.
- Novo aceite: se a lei exigir.
- Notificação: ampla; pode haver prazo reduzido (§7.3).
4.4. Editorial / técnica
Clarificação, reorganização, correcção linguística, actualização de URLs.
- Novo aceite: tipicamente não.
- Notificação: publicação no changelog; opcionalmente banner leve.
5. Quem notificar (segmentação)
| Âmbito da alteração | Público a notificar |
|---|---|
| Apenas fluxo de Artista (ex.: reporting de obras) | Artistas com Conta activa |
| Apenas Rádio (ex.: política de sync playout) | Titulares de Conta Rádio + admins designados |
| Apenas Ouvinte (ex.: SMS transaccional) | Opcional: aviso geral + utilizadores com Conta; para sem conta, política pública pode bastar salvo lei |
| Apenas Organização (ex.: formato de IO) | Utilizadores Conta Organização |
| Privacidade (bases/finalidades novas) | Todos os titulares afectados ou todos os utilizadores registados + banner |
| TGUs gerais | Todos os utilizadores registados + visitantes via banner |
Regra de ouro: notificar o conjunto mínimo necessário para compreensão e compliance, sem omitir quem perde um direito ou ganha uma obrigação nova.
6. Canais de notificação (por prioridade)
- Email para endereço verificado da Conta.
- Notificação in-app / painel persistente até reconhecimento (para alterações que exigem leitura).
- Push (app móvel) como reforço, não substituto único de prova.
- SMS apenas para alterações urgentes de serviço ou legais curtas (com link).
- Banner no site e no login do playout.
- RSS / feed do changelog para transparência (opcional).
Prova de entrega: logs de email/push, timestamp de «aceite» em base de dados, ou registo de visualização no painel quando exigido.
7. Prazos
7.1. Prazo mínimo de antecedência (padrão)
- Material / relevante (contrato): mínimo 15 dias antes da vigência, salvo excepções legais.
- Regulatória urgente: conforme exigência legal ou o mais breve possível com justificação documentada.
- Editorial: imediata na publicação ou no próximo ciclo de release.
7.2. Entrada em vigor
Sempre indicada no cabeçalho do documento e no changelog (effective_date). Pode haver período de convivência de versões para APIs (deprecated) quando aplicável.
7.3. Excepções (urgência)
- risco de segurança;
- ordem judicial ou administrativa;
- cessação de subcontratante crítico;
- correcção de erro que restaura direitos dos utilizadores (pode ser imediata).
8. Modelo de changelog transparente («o que mudou»)
Cada entrada deve conter:
## [PLAY258-TGU] 1.1.0 — 2026-04-01
**Tipo:** Relevante | **Aceite requerido:** Sim (utilizadores registados)
**Afecta:** all
### Resumo para o utilizador
- Passamos a linguagem mais simples.
### Detalhe jurídico
- Secção X: ...
### O que não muda
- ...
Ficheiro sugerido: docs/legal/CHANGELOG.md (criar na primeira alteração).
9. Mecanismo de novo aceite
9.1. Interstitial no login ou bloqueio de funcionalidades críticas até aceitar ou recusar (recusa pode implicar encerramento).
9.2. Registar: user_id, document_id, version, timestamp, ip_hash (opcional), locale.
9.3. Para menores, fluxo parental se aplicável.
10. Coerência entre documentos
Alterações a um anexo não devem contradizer TGUs; se necessário, actualizar referência cruzada no mesmo release (mesmo ID de pacote).
11. Contacto
info@voneka.co.mz | dpo@voneka.co.mz
Política operacional — ajustar prazos mínimos com assessoria local.