Documento de construção
PRD recebido no pacote de 2026-09-18. Ver Análise PRDs × v0.3 antes de implementar: a taxonomia deste pacote ainda está em conflito com as notas do v0.3.
Orquestro — Incremento 1 — Fundação
Versão: 1.0 — Freeze Candidate
Status: Especificado para protótipo/desenvolvimento após revisão técnica
Escopo: tenant, usuário, permissões, empresa, histórico, documentos e rastreabilidade
Gate principal: Gate D — Segurança
Fonte de verdade: Product Blueprint / MVP Freeze Candidate vigente do Orquestro
A Fundação cria a base segura, rastreável e isolada sobre a qual todo o restante do Orquestro irá operar.
1. Objetivo do incremento
Ao final deste incremento, deve ser possível:
uma empresa acessar seu próprio ambiente → possuir usuários → controlar quem pode fazer o quê → armazenar documentos → registrar histórico → rastrear ações importantes → impedir acesso entre empresas.
Este incremento não tem como objetivo fazer inteligência comercial. Ele constrói o chão necessário para que os próximos incrementos funcionem com segurança, histórico e rastreabilidade.
Princípios aplicáveis
- simples na tela; sofisticado por trás;
- segregação entre empresas;
- acesso baseado em necessidade;
- minimização de dados;
- proteção de documentos;
- rastreabilidade;
- histórico preservado;
- autorização no frontend e no backend;
- nenhuma ação crítica sem registro suficiente;
- nenhuma validação humana substituída por inferência da IA.
2. Escopo funcional
| Código | Capacidade |
|---|---|
| FND-01 | Ambiente da empresa / tenant |
| FND-02 | Entrar e acessar o Orquestro |
| FND-03 | Usuários, equipe e acessos |
| FND-04 | Perfis e permissões |
| FND-05 | Documentos base |
| FND-06 | Histórico, versões e rastreabilidade |
Telas diretamente ligadas ao incremento
- F01 — Entrar
- F02 — Equipe e acessos
- A01 — Histórico e rastreabilidade
Componentes internos
OrganizationUserMembershipPermissionDocumentDocumentRelationAuditEvent
3. FND-01 — Ambiente da empresa / tenant
3.1 Contexto e objetivo
Cada empresa cliente do Orquestro deve operar em um ambiente próprio e isolado.
Internamente o sistema pode usar o conceito de tenant, mas o cliente não precisa ver esse termo na interface.
A regra é absoluta:
Um usuário de uma empresa nunca pode visualizar dados de outra empresa.
3.2 Objeto principal — Organization
Campos mínimos neste incremento:
id
nome_do_ambiente
status
created_at
updated_atStatus:
ACTIVE
SUSPENDEDO cadastro comercial completo da empresa será desenvolvido no Incremento 2.
3.3 Regra estrutural
Todo objeto pertencente ao cliente deve carregar uma associação inequívoca à organização:
organization_idNão deve existir objeto comercial de cliente sem vínculo de organização.
3.4 Isolamento obrigatório
O isolamento deve existir em duas camadas:
- Interface: o usuário só visualiza sua empresa.
- Backend/banco/API: mesmo alterando URL, ID ou requisição, o usuário não consegue acessar objeto de outra empresa.
Esconder botão não é controle de acesso suficiente.
3.5 Exceções
Organização suspensa
- bloqueia acesso normal;
- não apaga dados;
- não apaga documentos;
- não apaga histórico.
Mensagem sugerida:
Seu acesso a este ambiente está temporariamente indisponível. Entre em contato com o administrador.
Usuário com acesso a múltiplas empresas
Não é requisito funcional do primeiro MVP.
A arquitetura não deve impedir evolução futura, mas não haverá seletor de múltiplos ambientes agora.
4. FND-02 — Entrar e acessar o Orquestro
4.1 Tela F01 — Entrar
Conteúdo mínimo
Bem-vindo ao Orquestro
- Acesso
- Botão Entrar
- Link/ação Preciso recuperar meu acesso
O mecanismo técnico de autenticação — senha, código, link seguro ou provedor externo — permanece decisão técnica.
O requisito de produto é:
somente usuário autenticado, ativo e vinculado a uma organização ativa pode acessar o ambiente.
4.2 Caminho feliz
usuário informa credencial
↓
sistema autentica
↓
confirma usuário ativo
↓
confirma vínculo ativo com organização
↓
carrega permissões
↓
abre o ambiente corretoPrimeiro acesso:
convite recebido
↓
usuário confirma acesso
↓
conta ativada
↓
entra no ambiente4.3 Estados da tela
Carregando
Entrando…
Impedir submissões duplicadas.
Credencial inválida
Não conseguimos confirmar seu acesso. Confira os dados e tente novamente.
Não revelar desnecessariamente se determinado e-mail existe.
Usuário desativado
Seu acesso a este ambiente não está ativo. Fale com o administrador da sua empresa.
Organização suspensa
Mensagem diferente da credencial incorreta.
Falha técnica
Não conseguimos entrar agora. Tente novamente.
Nunca simular sucesso.
5. FND-03 — Usuários, equipe e acessos
5.1 Tela F02 — Equipe e acessos
Título:
Equipe e acessos
Texto de apoio:
Veja quem pode usar o Orquestro e o que cada pessoa pode acessar.
Botão:
+ Adicionar pessoa
Lista mínima:
| Pessoa | Perfil | Status | Ações | |
|---|---|---|---|---|
| Exemplo | usuario@empresa.com | Administrador | Ativo | … |
5.2 Adicionar usuário
Campos:
- Nome
- Perfil
Perfis MVP:
- Administrador
- Usuário comercial
Ação:
Enviar convite
5.3 Estados do vínculo do usuário
INVITED
ACTIVE
DISABLEDINVITED
Convite criado/enviado, mas acesso ainda não ativado.
ACTIVE
Usuário pode acessar conforme suas permissões.
DISABLED
Usuário não pode mais entrar, mas seu histórico e autoria permanecem.
5.4 Reenviar convite
Se o vínculo ainda estiver INVITED, permitir Reenviar convite sem criar usuário duplicado.
5.5 Desativar usuário
Mensagem sugerida:
Desativar acesso de [nome]?
Essa pessoa não poderá mais entrar no Orquestro. O que ela já registrou continuará no histórico.
Ações:
- Cancelar
- Desativar acesso
5.6 Reativar usuário
Administrador pode reativar usuário desativado.
A autoria passada continua intacta.
5.7 Proteção contra ausência de administrador
A organização não pode terminar sem nenhum administrador ativo.
Se o único administrador tentar se desativar ou perder o perfil administrativo:
Adicione outro administrador antes de remover seu próprio acesso administrativo.
6. FND-04 — Perfis e permissões
6.1 Perfis mínimos do MVP
Administrador
Pode, no mínimo:
- configurar empresa;
- gerenciar usuários;
- visualizar dados comerciais globais;
- gerenciar parâmetros internos;
- consultar histórico administrativo;
- receber, por padrão, acesso financeiro sensível.
Usuário comercial
Pode, no mínimo:
- trabalhar leads e oportunidades permitidos;
- registrar interações;
- gerar materiais;
- acompanhar seus casos.
As capacidades comerciais serão habilitadas nos incrementos seguintes.
6.2 Matriz mínima
| Ação | Administrador | Comercial |
|---|---|---|
| Acessar ambiente | ✓ | ✓ |
| Editar dados básicos da empresa | ✓ | — |
| Gerenciar usuários | ✓ | — |
| Alterar perfis/permissões | ✓ | — |
| Ver todos os leads/oportunidades | ✓ | Conforme acesso |
| Trabalhar casos permitidos | ✓ | ✓ |
| Registrar interações | ✓ | ✓ |
| Gerar materiais | ✓ | ✓ |
| Ver histórico dos próprios casos | ✓ | ✓ |
| Ver histórico global | ✓ | — |
| Gerenciar parâmetros internos | ✓ | — |
6.3 Informações financeiras sensíveis
Permissão transversal:
VIEW_SENSITIVE_FINANCIAL_DATADeve poder proteger, no mínimo:
- valor/hora;
- custos internos;
- margem;
- remuneração;
- rentabilidade;
- outras premissas financeiras sensíveis.
No MVP:
- Administrador: ativa por padrão;
- Usuário comercial: desativada por padrão, podendo ser concedida pelo Administrador.
6.4 Regra de backend
Se o usuário não possui permissão para um dado sensível, o backend não deve retornar o valor.
Não basta esconder o componente visual.
6.5 Rastreabilidade da mudança
Mudanças de perfil ou permissão registram:
usuário afetado
estado anterior
estado novo
quem alterou
data/hora7. FND-05 — Documentos base
7.1 Objetivo
Criar a infraestrutura de documentos que será utilizada pelos próximos incrementos.
Uploads poderão futuramente alimentar:
- identidade comercial;
- propostas anteriores;
- histórico;
- clientes;
- casos;
- organograma;
- contratos e outros documentos relevantes.
Todo dado extraído futuramente deve conseguir preservar a relação com o documento-fonte.
7.2 Objeto Document
id
organization_id
nome_original
nome_exibicao
categoria
status
uploaded_by
uploaded_at
source_context
version
archived_at
archived_by7.3 Estados mínimos
UPLOADING
AVAILABLE
ERROR
ARCHIVED7.4 Categorias iniciais
GENERAL
COMPANY
COMMERCIAL_EVIDENCE
CLIENT
CASEA estrutura deve aceitar evolução para categorias como:
ORGANIZATIONAL_CHART
PROPOSAL
CONTRACTsem remodelagem estrutural.
7.5 Upload
Componente genérico:
+ Anexar arquivo
Em andamento
Enviando arquivo…
Sucesso
Arquivo adicionado.
Falha
Não conseguimos enviar este arquivo. Tente novamente.
Falha de upload não deve apagar os demais dados já preenchidos na tela.
7.6 Relação entre documento e objeto
Objeto lógico:
DocumentRelation
document_id
object_type
object_id
relationship_typeExemplos futuros:
organograma → empresa
proposta antiga → evidência comercial
contrato → oportunidade7.7 Arquivamento
Documento que já serviu como fonte relevante não deve desaparecer silenciosamente.
A ação padrão será Arquivar, preservando relações e histórico.
A exclusão física definitiva, se existir, será tratada na política técnica específica de documentos.
8. FND-06 — Histórico, versões e rastreabilidade
8.1 Princípio
Informações relevantes não devem desaparecer silenciosamente.
Quando substituídas, deve ser possível preservar:
- versão anterior;
- alteração realizada;
- responsável;
- data.
8.2 Diferença entre histórico e auditoria
Histórico
Mostra como a informação mudou ao longo do tempo.
Auditoria
Mostra quem fez o quê, quando e em qual objeto.
8.3 Objeto AuditEvent
id
organization_id
actor_user_id
object_type
object_id
action
from_state
to_state
change_summary
justification
created_at
ai_run_reference
human_validationOs dois últimos campos ficam preparados para incrementos futuros.
8.4 Ações base
CREATED
EDITED
STATUS_CHANGED
USER_INVITED
USER_ACTIVATED
USER_DISABLED
ROLE_CHANGED
PERMISSION_CHANGED
DOCUMENT_UPLOADED
DOCUMENT_ARCHIVED
VERSION_CREATEDNos incrementos futuros poderão entrar:
AI_SUGGESTED
HUMAN_VALIDATED
HUMAN_ADJUSTED
HUMAN_REJECTED8.5 Tela A01 — Histórico e rastreabilidade
Disponível ao Administrador no MVP.
Caminho:
Configurações → Histórico e rastreabilidade
Exemplo de visualização:
Hoje
09:41 — Letícia adicionou Rebeca como Usuário comercial.
09:38 — Camila alterou uma permissão de Letícia.
Filtros mínimos
- Pessoa
- Tipo de ação
- Período
Detalhe de evento
- O que aconteceu
- Pessoa/objeto afetado
- Antes
- Depois
- Quem fez
- Quando
A interface não deve exigir interpretação de JSON ou termos técnicos.
8.6 Versionamento
Auditoria e versionamento não são a mesma coisa.
Objetos que necessitarem de versão devem poder usar:
version
previous_version_idO versionamento detalhado de proposta, solução, apresentação e condições será usado nos incrementos correspondentes.
8.7 Regra para ações administrativas críticas
Para operações críticas como:
- mudança de perfil;
- mudança de permissão;
- desativação de usuário;
não confirmar silenciosamente sucesso se o registro obrigatório de auditoria não puder ser persistido.
9. Regra central da IA dentro da Fundação
Neste incremento, a IA praticamente não precisa atuar.
A Fundação apenas prepara a infraestrutura para os próximos fluxos:
IA sugere
↓
registro da sugestão
↓
humano revisa
↓
humano valida, ajusta ou rejeita
↓
auditoria registraNunca:
IA sugere
↓
status vira aprovado automaticamenteNenhum Human Gate futuro poderá ser ultrapassado apenas por inferência da IA.
10. Estados transversais obrigatórios de interface
Toda tela ou operação relevante deste incremento deve prever:
Carregando
O usuário sabe que o sistema está processando.
Sem dados
Explicar que ainda não há informação e qual é o próximo passo.
Exemplo:
Ainda não há outros usuários. Adicione alguém quando quiser trabalhar em equipe.
Erro
- explicar em linguagem simples o que falhou;
- preservar dados já digitados;
- permitir tentar novamente quando aplicável;
- nunca inventar resultado.
Sem permissão
Você não tem acesso a esta informação.
Não mascarar falta de permissão como erro técnico genérico.
Registro não encontrado
Não revelar se o objeto existe em outro tenant.
Upload em andamento
Status explícito.
Upload com falha
Nunca marcar como AVAILABLE.
11. Modelo de dados lógico do Incremento 1
ORGANIZATION
│
├── MEMBERSHIPS
│ └── USER
│
├── PERMISSIONS
│
├── DOCUMENTS
│ └── DOCUMENT_RELATIONS
│
└── AUDIT_EVENTSUser
Identidade da pessoa.
Organization
Ambiente da empresa.
Membership
Liga:
User ↔ OrganizationE carrega:
role
statusPermission
Permissões específicas e exceções.
Document
Arquivo e metadados.
DocumentRelation
Vínculo entre documento e objeto do Orquestro.
AuditEvent
Rastreabilidade de ações relevantes.
12. Caminho feliz completo do Incremento 1
Empresa cliente existe
↓
Administrador recebe/acessa convite
↓
entra no Orquestro
↓
ambiente correto é carregado
↓
Administrador abre Equipe e acessos
↓
adiciona outro usuário
↓
novo usuário recebe convite
↓
ativa acesso
↓
entra no mesmo ambiente
↓
permissões corretas são aplicadas
↓
documento pode ser anexado
↓
ações relevantes ficam registradas
↓
nenhum dado cruza empresas13. Casos de exceção obrigatórios
| Situação | Comportamento esperado |
|---|---|
| Usuário tenta entrar desativado | acesso negado, histórico mantido |
| Organização suspensa | acesso ao ambiente bloqueado |
| Usuário tenta acessar outro tenant | bloqueado |
| URL contém ID de objeto externo | bloqueado sem revelar conteúdo |
| Convite expirado/inválido | permitir solicitar novo convite |
| Convite já utilizado | não criar conta duplicada |
| E-mail já pertence a usuário | reutilizar identidade quando aplicável |
| Admin muda perfil | registrar antes/depois |
| Único admin tenta sair | impedir até existir outro admin |
| Upload falha | preservar tela e permitir tentar novamente |
| Documento arquivado | histórico e relações permanecem |
| Usuário sem permissão financeira | dado não retorna na camada autorizada |
| Auditoria falha durante ação crítica | não confirmar silenciosamente a ação como concluída |
14. O que não entra no Incremento 1
Para preservar o escopo da Fundação, ficam fora agora:
- identidade comercial detalhada;
- propostas anteriores;
- ofertas;
- clientes;
- mercado;
- pessoas de entrega;
- organograma;
- capacidade;
- terceirização de entrega;
- leads;
- pesquisa pública;
- IA comercial;
- precificação;
- propostas comerciais;
- dashboards comerciais;
- integrações extensas;
- SSO corporativo avançado;
- matriz complexa de dezenas de cargos.
Organograma e terceirização de entrega permanecem aprovados para o Incremento 2.
15. Requisitos funcionais numerados
A. Ambiente da empresa e isolamento
FND-REQ-001 — Criar ambiente isolado por empresa
Prioridade: MUST
Cada empresa cliente deve possuir um ambiente próprio identificado internamente por organization_id.
Aceite: todo objeto pertencente ao cliente possui associação inequívoca à organização.
FND-REQ-002 — Impedir visualização entre empresas
Prioridade: MUST
Usuário vinculado à Empresa A não pode visualizar dados da Empresa B.
FND-REQ-003 — Impedir acesso cruzado no backend
Prioridade: MUST
O isolamento deve ser aplicado também via backend/API, não apenas na interface.
FND-REQ-004 — Não revelar existência de objeto externo
Prioridade: MUST
Tentativa de acesso a objeto de outra organização não deve revelar conteúdo nem informações úteis sobre sua existência.
FND-REQ-005 — Suspender organização sem apagar histórico
Prioridade: MUST
Organização suspensa bloqueia acesso, mas não exclui dados, documentos ou histórico.
B. Autenticação e acesso
FND-REQ-006 — Exigir autenticação
Prioridade: MUST
Nenhuma área privada pode ser acessada sem autenticação válida.
FND-REQ-007 — Validar vínculo com empresa
Prioridade: MUST
Acesso exige usuário autenticado + Membership ativo + Organization ativa.
FND-REQ-008 — Bloquear usuário desativado
Prioridade: MUST
Usuário DISABLED não pode acessar o sistema e mantém autoria/histórico.
FND-REQ-009 — Bloquear organização suspensa
Prioridade: MUST
Mesmo com usuário ativo, organização SUSPENDED não pode ser acessada normalmente.
FND-REQ-010 — Exibir autenticação em andamento
Prioridade: MUST
Mostrar processamento e impedir submissão duplicada.
FND-REQ-011 — Tratar falha de autenticação
Prioridade: MUST
Falha deve manter o usuário fora e apresentar mensagem clara.
FND-REQ-012 — Recuperação de acesso
Prioridade: MUST
A tela deve possuir caminho funcional para recuperação de acesso.
C. Usuários e vínculo
FND-REQ-013 — Administrador pode adicionar usuário
Prioridade: MUST
Permitir nome, e-mail, perfil e envio de convite.
FND-REQ-014 — Estados do vínculo
Prioridade: MUST
Suportar INVITED, ACTIVE e DISABLED.
FND-REQ-015 — Evitar duplicidade desnecessária
Prioridade: MUST
Se o e-mail já corresponder a um usuário existente, reutilizar identidade quando permitido.
FND-REQ-016 — Reenviar convite
Prioridade: MUST
Reenvio não cria novo Membership.
FND-REQ-017 — Desativar usuário
Prioridade: MUST
Desativação impede acesso, preserva autoria e gera auditoria.
FND-REQ-018 — Reativar usuário
Prioridade: MUST
Reativação restaura acesso conforme permissões vigentes.
FND-REQ-019 — Preservar autoria após desligamento
Prioridade: MUST
Registros anteriores continuam atribuídos ao autor original.
FND-REQ-020 — Não deixar organização sem administrador
Prioridade: MUST
O último administrador não pode se desativar nem perder o papel administrativo sem outro administrador ativo.
D. Perfis e permissões
FND-REQ-021 — Perfil Administrador
Prioridade: MUST
Deve possuir as capacidades mínimas definidas neste PRD.
FND-REQ-022 — Perfil Usuário comercial
Prioridade: MUST
Deve possuir as capacidades mínimas definidas neste PRD.
FND-REQ-023 — Permissão financeira independente
Prioridade: MUST
Dados financeiros sensíveis devem poder ser restringidos.
FND-REQ-024 — Administrador recebe acesso financeiro por padrão
Prioridade: MUST
Usuário comercial não recebe essa permissão automaticamente.
FND-REQ-025 — Permissão aplicada no backend
Prioridade: MUST
Dado sem permissão não deve ser retornado pela camada autorizada.
FND-REQ-026 — Mudança de perfil rastreável
Prioridade: MUST
Registrar antes, depois, responsável e data/hora.
FND-REQ-027 — Mudança de permissão rastreável
Prioridade: MUST
Registrar antes, depois, responsável e data/hora.
E. Documentos
FND-REQ-028 — Permitir upload de documento
Prioridade: MUST
Infraestrutura deve permitir anexar arquivo à organização.
FND-REQ-029 — Registrar metadados
Prioridade: MUST
Registrar organização, nome, categoria, status, autor e data.
FND-REQ-030 — Estados do documento
Prioridade: MUST
Suportar UPLOADING, AVAILABLE, ERROR, ARCHIVED.
FND-REQ-031 — Mostrar upload em andamento
Prioridade: MUST
Usuário percebe que a operação ainda não terminou.
FND-REQ-032 — Falha não vira disponível
Prioridade: MUST
Upload com erro nunca recebe AVAILABLE.
FND-REQ-033 — Preservar dados da tela em falha
Prioridade: MUST
Falha de arquivo não apaga demais campos preenchidos.
FND-REQ-034 — Relacionar documento a objetos
Prioridade: MUST
Deve existir DocumentRelation genérico.
FND-REQ-035 — Preservar relação com a fonte
Prioridade: MUST
Informação extraída futuramente deve conseguir apontar para o documento-fonte.
FND-REQ-036 — Arquivar sem destruir histórico
Prioridade: MUST
Documento relevante não desaparece silenciosamente.
FND-REQ-037 — Categoria extensível
Prioridade: SHOULD
Novas categorias devem poder ser adicionadas sem remodelagem estrutural relevante.
F. Histórico, versões e auditoria
FND-REQ-038 — Registrar eventos relevantes
Prioridade: MUST
Deve existir AuditEvent com organização, ator, objeto, ação e data.
FND-REQ-039 — Registrar mudança de estado
Prioridade: MUST
Quando aplicável, registrar from_state e to_state.
FND-REQ-040 — Registrar resumo da alteração
Prioridade: MUST
Quando relevante, registrar descrição suficiente do que mudou.
FND-REQ-041 — Auditoria isolada por organização
Prioridade: MUST
Eventos de uma empresa não podem ser visualizados por outra.
FND-REQ-042 — Histórico permanece após desativação
Prioridade: MUST
Desativar usuário, arquivar documento ou suspender organização não elimina eventos existentes.
FND-REQ-043 — Preparar referência de versão
Prioridade: MUST
Objetos versionados devem poder usar version e previous_version_id.
FND-REQ-044 — Preservar versão anterior de informação crítica
Prioridade: MUST
Manter versão anterior, alteração, responsável e data.
FND-REQ-045 — Ações administrativas críticas exigem auditoria
Prioridade: MUST
Mudança crítica não deve ser confirmada silenciosamente se o AuditEvent obrigatório não puder ser persistido.
G. Tela de Histórico e rastreabilidade
FND-REQ-046 — Administrador pode consultar histórico
Prioridade: MUST
Disponibilizar tela administrativa de histórico.
FND-REQ-047 — Mostrar informações compreensíveis
Prioridade: MUST
Mostrar o que aconteceu, quem realizou, objeto afetado, antes/depois e data quando aplicável.
FND-REQ-048 — Filtrar histórico
Prioridade: MUST
Filtros mínimos: pessoa, tipo de ação, período.
H. Estados transversais de interface
FND-REQ-049 — Estado Carregando
Prioridade: MUST
Operação não imediata indica processamento.
FND-REQ-050 — Estado Sem dados
Prioridade: MUST
Explicar ausência e próximo passo.
FND-REQ-051 — Estado Erro
Prioridade: MUST
Explicar falha, preservar dados e permitir nova tentativa quando aplicável.
FND-REQ-052 — Estado Sem permissão
Prioridade: MUST
Mostrar acesso restrito sem mascarar como erro técnico.
FND-REQ-053 — Não inventar fallback
Prioridade: MUST
Nunca mostrar dado inexistente para preencher interface.
I. Linguagem
FND-REQ-054 — Português simples na interface
Prioridade: MUST
Não mostrar desnecessariamente termos como tenant, RBAC, membership ou audit event ao cliente.
16. Matriz resumida de requisitos
| Grupo | Quantidade |
|---|---|
| Empresa / isolamento | 5 |
| Acesso | 7 |
| Usuários | 8 |
| Permissões | 7 |
| Documentos | 10 |
| Histórico/auditoria | 8 |
| Tela de histórico | 3 |
| Estados UX | 5 |
| Linguagem | 1 |
| Total | 54 |
17. Casos de teste
Segurança e tenant
FND-TEST-001 — Empresa A vê seus próprios dados
Dado: usuário ativo da Empresa A.
Quando: acessa objeto da Empresa A.
Então: acesso permitido.
FND-TEST-002 — Empresa A não vê Empresa B
Quando: usuário da Empresa A tenta abrir objeto da Empresa B.
Então: acesso bloqueado.
FND-TEST-003 — Alteração manual de URL
Quando: usuário troca o ID da URL por objeto da Empresa B.
Então: nenhum conteúdo da Empresa B é exibido.
FND-TEST-004 — Chamada direta ao backend
Quando: usuário da Empresa A solicita via API objeto da Empresa B.
Então: solicitação negada.
FND-TEST-005 — Organização suspensa
Quando: usuário ativo tenta acessar organização suspensa.
Então: acesso bloqueado e dados preservados.
Autenticação
FND-TEST-006 — Entrada válida
Usuário ativo + organização ativa + vínculo ativo → ambiente aberto.
FND-TEST-007 — Usuário desativado
Credencial válida + vínculo DISABLED → acesso bloqueado.
FND-TEST-008 — Carregamento do login
Durante autenticação → estado Entrando… visível e sem requisição duplicada.
FND-TEST-009 — Falha de acesso
Credencial inválida → usuário permanece fora + mensagem clara.
FND-TEST-010 — Recuperação
Tela possui caminho funcional para recuperar acesso.
Usuários
FND-TEST-011 — Convidar novo usuário
Administrador informa nome/e-mail/perfil → vínculo INVITED criado.
FND-TEST-012 — Ativar convite
Pessoa completa processo → vínculo muda para ACTIVE.
FND-TEST-013 — Reenviar convite
Reenvio não cria segundo vínculo.
FND-TEST-014 — Usuário já existe
E-mail já cadastrado → identidade não é duplicada desnecessariamente.
FND-TEST-015 — Desativar
Admin desativa usuário → DISABLED + acesso bloqueado + histórico preservado.
FND-TEST-016 — Reativar
Admin reativa usuário → acesso conforme permissões atuais.
FND-TEST-017 — Preservar autoria
Após desativação, registros anteriores continuam com autor correto.
FND-TEST-018 — Último administrador
Único administrador tenta se desativar → sistema bloqueia e orienta.
Permissões
FND-TEST-019 — Administrador acessa gestão de equipe
Permitido.
FND-TEST-020 — Comercial tenta gerenciar usuários
Bloqueado.
FND-TEST-021 — Comercial sem permissão financeira
Dado sensível não aparece e não é retornado pelo backend.
FND-TEST-022 — Comercial recebe permissão financeira
Após concessão → passa a visualizar dados permitidos.
FND-TEST-023 — Alterar perfil
Mudança funciona e AuditEvent contém antes/depois.
FND-TEST-024 — Alterar permissão
Mudança funciona e AuditEvent correspondente é criado.
Documentos
FND-TEST-025 — Upload iniciado
Selecionar arquivo → status UPLOADING.
FND-TEST-026 — Upload concluído
Arquivo armazenado corretamente → AVAILABLE.
FND-TEST-027 — Upload falhou
Falha → ERROR, nunca AVAILABLE.
FND-TEST-028 — Formulário preservado
Campos preenchidos + upload falha → campos continuam preenchidos.
FND-TEST-029 — Metadados
Documento disponível possui organização, autor, data e categoria.
FND-TEST-030 — Relação com objeto
Documento associado por DocumentRelation.
FND-TEST-031 — Arquivar
Documento arquivado → histórico e relações preservados.
FND-TEST-032 — Isolamento documental
Usuário da Empresa A tenta acessar documento da Empresa B → bloqueado.
Auditoria e histórico
FND-TEST-033 — Criação de usuário gera evento
Convite → AuditEvent criado.
FND-TEST-034 — Desativação gera evento
Evento identifica administrador, usuário afetado e horário.
FND-TEST-035 — Alteração de perfil mostra antes/depois
AuditEvent contém estado anterior e novo.
FND-TEST-036 — Eventos isolados por tenant
Admin da Empresa A não encontra eventos da Empresa B.
FND-TEST-037 — Filtro por usuário
Retorna apenas eventos compatíveis.
FND-TEST-038 — Filtro por tipo
Retorna apenas ações escolhidas.
FND-TEST-039 — Filtro por período
Retorna apenas o intervalo selecionado.
FND-TEST-040 — Histórico sobrevive à desativação
Usuário desativado continua como autor de eventos anteriores.
FND-TEST-041 — Falha de auditoria em ação crítica
Simular indisponibilidade do AuditEvent durante mudança crítica → sistema não confirma silenciosamente a alteração como concluída.
Estados de interface
FND-TEST-042 — Lista vazia de equipe
Sem usuários adicionais → mensagem orienta próximo passo.
FND-TEST-043 — Falha ao carregar equipe
Exibir erro; nunca lista inventada.
FND-TEST-044 — Sem permissão
Usuário comercial tenta área administrativa → acesso restrito.
FND-TEST-045 — Carregamento
Tela consultando dados → indicador visível.
FND-TEST-046 — Recuperação após erro
Após erro recuperável → usuário consegue tentar novamente.
18. Teste ponta a ponta obrigatório
FND-E2E-001 — Fundação completa
Cenário
Criar:
- Empresa A — LC Verum Teste
- Empresa B — Empresa Externa Teste
Na Empresa A:
- administrador entra;
- adiciona usuário comercial;
- usuário aceita convite;
- administrador altera uma permissão;
- documento é anexado;
- documento é relacionado à empresa;
- comercial entra;
- acessa apenas o permitido;
- comercial tenta acessar dado financeiro sem permissão → bloqueado;
- comercial tenta acessar objeto da Empresa B → bloqueado;
- administrador consulta o histórico;
- todos os eventos relevantes estão presentes;
- usuário comercial é desativado;
- perde acesso;
- sua autoria anterior continua intacta.
Resultado esperado
PASS somente se todos os passos forem verdadeiros.
19. Gate D — Segurança
A Fundação só é considerada concluída quando o Gate D puder ser provado.
O Gate D não significa apenas “tela de login pronta”.
Deve existir:
isolamento
+
autenticação
+
autorização
+
permissões
+
documentos protegidos
+
rastreabilidade mínimaChecklist de saída
- FND-TEST-001 a FND-TEST-046 sem falhas críticas.
- FND-E2E-001 aprovado.
- Isolamento testado no frontend e backend.
- Usuário desativado realmente bloqueado.
- Permissões sensíveis realmente bloqueadas no backend.
- Documentos segregados por organização.
- Auditoria administrativa funcionando.
- Nenhum problema crítico de segurança conhecido aberto.
Gate D = PASS somente após comprovação objetiva.
20. Decisões técnicas propositalmente em aberto
Estas questões devem ser definidas nos PRDs técnicos correspondentes e não reabrem o Product Freeze:
- mecanismo específico de autenticação;
- provedor de autenticação;
- tamanho máximo de upload;
- formatos definitivos aceitos;
- storage;
- antivírus;
- política técnica de retenção;
- quantidade de usuários por plano;
- matriz futura completa de permissões;
- mecanismo de assinatura;
- notificações;
- SSO corporativo avançado.
Esses pontos são decisões técnicas/operacionais ainda não tomadas, não gaps do produto.
21. Freeze do Incremento 1
Considerar congelados como produto:
- Organization / tenant
- User + Membership
- Administrador + Usuário comercial
- Permissão financeira sensível independente
- F01 — Entrar
- F02 — Equipe e acessos
- A01 — Histórico e rastreabilidade
- Convite, ativação, desativação e reativação
- Documentos base + relação com fonte
- AuditEvent
- Isolamento obrigatório por organização
- Estados de interface
- 54 requisitos funcionais
- 46 casos de teste
- 1 teste E2E obrigatório
- Gate D verificável
22. Próximo incremento
Após a Fundação estar especificada e o Gate D encaminhado tecnicamente, seguir para:
Incremento 2 — Configuração Comercial
Escopo já aprovado:
- empresa e pessoas;
- organograma opcional;
- identidade comercial;
- propostas/vendas anteriores;
- ofertas e expertises;
- clientes;
- mercado;
- capacidade interna;
- terceirização de parte da entrega;
- dependências internas e externas;
- visão inicial;
- Human Gates correspondentes à configuração comercial.
Não expandir conceitualmente o Incremento 1 durante a construção sem Evidence → Learning → Proposed Change.