Orquestro — Documentação

V360 — MVP Freeze Candidate Final

Properties1
statushistorico

Leitura de 8 min

Superado pela v2

Substituído pela Orquestro — MVP Freeze Candidate Final v2 em 2026-09-20, depois da Reconciliação Final v0.3 × PRDs fechar os 8 conflitos e os 15 requisitos órfãos listados abaixo. Esta versão fica como histórico — não editar.

Documento-mãe do MVP (histórico)

Consolida os 7 incrementos e os 13 gates. Ver Análise PRDs × v0.3 para os pontos em conflito com o v0.3.

Orquestro

MVP Freeze Candidate Final

Código: Orquestro-MVP-FREEZE
Versão: 1.0 — Freeze Candidate Final
Status: FREEZE_CANDIDATE

1. Propósito deste documento

Este é o documento-mãe do MVP do Orquestro.

Ele não substitui os PRDs detalhados. Sua função é consolidar a arquitetura oficial, indicar os documentos canônicos e congelar as decisões transversais que orientam protótipo, modelo de dados, implementação, Cliente Zero e pilotos.

A partir deste ponto, novas funcionalidades conceituais não devem ser adicionadas por preferência ou impressão isolada. Mudanças passam a exigir evidência, aprendizado e decisão humana registrada.

2. Princípio do produto

A tecnologia ocupa os intervalos. As pessoas ocupam os momentos de impacto.

No Sales Intelligence:

  • pessoas conversam com pessoas;
  • o Orquestro prepara antes;
  • organiza depois;
  • conecta evidências;
  • ajuda a decidir;
  • aprende com resultados;
  • nunca valida ou decide sozinho.

Princípios de experiência congelados:

  • Human First;
  • Simples na tela;
  • Sofisticado por trás;
  • Contexto antes de comunicação;
  • Evidência antes de conclusão;
  • Negócio saudável;
  • Aprender sempre.

3. Arquitetura oficial — 7 incrementos

IncrementoNomeFunção principalHuman Gates
1FundaçãoTenant, autenticação, segurança, TruthMode, UX base—
2Configuração ComercialIdentidade, ofertas, mercado e capacidade1–4
3Lead e NecessidadeEntrada, contexto, Discovery e Need5
4SoluçãoSolution Fit e apresentação pré-proposta6–7
5NegócioBusiness Fit, preço e condições8–10
6Proposta e DecisãoProposal, apresentação final, negociação e decisão11–13
7Inteligência e AprendizadoDashboard, padrões, hipóteses, testes e Learningnenhum novo Gate comercial

4. Jornada macro

Configuração Comercial
↓
Lead entra
↓
Contexto e pesquisa
↓
Discovery humano
↓
Need validado
↓
Solution Fit
↓
Pré-Proposta
↓
Business Fit
↓
Preço
↓
Condições
↓
Proposal
↓
Apresentação Final
↓
Reunião humana
↓
WON / LOST / DECISION_PENDING / PARKED
↓
Contrato e relacionamento
↓
Sales-to-Delivery Handoff
↓
Inteligência e Aprendizado
↓
Evidence → Pattern → Hypothesis → Test → Learning → Proposed Change

A jornada admite retornos controlados e versionados, especialmente durante negociação.

5. Mapa definitivo dos 13 Human Gates

GateNomeDecisão humana
01Identidade Comercialvalida
02Ofertas e Expertisesvalida
03Mercadovalida leitura
04Capacidadeconfirma
05Necessidadecliente reconhece + vendedor registra
06Soluçãovendedor valida
07Apresentação Pré-Propostavendedor valida
08Análise do Negóciovendedor decide
09Preçovendedor define
10Condiçõesvendedor define
11Propostavendedor valida
12Apresentação Finalvendedor valida
13Decisãohumano registra resultado

Regra absoluta: a IA não fecha Human Gate.

6. Regra central da IA

IA pesquisa / organiza / compara / sugere
↓
Humano revisa
↓
Humano valida ou decide

A IA pode sugerir Need, Solution, Business Fit, preço, condições, mensagens, roteiros, padrões, hipóteses e testes.

A IA não pode transformar sugestão em fato, decisão, aprovação ou regra de metodologia sem validação humana explícita.

7. TruthMode canônico

Tipos principais:

EVIDENCE
CUSTOMER_STATEMENT
SELLER_OBSERVATION
REFERRER_PERCEPTION
PUBLIC_FACT
AI_HYPOTHESIS
GAP
HUMAN_VALIDATED_DECISION

Subtipos podem especializar o tipo principal sem substituí-lo.

Exemplos:

PUBLIC_REFERENCE → subtipo de EVIDENCE/PUBLIC_FACT conforme a natureza
PRICE_SUGGESTION → subtipo de AI_HYPOTHESIS
SOLUTION_SUGGESTION → subtipo de AI_HYPOTHESIS

Nunca promover silenciosamente uma origem para uma categoria mais forte.

8. Objetos centrais do domínio

Organização e acesso

Organization
User
OrganizationPerson
Role / Permission
AuditEvent

Configuração comercial

