# X-Intelligence — MVP SaaS proposto

Versão de trabalho · 16/10/2026 · M2M

## Base consultada e premissas
Blueprint M2M X-Intelligence, conversa de finalização do one-pager, logo SVG aprovado e one-pager final. O histórico recuperado do Blueprint está limitado às mensagens disponibilizadas pelo aplicativo; não foi possível recuperar decisões anteriores que não apareçam nesse material. Planos, limites e arquitetura abaixo são propostas para validação, não decisões já aprovadas.

## Problema, público e recorte
Equipes de arquitetura e modernização precisam transformar inventários dispersos em diagnósticos e roadmaps rastreáveis. Começar por empresas com aplicações Java/WebSphere e integrações MQ/ACE. A primeira entrega deve permitir concluir uma jornada de diagnóstico a roadmap aprovado, sem executar mudanças em produção.

## Jornada principal do MVP
1. Responsável cria organização e workspace, convida equipe e atribui papéis.
2. Analista cadastra aplicações ou importa CSV validado: nome, responsável, runtime, versão Java, criticidade, integrações, dependências e origem da informação.
3. Diagnose: questionário registra situação atual, evidências e lacunas; não deduz compatibilidade sem evidência.
4. Engage: equipe registra objetivos, responsáveis, restrições e critérios de sucesso.
5. Ideate: equipe organiza iniciativas por valor, esforço, risco e dependências; Copilot propõe hipóteses com referências aos dados autorizados.
6. Revisor aprova uma versão do diagnóstico/roadmap. Alterações posteriores geram nova versão.
7. Implement: acompanhamento manual de iniciativas e checkpoints, sem execução automatizada.
8. Optimize: registro de indicadores e aprendizados para um novo ciclo.
9. Exportação do relatório e roadmap com premissas, pendências e histórico de aprovação.

## Planos e direitos de acesso propostos
Explore: 1 workspace, 2 usuários, 5 aplicações, diagnóstico e exportação básicos.
Team: 3 workspaces, 10 usuários, 50 aplicações, colaboração, revisões e Copilot com franquia a definir.
Enterprise: volumes contratados, suporte e requisitos específicos; SSO e conectores somente após avaliação e implementação.
Preços a validar por entrevistas e custo operacional. Não prometer IA ilimitada. Separar assinatura, consumo adicional e serviços profissionais. Para o piloto, concessão manual de plano pelo operador; cobrança automática em fase posterior.

## Acesso e governança a implementar
Papéis: proprietário da organização (membros/plano), administrador do workspace, analista (cadastro e rascunhos), revisor (aprovação) e leitor (consulta). Aplicar permissões e limites no servidor, nunca apenas na interface. Isolar dados por organização e validar esse isolamento em todas as operações, exportações e fontes do Copilot. Registrar alterações, aprovações e alterações de membros. Definir retenção, exclusão e termos de tratamento antes de dados reais. Nenhuma certificação de segurança está sendo alegada.

## Arquitetura e entidades propostas
Frontend web responsivo; API autenticada; banco relacional; armazenamento privado de documentos; provedor de identidade; gateway de IA com contabilização de uso por organização. Entidades: Organization, Membership, Workspace, Application, Dependency, Assessment, Evidence, Initiative, RoadmapVersion, Approval, AuditEvent, SubscriptionEntitlement, UsageEvent. Vincular todas as entidades de negócio à organização. Segredos apenas no servidor. Escolha final de provedores depende de requisitos de residência de dados, custo e autenticação.

## Copilot no MVP
Restringir inicialmente a resumo de diagnóstico e sugestões de próximos passos usando dados do workspace. Identificar claramente hipóteses e lacunas; referências de evidência obrigatórias quando disponíveis. Sem execução de comandos, alteração de código ou acesso automático a produção. Implementar limite de uso, rastreabilidade, proteção de fontes e revisão humana. Seleção de provedor e uso de dados para treinamento precisam de validação contratual.

## Fases e critérios de aceite
Fase A — Fundação: identidade, isolamento por organização, papéis e limites. Aceite: uma organização não consegue acessar dados de outra, inclusive por IDs ou exportações.
Fase B — Diagnóstico: inventário, CSV com prévia e relatório de erros, questionário e evidências. Aceite: usuário cadastra/importa, corrige erros e recupera os dados após novo acesso.
Fase C — Roadmap: iniciativas, dependências, revisões, aprovação e exportação. Aceite: exportação corresponde à versão aprovada e identifica autor/revisor.
Fase D — Copilot e piloto: sugestões com evidências, cotas e feedback. Aceite: conteúdo gerado permanece rascunho até aprovação; falha do provedor não perde os dados.
Fase E — Comercialização: validar preço, termos, suporte, cobrança e provisionamento. Aceite: mudanças de plano e cancelamento atualizam direitos de acesso de forma verificável.
Não há cronograma fechado: estimar após validar equipe, escopo de integrações e requisitos de dados.

## Fora do primeiro MVP
Migração automática de código, descoberta por agentes instalados, conectores de produção, marketplace, billing automático, SSO corporativo e execução autônoma. Cada um exige um incremento validado separadamente.

## Métricas de validação
Tempo até primeiro diagnóstico completo; percentual de cadastros com evidências suficientes; roadmaps aprovados; retorno semanal da equipe; custo de IA por diagnóstico; conversão do piloto para assinatura. Definir metas após a primeira coorte, sem anunciar resultados inexistentes.

## Domínios — recomendação
Usar x-intelligence.app como endereço principal da marca, com app.x-intelligence.app para o SaaS futuro. x-intelligence.m2mit.solutions pode redirecionar para o principal, preservando o vínculo M2M. Isso evita depender de múltiplos endereços equivalentes e deixa m2mit.io/net/info para a estratégia institucional. Não é necessário que um domínio de produto aponte primeiro para um subdomínio M2M: ambos podem ser cadastrados no provedor de hospedagem conforme o papel escolhido.
Confirmar a grafia do segundo domínio: foi informado x-intelligence.clou; não assumir que é x-intelligence.cloud. Se for .cloud, avaliar seu uso como redirecionamento para o principal.
DNS resolve nomes; redirecionamento HTTP altera a URL vista pelo visitante. Subdomínios podem usar CNAME conforme o destino fornecido pela hospedagem; a raiz exige registros e validações específicos do provedor. Não copiar IPs nem inferir destinos. Referências: https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-subdomain/ e https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-zone-apex/ .
Nenhum DNS ou domínio customizado foi alterado nesta entrega. O site inicial é privado no Sites; a abertura pública exige uma decisão posterior de audiência.

## O que está entregue neste site
Site institucional responsivo, identidade aprovada, planos propostos, Journey Xperience interativa, workspace demonstrativo com dados fictícios, apresentação PDF e geração local de briefing. Não há autenticação SaaS, base de clientes, pagamentos, envio de formulários, conectores ou IA real. A hospedagem privada do Sites protege a revisão do site; não substitui o modelo de autorização do SaaS.