Quem vê o quê, e o que acontece se algo der errado

Uma empresa nunca vê a outra

Toda leitura e toda escrita no Stonen são limitadas à organização de quem está pedindo. Um registro de outra empresa não é filtrado da tela: ele é recusado pela API, com um erro próprio.

Para o seu negócio, isso significa: a sua carteira de clientes, o seu estoque, os seus preços e as suas conversas não aparecem para outra empresa que use o mesmo produto — nem por erro de digitação, nem por link compartilhado por engano.

Esse isolamento vale para todos os perfis, inclusive o titular da conta. Não há um perfil que enxergue tudo.

Cada pessoa vê o que o papel dela permite

O acesso é decidido por 35 permissões, combinadas em quatro perfis. A regra que atravessa todas é a que o dono do produto fixou: leitura ampla, ação comercial restrita.

A tabela completa — cada permissão contra cada perfil — é gerada a partir do próprio código que a API usa em cada requisição, e não escrita à mão. Se a tabela estiver errada, o código está errado junto.

Algumas ações exigem motivo declarado para serem aceitas, e a recusa é do servidor, não da tela. Esconder um botão não é controle de acesso.

O que foi feito fica registrado

As decisões comerciais são gravadas como eventos, e não como um campo que a próxima alteração sobrescreve. A recomendação original, a decisão da pessoa, a abordagem, a resposta do cliente e o desfecho ficam ligados entre si.

Para o seu negócio, isso serve para responder perguntas do tipo *"por que esse material foi oferecido para esse cliente?"*, *"quem mudou o responsável desta oportunidade?"* e *"o que o cliente respondeu, e quando?"* — meses depois, sem depender da memória de ninguém.

É um histórico do que aconteceu com a operação comercial. Não é um log de auditoria de segurança no sentido formal: o Stonen não mantém registro próprio de tentativas de login, porque a autenticação é feita por um sistema de identidade separado.

Senha não fica aqui

O Stonen não guarda senha. Quem autentica é um sistema de identidade separado, e o produto recebe apenas a confirmação de quem é a pessoa e do que ela tem direito.

A consequência prática: desligar o acesso de alguém não depende de mexer no Stonen, e um problema no Stonen não expõe credencial de ninguém.

Isso também é uma dependência: sem o sistema de identidade disponível, ninguém entra. O produto foi construído para recusar subir sem ele, em vez de abrir uma porta alternativa.

Backup e recuperação

Existem quatro camadas de cópia, com cadências diferentes, porque cada uma protege contra uma falha diferente: erro de aplicação, perda da máquina, perda da conta do provedor, e perda total.

A restauração foi ensaiada, e não apenas documentada: num teste com registro de data, o banco voltou a responder em cerca de 15 segundos.

O que ainda não existe: recuperação para um instante exato (*point-in-time*). O pior caso realista de perda é a janela entre duas cópias — cerca de 24 horas. Fechar isso é uma decisão de custo em aberto, e está registrada como tal.

O que ainda não existe

Esta lista está aqui porque decidir com ela é diferente de decidir sem ela.

• Não há monitor externo à máquina. Existe um vigia que percebe "a aplicação caiu" e avisa. Ele não percebe "o servidor inteiro morreu", porque ele mora no servidor.
• Não há nível de serviço contratado (SLA). A medição de disponibilidade começou em setembro de 2026; sem histórico não há base para prometer número em contrato, e prometer sem base seria pior do que não prometer.
• Não há certificação nem auditoria externa de segurança.
• A recuperação para um instante exato não existe — ver a seção anterior.
• Uma única empresa em produção. O isolamento entre organizações é testado, mas o comportamento sob várias empresas simultâneas ainda não foi medido em escala real.

Cada um desses itens tem responsável e custo identificados no acompanhamento interno do produto. Nenhum está esquecido; alguns estão esperando decisão de investimento.