CommercialIdentity
Offer
Expertise
MarketDefinition
CapacitySnapshot
DeliveryPerson
ExternalDeliveryPartner

Ciclo comercial

Lead
Stakeholder
Referral
ResearchFinding
Meeting
Need
Opportunity

Solução

Solution
Presentation(type=PRE_PROPOSAL | FINAL_PROPOSAL)
MeetingBrief

Negócio

BusinessScope
EffortEstimate
OpportunityCapacityImpact
CostEstimate
ComplexityAssessment
BusinessFit
PricingScenario
CommercialConditionScenario

Proposta, decisão e relacionamento

Proposal
CommercialDecision
ClientCounterproposal
LossReason
DecisionPendingContext
FollowUp
ParkedContext
ContractRecord
CustomerRelationship
SalesToDeliveryHandoff

Aprendizado

CommercialMetricSnapshot
PatternObservation
LearningHypothesis
LearningTest
LearningTestResult
Learning
ProposedChange
AIContributionMetric
StrategicPotentialOutcome

9. Separação obrigatória de estados

Os seguintes conceitos não podem ser fundidos:

Opportunity
CommercialDecision
ContractRecord
CustomerRelationship

CommercialDecision

WON
LOST
DECISION_PENDING
PARKED

ContractRecord

PENDING
ACTIVE
ENDED
CANCELLED

CustomerRelationship

ACTIVE
INACTIVE_WITH_POTENTIAL
INACTIVE

10. Regra WON × Contrato × Cliente Ativo

Definição final:

WON = aceite comercial registrado pelo humano.

Cliente Ativo = existe ao menos um contrato ACTIVE.

Portanto:

cliente aceita
↓
WON
↓
Gate 13
↓
Contract PENDING
↓
“Fechado — aguardando contrato”
↓
Contract ACTIVE
↓
CustomerRelationship ACTIVE
↓
Handoff liberado para entrega

WON não deve ser adiado artificialmente até a assinatura do contrato.

11. Parked e relacionamento futuro

Quando não é o momento, mas existe contexto legítimo para retorno:

CommercialDecision = PARKED

Se não houver contrato ativo:

CustomerRelationship = INACTIVE_WITH_POTENTIAL

Registrar:

  • por que não é agora;
  • o que precisa mudar;
  • quando retomar, se conhecido.

PARKED não é LOST.

12. Sales-to-Delivery Handoff

Após WON:

criar/preservar Handoff em draft

Após contrato ACTIVE:

Handoff → READY_FOR_DELIVERY

O Handoff carrega contexto e conhecimento, incluindo Need, futuro desejado, realidade atual, prioridade, critérios de sucesso, escopo prometido, responsabilidades, stakeholders, sensibilidades, premissas e exclusões.

Dados internos sensíveis de precificação não devem ser expostos sem necessidade.

13. Contrato transversal de UX

Estados herdados por todas as telas, quando aplicáveis:

LOADING
EMPTY
ERROR
AI_PROCESSING
RESULT_UNAVAILABLE
INSUFFICIENT_INFORMATION
NO_PERMISSION

Regras:

  • preservar o que o usuário digitou;
  • não fabricar conteúdo quando IA/pesquisa falhar;
  • oferecer retry;
  • permitir continuidade manual quando possível;
  • explicar falta de dados em linguagem simples.

14. Fallback de fontes externas

Quando uma pesquisa ou referência externa não estiver disponível:

Tentar novamente
Continuar sem isso
Adicionar fonte manual

Fonte manual preserva origem, autor e data e nunca é apresentada como resultado automático.

15. Explicabilidade

Toda recomendação relevante deve conseguir responder:

Por que o Orquestro está sugerindo isso?

Estrutura mínima, quando aplicável:

reasoning_summary
evidence_refs[]
limitations[]
confidence_optional

Isso é explicação verificável da base da sugestão, não exposição de raciocínio interno privado.

16. Multi-tenant e segurança

Todo objeto persistente pertencente ao cliente deve possuir organization_id inequívoco.

O MVP exige:

  • autenticação;
  • autorização;
  • segregação por tenant;
  • proteção de anexos;
  • controle de acesso a dados financeiros;
  • menor privilégio;
  • histórico;
  • auditoria.

Dados privados de tenants diferentes não podem ser usados em conjunto no aprendizado comercial do cliente.

17. Versionamento

Se uma versão sustentou uma decisão posterior, ela não desaparece.

Estrutura recomendada:

version
previous_version_id
status
created_by
created_at
superseded_at_optional

Aplica-se especialmente a Need, Solution, Presentation, BusinessScope, EffortEstimate, BusinessFit, PricingScenario, CommercialConditionScenario, Proposal, Learning e ProposedChange.

18. Auditoria

Distinguir sempre:

HUMAN_ACTION
AI_SUGGESTION
SYSTEM_EVENT

Eventos relevantes registram tenant, objeto, versão quando pertinente, ator, data/hora e mudança realizada.

Sugestão de IA nunca deve aparecer como decisão humana.

19. Aprendizado

Fluxo congelado:

Evidence
↓
Pattern
↓
Hypothesis
↓
Humano decide testar
↓
Test
↓
Result
↓
Learning validado pelo humano
↓
Proposed Change
↓
Humano aprova/rejeita

