V360 — Documentação

Índice do MVP - Requisitos

Leitura de 10 min

V360 Sales Intelligence™ - Índice do MVP e Pacote de Requisitos

Data da consolidação: 2026-09-15
Status: pacote de requisitos em rascunho para refinamento funcional e implementação incremental
Escopo: primeira fatia operacional ponta a ponta do V360 Sales Intelligence™

1. Fontes e precedência usadas nesta consolidação

  1. Product Blueprint & MVP Freeze Candidate - Candidate 0.2: baseline funcional mais recente fornecida para o Sales Intelligence.
  2. Kit Requisitos V360: formato operacional dos requisitos, etapas, taxonomia de gates e stack técnica desta construção.
  3. Freeze Candidate 0.1: referência histórica quando compatível com as fontes mais recentes.
  4. Fontes-mestras do projeto V360: governança, rastreabilidade, segurança, arquitetura do conhecimento e Product Markdown Rail, quando não conflitantes com instruções/fonte mais recentes.

Quando existir conflito material, a decisão mais recente e específica deve prevalecer. Este pacote não transforma sozinho uma divergência documental em Founder Resolution; a pendência deve permanecer registrada para decisão formal quando necessário.

2. Escopo congelado desta primeira fatia

Este pacote cobre o Sales Intelligence ponta a ponta descrito no Product Blueprint atual. A plataforma pode ter arquitetura evolutiva e outros Domain Packs em horizontes posteriores, mas este conjunto de requisitos não adiciona outros módulos V360 à primeira fatia operacional.

Regra de freeze aplicada:

  • entra agora o que é necessário para completar o fluxo ponta a ponta;
  • entra agora o que é necessário para segurança, segregação ou confiabilidade;
  • entra agora o que é necessário para viabilizar piloto real;
  • melhoria baseada em evidência fica identificada para avaliação;
  • expansão futura permanece fora do MVP desta fatia.

3. Regras imutáveis do produto preservadas

  • IA sugere. Humano valida.
  • A IA não aprova necessidade, Solution Fit, Business Fit, preço, desconto, proposta, decisão ou mudança crítica de status sozinha.
  • Informação preserva origem, fonte, data, autor, contexto e versão quando aplicável.
  • Fato, declaração do cliente, observação do vendedor, percepção de quem indicou, fonte pública, hipótese da IA, lacuna e decisão humana não podem ser misturados.
  • Lead não é oportunidade.
  • Oportunidade só nasce após necessidade suficientemente validada e Gate 5 humano.
  • Não avançar também pode ser um bom resultado.
  • Toda mudança material em preço, escopo, prazo, forma de pagamento, esforço ou equipe retorna à Análise do Negócio / Business Fit antes de aceite definitivo.
  • Nenhum envio ou negociação é autônomo no MVP.
  • Sem informação suficiente, o sistema deve dizer que não há informação suficiente; nunca inventar fallback.
  • Dados de organizações diferentes permanecem segregados.
  • Histórico material não desaparece silenciosamente.

4. Taxonomia operacional de etapas usada nos REQs

  • E0 - Cadastro Básico
  • E1 - Quem Somos
  • E2 - O Que Vendemos
  • E3 - Mercado
  • E4 - Capacidade de Entrega
  • E5 - Lead Entra / Análise Pré-Abordagem
  • E6 - Quick Call
  • E7 - Need Validation
  • E8 - Solution Fit
  • E9 - Pré-Proposta
  • E11 - Business Fit
  • E12 - Proposta Final
  • E13 - Decisão
  • E14 - Follow-up e Parked
  • E15 - Sales-to-Delivery Handoff
  • inteligencia - inteligência comercial e aprendizado
  • transversal - Foundation, segurança, dados e regras comuns

Nota: E10 não aparece na taxonomia operacional fornecida no Kit Requisitos. Ele não foi inventado neste pacote.

5. Human Gates usados nos arquivos

A taxonomia operacional do Kit de Requisitos define 11 gates:

  1. Identidade Comercial
  2. Ofertas
  3. Mercado
  4. Capacidade
  5. Necessidade Validada
  6. Solution Fit
  7. Apresentação Pré-Proposta
  8. Business Fit
  9. Proposta Final
  10. Apresentação Final
  11. Decisão Comercial

O Product Blueprint Candidate 0.2 apresenta uma decomposição conceitual mais granular, com preço e condições explicitados separadamente. Para não inventar números de gate fora do formato do Kit, os arquivos REQ usam os 11 gates operacionais. As validações humanas de preço e condições continuam obrigatórias por regra de negócio, rastreabilidade e loop de Business Fit.

6. Stack técnica adotada neste pacote

Conforme o Kit Requisitos V360:

  • Next.js + TypeScript;
  • Neon / PostgreSQL;
  • Neon Auth;
  • Cloudflare R2;
  • IA via API da Anthropic.

Existe baseline histórica do projeto com tecnologias diferentes. Este pacote registra como dúvida formal a confirmação no Decision Log de que a stack do Kit substitui as baselines conflitantes para esta construção.

7. Questões que não reabrem o Product Freeze

Estas decisões continuam para os PRDs específicos:

  • formatos e tamanho máximo de upload;
  • matriz completa de permissões;
  • algoritmo exato de precificação;
  • fórmula detalhada de capacidade;
  • fontes externas prioritárias;
  • regras de comparabilidade;
  • template visual final;
  • assinatura;
  • integrações;
  • notificações;
  • política completa de retenção.

Enquanto não forem decididas, nenhum REQ deve preencher essas lacunas por suposição.

8. Inventário de requisitos

Transversal / Foundation (15)

E0 - Cadastro Básico (1)

E1 - Quem Somos (3)

E2 - O Que Vendemos (2)

E3 - Mercado (3)

E4 - Capacidade de Entrega (4)

E5 - Lead Entra / Análise Pré-Abordagem (5)

E6 - Quick Call (2)

E7 - Need Validation (4)

E8 - Solution Fit (4)

E9 - Pré-Proposta (5)

E11 - Business Fit (12)

E12 - Proposta Final (5)

E13 - Decisão (4)

E14 - Follow-up e Parked (8)

E15 - Sales-to-Delivery Handoff (2)

Inteligência e Aprendizado (11)

Total de requisitos: 90

9. Próximo uso recomendado

  1. Importar esta pasta para 05 Construção/Requisitos no Obsidian. Feito em 2026-09-16 (REQ-001 a REQ-090).
  2. Refinar os REQs que contêm Dúvidas em aberto antes de implementação definitiva.
  3. Para cada funcionalidade de desenvolvimento, aplicar o Product Markdown Rail: caminho feliz, exceções/erros, dados/rastreabilidade, permissões e critérios de aceite objetivos.
  4. Implementar por incrementos, mantendo Human Gates e trilha de auditoria desde a Foundation.
  5. Rodar Cliente Zero antes de considerar a fatia pronta para piloto externo.
  6. Registrar Evidence → Learning → Proposed Change antes de mudar o produto por feedback de piloto.

Visão de gráfico

Backlinks