docs(skills): biblioteca operacional ScoreOdonto Enterprise
Skills estruturantes preenchidas com conteúdo real (baseado no código): FASE_01 Arquitetura, FASE_02 Negócio, FASE_03 Pessoas, FASE_04 Financeiro, FASE_05 UI/UX (regras rígidas de desktop/container/grid), FASE_07 Infra, FASE_08 Auditoria (Rotas/Fluxos). Demais skills permanecem como scaffold para preenchimento futuro. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
VPS 4 Builder
@@ -0,0 +1,35 @@
|
||||
# SCOREODONTO ENTERPRISE SKILLS
|
||||
|
||||
## REGRA Nº 1 — NÃO QUEBRAR O QUE JÁ FUNCIONA
|
||||
|
||||
Antes de qualquer alteração:
|
||||
|
||||
- Auditar impacto.
|
||||
- Identificar dependências.
|
||||
- Identificar telas afetadas.
|
||||
- Identificar APIs afetadas.
|
||||
- Identificar tabelas afetadas.
|
||||
- Identificar permissões afetadas.
|
||||
- Identificar integrações afetadas.
|
||||
|
||||
PROIBIDO:
|
||||
|
||||
- Refatorar sem auditoria.
|
||||
- Remover funcionalidades existentes sem validação.
|
||||
- Alterar identidade visual aprovada.
|
||||
- Alterar fluxo financeiro sem mapeamento.
|
||||
- Alterar entidades centrais sem documentação.
|
||||
|
||||
Toda implementação deve seguir:
|
||||
|
||||
Auditoria → Planejamento → Aprovação → Implementação → Validação.
|
||||
|
||||
Arquitetura oficial:
|
||||
|
||||
Pessoa → Vínculo → Workspace
|
||||
|
||||
Workspaces:
|
||||
- Clínica
|
||||
- Consultório
|
||||
- Laboratório
|
||||
- Sala
|
||||
@@ -0,0 +1,69 @@
|
||||
# SKILL — Modelagem Mestra
|
||||
|
||||
> **Skill raiz.** Todas as demais skills herdam destas regras. Baseado em evidências reais do
|
||||
> `backend/server.js` e do schema. Antes de qualquer alteração: **Auditoria → Planejamento → Aprovação → Implementação → Validação.**
|
||||
|
||||
## Conceito de negócio
|
||||
O ScoreOdonto **não é um sistema de clínica**; é uma **plataforma de pessoas** que atuam dentro de
|
||||
workspaces. A clínica é apenas **um tipo de workspace**. A arquitetura oficial é:
|
||||
|
||||
```
|
||||
Pessoa → Vínculo → Workspace → Serviços → Marketplace → Financeiro
|
||||
```
|
||||
|
||||
## Objetivo da skill
|
||||
Fixar o modelo mental único do sistema, para que nenhum módulo volte ao paradigma legado
|
||||
"Clínica → tudo". Toda entidade nova deve se posicionar nessa cadeia.
|
||||
|
||||
## Entidades centrais (fonte da verdade)
|
||||
| Camada | Tabela real | Papel |
|
||||
|---|---|---|
|
||||
| Pessoa | `usuarios` | Identidade única (login). Âncora de tudo. |
|
||||
| Vínculo | `vinculos` | Liga pessoa↔workspace com papel e RBAC. |
|
||||
| Workspace | `clinicas` (`tipo` ∈ pessoal/consultorio/clinica) + `salas` | Contexto operacional. |
|
||||
| Capacidades | `usuario_plugins`, `usuario_areas` | Atributos da pessoa (não do workspace). |
|
||||
|
||||
## Relacionamentos
|
||||
- `usuarios (1) → (N) vinculos (N) → (1) clinicas` — uma pessoa, vários workspaces, papel por workspace.
|
||||
- `clinicas.owner_id → usuarios.id` — todo workspace tem dono.
|
||||
- Ao registrar, cria-se automaticamente um **workspace pessoal** (`clinicas.tipo='pessoal'`).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **A pessoa (`usuarios`) é a âncora.** Capacidades (áreas, plugins, tutor) pertencem à pessoa.
|
||||
2. **Clínica/Consultório/Sala/Laboratório são `tipo` de workspace**, nunca entidades de topo.
|
||||
3. **Todo dado operacional é escopado por workspace** (`clinica_id`) via `tenantGuard`.
|
||||
4. **Nunca duplicar a pessoa** para representá-la em outro workspace — use `vinculos`.
|
||||
5. **Migração aditiva**: colunas novas via `ALTER TABLE ... ADD COLUMN IF NOT EXISTS` (padrão atual).
|
||||
|
||||
## Casos de uso
|
||||
- Dentista atende em 3 clínicas → 1 `usuarios` + 3 `vinculos`.
|
||||
- Profissional autônomo sem clínica → `usuarios` + workspace `tipo='pessoal'`.
|
||||
- Locador de sala → `usuarios` + `salas` (workspace `tipo='sala'`).
|
||||
|
||||
## Anti-padrões (PROIBIDO)
|
||||
- ❌ Criar tabela-entidade nova "espelhando" a pessoa por workspace (vide débito de `dentistas`).
|
||||
- ❌ Tratar `clinica` como raiz hierárquica do sistema.
|
||||
- ❌ Guardar identidade/capacidade no workspace em vez de na pessoa.
|
||||
- ❌ Escrever dado operacional sem `clinica_id`.
|
||||
|
||||
## Impactos em outros módulos
|
||||
Esta skill governa **todas**: Pessoa, Workspace, Vínculos, Multiempresa, RBAC e todos os módulos
|
||||
de negócio. Qualquer conflito com ela é defeito de modelagem (gravidade ALTA).
|
||||
|
||||
## Débitos conhecidos (legado clínica-cêntrico ainda vivo)
|
||||
- `pacientes` (sem `usuario_id`, preso à clínica) e `dentistas` (tabela paralela a `usuarios`).
|
||||
- Workspace dividido em 2 tabelas (`clinicas` + `salas`).
|
||||
> Ver `../FASE_08_AUDITORIA/SKILL_Entidades.md`.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
P[Pessoa · usuarios] --> V[Vínculo · vinculos]
|
||||
V --> W{Workspace}
|
||||
W -->|tipo=clinica| C[Clínica]
|
||||
W -->|tipo=consultorio| K[Consultório]
|
||||
W -->|tipo=sala| S[Sala]
|
||||
W -->|tipo=pessoal| PP[Workspace Pessoal]
|
||||
P --> CAP[Capacidades · areas/plugins]
|
||||
W --> OP[Operação · pacientes/agenda/financeiro]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,48 @@
|
||||
# SKILL — Multiempresa (Tenancy)
|
||||
|
||||
> Herda de `SKILL_ModelagemMestra.md`. Regra de isolamento de dados entre workspaces.
|
||||
|
||||
## Conceito de negócio
|
||||
Cada workspace é um inquilino (tenant). Dados de uma clínica **nunca** podem vazar para outra.
|
||||
A mesma pessoa pode transitar entre tenants via vínculos, mas os **dados ficam no tenant**.
|
||||
|
||||
## Objetivo
|
||||
Garantir isolamento por `clinica_id` em 100% da operação e impedir queries sem escopo.
|
||||
|
||||
## Entidades envolvidas
|
||||
- Toda tabela operacional tem `clinica_id` (`pacientes`, `agendamentos`, `financeiro`,
|
||||
`procedimentos_realizados`, `orcamentos`, `contratos`, `repasses`, `glosas`, `protese_os`…).
|
||||
- `audit_log` por `clinica_id`.
|
||||
|
||||
## Relacionamentos / mecanismo real
|
||||
- **`tenantGuard`** (middleware) injeta `req.clinicaId` e é exigido na maioria das 277 rotas.
|
||||
- **`authGuard`** é o plano de identidade (rotas `me/*`) — sem tenant.
|
||||
- O cliente envia o workspace ativo; o backend valida o vínculo antes de servir dados.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Toda query operacional filtra `clinica_id = $req.clinicaId`.** Sem exceção.
|
||||
2. Rota que toca dado de clínica usa `tenantGuard`; rota de identidade usa `authGuard`.
|
||||
3. `superadmin` é o único plano transversal (gestão global) — auditar com cuidado.
|
||||
4. Marketplace cross-tenant (salas/propostas) é **acoplamento intencional** e explícito.
|
||||
|
||||
## Casos de uso
|
||||
- Listar pacientes → sempre do `clinica_id` ativo.
|
||||
- Trocar workspace → recomputar tudo no novo `clinica_id`.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ `SELECT ... FROM pacientes` sem `clinica_id`.
|
||||
- ❌ Confiar em `clinica_id` vindo do corpo do request sem validar o vínculo.
|
||||
- ❌ Agregar entre clínicas fora dos fluxos de marketplace/superadmin.
|
||||
|
||||
## Impactos
|
||||
Base de segurança de TODOS os módulos. Falha aqui = vazamento de dados (gravidade ALTA) + risco LGPD.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
REQ[Request] --> AG{Guard}
|
||||
AG -->|authGuard| ID[Identidade · me/*]
|
||||
AG -->|tenantGuard| TEN[req.clinicaId]
|
||||
TEN --> Q[Query SEMPRE com clinica_id]
|
||||
Q --> DB[(Postgres)]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,48 @@
|
||||
# SKILL — Pessoa
|
||||
|
||||
> Herda de `SKILL_ModelagemMestra.md`. A Pessoa é a **âncora única** do sistema.
|
||||
|
||||
## Conceito de negócio
|
||||
Toda interação no ScoreOdonto parte de uma **pessoa** (humano com login). Papéis (dentista,
|
||||
biomédico, protético, paciente, tutor, dono) são **facetas** da mesma pessoa, não entidades separadas.
|
||||
|
||||
## Objetivo
|
||||
Garantir que identidade, capacidades e histórico fiquem na pessoa — nunca duplicados por workspace.
|
||||
|
||||
## Entidades envolvidas
|
||||
- `usuarios` — identidade (login, `role` global, `is_tutor`).
|
||||
- `usuario_areas` — áreas de atuação (multi-área; ref. `areas`).
|
||||
- `usuario_plugins` — capacidades/add-ons por pessoa (`me/plugins`).
|
||||
- `vinculos` — onde a pessoa atua e com qual papel.
|
||||
|
||||
## Relacionamentos
|
||||
- `usuarios (1) → (N) vinculos` — pessoa em vários workspaces.
|
||||
- `usuarios (1) → (N) usuario_areas` e `(N) usuario_plugins`.
|
||||
- Marketplace de profissionais: `propostas_profissional.profissional_id → usuarios.id`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Uma pessoa = um `usuarios`** (idealmente deduplicado por CPF/e-mail).
|
||||
2. **Capacidades vivem na pessoa**, não no workspace.
|
||||
3. `role` global em `usuarios` só para `superadmin`; os demais papéis vêm de `vinculos.role`.
|
||||
4. Toda rota de identidade usa `authGuard` (não `tenantGuard`).
|
||||
|
||||
## Casos de uso
|
||||
- Pessoa é dentista numa clínica e dono de sala em outra → 2 vínculos, papéis distintos.
|
||||
- Pessoa ativa o plugin de Salas → grava em `usuario_plugins` (vale em qualquer dispositivo).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Criar `dentistas`/`proteticos` como tabela de identidade paralela (débito atual de `dentistas`).
|
||||
- ❌ Persistir capacidade só no `localStorage` sem refletir em `usuario_plugins` (risco de divergência).
|
||||
|
||||
## Impactos em outros módulos
|
||||
Base de Vínculos, RBAC, Marketplace, Tutoria, Pessoas (Fase 3). Mudou a pessoa → reflete em todos.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[usuarios] --> A[usuario_areas]
|
||||
U --> PL[usuario_plugins]
|
||||
U --> V[vinculos]
|
||||
U --> PR[propostas_profissional]
|
||||
V --> WS[Workspaces]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,47 @@
|
||||
# SKILL — RBAC (Controle de Acesso)
|
||||
|
||||
> Herda de `SKILL_Vinculos.md`. Define quem vê e faz o quê, por papel e função, no workspace ativo.
|
||||
|
||||
## Conceito de negócio
|
||||
Acesso é decidido pelo **papel da pessoa no workspace ativo** + permissões finas da `funcao`.
|
||||
O frontend espelha o backend: menu e telas seguem a mesma matriz de papéis.
|
||||
|
||||
## Objetivo
|
||||
Padronizar a decisão de acesso e manter front/back coerentes (sem permissão hardcoded).
|
||||
|
||||
## Entidades / mecanismo real
|
||||
- **Backend:** `tenantGuard`/`authGuard`; `vinculos.role` + `funcoes` (permissões); `usuarios.role` só p/ `superadmin`.
|
||||
- **Frontend:** `App.tsx → isViewAllowed(view, role)` e o filtro de menu em `components/Sidebar.tsx`.
|
||||
- Papéis: `superadmin` (global), `admin`/`donoclinica`/`donoconsultorio` (amplo), `funcionario`,
|
||||
`dentista`, `biomedico`, `protetico`, `paciente`, `donosala`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Decisão por papel/função**, nunca por identidade individual.
|
||||
2. Quando a `funcao` define permissões explícitas (`permissoes[]`), elas **prevalecem** sobre o default do papel.
|
||||
3. Telas `superadmin*` e o catálogo de `plugins` são **exclusivos do superadmin**.
|
||||
4. Workspace `tipo='sala'` restringe o menu a painel da sala/conta/notificações.
|
||||
5. **Mudou regra de acesso no backend → atualizar `isViewAllowed` e `Sidebar` no mesmo PR.**
|
||||
|
||||
## Casos de uso
|
||||
- Biomédico não vê Ortodontia/RX (não-odonto) — regra explícita no menu.
|
||||
- Cargo customizado com `permissoes:['agenda','financeiro']` → menu reduzido a isso.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Liberar tela no front sem proteger a rota no back (e vice-versa).
|
||||
- ❌ Checar `if (email === 'x')`.
|
||||
- ❌ Esquecer de espelhar a permissão nos dois lados (front/back divergentes).
|
||||
|
||||
## Impactos
|
||||
Governa todo o menu, todas as rotas e a experiência por papel. Ver `../FASE_08_AUDITORIA/SKILL_Rotas.md`.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
P[Pessoa] --> V[vinculo.role no workspace ativo]
|
||||
V --> F{tem funcao com permissoes?}
|
||||
F -->|sim| PERM[usa permissoes da funcao]
|
||||
F -->|não| DEF[usa default do papel]
|
||||
PERM --> UI[Sidebar + isViewAllowed]
|
||||
DEF --> UI
|
||||
UI --> API[rota protegida por guard]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,46 @@
|
||||
# SKILL — Vínculos
|
||||
|
||||
> Herda de `SKILL_ModelagemMestra.md`. O vínculo é a **ponte** pessoa↔workspace e o lugar do papel.
|
||||
|
||||
## Conceito de negócio
|
||||
Uma pessoa não "é" dentista no sistema — ela **tem um vínculo de papel dentista** num workspace.
|
||||
Mudou de workspace, muda o papel. É o que permite multi-clínica sem duplicar a pessoa.
|
||||
|
||||
## Objetivo
|
||||
Centralizar papel + RBAC na relação, nunca na identidade nem no workspace.
|
||||
|
||||
## Entidades envolvidas
|
||||
- `vinculos(id, usuario_id, clinica_id, role, setor_id, funcao_id)`.
|
||||
- `funcoes` (cargos com permissões) e `setores` — por workspace.
|
||||
- Constraint real de papéis (`vinculos_role_check`):
|
||||
`paciente, dentista, biomedico, protetico, funcionario, donoclinica, donoconsultorio, donosala, admin`.
|
||||
|
||||
## Relacionamentos
|
||||
- `vinculos.usuario_id → usuarios.id`; `vinculos.clinica_id → clinicas.id`.
|
||||
- `vinculos.funcao_id → funcoes.id` (permissões finas); `vinculos.setor_id → setores.id`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Papel operacional vem do vínculo** (`vinculos.role`), não de `usuarios` (exceto `superadmin`).
|
||||
2. **N vínculos por pessoa** — multi-workspace é nativo. Nunca duplicar a pessoa.
|
||||
3. A permissão efetiva = papel do vínculo **+** permissões da `funcao` (quando houver).
|
||||
4. Remover acesso = remover/alterar o vínculo, jamais apagar a pessoa.
|
||||
|
||||
## Casos de uso
|
||||
- Convidar membro: cria `vinculos` com `role` + `funcao_id`.
|
||||
- Profissional sai da clínica: deleta o vínculo; histórico e identidade permanecem.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Guardar papel em tabela-recurso (débito de `dentistas`).
|
||||
- ❌ Permissão hardcoded por e-mail/nome em vez de papel/função.
|
||||
|
||||
## Impactos
|
||||
Base direta de RBAC, Multiempresa, Gestão de Equipe e do menu/`isViewAllowed` do frontend.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[usuarios] --> VN[vinculos: role, setor, funcao]
|
||||
VN --> CL[clinicas/workspace]
|
||||
VN --> FU[funcoes: permissões]
|
||||
VN --> SE[setores]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,50 @@
|
||||
# SKILL — Workspace
|
||||
|
||||
> Herda de `SKILL_ModelagemMestra.md`. Workspace é o **contexto operacional** onde a pessoa atua.
|
||||
|
||||
## Conceito de negócio
|
||||
Todo dado operacional (pacientes, agenda, financeiro) pertence a um **workspace**, nunca diretamente
|
||||
à pessoa. A clínica é o workspace mais comum, mas é só um `tipo`.
|
||||
|
||||
## Objetivo
|
||||
Padronizar o conceito de workspace e impedir o retorno ao modelo clínica-cêntrico.
|
||||
|
||||
## Entidades envolvidas
|
||||
- `clinicas` — tabela de workspace. Colunas-chave: `tipo` (`pessoal`|`consultorio`|`clinica`),
|
||||
`owner_id`, `cor`, `geo` (PostGIS). **Hoje "clinicas" É a tabela de workspaces.**
|
||||
- `salas` — workspace `tipo='sala'` (tabela separada — débito de unificação).
|
||||
- `vinculos` — quem pertence ao workspace e com qual papel.
|
||||
|
||||
## Relacionamentos
|
||||
- `clinicas.owner_id → usuarios.id`.
|
||||
- Operação: `pacientes.clinica_id`, `agendamentos.clinica_id`, `financeiro.clinica_id`, etc.
|
||||
- Agregação no app: `GET /api/me/workspaces` → `listarWorkspaces()` reúne clínicas (via vínculo) + salas.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Tudo que é operacional carrega `clinica_id`** e passa por `tenantGuard`.
|
||||
2. O **workspace ativo** (cacheado no cliente) governa menu, permissões e dados visíveis.
|
||||
3. `tipo='sala'` **isola o contexto** (menu reduzido: painel da sala/conta/notificações).
|
||||
4. Workspace pessoal (`tipo='pessoal'`) é criado automaticamente no registro.
|
||||
|
||||
## Casos de uso
|
||||
- Trocar de workspace no seletor → recarrega contexto (cor de marca, menu, dados).
|
||||
- Sala como workspace → usuário cai em `sala-home`, sem acesso à operação clínica.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Ler/gravar operação sem `clinica_id`.
|
||||
- ❌ Tratar `salas` e `clinicas` como conceitos distintos na lógica de negócio (são ambos workspace).
|
||||
- ❌ Vazar dados entre workspaces (sempre filtrar por `req.clinicaId`).
|
||||
|
||||
## Impactos
|
||||
Governa Multiempresa, RBAC e todos os módulos de Workspace (Fase 2) e operação.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
WS[Workspace] -->|clinicas.tipo| T1[clinica]
|
||||
WS --> T2[consultorio]
|
||||
WS --> T3[pessoal]
|
||||
WS -->|salas| T4[sala]
|
||||
WS --> OP[pacientes / agenda / financeiro · clinica_id]
|
||||
WS --> VN[vinculos · membros + papéis]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,42 @@
|
||||
# SKILL — Clínicas (Workspace)
|
||||
|
||||
> Herda de `SKILL_Workspace.md`. Tipo de workspace mais completo do sistema.
|
||||
|
||||
## O que é?
|
||||
Workspace `clinicas.tipo='clinica'` — a empresa odontológica com equipe, pacientes e operação plena.
|
||||
|
||||
## Quem usa?
|
||||
Donos (`donoclinica`/`admin`), funcionários, dentistas, biomédicos, protéticos vinculados.
|
||||
|
||||
## Quais módulos possui?
|
||||
Dashboard, Agenda, Pacientes, Ortodontia, Próteses/GTO, Financeiro, Comissões, Repasses, Glosas,
|
||||
Orçamentos, Contratos, Relatórios, Leads, Equipe/RBAC, Planos/Procedimentos/Especialidades,
|
||||
RX (plugin), Configurações. (Menu completo — ver `../FASE_08_AUDITORIA/SKILL_Rotas.md`.)
|
||||
|
||||
## Quais receitas gera?
|
||||
Produção de procedimentos (RECEITA), contratos/cobrança, recuperação de glosas. Paga repasses (DESPESA).
|
||||
> Detalhe do dinheiro em `../FASE_04_FINANCEIRO/`.
|
||||
|
||||
## Quais permissões possui?
|
||||
Donos/admin: acesso amplo (menos telas `superadmin`). Demais papéis: subconjunto por papel/função (RBAC).
|
||||
|
||||
## Entidades envolvidas
|
||||
`clinicas` + toda a operação por `clinica_id` + `vinculos`/`funcoes`/`setores`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Operação sempre escopada por `clinica_id` (`tenantGuard`).
|
||||
2. A clínica é **um tipo de workspace**, não a raiz do sistema.
|
||||
3. Equipe entra por vínculo; permissões por papel/função.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Assumir "uma clínica por usuário" (a pessoa pode ter várias).
|
||||
- ❌ Tratar clínica como dona da pessoa.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
CL[Clínica] --> EQ[Equipe via vinculos]
|
||||
CL --> PAC[Pacientes]
|
||||
CL --> AG[Agenda]
|
||||
CL --> FIN[Financeiro → Comissão → Repasse]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,37 @@
|
||||
# SKILL — Consultórios (Workspace)
|
||||
|
||||
> Herda de `SKILL_Workspace.md`. Variante enxuta da clínica.
|
||||
|
||||
## O que é?
|
||||
Workspace `clinicas.tipo='consultorio'` — operação individual/pequena de um profissional-dono.
|
||||
Mesma tabela e mecânica da clínica; muda o `tipo` e o papel do dono (`donoconsultorio`).
|
||||
|
||||
## Quem usa?
|
||||
`donoconsultorio` (profissional que opera por conta própria) e eventuais membros.
|
||||
|
||||
## Quais módulos possui?
|
||||
Os mesmos da clínica (herda a operação), normalmente com equipe menor. O `tipo` distingue rótulo/UX,
|
||||
não um conjunto de tabelas separado.
|
||||
|
||||
## Quais receitas gera?
|
||||
Iguais às da clínica (produção, contratos), em escala individual.
|
||||
|
||||
## Quais permissões possui?
|
||||
`donoconsultorio` tem acesso amplo (não-`superadmin`), idêntico ao dono de clínica.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Consultório = `tipo` de workspace**, não um módulo nem uma entidade separada.
|
||||
2. `donoconsultorio` é o **papel do dono**; o `tipo='consultorio'` é o **workspace**.
|
||||
3. Não criar tabelas próprias de "consultório" — reutilizar a operação por `clinica_id`.
|
||||
|
||||
## Anti-padrões / Débito conhecido
|
||||
- ⚠️ Acoplamento **role↔tipo** (`donoconsultorio`⇄`tipo='consultorio'`): decisão duplicada.
|
||||
Ao ramificar lógica, prefira o `tipo` do workspace, não a role.
|
||||
- ❌ Duplicar telas/tabelas só para "consultório".
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
K[Consultório · tipo=consultorio] --> OWN[Dono · donoconsultorio]
|
||||
K --> OP[Operação reutilizada por clinica_id]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,43 @@
|
||||
# SKILL — Delivery (Profissionais temporários) — ALVO / ROADMAP
|
||||
|
||||
> Herda de `SKILL_Marketplace.md`. **ATENÇÃO: não existe no código hoje.** Esta skill descreve o conceito-alvo
|
||||
> e as **sementes reais** sobre as quais ele se apoiaria — sem inventar funcionalidade.
|
||||
|
||||
## O que NÃO existe hoje (estado real)
|
||||
Não há nenhuma implementação de "delivery"/plantão/diária de profissional: sem contratação temporária,
|
||||
sem vínculo por período, sem pagamento de profissional avulso. Buscas por `delivery/temporario/plantao/
|
||||
freela/substituto` no `server.js` **não retornam feature** — apenas os fragmentos abaixo.
|
||||
|
||||
## Sementes reais já existentes (base para o alvo)
|
||||
1. **Marketplace de Profissionais**: `profissionais-disponiveis`, `profissionais/marketplace`, `propostas`
|
||||
(clínica→profissional). Hoje só **mensagem/conexão**, status `pendente`.
|
||||
2. **Modelos de período** (vindos das Salas): `RESERVA_MODELOS = ['hora','turno','diaria','semanal','mensal']`
|
||||
e `valor_diaria`/`diaria_consulta` — o conceito de **diária** já está modelado para salas.
|
||||
3. **Vínculos temporários**: `vinculos` já suporta papel por workspace — a base para um vínculo com prazo.
|
||||
|
||||
## Conceito-alvo (Delivery)
|
||||
Profissional aceita uma **escala temporária** numa clínica (ex.: diária/turno), com início/fim, valor e
|
||||
pagamento — unindo a proposta de profissional ao modelo de período e a um vínculo com prazo.
|
||||
|
||||
## O que faltaria (lacunas — descrever, NÃO implementar)
|
||||
- Evoluir `propostas_profissional` de mensagem → **acordo com período + valor + aceite**.
|
||||
- Vínculo temporário (`vinculos` com janela de validade) e seu encerramento automático.
|
||||
- Captura de pagamento (mesma lacuna de Salas) e repasse ao profissional avulso.
|
||||
|
||||
## Regras obrigatórias (se um dia evoluir)
|
||||
1. Construir **sobre as sementes** (propostas + modelos de período + vínculos), sem entidade paralela nova.
|
||||
2. Manter Pessoa→Vínculo→Workspace: delivery é **vínculo temporário**, não nova classe de pessoa.
|
||||
3. Seguir Auditoria → Planejamento → **Aprovação** antes de qualquer implementação.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Documentar/assumir Delivery como se existisse.
|
||||
- ❌ Criar tabela/role nova "delivery" em vez de reusar `vinculos` + `propostas`.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PROF[Profissional · perfil] --> PROP[Proposta hoje: mensagem]
|
||||
PROP -. alvo .-> ACORDO[Acordo: período + valor + aceite]
|
||||
ACORDO -. alvo .-> VT[vinculo temporário]
|
||||
VT -. alvo .-> PAY[(pagamento + repasse)]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,46 @@
|
||||
# SKILL — Laboratórios (Workspace-alvo)
|
||||
|
||||
> Herda de `SKILL_Workspace.md`. **Atenção:** o estado ATUAL difere da arquitetura-alvo.
|
||||
|
||||
## O que é? (estado real hoje)
|
||||
Hoje o laboratório é um **cadastro interno por clínica** (`protese_laboratorios`), usado nas Ordens de
|
||||
Serviço de prótese e no **custo lab** que abate comissão. **Não** tem identidade própria nem login,
|
||||
**não** cruza clínicas. (Modelo "A — cadastro auxiliar".)
|
||||
|
||||
## Arquitetura-alvo (declarada no LEIA-PRIMEIRO)
|
||||
O laboratório é listado como **tipo de workspace** (Clínica/Consultório/Laboratório/Sala). Ou seja,
|
||||
a visão oficial é elevá-lo a **participante/operador do ecossistema**, não apenas lookup.
|
||||
|
||||
## Quem usa?
|
||||
Protéticos/laboratórios e as clínicas que enviam OS. (O protético-pessoa é tratado em
|
||||
`../FASE_03_PESSOAS/SKILL_Proteticos.md` — não confundir pessoa com laboratório.)
|
||||
|
||||
## Quais módulos possui? (hoje)
|
||||
Cadastro de laboratório + produtos (`protese_produtos`) + OS (`protese_os`, `protese_os_evento`,
|
||||
`protese_os_foto`). Integra com Comissões via custo lab.
|
||||
|
||||
## Quais receitas gera?
|
||||
Indireta hoje (operacional: custo lab compõe a margem). Como workspace, poderia faturar produção própria.
|
||||
|
||||
## Quais permissões possui?
|
||||
Hoje: dentro do RBAC da clínica que cadastra. Como workspace: teria papéis/vínculos próprios.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Não confundir** laboratório (fornecedor/operador) com protético (pessoa).
|
||||
2. Enquanto for cadastro, manter `clinica_id` e custo lab consistentes com Comissões.
|
||||
3. Qualquer evolução para workspace é decisão arquitetural → seguir Auditoria→Aprovação (não implementar aqui).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Tratar o laboratório como pessoa (login) sendo cadastro, ou vice-versa.
|
||||
- ❌ Recadastrar o mesmo laboratório em cada clínica como se fossem distintos (limitação atual a registrar).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph Hoje
|
||||
LAB[protese_laboratorios · cadastro por clínica] --> OS[protese_os] --> COM[custo lab → Comissão]
|
||||
end
|
||||
subgraph Alvo
|
||||
LABW[Laboratório · workspace] --> OPR[Opera no ecossistema]
|
||||
end
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,44 @@
|
||||
# SKILL — Marketplace
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Workspace.md` e `SKILL_Pessoa.md`. O marketplace só existe
|
||||
> porque a base é **Pessoa → Vínculo → Workspace** (atores cruzam fronteiras de clínica).
|
||||
|
||||
## Conceito
|
||||
O marketplace conecta **pessoas/workspaces** entre si, cross-tenant. São **três frentes** reais hoje,
|
||||
em maturidades diferentes:
|
||||
|
||||
| Frente | O que existe | Receita |
|
||||
|---|---|---|
|
||||
| **Salas (locação)** | CRUD + `salas/marketplace` + reservas (`sala_reservas`), modelos `hora/turno/diaria/semanal/mensal` com `valor_*` | `valor` registrado, **sem gateway** |
|
||||
| **Profissionais** | `profissionais/perfil`, `profissionais/marketplace`, `profissionais-disponiveis`, `propostas` (clínica→profissional) | **Só mensagem**, sem cobrança |
|
||||
| **Tutoria orto** | candidatura paga (MercadoPago) + solicitações | ✅ **única automatizada** (`comissao_pct`) |
|
||||
|
||||
## Entidades / rotas reais
|
||||
- Salas: `salas`, `sala_reservas` · `GET/POST/PUT /api/salas*`, `/api/sala-reservas*`.
|
||||
- Profissionais: `propostas_profissional` (`status='pendente'`, dup-check por clínica+profissional) ·
|
||||
`/api/profissionais/*`, `/api/propostas*`. Perfil = `usuarios` (nível pessoa, `authGuard`).
|
||||
- Tutoria: ver `../FASE_03_PESSOAS/SKILL_Tutores.md`.
|
||||
|
||||
## Permissões
|
||||
- Salas: plugin `locacao-salas` (sempre ON), todos menos `superadmin`.
|
||||
- Profissionais: plugin `profissionais-marketplace`, clínicos exceto `paciente`.
|
||||
- O catálogo de plugins é exclusivo do `superadmin`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Marketplace é **cross-tenant intencional** — mas cada lado continua isolado por `clinica_id`/workspace.
|
||||
2. **Sinalizar lacunas de pagamento** (salas/profissionais), nunca presumir transação concluída.
|
||||
3. Proposta de profissional hoje é **conexão (mensagem)**, não contratação — não inventar fluxo inexistente.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Acoplar marketplace à clínica (Modelo A) — ele depende da pessoa/workspace (Modelo B).
|
||||
- ❌ Tratar reserva/proposta como paga.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P[Pessoa/Workspace] --> S[Salas: reserva valor/modelo]
|
||||
P --> PR[Profissionais: perfil + proposta]
|
||||
P --> T[Tutoria: MercadoPago]
|
||||
S -. falta .-> PAY[(gateway)]
|
||||
PR -. falta .-> CONTR[(contratação/cobrança)]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,43 @@
|
||||
# SKILL — Salas (Workspace + Marketplace)
|
||||
|
||||
> Herda de `SKILL_Workspace.md`. Único workspace que já nasce no modelo novo + marketplace.
|
||||
|
||||
## O que é?
|
||||
Workspace `tipo='sala'` (tabela `salas`) que pode ser **locado** a terceiros. Plugin `locacao-salas`
|
||||
é **sempre ativo** (capability de plataforma).
|
||||
|
||||
## Quem usa?
|
||||
- **Locador** (`donosala` ou qualquer conta): cadastra e administra salas ("Minhas Salas").
|
||||
- **Locatário** (qualquer profissional): busca e reserva ("Alugar Salas").
|
||||
|
||||
## Quais módulos possui?
|
||||
Painel da sala (`sala-home`), marketplace de salas, reservas (`sala_reservas`), geolocalização (PostGIS `geo`).
|
||||
|
||||
## Quais receitas gera?
|
||||
**Potencial.** `sala_reservas` já tem `valor`, `modelo` e workflow de status (`pendente`→`aceita`),
|
||||
mas **não há captura de pagamento** (gateway) — o fluxo financeiro **não fecha** hoje.
|
||||
> É a alavanca de receita mais próxima de destravar. Ver `../FASE_04_FINANCEIRO/SKILL_Faturamento.md`.
|
||||
|
||||
## Quais permissões possui?
|
||||
Workspace `tipo='sala'` **isola** o contexto: menu só painel da sala/conta/notificações.
|
||||
Os itens "Minhas Salas"/"Alugar Salas" são de plugin (todos menos `superadmin`).
|
||||
|
||||
## Entidades envolvidas
|
||||
`salas`, `sala_reservas` (cross-tenant: locação entre workspaces distintos).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Reserva é **cross-tenant intencional** — validar disponibilidade (anti-overbooking de sala).
|
||||
2. Contexto de sala isola da clínica (não misturar operação clínica no workspace de sala).
|
||||
3. `valor` da reserva é registrado; **pagamento real é externo** (lacuna a sinalizar, não assumir).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Assumir que a reserva foi paga (não há gateway).
|
||||
- ❌ Vazar dados da clínica para o contexto de sala.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
SAL[Sala · workspace] --> MKT[Marketplace de salas]
|
||||
MKT --> RES[sala_reservas: valor, status]
|
||||
RES -. falta .-> PAY[(Pagamento/gateway)]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,39 @@
|
||||
# SKILL — Biomédicos (Pessoa)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Pessoa.md`. Profissional de **biomedicina estética**, não-odonto.
|
||||
|
||||
## Perfil
|
||||
Pessoa (`usuarios`) com vínculo `biomedico`. Tem **catálogo próprio** (especialidades/procedimentos de
|
||||
biomedicina) — semeável via `POST /api/me/seed-biomedicina`. Multi-área pelo perfil (`usuario_areas`/`areas`).
|
||||
|
||||
## Fluxos
|
||||
- Agenda própria + Tratamentos + lançamento de procedimentos do seu catálogo.
|
||||
- **Sem** itens odontológicos (Ortodontia, RX, tutoria orto) — separação explícita no menu.
|
||||
|
||||
## Permissões (RBAC)
|
||||
Menu: `dashboard, agenda, tratamentos, especialidades, procedimentos, clinicas, notificacoes,
|
||||
configuracoes, diretorio-profissionais`. Não vê Ortodontia/RX/tutoria.
|
||||
|
||||
## Marketplace
|
||||
Publica perfil no diretório de Profissionais; recebe propostas; pode locar/alugar salas.
|
||||
|
||||
## Financeiro
|
||||
Produção gera RECEITA/Comissão no workspace onde atua (mesma mecânica de `comissao_regras`/Repasse).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Catálogo de biomedicina é **da área**, não misturar com catálogo odonto.
|
||||
2. Identidade/áreas na pessoa; papel no vínculo.
|
||||
3. Não expor telas odonto ao papel `biomedico` (regra de menu já existente).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Vazar Ortodontia/RX para o menu do biomédico.
|
||||
- ❌ Duplicar a pessoa por local de atuação.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
B[Biomédico · usuarios] --> V[vinculo role=biomedico]
|
||||
B --> AR[usuario_areas: biomedicina]
|
||||
V --> AG[Agenda] --> PR[Procedimento área] --> COM[Comissão→Repasse]
|
||||
B --> MKT[Diretório/Propostas]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,45 @@
|
||||
# SKILL — Dentistas (Pessoa)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Pessoa.md` e `SKILL_Vinculos.md`.
|
||||
|
||||
## Perfil
|
||||
Pessoa (`usuarios`) com vínculo de papel `dentista` num workspace. É o clínico odontológico completo.
|
||||
**Débito conhecido:** existe também a tabela `dentistas` (recurso de agenda por clínica, com `usuario_id`
|
||||
opcional) — a MESMA pessoa pode aparecer como `usuarios` + `dentistas`. Tratar `dentistas` como
|
||||
**projeção de agenda**, não como identidade. Ver `../FASE_08_AUDITORIA/SKILL_Entidades.md`.
|
||||
|
||||
## Fluxos
|
||||
- Atende na Agenda → registra Procedimento Realizado → gera RECEITA/Comissão.
|
||||
- Ortodontia completa (triagem, plano, evoluções, fotos, contenção).
|
||||
- Pode pedir tutoria de orto e/ou ser tutor (ver `SKILL_Tutores.md`).
|
||||
|
||||
## Permissões (RBAC)
|
||||
Menu odonto: `dashboard, agenda, ortodontia, proteses, tratamentos, clinicas, configuracoes,
|
||||
candidatura-tutor, diretorio-profissionais` (+ RX e tutoria-painel conforme plugin/aprovação).
|
||||
**NÃO** vê telas administrativas globais nem `superadmin`.
|
||||
|
||||
## Marketplace
|
||||
- Publica perfil no diretório de Profissionais (`profissionais/perfil`, nível pessoa via `authGuard`).
|
||||
- Recebe propostas de clínicas (`propostas_profissional`).
|
||||
- Pode locar/alugar salas (plugin `locacao-salas`).
|
||||
|
||||
## Financeiro
|
||||
Gera comissão sobre procedimentos realizados (regra `comissao_regras`); recebe via Repasse.
|
||||
Ver `../FASE_04_FINANCEIRO/SKILL_Comissoes.md` e `SKILL_Repasses.md`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Identidade e capacidades na pessoa; papel no vínculo (multi-clínica nativo).
|
||||
2. Não duplicar a pessoa para representá-la em outra clínica — novo `vinculo`.
|
||||
3. `dentistas` é recurso de agenda, não fonte de identidade.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Hardcodar permissão por e-mail. ❌ Criar identidade do dentista fora de `usuarios`.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
D[Dentista · usuarios] --> V[vinculo role=dentista]
|
||||
V --> AG[Agenda] --> PR[Procedimento] --> COM[Comissão→Repasse]
|
||||
D --> MKT[Diretório/Propostas]
|
||||
D --> TUT[Tutoria orto]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,41 @@
|
||||
# SKILL — Pacientes (Pessoa — com débito de modelagem)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Pessoa.md`. **Atenção:** estado atual contraria a arquitetura-alvo.
|
||||
|
||||
## Perfil (estado real hoje)
|
||||
O paciente é registrado em `pacientes` com `clinica_id` e **sem `usuario_id`** — ou seja, **pertence à
|
||||
clínica**, não ao ecossistema. O mesmo CPF em 2 clínicas vira **2 registros** (sem prontuário único).
|
||||
Há resíduo legado: existem INSERTs com e sem `clinica_id`. Ver `../FASE_08_AUDITORIA/SKILL_Entidades.md`.
|
||||
|
||||
## Fluxos
|
||||
- Origem: cadastro direto **ou** conversão de Lead (`leads/:id/converter` cria paciente + agendamento).
|
||||
- Agenda, Orçamento, Procedimentos, Ortodontia, RX, Receita/Exame, Score, Faltas, Família.
|
||||
|
||||
## Permissões (RBAC)
|
||||
- Operadores (funcionário/donos) gerenciam pacientes da clínica ativa.
|
||||
- O **paciente-usuário** (papel `paciente`, quando existe login) vê só: `tratamentos, notificacoes, configuracoes`.
|
||||
|
||||
## Privacidade / LGPD
|
||||
O modelo atual (paciente preso à clínica) **favorece isolamento** — cada clínica é controladora dos
|
||||
seus dados. Compartilhar histórico entre clínicas exigiria base legal/consentimento. **Não** presumir
|
||||
"paciente do ecossistema" sem decisão arquitetural + jurídica.
|
||||
|
||||
## Marketplace / Financeiro
|
||||
Não participa de marketplace. É **origem de RECEITA** (procedimentos, contratos), nunca recebe repasse.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Paciente sempre escopado por `clinica_id` (tenancy).
|
||||
2. **Não** unificar pacientes entre clínicas sem aprovação (impacto LGPD direto).
|
||||
3. Conversão de lead é anti-overbooking — preservar a checagem.
|
||||
|
||||
## Anti-padrões / Débito
|
||||
- ⚠️ Falta de identidade de pessoa no paciente é o maior atrito com o modelo Pessoa→Workspace (gravidade ALTA).
|
||||
- ❌ Deduplicar/“mesclar” pacientes entre clínicas sem base legal.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
L[Lead] -->|converter| PAC[Paciente · clinica_id]
|
||||
PAC --> AG[Agenda] --> PR[Procedimento] --> FIN[RECEITA]
|
||||
PAC --> ORC[Orçamento] --> CON[Contrato]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,42 @@
|
||||
# SKILL — Protéticos (Pessoa)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Pessoa.md`. **Não confundir** com o Laboratório (entidade/fornecedor):
|
||||
> ver `../FASE_02_NEGOCIO/SKILL_Laboratorios.md`.
|
||||
|
||||
## Perfil
|
||||
Pessoa (`usuarios`) com vínculo `protetico` — profissional do laboratório. É **profissional do
|
||||
ecossistema** (modelo B da auditoria), não um "fornecedor" abstrato. O fornecedor é o **laboratório**.
|
||||
|
||||
## Fluxos
|
||||
- Agenda própria + Próteses (OS de laboratório: `protese_os`, produtos, materiais, custo lab, entrega).
|
||||
- Lança GTO (guia de tratamento) quando aplicável.
|
||||
|
||||
## Permissões (RBAC)
|
||||
Menu: `dashboard, agenda, proteses, tratamentos, lancar-gto, clinicas, notificacoes, configuracoes,
|
||||
diretorio-profissionais`. Sem Ortodontia/RX/pacientes clínicos.
|
||||
|
||||
## Marketplace
|
||||
Perfil no diretório de Profissionais; propostas; salas (plugin).
|
||||
|
||||
## Financeiro
|
||||
O **custo lab** das próteses **abate a base de comissão** do procedimento (entra em `computeComissoes`).
|
||||
Ver `../FASE_04_FINANCEIRO/SKILL_Comissoes.md`.
|
||||
|
||||
## Conflito conceitual a vigiar (gravidade baixa)
|
||||
A faceta "fornecedor" pertence ao **laboratório** (cadastro `protese_laboratorios`), não à pessoa.
|
||||
Manter pessoa (protético) e laboratório (entidade) **separados e bem ligados**.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Protético = pessoa/profissional; Laboratório = entidade/fornecedor. Não fundir.
|
||||
2. Custo lab consistente com Comissões.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Tratar o protético como cadastro de fornecedor (ou o laboratório como login).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PT[Protético · usuarios] --> V[vinculo role=protetico]
|
||||
V --> OS[Próteses/OS] --> CL[custo lab → Comissão]
|
||||
PT -. usa .-> LAB[Laboratório · fornecedor]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,34 @@
|
||||
# SKILL — Secretárias / Recepção (Pessoa)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Pessoa.md` e `SKILL_RBAC.md`.
|
||||
> **Importante:** no código **não existe role `secretaria`** — a secretária é o papel `funcionario`
|
||||
> (eventualmente com `funcao` customizada para refinar permissões).
|
||||
|
||||
## Perfil
|
||||
Pessoa (`usuarios`) com vínculo `funcionario`. Opera o front-office da clínica (não-clínico).
|
||||
|
||||
## Fluxos
|
||||
- Leads (captar/converter), Pacientes, Agenda, Financeiro, Orçamentos, Contratos, Relatórios, Glosas.
|
||||
|
||||
## Permissões (RBAC)
|
||||
Menu padrão do `funcionario`: `dashboard, leads, pacientes, agenda, financeiro, tratamentos,
|
||||
lancar-gto, proteses, relatorios, glosas, orcamentos, contratos, clinicas, notificacoes, configuracoes,
|
||||
diretorio-profissionais`. Permissões podem ser **estreitadas por `funcao`** (RBAC fino) no workspace.
|
||||
|
||||
## Marketplace / Financeiro
|
||||
Não participa de marketplace como profissional. Opera o financeiro da clínica, mas **não recebe comissão/repasse**.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. "Secretária" = papel `funcionario` + `funcao` opcional. Não criar role nova sem decisão arquitetural.
|
||||
2. Para restringir acesso, use **`funcao` com `permissoes[]`** (prevalece sobre o default do papel).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Inventar role `secretaria` no código (quebra a constraint `vinculos_role_check`).
|
||||
- ❌ Dar a funcionário telas de superadmin/admin global.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
S[Secretária · usuarios] --> V[vinculo role=funcionario + funcao]
|
||||
V --> FO[Leads/Agenda/Pacientes/Financeiro]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,42 @@
|
||||
# SKILL — Tutores de Ortodontia (Pessoa)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Pessoa.md`. Única faceta com **receita de plataforma automatizada**.
|
||||
|
||||
## Perfil
|
||||
Pessoa (`usuarios`) com flag `is_tutor=true` após **candidatura paga** (MercadoPago). Não é uma role de
|
||||
vínculo — é uma **capacidade da pessoa** (atributo), liberada pelo painel de tutoria.
|
||||
|
||||
## Fluxos
|
||||
- Candidatura (`tutoria/candidaturas`) → pagamento (`preferences` MercadoPago) → `mp-webhook` ativa o tutor.
|
||||
- Tutor resolve solicitações de orto (`ortho_tutoring_request`), troca mensagens/pacotes de fotos.
|
||||
- Gestão pelo superadmin (`admin/candidaturas`, `admin/repasses`, `admin/tutor-config`).
|
||||
|
||||
## Permissões (RBAC)
|
||||
- `candidatura-tutor`: disponível a dentistas.
|
||||
- `tutoria-painel`: **só para tutores aprovados** (`is_tutor`).
|
||||
- `admin-gestao-tutores`: **só superadmin**.
|
||||
|
||||
## Marketplace / Financeiro (modelo de receita)
|
||||
- Configuração global em `ortho_tutor_config` (`comissao_pct`, default **20%**, `taxa_inscricao`, chave PIX,
|
||||
credenciais MercadoPago).
|
||||
- Cada consultoria registra `valor_consultoria`, `comissao_pct`, `valor_tutor`, `status_repasse`.
|
||||
- **A plataforma fica com a comissão (`comissao_pct`)**; o tutor recebe `valor_tutor` (repasse próprio,
|
||||
distinto do repasse de clínica em `../FASE_04_FINANCEIRO/SKILL_Repasses.md`).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. `is_tutor` é capacidade da pessoa — não criar role de vínculo "tutor".
|
||||
2. Pagamento via MercadoPago é idempotente (webhook). Não duplicar ativação.
|
||||
3. Repasse de tutoria é fluxo próprio (não confundir com repasse de comissão de clínica).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Ativar tutor sem confirmar pagamento (webhook/`confirmar-pagamento`).
|
||||
- ❌ Misturar `comissao_pct` da tutoria com `comissao_regras` da clínica.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
D[Dentista] --> CAND[Candidatura]
|
||||
CAND -->|MercadoPago| WH[mp-webhook] --> T[is_tutor=true]
|
||||
T --> REQ[Solicitações orto]
|
||||
REQ --> $[valor_tutor + comissão plataforma]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,34 @@
|
||||
# SKILL — Assinaturas (da plataforma / SaaS)
|
||||
|
||||
> Herda de `SKILL_Financeiro.md`. **Receita da PLATAFORMA** (não da clínica). Hoje é manual.
|
||||
|
||||
## Conceito
|
||||
Assinatura é a relação de **cobrança da plataforma com a pessoa/conta** — a monetização do SaaS.
|
||||
**Distinta** de `contrato_assinaturas` (aceite de contratos da clínica). Não confundir.
|
||||
|
||||
## Entidades / mecanismo real
|
||||
- `assinaturas(id, usuario_id, status, valor, validade, created_at)`.
|
||||
- Gestão pelo **superadmin**: `PUT /api/superadmin/assinaturas/:userId` (define status/valor/validade) e
|
||||
`GET|PUT /api/superadmin/pricing` (tabela de preços).
|
||||
- **Estado atual: cobrança MANUAL** (superadmin define) — **não há gateway/recorrência automática**.
|
||||
|
||||
## Receita
|
||||
É a alavanca de **receita recorrente da plataforma** mais direta (base multiempresa + pricing já existem),
|
||||
porém ainda não automatizada. Ver auditoria estratégica (`documentação/AUDITORIA-ESTRATEGICA-MODELAGEM.md`).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Assinatura é **da pessoa/conta** (`usuario_id`), coerente com Pessoa→Workspace.
|
||||
2. Só `superadmin` gerencia (`superadminGuard`).
|
||||
3. Não confundir com assinatura de contrato nem com repasse.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Tratar `assinaturas` como assinatura de documento.
|
||||
- ❌ Assumir recorrência/gateway que não existe (cobrança é manual hoje).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
SA[superadmin] --> PRC[pricing]
|
||||
SA --> ASS[assinaturas: usuario_id, status, valor, validade]
|
||||
ASS -. falta .-> GW[(gateway/recorrência)]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,38 @@
|
||||
# SKILL — Comissões
|
||||
|
||||
> Herda de `SKILL_Financeiro.md`. Cálculo da remuneração do profissional sobre a produção.
|
||||
|
||||
## Conceito
|
||||
Comissão = **(base − custo_lab) × percentual**. A base é a produção do profissional no período; o custo
|
||||
lab (próteses) é abatido antes do percentual.
|
||||
|
||||
## Entidades / mecanismo real
|
||||
- `comissao_regras(id, clinica_id, procedimento_id, profissional_id, percentual, custo_lab)`.
|
||||
- Função `computeComissoes(pool, clinicaId, {inicio, fim, base, profissionalId})` agrega a produção.
|
||||
- Três níveis de regra (precedência): **override por profissional** > **por procedimento** > **padrão da clínica**.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Custo lab **sempre abatido** antes do percentual.
|
||||
2. Lançamentos com `sem_comissao=true` (garantia/reabertura do mesmo profissional, despesa de repasse) **não entram**.
|
||||
3. Base configurável (produção × recebido) — respeitar o parâmetro `base`.
|
||||
4. Mudou regra de comissão → auditar impacto em Repasses (não recalcular repasses já fechados).
|
||||
|
||||
## Fluxos
|
||||
Produção (`procedimentos_realizados` → `financeiro` RECEITA) → `computeComissoes` → **Repasse** (fechar).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Ignorar `custo_lab` no cálculo. ❌ Comissionar lançamento `sem_comissao`.
|
||||
- ❌ Alterar percentual e recalcular retroativamente repasses fechados (snapshot é imutável).
|
||||
|
||||
## Permissões
|
||||
Definição de regras: donos/admin. Ver `../FASE_01_ARQUITETURA/SKILL_RBAC.md`.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PROD[Produção do período] --> BASE[base]
|
||||
LAB[custo_lab próteses] --> CALC
|
||||
BASE --> CALC[(base − custo_lab) × %]
|
||||
REG[comissao_regras: prof > proc > clínica] --> CALC
|
||||
CALC --> REP[Repasse]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,36 @@
|
||||
# SKILL — Contratos
|
||||
|
||||
> Herda de `SKILL_Financeiro.md`. Formalização de acordos (paciente/profissional ↔ clínica) e cobrança.
|
||||
|
||||
## Conceito
|
||||
Contrato transforma um acordo (orçamento, remuneração, prestação) em documento com **modelo + variáveis +
|
||||
partes + assinaturas**, podendo **gerar cobrança** no financeiro.
|
||||
|
||||
## Entidades / fluxo real
|
||||
- `contrato_modelos` (modelos com variáveis `{{...}}`, categorias: remuneração, prestação, etc.).
|
||||
- `contratos` / instâncias (`status`: rascunho → aguardando_assinatura → assinado → vigente → encerrado/cancelado).
|
||||
- `contrato_partes` (as partes do contrato) e `contrato_assinaturas` (aceite por parte: assinado_em, ip,
|
||||
user_agent, hash) — **assinatura eletrônica de contrato** (≠ assinatura de plataforma, ver `SKILL_Assinaturas.md`).
|
||||
- Ações: `enviar` (cria assinaturas pendentes), `assinar`, `gerar-cobranca` (→ `financeiro`), `cancelar`, `duplicar`.
|
||||
|
||||
## Variáveis de remuneração (já modeladas)
|
||||
`{{PERCENTUAL}}`, `{{PERCENTUAL_REPASSE}}`, `{{VALOR}}`, `{{BASE_REPASSE}}`, `{{PRAZO_REPASSE}}` — contratos
|
||||
de comissão/percentual referenciam o mesmo conceito de Repasse.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Respeitar a máquina de estados (não pular rascunho→vigente sem assinatura).
|
||||
2. `gerar-cobranca` cria lançamento em `financeiro` (`origem='contrato'`, `contrato_id`).
|
||||
3. Assinatura grava trilha (ip/user_agent/hash) — não remover (valor probatório).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Confundir `contrato_assinaturas` (assinatura do documento) com `assinaturas` (mensalidade da plataforma).
|
||||
- ❌ Encerrar/cancelar sem auditoria.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
M[contrato_modelos] --> I[contratos: rascunho]
|
||||
I --> E[enviar → assinaturas pendentes]
|
||||
E --> A[assinar → assinado/vigente]
|
||||
A --> COB[gerar-cobranca → financeiro]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,49 @@
|
||||
# SKILL — Faturamento (visão consolidada do dinheiro)
|
||||
|
||||
> Herda de `SKILL_Financeiro.md`. Mapa de **onde o dinheiro nasce, para onde vai e quem é o responsável.**
|
||||
|
||||
## As três camadas de receita (estado real)
|
||||
1. **Receita da clínica** (operacional): produção de procedimentos, contratos/cobrança, recuperação de glosas.
|
||||
Responsável: a clínica. Tabela: `financeiro` (RECEITA).
|
||||
2. **Receita do profissional** (repasse): comissão sobre a produção. Responsável: clínica paga; profissional recebe.
|
||||
Tabelas: `comissao_regras` → `repasses` → `financeiro` (DESPESA).
|
||||
3. **Receita da plataforma**: (a) **Tutoria** — `comissao_pct` via MercadoPago (**automatizada**);
|
||||
(b) **Assinaturas** — SaaS por conta (**manual**, sem gateway); (c) **Locação de salas** — `valor` na
|
||||
reserva, **sem captura de pagamento** (lacuna).
|
||||
|
||||
## Mapa origem → destino → responsável
|
||||
| Origem | Tabela | Destino | Responsável |
|
||||
|---|---|---|---|
|
||||
| Procedimento (RECEITA) | `financeiro` | caixa da clínica | Clínica |
|
||||
| Contrato (cobrança) | `financeiro` | caixa da clínica | Clínica |
|
||||
| Convênio − Glosa | `glosas`/`financeiro` | recupera receita | Clínica |
|
||||
| Comissão → Repasse pago | `repasses`→`financeiro` DESPESA | profissional | Clínica paga |
|
||||
| Tutoria | `ortho_tutoring_request` + MercadoPago | plataforma (`comissao_pct`) + tutor (`valor_tutor`) | Plataforma |
|
||||
| Assinatura SaaS | `assinaturas` | plataforma | Plataforma (manual) |
|
||||
| Locação de sala | `sala_reservas.valor` | locador | — (sem gateway) |
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Não misturar as três camadas: clínica ≠ profissional ≠ plataforma.
|
||||
2. Toda lacuna de captura (salas, assinaturas) deve ser **sinalizada, não presumida como paga**.
|
||||
3. Mudança em qualquer camada → mapear efeito nas demais antes (ver `../FASE_08_AUDITORIA/SKILL_Fluxos.md`).
|
||||
|
||||
## Oportunidades (já mapeadas, não implementar aqui)
|
||||
- Gateway na **Locação de Salas** (receita mais próxima) e **recorrência das Assinaturas**.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Clínica
|
||||
PR[Procedimento] --> R[financeiro RECEITA]
|
||||
CON[Contrato] --> R
|
||||
R --> GL[Glosas]
|
||||
end
|
||||
subgraph Profissional
|
||||
R --> COM[Comissão] --> REP[Repasse] --> D[financeiro DESPESA]
|
||||
end
|
||||
subgraph Plataforma
|
||||
TUT[Tutoria · MercadoPago] --> PLT[comissao_pct + valor_tutor]
|
||||
ASS[Assinaturas · manual] --> PLT
|
||||
SAL[Salas · valor] -. falta gateway .-> PLT
|
||||
end
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,41 @@
|
||||
# SKILL — Financeiro (núcleo do caixa)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Multiempresa.md`. Tabela central do dinheiro: `financeiro`.
|
||||
|
||||
## Conceito
|
||||
`financeiro` registra **RECEITA** e **DESPESA** da clínica (escopo `clinica_id`). É o caixa unificado de
|
||||
onde derivam comissões, repasses e glosas.
|
||||
|
||||
## Entidades / colunas-chave (reais)
|
||||
`financeiro(id, clinica_id, descricao, valor, tipo['RECEITA'|'DESPESA'], status['Pago'|'Pendente'|...],
|
||||
formapagamento, datavencimento, data_competencia, pago_em, paciente_id, profissional_id, procedimento_id,
|
||||
agendamento_id, realizado_id, contrato_id, origem, centro_custo, fornecedor, sem_comissao, deleted_at)`.
|
||||
|
||||
## Origens (origem=...)
|
||||
- `procedimento` — gerado ao lançar Procedimento Realizado (RECEITA, se `valor>0`).
|
||||
- `contrato` — cobrança de contrato (`gerar-cobranca`).
|
||||
- `repasse` — DESPESA ao pagar repasse (`centro_custo='COMISSÕES'`, `sem_comissao=true`).
|
||||
- Lançamento manual (avulso) — RECEITA/DESPESA direto na tela.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Todo lançamento carrega `clinica_id` e `tipo`.
|
||||
2. **`sem_comissao`** marca o que NÃO deve gerar repasse (garantia, despesa de repasse).
|
||||
3. **`deleted_at`** = soft-delete (estorno reversível). Nunca DELETE físico de lançamento conciliado.
|
||||
4. RECEITA de procedimento é **opcional** (`valor>0` e `gerarLancamento!==false`) — alterar muda o caixa.
|
||||
|
||||
## Fluxos a jusante
|
||||
RECEITA → base de **Comissão**; DESPESA de repasse fecha o ciclo. Recebíveis de convênio → **Glosas**.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Apagar lançamento fisicamente. ❌ Lançar sem `clinica_id`/`tipo`.
|
||||
- ❌ Recriar comissão a partir de despesa de repasse (use `sem_comissao`).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PR[Procedimento] -->|origem=procedimento| R[financeiro RECEITA]
|
||||
CON[Contrato] -->|gerar-cobranca| R
|
||||
RP[Repasse pago] -->|origem=repasse| D[financeiro DESPESA]
|
||||
R --> COM[Comissão]
|
||||
R --> GL[Glosas]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,35 @@
|
||||
# SKILL — Repasses
|
||||
|
||||
> Herda de `SKILL_Comissoes.md`. Fechamento e pagamento da comissão ao profissional.
|
||||
|
||||
## Conceito
|
||||
Repasse é o **snapshot imutável** da comissão de um profissional num período, que vira **DESPESA** quando pago.
|
||||
|
||||
## Entidades / fluxo real
|
||||
- `repasses(id, clinica_id, profissional_id, inicio, fim, base, base_valor, custo_lab_total,
|
||||
comissao_valor, qtd_lancamentos, detalhes(JSON), status['fechado'|'pago'|'cancelado'], pago_em,
|
||||
financeiro_id, comprovante_*)`.
|
||||
- `POST /repasses/fechar` → calcula via `computeComissoes` e grava `status='fechado'` (snapshot em `detalhes`).
|
||||
- `POST /repasses/:id/pagar` → cria `financeiro` DESPESA (`origem='repasse'`, `centro_custo='COMISSÕES'`,
|
||||
`sem_comissao=true`) e marca `status='pago'` + `financeiro_id`.
|
||||
- `POST /repasses/:id/cancelar` → se estava pago, **estorna** a DESPESA (soft-delete) e zera `financeiro_id`.
|
||||
- Comprovante: `POST /repasses/:id/comprovante`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Só paga repasse **fechado**. O snapshot (`detalhes`) é **imutável** após fechar.
|
||||
2. DESPESA de repasse nasce com `sem_comissao=true` (não recomissionar).
|
||||
3. Cancelamento é **reversível** (estorno por soft-delete) — preservar.
|
||||
4. Toda transição registra `audit_log` (`registrarAudit`). Manter.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Editar valores de um repasse fechado (refazer = cancelar + novo fechamento).
|
||||
- ❌ Pagar sem gerar a DESPESA correspondente (quebra a conciliação).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
COM[Comissão do período] --> F[fechar → repasses status=fechado]
|
||||
F --> P[pagar → financeiro DESPESA]
|
||||
P --> C{cancelar?}
|
||||
C -->|sim| EST[estorna DESPESA soft-delete]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,39 @@
|
||||
# SKILL — Containers & Identidade Visual (REGRA RÍGIDA)
|
||||
|
||||
> Herda de `SKILL_DesktopWidth.md`. Preservar a identidade visual aprovada. **Não inventar design.**
|
||||
|
||||
## Padrão real de container (não regredir)
|
||||
- **Wrapper de página:** `max-w-7xl mx-auto` + `p-4 md:p-8` (definido em `App.tsx`).
|
||||
- **Cards:** fundo branco, bordas suaves (`border-gray-200`), cantos arredondados (`rounded-xl`/`2xl`),
|
||||
sombra leve. Tipografia de rótulo em caixa-alta, peso forte (`font-bold/black uppercase` em labels/menus).
|
||||
- **Sidebar:** `w-64`, branca, item ativo pintado com a **cor de marca**.
|
||||
|
||||
## Cor de marca (token oficial — NÃO hardcodar)
|
||||
- Variável CSS `--brand-color`, vinda de `activeWorkspace.cor` (default `#2563eb`; superadmin `#dc2626`).
|
||||
- Classes utilitárias existentes: `bg-brand`, `text-brand`, `border-brand`, `hover:bg-brand`, `focus:ring-brand`.
|
||||
- **Sempre** usar o token/classe de marca para realce — nunca cravar um hex novo.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Preservar cores, estilos e identidade visual** aprovados — alterações visuais exigem aprovação.
|
||||
2. Realce/seleção usa **a cor do workspace** (`--brand-color`), não cor fixa.
|
||||
3. Reutilizar componentes existentes (`PageHeader`, `Toast`, `StackModal`, `EmptyState`, `Header`) — não recriar.
|
||||
4. Espaçamento e raio consistentes com o resto do app (não introduzir novo sistema de spacing).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Hardcodar `#2563eb` (ou qualquer hex) em vez de `var(--brand-color)`/classes `*-brand`.
|
||||
- ❌ Criar um novo "design system" paralelo ou trocar a tipografia/raio/sombra padrão.
|
||||
- ❌ Container de página fora do `max-w-7xl mx-auto`.
|
||||
- ❌ Recriar modal/toast/header quando já existe componente.
|
||||
|
||||
## Validação
|
||||
- A tela nova é **indistinguível em estilo** das telas existentes? Se não, parar.
|
||||
- Trocar de workspace muda o realce conforme a cor da clínica? (token funcionando)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
WS[workspace.cor] --> VAR[--brand-color]
|
||||
VAR --> BR[classes *-brand / realces]
|
||||
COMP[Componentes existentes] --> UI[Tela consistente]
|
||||
WRAP[max-w-7xl mx-auto] --> UI
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,44 @@
|
||||
# SKILL — Desktop Width (REGRA RÍGIDA)
|
||||
|
||||
> Objetivo desta skill: **impedir que qualquer agente estique divs, quebre o desktop ou invente layout.**
|
||||
> Tudo abaixo reflete a convenção REAL do código (`frontend/App.tsx`, Tailwind 4). Não inventar valores.
|
||||
|
||||
## Regra de ouro
|
||||
**O conteúdo de toda página vive dentro do wrapper canônico:**
|
||||
```
|
||||
<div className="max-w-7xl mx-auto"> ... </div>
|
||||
```
|
||||
Esse wrapper já existe globalmente em `App.tsx` (a área de conteúdo é `max-w-7xl mx-auto` com `p-4 md:p-8`).
|
||||
`max-w-7xl` = **1280px** centralizado. **NUNCA** remover, sobrepor ou furar esse limite.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **PROIBIDO `w-screen`, `100vw`, `max-w-none` ou `max-w-full`** em containers de página no desktop.
|
||||
2. **PROIBIDO full-width**: nada de conteúdo encostando nas bordas da viewport em telas largas.
|
||||
3. **Largura máxima de conteúdo = `max-w-7xl` (1280px)**, centralizado com `mx-auto`. É o padrão do app.
|
||||
4. Subseções podem ser mais estreitas (`max-w-2xl`, `max-w-3xl`, `max-w-md` para formulários) — **nunca mais largas** que o wrapper.
|
||||
5. **Sidebar fixa `w-64` (256px)** — não alterar sem auditoria de UX.
|
||||
6. Em ultrawide (>1280px) a sobra vira **margem lateral** (centralização), nunca esticão de conteúdo.
|
||||
|
||||
## Padrão real observado (não regredir)
|
||||
- Wrapper de página: `max-w-7xl mx-auto` + `p-4 md:p-8`.
|
||||
- Larguras de cards/formulários: `max-w-md / 2xl / 3xl` conforme densidade.
|
||||
- Breakpoints usados: `sm:` `md:` `lg:` (o `xl:` é raro — **não** introduzir layouts dependentes de `xl/2xl` sem necessidade).
|
||||
|
||||
## Anti-padrões (o que QUEBRA o desktop)
|
||||
- ❌ Trocar `max-w-7xl` por `max-w-full`/`w-full` no nível da página.
|
||||
- ❌ Criar grids que se expandem indefinidamente em telas largas.
|
||||
- ❌ Remover o `mx-auto` (conteúdo cola à esquerda).
|
||||
- ❌ Inventar nova paleta/identidade (ver Containers/DesignSystem).
|
||||
|
||||
## Validação obrigatória antes de entregar
|
||||
- Conferir em **desktop largo** (≥1920px): conteúdo centralizado, margens laterais, sem esticão.
|
||||
- Conferir em **mobile**: `p-4`, coluna única, sem overflow horizontal.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
V[Viewport larga] --> M1[margem]
|
||||
V --> C[max-w-7xl · 1280px · mx-auto]
|
||||
V --> M2[margem]
|
||||
C --> CONT[Conteúdo da página]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,40 @@
|
||||
# SKILL — Grid System (REGRA RÍGIDA)
|
||||
|
||||
> Herda de `SKILL_DesktopWidth.md`. Layout responsivo **mobile-first**, como já feito no app.
|
||||
|
||||
## Padrão real (não regredir)
|
||||
O app é **mobile-first**: começa em coluna única e cresce por breakpoint. Convenção observada:
|
||||
```
|
||||
grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 (cards/listas)
|
||||
grid grid-cols-2 md:grid-cols-4 (KPIs/contadores)
|
||||
```
|
||||
Breakpoints em uso: `sm:` `md:` `lg:` (predominantes); `xl:` é raro — **não** depender dele.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Mobile-first sempre:** definir o estado base (1 coluna) e escalar com `md:`/`lg:`.
|
||||
2. **Teto de colunas em `lg:`** (até `lg:grid-cols-4`). Não criar grids que multiplicam colunas em ultrawide.
|
||||
3. Usar `gap-*` consistente com o app; não misturar grid com float/posicionamento absoluto para layout.
|
||||
4. Tabelas largas: scroll interno (`overflow-x-auto`), **nunca** estourar o `max-w-7xl`.
|
||||
5. Formulários: largura contida (`max-w-md/2xl`) e centralizada, não full-width.
|
||||
|
||||
## Casos de uso
|
||||
- Dashboard de KPIs: `grid-cols-2 md:grid-cols-4`.
|
||||
- Lista de cards: `grid-cols-1 md:grid-cols-2 lg:grid-cols-3`.
|
||||
- Form de cadastro: `max-w-2xl mx-auto`.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ `grid-cols-6`/`grid-cols-12` que esticam em telas largas sem teto.
|
||||
- ❌ Layout que só foi testado em desktop (quebra no mobile).
|
||||
- ❌ Conteúdo de grid ultrapassando o wrapper `max-w-7xl`.
|
||||
- ❌ Introduzir dependência de `xl:`/`2xl:` para o layout funcionar.
|
||||
|
||||
## Validação
|
||||
- Mobile (1 coluna, sem overflow), tablet (`md:`), desktop (`lg:`), ultrawide (centralizado, sem esticão).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
B[grid-cols-1 · base/mobile] --> M[md:grid-cols-2/3]
|
||||
M --> L[lg:grid-cols-3/4 · TETO]
|
||||
L --> X[ultrawide: centraliza, não estica]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,33 @@
|
||||
# SKILL — Build Once → Promote → Deploy
|
||||
|
||||
> Orientação de infra oficial. Fonte: `documentos-unicos/deploy/`. Implementação de referência: scoreodonto.com.
|
||||
|
||||
## Conceito
|
||||
**Push** na `main` builda a imagem **uma vez** e publica por **commit** (`:<sha>` + `:latest`) — **sem deploy**.
|
||||
A **tag `vX.Y.Z`** **re-tagueia** essa MESMA imagem (mesmo digest, sem rebuild) e deploya. **Produção nunca builda.**
|
||||
|
||||
## Garantia central
|
||||
A imagem em produção é **byte-idêntica** à que foi buildada e testada. A tag é só um rótulo de release
|
||||
sobre um artefato imutável. Validado em scoreodonto (`:v1.0.16` == `:471c2c2`, mesmo digest).
|
||||
|
||||
## Fluxo real
|
||||
```
|
||||
PUSH main (commit C) → CI build 1x → publica :C + :latest (NÃO deploya)
|
||||
TAG vX.Y.Z (em C) → CI re-tag :C → :vX.Y.Z (sem rebuild) + deploy (up --no-build)
|
||||
```
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Produção só executa imagem pronta** (`pull` + `up -d --no-build`). Nunca `build` na VPS1.
|
||||
2. **Tag exige commit já publicado** (push antes). Sem isso o CI **falha de propósito** (não builda na tag).
|
||||
3. Versão nasce da **tag git**, injetada em runtime (`APP_VERSION`), não escrita à mão.
|
||||
4. Push e tag exigem **autorização explícita do administrador**.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Buildar em produção. ❌ Tag sem push. ❌ Versão hardcoded em arquivo.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PUSH[push main · commit C] --> B[CI build 1x] --> REG[registry :C + :latest]
|
||||
TAG[tag vX.Y.Z] --> PROM[CI re-tag :C→:vX.Y.Z] --> DEP[VPS1 up --no-build]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,32 @@
|
||||
# SKILL — CI/CD (Gitea Actions)
|
||||
|
||||
> Herda de `SKILL_BuildOnce.md`. Automação de build/promote/deploy por evento git.
|
||||
|
||||
## Conceito
|
||||
O pipeline roda no **Gitea Actions**, runner `vps4-builder` (VPS4, rootless, **instance-scoped** — atende
|
||||
todos os repos). Workflow: `.gitea/workflows/build.yml`.
|
||||
|
||||
## Gatilhos reais
|
||||
- **Push na `main`** → job build: builda `scoreodonto-*:<sha>` e **publica no registry** (não deploya).
|
||||
- **Tag `v*`** → job promote/deploy: re-tag (digest idêntico) → `deploy-prod.sh` na VPS1.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. O runner builda; **produção só consome**. Não mover build para a VPS1.
|
||||
2. Segredos do CI vêm de **secrets do Gitea**, nunca commitados no repo. (Ver `⚠️ SKILL_PostgreSQL`/Registry.)
|
||||
3. Tag só promove se o commit já está no registry (senão falha proposital).
|
||||
4. Manter o pipeline idempotente e auditável (logs do run).
|
||||
|
||||
## Pré-requisitos
|
||||
- Gitea Actions habilitado no repo; runner `vps4-builder` online; `docker login` no registry.
|
||||
- SSH VPS4→VPS1 para o passo de deploy (rsync/`deploy-prod.sh`).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Credencial em texto no `build.yml`. ❌ Deploy manual fora do pipeline sem registrar.
|
||||
- ❌ Pipeline que builda na tag (quebra o Build-Once).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PUSH[push main] --> RUN[vps4-builder] --> REG[(registry)]
|
||||
TAG[tag v*] --> RUN2[vps4-builder promote] --> SSH[VPS1 deploy-prod.sh]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,33 @@
|
||||
# SKILL — Deploy Imutável & Rollback
|
||||
|
||||
> Herda de `SKILL_BuildOnce.md`. Como promover e reverter sem rebuild.
|
||||
|
||||
## Conceito
|
||||
O deploy troca **qual imagem** roda, não o código no servidor. Reverter = apontar para outra imagem.
|
||||
|
||||
## Fluxo real
|
||||
- Promover: `deploy-prod.sh <tag>` na VPS1 → `pull` + `docker compose -f docker-compose.prod.yml up -d --no-build`.
|
||||
- `docker-compose.prod.yml` usa `image:` do registry, `APP_VERSION`/`GIT_COMMIT` em runtime.
|
||||
- Rollback: `deploy-prod.sh <ref-anterior>` (segundos/minutos, só troca imagem).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Referência confiável = commit (`:<sha>`)**. Tags antigas (pré-Build-Once) podem ter sido republicadas.
|
||||
2. **Migrações são aditivas** (`ADD COLUMN IF NOT EXISTS`) → voltar o código é seguro (schema extra fica inerte).
|
||||
3. **Backup do banco antes de release sensível** (container `pg_dump -Fc` → `/home/deploy/backups/`).
|
||||
4. Validar `/api/version` e `/api/health` após deploy.
|
||||
|
||||
## Pré-requisitos de PROD (uma vez, por projeto)
|
||||
- Arquivo de segredos presente na VPS1 (env_file do compose) — **copiado manualmente, fora do git** (chmod 600).
|
||||
- `docker login git.clube67.com` na VPS1 (para o `pull`).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Reverter via rebuild. ❌ Migração destrutiva (DROP/ALTER que apaga) — quebra rollback.
|
||||
- ❌ Confiar em tag `:vX.Y.Z` como imutável se for anterior ao Build-Once.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
REG[(registry)] --> PULL[VPS1 pull :ref] --> UP[up -d --no-build]
|
||||
UP --> CHK[/api/version + /api/health/]
|
||||
CHK -->|quebrou| RB[deploy-prod.sh ref-anterior]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,34 @@
|
||||
# SKILL — Docker Rootless & Roteamento
|
||||
|
||||
> Herda de `SKILL_DeployImutavel.md`. Como os containers rodam e são expostos.
|
||||
|
||||
## Topologia real
|
||||
- **Rede privada WireGuard** `10.99.0.0/24`.
|
||||
- **VPS1 (produção):** Docker **rootless** — comandos usam `DOCKER_HOST=unix:///run/user/1000/docker.sock`.
|
||||
Roda Traefik (borda TLS) + apps (scoreodonto, rx, newwhats, subdomínio, mercado).
|
||||
- **VPS4 (dev+builder):** Docker rootless; roda `dev.<projeto>` (imagem buildada, **não** HMR) + runner.
|
||||
- **Roteamento (Traefik na VPS1):** termina TLS e roteia por host:
|
||||
`scoreodonto.com` → containers de produção locais; `dev.scoreodonto.com` → `10.99.0.4:8020` (VPS4) via WireGuard.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Na VPS1, sempre exportar `DOCKER_HOST` rootless antes de comandos `docker`.
|
||||
2. Exposição pública **só via Traefik** (TLS `certresolver=le`); apps não publicam porta na internet.
|
||||
3. `dev.<projeto>` é descartável (VPS4); produção é a real (VPS1) — **confirmar DEV ou PROD antes de agir**.
|
||||
4. Editar dev exige **rebuild + recreate** (não há hot-reload no container atual).
|
||||
|
||||
## ⚠️ Para abrir produção
|
||||
- Garantir que apenas Traefik exponha portas; conferir labels de roteador/host por app.
|
||||
- Rede WireGuard fechada; serviços de dados (VPS3) **nunca** expostos à internet.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ `docker` na VPS1 sem `DOCKER_HOST` rootless. ❌ Publicar porta de app direto na internet.
|
||||
- ❌ Confundir `dev.` (VPS4) com produção (VPS1).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
NET[Internet] -->|TLS| TR[Traefik VPS1]
|
||||
TR -->|host scoreodonto.com| APP[containers prod]
|
||||
TR -->|host dev.*| WG[WireGuard → VPS4:8020]
|
||||
APP --> DADOS[(VPS3 dados · só rede privada)]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,30 @@
|
||||
# SKILL — Gitea (código + registry + CI)
|
||||
|
||||
> Herda de `SKILL_CICD.md`. A VPS3 concentra a "fonte da verdade" do código.
|
||||
|
||||
## Papel real
|
||||
- **Código:** Gitea na **VPS3** é a fonte da verdade (repo `ruicesar/scoreodonto.com`).
|
||||
- **Registry:** Container Registry embutido do Gitea (ver `SKILL_Registry.md`).
|
||||
- **CI:** Gitea Actions + runner `vps4-builder` (ver `SKILL_CICD.md`).
|
||||
- Doc oficial da stack: repo `ruicesar/Documentos-Unicos` (local `documentos-unicos/`).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Nunca `git push --force` na `main`.** Push/tag exigem autorização do administrador.
|
||||
2. **Segredos via Gitea Secrets / webhooks**, nunca commitados.
|
||||
3. Idioma português em commits/docs (regra da stack).
|
||||
4. Webhooks/Actions antigos desligados não devem ser reativados sem auditoria.
|
||||
|
||||
## ⚠️ Higiene de repositório (para abrir produção)
|
||||
- **Não versionar `.env`/segredos.** Hoje `backend/.env` está rastreado — corrigir e **rotacionar** as
|
||||
credenciais expostas (ver `SKILL_PostgreSQL`). Confirmar `.gitignore` cobrindo `**/.env` e `.secrets`.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ `push --force` na main. ❌ Commitar segredo. ❌ Reativar webhook legado sem auditoria.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
DEV[VPS4 dev] -->|push| GITEA[Gitea VPS3]
|
||||
GITEA --> ACT[Actions · vps4-builder]
|
||||
GITEA --> REG[(Registry)]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,25 @@
|
||||
# SKILL — PostGIS (geolocalização)
|
||||
|
||||
> Herda de `SKILL_PostgreSQL.md`. Extensão geoespacial usada por busca por proximidade.
|
||||
|
||||
## Onde é usado (real)
|
||||
- Coluna `geo geography(Point,4326)` em `clinicas` e `salas` (e `cep_geo` para CEP→coordenada).
|
||||
- Suporta o **marketplace de salas** (achar salas próximas) e geocódigo de endereço.
|
||||
- O container `pgdev` é uma imagem **PostGIS** (dev espelha a capacidade da produção).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Usar `geography(Point,4326)` (lat/long padrão) — não inventar SRID.
|
||||
2. Índice espacial (GIST) quando houver busca por distância em volume.
|
||||
3. Geocódigo (`cep_geo`) é cache — tratar ausência com fallback, não quebrar o cadastro.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Guardar lat/long como texto solto em vez de tipo geográfico.
|
||||
- ❌ Busca por proximidade sem índice (varredura completa).
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
END[Endereço/CEP] --> GEO[cep_geo → ponto]
|
||||
GEO --> SAL[salas.geo]
|
||||
SAL --> PROX[busca por proximidade · marketplace]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,32 @@
|
||||
# SKILL — PostgreSQL (dados)
|
||||
|
||||
> Herda de `../FASE_01_ARQUITETURA/SKILL_Multiempresa.md`. Banco de produção e isolamento de dev.
|
||||
|
||||
## Topologia real
|
||||
- **Produção:** PostgreSQL no host da **VPS3** (`10.99.0.3:5432`), banco `scoreodonto`, user `scoreodonto_user`.
|
||||
- **DEV isolado:** container **`pgdev`** (PostGIS) na VPS4, banco `scoreodonto_dev`, user `devadmin` —
|
||||
**não toca produção**. `pg-dev-refresh.sh` / `pg-dev-reset.sh` para repuxar/limpar.
|
||||
- Acesso via WireGuard (`10.99.0.0/24`). Sem shell na VPS3 → operar por container (`pg_dump`/`pg_restore`).
|
||||
|
||||
## Regras obrigatórias
|
||||
1. **Toda query operacional filtra `clinica_id`** (tenancy — ver Multiempresa).
|
||||
2. **Migrações aditivas** no boot (`CREATE TABLE/ADD COLUMN IF NOT EXISTS`). Nunca DROP/ALTER destrutivo.
|
||||
3. **Backup antes de release sensível**: `pg_dump -Fc` → `/home/deploy/backups/`.
|
||||
4. Testar migração arriscada **sempre em `pgdev`** antes da produção.
|
||||
|
||||
## ⚠️ SEGREDOS (crítico para abrir produção)
|
||||
- **A senha do banco NÃO pode ficar em arquivo versionado nem como default em `docker-compose.yml`.**
|
||||
Hoje há default hardcoded no compose (`SCOREO_DB_PASS:-...`) e `backend/.env` está **rastreado no git** —
|
||||
isso vaza credenciais. Segredos devem vir de **env_file fora do git** (chmod 600) ou secrets do CI.
|
||||
- Rotacionar qualquer credencial que tenha entrado no histórico do git.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Query sem `clinica_id`. ❌ Migração destrutiva. ❌ Senha no compose/`.env` versionado.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
APP[Backend VPS1] -->|WireGuard| PG[(Postgres VPS3 · scoreodonto)]
|
||||
DEVAPP[Backend DEV VPS4] --> PGDEV[(pgdev · scoreodonto_dev)]
|
||||
PG --> BKP[/home/deploy/backups · pg_dump -Fc/]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,25 @@
|
||||
# SKILL — Registry de Imagens
|
||||
|
||||
> Herda de `SKILL_BuildOnce.md`. Onde os artefatos imutáveis vivem.
|
||||
|
||||
## Conceito
|
||||
Registry = **Container Registry embutido do Gitea** (`git.clube67.com`, namespace `ruicesar/`).
|
||||
Não há `registry:2` separado. Imagens: `git.clube67.com/ruicesar/scoreodonto-{backend,frontend}:<tag>`.
|
||||
|
||||
## Regras obrigatórias
|
||||
1. Imagem por **commit** (`:<sha>`) é a fonte; `:vX.Y.Z` é alias imutável do mesmo digest.
|
||||
2. `docker login git.clube67.com` na VPS1 (pull) e no runner (push) — credenciais via secrets, não no git.
|
||||
3. **Imagem enxuta**: `.dockerignore` deve excluir `node_modules`, `data/`, dumps, mídia pesada.
|
||||
(Lição do RX: camadas grandes davam PUT 500/499 no registry.)
|
||||
4. Não sobrescrever uma tag de release com código diferente (quebra a imutabilidade).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Republicar `:vX.Y.Z` apontando para outro código. ❌ Empurrar imagem gigante (sem `.dockerignore`).
|
||||
- ❌ Guardar credencial do registry em arquivo versionado.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
RUN[runner build] -->|push :sha| REG[(Gitea Registry · ruicesar/)]
|
||||
REG -->|pull :ref| VPS1[Produção]
|
||||
```
|
||||
</content>
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,47 @@
|
||||
# SKILL — Auditoria de Fluxos
|
||||
|
||||
> Objetivo: ensinar a **mapear o fluxo de negócio ponta a ponta antes de alterar** — sobretudo o do dinheiro.
|
||||
> Regra Nº1: não quebrar o que funciona. Toda mudança em fluxo financeiro exige mapeamento prévio.
|
||||
|
||||
## Fluxo principal (núcleo — verificado no código)
|
||||
```
|
||||
Lead ─converter→ Paciente + Agendamento ─presença→ Procedimento Realizado
|
||||
→ Financeiro RECEITA (origem='procedimento', flag sem_comissao)
|
||||
→ Comissão = (base − custo_lab) × % [comissao_regras + computeComissoes]
|
||||
→ Repasse FECHADO → pagar → Financeiro DESPESA (origem='repasse', centro_custo='COMISSÕES')
|
||||
```
|
||||
Ramos: Orçamento → Contrato → `gerar-cobranca` → Financeiro; Glosas sobre recebíveis de convênio.
|
||||
|
||||
## Pontos sensíveis (não quebrar)
|
||||
1. **RECEITA é opcional** no procedimento (`valor>0` e `gerarLancamento!==false`) — alterar isso muda o caixa.
|
||||
2. **`sem_comissao`** propaga garantia/reabertura e o repasse pago (evita recomissionar). Manter.
|
||||
3. **Repasse cancelado estorna** a despesa (soft-delete). Preservar a reversibilidade.
|
||||
4. **Anti-overbooking** na conversão de lead e na agenda — não remover a checagem.
|
||||
5. **Marketplace**: só Tutoria captura pagamento (MercadoPago); Salas tem `valor` sem gateway.
|
||||
|
||||
## Como auditar um fluxo (comandos)
|
||||
```bash
|
||||
# Achar o handler de uma etapa
|
||||
grep -n "repasses/fechar\|procedimentos-realizados\|leads/:id/converter" backend/server.js
|
||||
# Ver o que cada etapa INSERE/ATUALIZA
|
||||
grep -nE "INSERT INTO (financeiro|repasses|procedimentos_realizados)" backend/server.js
|
||||
# Conferir auditoria
|
||||
grep -n "registrarAudit" backend/server.js | head
|
||||
```
|
||||
|
||||
## Checklist antes de alterar um fluxo
|
||||
1. Onde começa, onde termina, o que cada etapa grava (tabela + colunas)?
|
||||
2. Há `audit_log` (`registrarAudit`) na etapa? Manter.
|
||||
3. A mudança afeta comissão/repasse/caixa? Mapear o impacto a jusante.
|
||||
4. Existe reversão (estorno/soft-delete)? Não quebrá-la.
|
||||
5. Validar em `dev.scoreodonto.com` com banco `pgdev` antes de qualquer promoção.
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Alterar geração de RECEITA/DESPESA sem mapear o efeito em Comissões/Repasses.
|
||||
- ❌ Remover flags `sem_comissao`/`deleted_at` (quebram não-duplicação e estorno).
|
||||
- ❌ Mexer no fluxo sem reproduzir ponta a ponta em DEV.
|
||||
|
||||
## Entregável
|
||||
Diagrama Mermaid do fluxo + tabela etapa→tabela→efeito + riscos. (Modelo:
|
||||
`documentação/MAPA-FUNCIONAL-COMPLETO.md`, Etapas 4 e 8.)
|
||||
</content>
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,43 @@
|
||||
# SKILL — Auditoria de Rotas
|
||||
|
||||
> Objetivo: ensinar qualquer agente a **mapear e entender as rotas antes de alterar** — front e back.
|
||||
> Regra Nº1: não quebrar o que funciona. Sempre Auditoria → Planejamento → Aprovação.
|
||||
|
||||
## Onde a verdade está
|
||||
- **Frontend (navegação):** `frontend/App.tsx` — `ROUTE_MAP` (URL→view), `VIEW_TO_ROUTE` (view→URL),
|
||||
`renderView()` (view→componente), `isViewAllowed()` (RBAC), e o filtro de menu em `components/Sidebar.tsx`.
|
||||
Não há `react-router` — o roteamento é próprio.
|
||||
- **Backend (API):** `backend/server.js` — **277 rotas** `app.<método>('/api/...')`, quase todas com `tenantGuard`.
|
||||
|
||||
## Como mapear (comandos de auditoria)
|
||||
```bash
|
||||
# Rotas de API (método + caminho)
|
||||
grep -oE "app\.(get|post|put|delete|patch)\('[^']+" backend/server.js | sort -u
|
||||
# Rotas do frontend (URL → view)
|
||||
sed -n '/ROUTE_MAP/,/};/p' frontend/App.tsx
|
||||
# Permissões por papel
|
||||
sed -n '/isViewAllowed/,/^ };/p' frontend/App.tsx
|
||||
sed -n '/menuItems/,/];/p' frontend/components/Sidebar.tsx
|
||||
```
|
||||
|
||||
## Checklist antes de mexer numa rota
|
||||
1. A URL existe em **ambos** `ROUTE_MAP` e `VIEW_TO_ROUTE`? (senão deep-link quebra)
|
||||
2. Qual `isViewAllowed`/menu libera essa view e para quais papéis?
|
||||
3. Qual rota de API ela consome? Tem `tenantGuard` (escopo de clínica)?
|
||||
4. Quais tabelas a rota toca? (ver `SKILL_Banco.md`/`SKILL_Entidades.md`)
|
||||
5. Alterou acesso no back? **Espelhe** em `isViewAllowed` + `Sidebar` no mesmo PR.
|
||||
|
||||
## Débitos conhecidos a vigiar (já auditados)
|
||||
- `/comissoes`, `/glosas`, `/cadastro-dentista`: existem em `VIEW_TO_ROUTE` mas **faltam em `ROUTE_MAP`**
|
||||
→ deep-link/refresh cai em `dashboard`. (Documentado em `MAPA-FUNCIONAL-COMPLETO.md`.)
|
||||
- `/admin/sync`: rota existe, mas `isViewAllowed` retorna `false` sempre (tela inacessível).
|
||||
|
||||
## Anti-padrões
|
||||
- ❌ Adicionar view sem registrar nas DUAS direções (`ROUTE_MAP` + `VIEW_TO_ROUTE`).
|
||||
- ❌ Liberar tela no menu sem proteger a rota de API correspondente.
|
||||
- ❌ Alterar caminho de API sem buscar todos os consumidores no frontend (`services/backend.ts`).
|
||||
|
||||
## Entregável da auditoria
|
||||
Tabela URL → view → componente → papéis → rota(s) de API → tabelas, + riscos. (Modelo:
|
||||
`documentação/MAPA-FUNCIONAL-COMPLETO.md`, Etapa 1.)
|
||||
</content>
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Skill Enterprise
|
||||
|
||||
## Objetivo
|
||||
Executar auditoria e evolução sem quebrar funcionalidades existentes.
|
||||
|
||||
## Checklist Obrigatório
|
||||
- Mapear impacto.
|
||||
- Mapear dependências.
|
||||
- Mapear entidades.
|
||||
- Mapear APIs.
|
||||
- Mapear permissões.
|
||||
- Validar desktop.
|
||||
- Validar mobile.
|
||||
- Atualizar documentação.
|
||||
|
||||
## UI Desktop
|
||||
- Preservar cores.
|
||||
- Preservar estilos.
|
||||
- Preservar identidade visual.
|
||||
- Corrigir larguras excessivas.
|
||||
- Aplicar max-width.
|
||||
- Evitar telas ultrawide desbalanceadas.
|
||||
|
||||
## Entregáveis
|
||||
- Relatório técnico.
|
||||
- Relatório negócio.
|
||||
- Mermaid.
|
||||
- Riscos.
|
||||
- Plano de execução.
|
||||
Reference in New Issue
Block a user