# Checkpoint G2 — RBAC aplicado (API + banco + UI + e2e) — 2026-07-16
Status: COMPLETO

## 1. Entregue nesta fase

| Feature | Título | Commit | Verificação |
|---|---|---|---|
| G2-01 | Matriz role×endpoint aplicada server-side em /api/v1 | 4e90ad4 | gov-verifier PASS 2026-07-16 (2ª rodada; 1 finding reparado) |
| G2-02 | Papel de membro editável pós-convite (API + UI + audit) | b157aee | gov-verifier PASS 2026-07-16 (1ª rodada) |
| G2-03 | RLS por role nas tabelas de configuração + invariantes verdes | f3954ab | gov-verifier PASS 2026-07-16 (1ª rodada) |
| G2-04 | E2E de papéis (Playwright) | da453e4 | gov-verifier PASS 2026-07-16 (1ª rodada) |

## 2. Evidências (prova, não afirmação) — gates da fase G2

**Gate "matriz role×endpoint server-side (não só RLS, não só UI)"** — helper único
`lib/auth/require-role.ts` (getUser + fn_user_role_in_org + fail() 403 padronizado
+ audit `authz.denied`), aplicado a ~47 rotas de /api/v1 conforme spec 13 §4.
Prova mecânica: `tests/unit/rbac-matrix.test.ts` (12 testes, 403 para role
insuficiente + 200 para role mínimo por grupo de rota) + `lib/auth/require-role.test.ts`
(9 testes). Suíte unit da fase: **123/123 verdes**.

**Gate "papel de membro editável pós-convite, com audit"** — PATCH canônico
`/api/v1/team/[user_id]` (lógica única em `_shared.ts`, `/role` mantido como alias),
guard de último admin (409, provado ao vivo), audit `team.role_changed` com
old/new_role (linha real observada em api_audit_log no dev). UI: seletor inline na
página Equipe (admin only, nunca na própria linha), otimista com rollback + toast.
Screenshot: `loop/checkpoints/evidence/G2/G2-02-team-role-selector.png`.

**Gate "invariantes de RBAC de G1 todos verdes (flip dos test.fails)"** — os 2
`it.fails` GAP(G2) de `tests/invariants/gov-1-rbac.test.ts` flipados para testes
normais na G2-03 (commit f3954ab com `DESKCOMM_GOV_INVARIANTS_EDIT=1` citando o
flip) após a migration 0030 (tripla completa: migrations/ + apêndice baseline +
MANIFEST; `check-migration-triple.sh` exit 0; NNNN 0030 inédito nas 10 branches).
`pnpm test:db`: install (ON_ERROR_STOP=1) + update (re-apply) verdes; **35/35
invariantes verdes no Postgres descartável pós-update**, incluindo o novo
`gov-1-rbac-config-write.test.ts` (manager escreve config, agent não; viewer
read-only em conversations; SELECTs preservados byte-idênticos — leitura NÃO foi
estreitada, escopo own é G4-01).

**Gate "E2E de papéis passa"** — `tests/e2e/rbac-roles.spec.ts`: agent →
api-tokens/billing → 403 renderizado; admin entra com **login MFA TOTP real**
(challenge em /login/mfa, código gerado de `tests/e2e/utils/totp.ts`, RFC 6238,
zero dependência nova); agent vê inbox e kanban; viewer → POST /api/v1/messages →
403 `forbidden_role`. Run do verifier: **12 passed / 1 failed (32.4s)** — o único
vermelho é `error-pages.spec.ts` "/500", **pré-existente** (rota app/500 nunca
existiu; vem do EPIC-12, commit 5d0cdb5, ancestral de main; independência do diff
provada em 3 eixos). Axe (serious/critical) zerado em /403, api-tokens, billing,
inbox e kanban, com 1 exclusão documentada (tablist do InboxFilters, violação
pré-existente). Screenshot: `evidence/G2/G2-04-agent-billing-403.png`.

## 3. Pendências (cópia auditável da inbox operacional)

- **INB-03 (open, needs_human, da G2-01)** — follow-ups não-vetantes: (1)
  `onboarding/whatsapp/session` POST cria channel_session sem gate de role (a rota
  equivalente channel-sessions exige admin) — gate admin aqui também? Recomendação:
  sim, por consistência. (2) `leads/bulk action=assign` tem piso agent hoje; o
  endpoint batch da G3-04 já nasce ≥manager — nota pra G3-04 não esquecer.
- **INB-04 (open, needs_human, da G2-02)** — race no guard de último admin
  (check-then-write sem lock, pré-existente do EPIC-09): 2 PATCHes simultâneos
  podem rebaixar os 2 últimos admins. (A) fechar com constraint/trigger
  (mini-feature, migration tripla) · (B) aceitar o risco. Recomendação: A.
- **INB-05 (open, proposal, da G2-03)** — spec 13 §4 nota 8 prevê `api_audit_log`
  SELECT manager+ "aplicada em G2", mas nenhuma feature G2 cobre; segue admin-only.
  (A) manter admin-only e corrigir a nota da spec · (B) mini-feature nova.
  Recomendação: A.

## 4. Riscos observados na construção

- `error-pages.spec.ts` "/500" é vermelho crônico (rota nunca existiu) — merece
  forward-fix fora do épico pra suíte e2e voltar a ser binária.
- Violação axe pré-existente no tablist do InboxFilters (aria-controls para
  painel não renderizado) — excluída de forma documentada no spec novo; corrigir
  quando G4-02 tocar o inbox.
- `member.role_changed` fica no union de audit sem emissor (doutrina append-only;
  histórico antigo permanece válido) — cosmético, sem ação.
- O gate admin-only de `billing/page.tsx` não existia (agent renderizava billing);
  adicionado na G2-04 como desvio mínimo aprovado pelo verifier — sinal de que
  outras páginas podem ter gates de UI faltando mesmo com a API fechada (a G2-01
  fechou o server-side; auditoria de páginas não era acceptance de nenhuma feature).
- Race do último admin (INB-04) documentada acima.

## 5. O que a PRÓXIMA fase (G3) precisa

- Aprovação deste checkpoint (`loop/checkpoints/G2.approved`).
- Decisões do dono nos INB-03/04/05 (nenhuma bloqueia G3-01, mas INB-03.2 toca a
  G3-04 e INB-04 pode virar mini-feature da G3).
- Nada de infra nova: G3-01 (eventos de atribuição) usa o harness test:db/invariants
  já operante; decisões de produto G1-06 (transferência imediata, reuso do role
  agent) já transcritas na spec 13.

## 6. Custo da fase

- 4 sessões do loop (started 21:53, 22:32, 22:53, 23:09 — sessions.log), todas
  fechadas com PASS na mesma noite de 2026-07-16 (~1h40 de parede no total).
- 1 rodada de reparo (G2-01); zero features bloqueadas; teto diário atingido
  exatamente na última sessão (12/12).