# ADR-052 — Solicitações de serviços digitais: módulo com protocolo, não helpdesk

| Campo | Valor |
|---|---|
| **Status** | Aceito (2026-10-23) |
| **Data** | 2026-10-23 |
| **Plano de origem** | `wiki/implementation-phases/P25-sic-lgpd-governo-digital.md`, `wiki/backlog/servico-solicitacoes.md` |
| **Relacionadas** | ADR-001, ADR-009, ADR-012, ADR-017, ADR-019, ADR-021, ADR-024, ADR-028, ADR-033, ADR-035, ADR-043 |

## Contexto

O PNTP 15.3 exige pelo menos um serviço público digital real, com formulário, protocolo e
acompanhamento. O produto já tem Carta de Serviços (catálogo) e o maquinário de protocolo/prazos
da Ouvidoria/e-SIC. A tentação é contratar ou construir um helpdesk/ticket genérico; isso traz SLA
comercial, fila humana, chat e workflow configurável que o produto não precisa e que duplicaria o
protocolo existente.

Também não se pode criar um motor de workflow/BPMN: o serviço tem um fluxo simples, explícito e
fechado. A integração com protocolo único/SEI fica fora do MVP; link externo é navegação.

## Decisão

1. **Módulo, não service:** `Servicos/Solicitacoes` (token `solicitacoes`, grupo `Servicos`) é dono
   das solicitações, eventos, anexos e status. Não é helpdesk, chat, SLA comercial nem motor de
   workflow.
2. **Catálogo separado:** `Servicos/CartaServicos` (P15) continua dono de `servicos_publicos`;
   ganha `digital`, `form_schema` versionado, `prazo_dias` e `canal`. O schema é fechado
   (`string|text|email|phone|date|select|checkbox|file`) e não aceita HTML.
3. **Protocolo reutilizado:** `ProtocolGenerator`/`Deadline` (P11) são injetados. Reuso por
   composição/convenção, **sem trait** e sem cópia da máquina de protocolo.
4. **Snapshot e estado explícito:** a solicitação grava a versão do `form_schema` e as respostas
   validadas; transições são explícitas
   (`recebida → em_analise → aguardando_documento → deferida|indeferida`, com `cancelada`).
   Transição inválida responde `422`; não há workflow configurável.
5. **Portal e CMS:** portal solicita e acompanha (`protocolo + e-mail` ou link assinado com TTL);
   CMS tem inbox, assume, solicita documento, defere, indefere e cancela. Anexos sempre privados
   via Media; timeline imutável; cada ação auditada.
6. **LGPD e abuso:** consentimento, finalidade, retenção, contato cifrado, `ip_hash` diário,
   rate limit e auditoria de acesso. Sem PII em log/telemetria. Sem API pública de solicitações no
   MVP.
7. **Um serviço real no demo:** a fase só fecha com pelo menos um serviço `digital=true` com
   formulário e acompanhamento ponta a ponta.

## Justificativa — alternativas descartadas

| Alternativa | Por que não |
|---|---|
| Helpdesk/ticket genérico | SLA comercial, fila e chat que o produto não usa; duplica protocolo. |
| Service `Solicitacoes` | Não é compartilhado entre áreas; o domínio é do módulo. |
| Motor BPMN/workflow configurável | Um fluxo fechado não justifica engine; vira produto paralelo. |
| Protocolo próprio no módulo | Duplica prazos/formato do P11 e cria duas verdades. |
| Integração SEI/protocolo único no MVP | Dependência externa e credencial; link é navegação. |
| Formulário HTML livre | Viola ADR-017/028; schema fechado e AST são obrigatórios. |

## Consequências

**Positivas**
- PNTP 15.3 atendido com um fluxo pequeno e auditável.
- Reuso do protocolo/prazo sem acoplar Ouvidoria, e-SIC e Serviços.
- Anexos e PII tratados no caminho já existente (Media/LGPD/auditoria).

**Custos / riscos**
- O `form_schema` versionado exige validação server-side e compatibilidade de leitura.
- Acompanhamento público por protocolo + e-mail/link assinado precisa de rate limit e testes de
  enumeração.
- O inbox do CMS não pode virar fila comercial; o escopo é resposta e transição de estado.

## Exemplo mínimo

```text
POST /servicos/{slug}/solicitar
  -> solicitacoes_servico.protocolo = SOL-2026-000123
  -> status = recebida, due_at = Deadline::from($servico)

GET /servicos/acompanhar/{protocolo}?email=...
  -> status + timeline pública + pendências (sem anexo por URL adivinhável)
```

```php
final readonly class CreateSolicitacao
{
    public function __construct(
        private ProtocolGenerator $protocols,
        private Deadline $deadline,
    ) {}
}
```

## Verificação

- Pelo menos um serviço real cria solicitação e protocolo único; acompanhamento mostra o status.
- Transição inválida retorna 422; ação no CMS gera evento auditado.
- Anexo privado não é acessível por URL direta; download exige autorização.
- Reenvio do mesmo protocolo/e-mail não enumera solicitações de terceiros.
- `form_schema` antigo continua legível; nova versão não reescreve o passado.
- Sem PII em log/telemetria; retenção/expurgo cobertos por `RetentionRegistry`.