docs(salas): registra fix de menu + feature de manutenção/operador na análise da recepção

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

doc/ANALISE-AREA-RECEPCAO-TC.md

@@ -113,3 +113,46 @@ Dois lados do mesmo fluxo, unidos pela mesma `protese_os`:
 - **Fase 2** → casa do **protético** (quem produz; avança status na Bancada).
 - **Esta análise** → **recepção/TC** (quem encomenda e acompanha; lê o status no hub).
 O status que o lab avança é o mesmo que a recepção lê — o "Lab Case Manager" repartido entre os papéis.
+
+---
+
+## 6. Salas: acesso do funcionário corrigido + bloqueio de manutenção (23/jun)
+
+Gatilho: a mesma recepcionista aparecia com **MINHAS SALAS** e **ALUGAR SALAS** (gestão de
+locação, de titular) e deveria ter apenas a **agenda da sala** e o **bloqueio para manutenção**.
+
+### 6a. Bug — vazamento dos menus de locação ✅ corrigido (`Sidebar.tsx`)
+`MINHAS SALAS` (locador) e `ALUGAR SALAS` (locatário) eram empurrados a "todos menos
+superadmin" (`Sidebar.tsx:42`), vazando para **funcionário e paciente** — papéis que não são
+titulares de sala. Passaram a exibir apenas a `PAPEIS_LOCACAO`
+(`donosala/donoclinica/donoconsultorio/admin/dentista/biomedico/protetico`). O backend já era
+seguro por ownership; era vazamento só de UI.
+
+### 6b. Feature — acesso operacional + manutenção ✅ implementada e validada no DEV
+Não existia caminho para "funcionário vê só a agenda" nem "bloqueio para manutenção" — foram
+criados (modelos de mercado: *Dentrix/Open Dental Lab... não; aqui é gestão de espaço* — o
+padrão é **front desk opera a agenda da sala sem tocar no financeiro do locador**).
+
+- **Acesso operacional** (`server.js` `listarWorkspaces`): sala cuja `clinica_id` é uma clínica
+  onde o usuário tem vínculo (e ele **não** é o dono) entra como workspace `tipo='sala'` com
+  `papel_sala='operador'`. O `SalaHomeView` detecta o modo operador e **esconde recebíveis,
+  relatório e baixa** — mostra só a **agenda** + botão de bloqueio.
+- **Bloqueio de manutenção** (`POST /api/salas/:id/manutencao`): reserva `tipo='manutencao'`
+  (coluna nova, default `'locacao'`), `valor=0`, nasce `'confirmada'` (sem aprovação) e **não
+  gera recebível**. Acesso: dono **ou** membro com vínculo na clínica da sala. Reaproveita o
+  anti-conflito de horário (409) e o cancelamento por solicitante/unidade. A agenda renderiza
+  o bloqueio em **cinza** (legenda "Manutenção").
+
+**Validação ponta a ponta (DEV, JWT real da recepcionista, sala de teste vinculada à clínica):**
+| Caso | Resultado |
+|---|---|
+| Sala da clínica vira workspace operador dela | ✅ query retorna a sala |
+| POST bloqueio | ✅ `status:confirmada, tipo:manutencao` |
+| GET agenda mostra bloqueio + motivo | ✅ `valor:0, motivo:"Conserto do equipo"` |
+| Conflito de horário | ✅ HTTP 409 |
+| Não gera financeiro | ✅ 0 lançamentos |
+
+Commits: `fix(salas)` (menu) + `feat(salas)` (operador + manutenção). Backend e frontend no ar
+no DEV; dados de teste limpos.
+
+> ⚠️ Pendente de push + deploy (produção segue em v1.0.19).