Gestao de Licencas

 +-----------------+      +------------------+      +----------------+
 |  Cliente final  |      |  Lider projeto   |      |  Orgaos        |
 |  (empresa com   |<---->|  (operador GLC)  |<---->|  publicos      |
 |   licencas)     |      |                  |      |  (Fed/Est/Mun) |
 +--------+--------+      +---------+--------+      +--------+-------+
          | WhatsApp/email          | Painel web             | Portais/forms
          |                         |                        |
          v                         v                        v
 +--------------------------------------------------------------+
 |                   Sistema GLC (v1 = so Bloco A)              |
 |                                                              |
 |  +-----------+   +-----------+   +-----------+  +---------+  |
 |  | Bloco A   |   | Bloco B   |   | Bloco C   |  | Bloco D |  |
 |  | MAPEAR    |-->| WORKPLAN  |-->| PRODUCAO  |  | PROMO   |  |
 |  | (v1)      |   | (v2)      |   | (v3)      |  | (v4)    |  |
 |  +-----+-----+   +-----+-----+   +-----+-----+  +----+----+  |
 |        |               |               |             |        |
 |        +---------------+---------------+-------------+        |
 |                        |                                      |
 |                        v                                      |
 |          +------------------------------+                     |
 |          | Dominio compartilhado        |                     |
 |          |  - Empresa (CNPJ, socios)    |                     |
 |          |  - Licenca (tipo, numero,    |                     |
 |          |    orgao, emissao, venc)     |                     |
 |          |  - Catalogo licencas         |                     |
 |          |    (por vertical/municipio)  |                     |
 |          +------------------------------+                     |
 +--------------------------------------------------------------+

 +--------------------------------------------------------------+
 |                         VPS Rafael                           |
 |                                                              |
 |   +-------------+   +----------+   +------------------+     |
 |   |  Traefik    |-->|  glc-web |-->|    glc-api       |     |
 |   |  (443)      |   | Next.js  |   |   FastAPI        |     |
 |   |  Regra 9    |   | Regra 15 |   |   Regra 12       |     |
 |   +-------------+   +----------+   +--------+---------+     |
 |                                             |                |
 |                                             v                |
 |                                    +-----------------+       |
 |                                    |   PocketBase    |       |
 |                                    |   (glc-db)      |       |
 |                                    |   Regra 11      |       |
 |                                    +--------+--------+       |
 |                                             |                |
 |                                             v                |
 |                                    +-----------------+       |
 |                                    |    data/        |       |
 |                                    |    (volume)     |       |
 |                                    +-----------------+       |
 |                                                              |
 |   Rede: coolify (externa, compartilhada com Traefik)         |
 +--------------------------------------------------------------+

   Fora: Claude API (classificacao), SMTP (alertas)

• Email de parceiro com escopo grande e bom material de requisitos, mas vem com **duas misturas**: lingua (pt/es) e terminologia (licenca/alvara/cadastro tratados como sinonimos). Transcrever integral antes de parafrasear evita perda. Parafrasear vira glossario depois.
• Um escopo descrito em 4 frentes (Mapeamento/Workplan/Producao/Promocao) ja **entrega a decomposicao em blocos de graca** — nao precisa inventar. Usar a estrutura do autor como primeiro rascunho da arquitetura (Regra 1 + Regra 17 — blocos vs. integracoes).
• A camada `docs/playbook/` forca a **explicar** cada decisao, nao so tomar. Isso expoe decisoes ainda nao maduras mais cedo. Util para caso o proprio Rafa precise justificar para o Ale ou outro parceiro futuro.
• Diferenca entre **pergunta aberta** e **decisao arquitetural** importa. Perguntas abertas vivem em `requisitos.md`; propostas de resposta viram ADR em status "proposta"; decisoes validadas viram ADR em status "aceito". Essa disciplina de status impede confundir opiniao do Claude com decisao do Rafa+Ale. ADR 0003 foi escrito exatamente para materializar essa separacao.
• Etapas do playbook sao escritas pelo Rafa (autenticidade, controle). IA so corrige typos e ajuda com estrutura. O conteudo e a concepcao do humano — esse e o contrato.
• --

• **Bloqueio humano nao trava execucao indefinidamente.** Duas sessoes passaram com "call com Ale pendente" como bloqueio raiz. Todo o Sprint 0 dependia dessa call. Solucao: Rafa (CEO) autorizou decidir P1-P6 por coerencia, marcar ADRs como "aceito por coerencia, aguarda ratificacao", e seguir. Reverter e barato (1 ADR-bis por decisao discordada); paralisia custa o projeto. **Regra a incorporar nas 17**: quando dependencia humana mantem projeto parado > 2 sessoes, decide por coerencia e segue. Documenta como hipotese. Trata divergencia quando chegar, nao antes.
• **Dashboard visual `/scopo` expos o problema, nao causou.** A analise externa (especialista de execucao) que apontou o bloqueio so foi possivel porque a documentacao estava densa, os ADRs explicitos, os status honestos. Documentacao densa + status honesto = auditavel externamente. Vale replicar em outros `_RFM-*`.
• **ADR em 3 status (proposta / aceito por coerencia / aceito) e mais util que 2.** O status intermediario "aceito por coerencia, aguarda ratificacao" preserva autenticidade (nao finge que foi decisao humana) e libera execucao. Quando ratificado, vira "aceito"; quando discordado, vira "superado por 000X-bis".
• **Risco de over-documentacao real.** O projeto tem mais linhas de doc+ADR+playbook que de codigo (0 linhas de codigo do produto, ~1000 linhas de doc). Funcional enquanto o catalogo de licencas e a planilha de custo sao as proximas entregas — mas se o ratio nao inverter ate fim de Sprint 0, sinal de processo se alimentando.
• --

• **Ler `_RFM-0000-Regras/regras.md` antes de escrever plano, nao durante.** Nesta sessao planejei deploy com Cloudflare A record + Coolify UI quando a Regra 7 ja tem o padrao canonico (`docker --context vps-rafael compose up -d --build`) e a Regra 10 ja resolveu DNS por wildcard. Resultado: ~40min perdidos em caminho custom que funciona mas nao casa com a infra. A Regra 1 principio 6 ("IA executa, humano arquiteta") implica IA ler o metodo **antes** de propor, nao depois.
• **Pagina `/scopo` como ferramenta meta — vale o investimento mesmo antes do produto.** O painel visual do proprio escopo ajuda a ver furos que texto puro nao expoe (redundancia entre secoes, severidade ambigua de riscos, ADRs sem status claro). Vira ferramenta de fechar `requisitos.md` + `arquitetura.md` mais rapido, nao distracao. Audiencia interna (Rafa + Ale) pode expor riscos e ADRs em "proposta" sem diluir — e inclusive o que faz a conversa valer.
• **Sandbox do Claude Code trata cada acao em infra compartilhada como nova.** Consent via AskUserQuestion, Skill invocado pelo agente ou mensagem anterior do usuario **nao conta** — so conta edicao manual de `.claude/settings.local.json` pelo humano. Stack Rafoso Mode precisa ter as regras de permissao padrao pre-escritas em template de novo projeto (`Bash(docker --context vps-rafael *)`, `Bash(docker compose *)`, `Bash(ssh vps-rafael *)`), se nao cada sessao de deploy vira ping-pong.
• **Wildcard DNS reduz a fricao de novo subdominio a zero.** `*.rafaelcamargo.online` → VPS-IP ja configurado no Cloudflare significa que qualquer novo app so precisa de container com label Traefik — sem toque em DNS. Vale confirmar com `getent hosts random123.rafaelcamargo.online` antes de assumir que precisa criar A record.