O Orquestro aceita resultados inconclusivos.

Padrão não é verdade. Correlação não é causalidade. Learning não altera metodologia sozinho.

20. O que está dentro do MVP

  • configuração comercial;
  • Lead e contexto;
  • Discovery humano;
  • Need Validation;
  • Solution Fit;
  • apresentações pré-proposta e final;
  • Business Fit;
  • capacidade e esforço;
  • precificação assistida;
  • condições comerciais;
  • Proposal;
  • decisão;
  • negociação e contraproposta;
  • follow-up contextual;
  • Parked/reativação;
  • registro mínimo de contrato;
  • CustomerRelationship;
  • Sales-to-Delivery Handoff;
  • Dashboard e One Page;
  • aprendizado estruturado;
  • Cliente Zero e pilotos.

21. O que permanece fora do MVP

  • negociação autônoma;
  • envio comercial autônomo;
  • previsão automática de fechamento;
  • scoring opaco;
  • Machine Learning preditivo;
  • otimização autônoma de preço;
  • benchmark avançado entre tenants;
  • assinatura eletrônica nativa obrigatória;
  • Customer Success completo;
  • fidelização automatizada;
  • IA alterando a própria metodologia.

22. Documentos canônicos

#DocumentoRequisitosTestesE2Es
1Orquestro_Incremento_01_Fundacao_PRD.md54461
2Orquestro_Incremento_02_Configuracao_Comercial_PRD.md130821
3Orquestro_Incremento_03_Lead_e_Necessidade_PRD.md130633
4Orquestro_Incremento_04_Solucao_PRD.md245964
5Orquestro_Incremento_05_Negocio_PRD_v1.1_PATCHED.md2891135
6Orquestro_Incremento_06_Proposta_e_Decisao_PRD_v1.1_PATCHED.md257867
7Orquestro_Incremento_07_Inteligencia_e_Aprendizado_PRD.md342968
TRVOrquestro_Revisao_Transversal_Final_MVP.md60305

Os arquivos originais dos Incrementos 5 e 6 ficam superseded pelas versões v1.1_PATCHED para fins do Freeze Candidate Geral.

23. Resumo quantitativo consolidado

Incrementos 1–7

Requisitos: 1447
Testes: 582
E2Es: 29

Camada transversal

Requisitos: 60
Testes: 30
E2Es: 5

Total documentado do Freeze Candidate

Requisitos: 1507
Testes: 612
E2Es: 34

Os totais representam IDs únicos documentados e não eliminam herança entre regras locais e transversais.

24. Critérios globais de aceite do Freeze Candidate

  • Os 13 Human Gates estão implementáveis e exclusivamente humanos.
  • Os sete incrementos herdam Orquestro-TRV.
  • TruthMode canônico é usado de ponta a ponta.
  • Estados globais de UX estão previstos.
  • Falha de IA preserva input e permite fallback quando possível.
  • Fonte manual preserva origem.
  • Sugestões relevantes são explicáveis.
  • Todo objeto persistente do tenant possui associação inequívoca a organization_id.
  • Objetos decisórios preservam versão e histórico.
  • Auditoria distingue ação humana, IA e sistema.
  • Opportunity, CommercialDecision, ContractRecord e CustomerRelationship estão separados.
  • WON funciona antes do contrato ativo quando há aceite comercial.
  • Cliente Ativo depende de contrato ACTIVE.
  • Parked permanece diferente de Lost.
  • Handoff preserva conhecimento após WON e só é liberado conforme contrato.
  • IA não altera metodologia sozinha.
  • Cliente Zero não é apresentado como validação externa.
  • Pilotos produzem Evidence → Learning → Proposed Change.
  • Nenhuma funcionalidade conceitual nova é adicionada sem evidência posterior ao Freeze.

25. Questões técnicas que não reabrem o Freeze

Podem ser definidas em modelo de dados, protótipo e arquitetura técnica:

  • limite de upload;
  • formatos exatos de anexos;
  • limites por plano;
  • matriz completa de permissões;
  • algoritmos matemáticos finais;
  • pesos de heurísticas;
  • fontes externas prioritárias;
  • thresholds de comparabilidade;
  • retenção detalhada;
  • notificações;
  • integrações futuras;
  • detalhes finais de UI;
  • performance;
  • infraestrutura;
  • contratos de API.

26. Próxima fase aprovada

Freeze Candidate
↓
Modelo de Dados Consolidado
↓
Mapa de Telas / Protótipo navegável
↓
Cliente Zero — LC Verum
↓
Correções por evidência
↓
Pilotos externos
↓
Evidence → Learning → Proposed Change

O produto deixa de avançar por expansão conceitual e passa a avançar por construção e evidência.

27. Decisão final

Fica declarado:

Os sete incrementos do Orquestro estão conceitualmente fechados e alinhados pela Revisão Transversal Final.

O conjunto documental está apto a seguir como MVP Freeze Candidate para protótipo, modelo de dados, Cliente Zero e pilotos.

Status: FREEZE_CANDIDATE

Visão de gráfico