INOVA-R — inovação incorporada a software existente

Rascunho em validação. Esta é a primeira versão do framework, aberta para discussão. O nome ainda é provisório. Nada aqui foi medido ainda.

INOVA-R quer dizer Inovação Orientada por Referências Validadas e Reutilizáveis. Em palavras simples: o lab testa uma ideia, prova que ela é útil e entrega tudo o que o time do produto precisa para colocá-la para rodar.

Por que isso se torna necessário

O desenvolvimento assistido por IA reduz o esforço de explorar alternativas, implementar software e produzir documentação e testes. Com isso, crescem o número de tecnologias que uma organização consegue avaliar e a expectativa de que seus produtos evoluam rápido.

O desafio deixa de ser gerar código. Passa a ser selecionar problemas relevantes, validar valor real e incorporar capacidades com confiabilidade, governança e continuidade.

O INOVA-R organiza dois ciclos conectados:

Inovação contínua e validação em um ambiente independente — como a organIA.
Incorporação e evolução em produtos existentes — como a WeON.

O software validado não é descartado por padrão. Ele é um ativo técnico, sujeito a avaliação de compatibilidade, segurança e qualidade antes de entrar em produção.

Escopo


Objetivo	Acelerar a validação de tecnologias emergentes vinculadas a oportunidades e resultados observáveis para usuários.
Unidade de transferência	Implementação de referência executável, documentada, testada, versionada e com contexto operacional.
Cliente interno	Produto e Engenharia, que ampliam o valor da referência e decidem sua incorporação.
Regra de governança	Nenhuma capacidade é promovida só porque funciona em inovação. O destino depende de gates de valor, segurança, compatibilidade e operação.

Dois ciclos, cinco etapas

 CICLO A — DESCOBERTA E INOVAÇÃO          CICLO B — PRODUTO E ESCALA
 ┌──────────┐  ┌──────────┐  ┌─────────┐   ┌────────────┐  ┌──────────────────────┐
 │1 Explorar│→ │2 Construir│→ │3 Validar│ → │4 Amplificar│→ │5 Incorporar e evoluir│
 └──────────┘  └──────────┘  └─────────┘   └────────────┘  └──────────┬───────────┘
       ▲                                                              │
       └──────────── aprendizados de produção geram novas hipóteses ──┘

Etapa	Quem conduz	O que acontece	Saída
1. Explorar	Inovação + Produto	Mapear tecnologias, dores, oportunidades e hipóteses com baseline	Hipótese, público, métrica, risco e decisão de investir
2. Construir	Inovação / Engenharia	Implementação real, testes, contratos, instrumentação e harness	Referência executável e rastreável
3. Validar	Inovação + usuários	Uso real ou piloto controlado, tarefas, entrevistas e indicadores	Evidências de utilidade e resultado; seguir, iterar ou encerrar
4. Amplificar	Produto + Engenharia	Como dados, CRM, canais e fluxos do destino criam valor adicional	Proposta de valor contextual e plano de medição
5. Incorporar e evoluir	Engenharia + Produto + Operações	Transferir, adaptar, integrar, testar, lançar aos poucos e operar	Critérios de produção atendidos; métricas de valor acompanhadas

Gates de decisão

G1 — Priorização: problema, beneficiário, hipótese, métrica e custo de oportunidade definidos.
G2 — Qualidade: testes relevantes, riscos e limites registrados, versão de referência fixada.
G3 — Valor: validação com usuários e critérios combinados antes; efeitos positivos, neutros e negativos documentados.
G4 — Amplificação: hipóteses adicionais explícitas, ganho esperado separado do ganho já comprovado.
G5 — Produção: integração, segurança, privacidade, governança, operação, reversão e monitoramento definidos.

Em cada gate: avançar, iterar com prazo, manter em pesquisa ou interromper — sempre com o registro do porquê.

Pacote de Referência Transferível (PRT)

O PRT é o contrato de transferência da equipe de inovação para a equipe do produto — e para os agentes de programação. Não é só entregar um repositório: preserva intenção, valor, arquitetura, evidências e regras de operação.

Componente	Conteúdo mínimo
Referência versionada	Commit/tag, mapa de módulos, instruções de execução, dependências
Especificação + critérios	Problema, usuários, comportamentos, exceções, requisitos não funcionais, critérios de aceite
Evidências de validação	Plano de testes, resultados técnicos, tarefas com usuários, métricas, limitações
Harness de desenvolvimento IA	CLAUDE.md, AGENTS.md e regras: arquitetura, convenções, comandos, restrições, testes, gates
Integração e segurança	APIs/eventos, dados, permissões, isolamento multiempresa, privacidade, rollback
Plano de amplificação	O que já foi validado, hipóteses no produto, donos, métricas e critérios
Decisão e rastreabilidade	ADRs, PRs, dono do pacote, exceções aprovadas, histórico

Transferência assistida por agentes de programação

Agentes como Claude Code e Codex precisam entender a solução de origem e o produto de destino, sem supor que os dois compartilham arquitetura, segurança ou contrato de dados.

Contexto de origem: escopo validado, limites, testes, decisões de arquitetura, componentes reutilizáveis.
Contexto de destino: estrutura do repositório, APIs, domínio, autenticação, autorização, multi-tenant, observabilidade, CI/CD.
Plano de integração: correspondências e diferenças, mudanças propostas, tarefas, pontos de aprovação humana, estratégia incremental.
Verificação obrigatória: revisão humana do diff e dos riscos, testes, segurança e privacidade, aceite de Produto, monitoramento.

O código é reutilizado onde a compatibilidade permite. Reescrever precisa ser justificado — e a ferramenta de IA não decide sozinha que o reaproveitamento é seguro.

Amplificação: dois valores que não se confundem

(A) o valor já evidenciado na implementação de referência;
(B) o valor adicional possível quando a capacidade encontra os dados, os fluxos e os clientes do produto de destino.

(B) é sempre hipótese, e precisa ser validado de novo no contexto do destino.

Exemplo ilustrativo: o Work Pilot da organIA grava reuniões, gera atas e permite consultá-las. No WeON, as hipóteses a testar seriam associar a ata a contatos e oportunidades do CRM, gatilhos de follow-up e visibilidade de objeções por segmento. A evidência exigida muda: de tempo poupado e qualidade da ata para adoção, conversão e retrabalho — sem comprometer privacidade.

Como medir

Dimensão	Indicadores
Velocidade de aprendizagem	Dias até a primeira implementação funcional e até a primeira evidência de valor
Eficiência de transferência	Tempo da aprovação à integração, esforço de adaptação, % de código reutilizado
Resultado de produto	Ativação, adoção, retenção e impacto na métrica-alvo, com baseline
Confiabilidade	Falhas, regressões, incidentes de segurança, taxa de rollback
Portfólio	Hipóteses testadas, % encerradas por evidência, % incorporadas, custo por capacidade validada

Não se promete redução de prazo ou aumento de valor sem medição contra uma linha de base real.

De onde vêm as ideias

O INOVA-R combina práticas consolidadas num arranjo próprio — o que não significa que o framework como um todo já tenha sido validado:

Continuous Discovery (Teresa Torres) — validação contínua de valor com usuários.
InnerSource — reutilização de software entre equipes e produtos internos.
Software Product Lines (SEI–CMU) — reúso planejado de ativos e engenharia de variabilidade.
Spec-Driven Development (GitHub Spec Kit) — especificação como contexto estruturado para agentes.
CLAUDE.md / AGENTS.md — instruções persistentes para ferramentas de desenvolvimento com IA.

Próximos passos

Modelos oficiais: Opportunity Brief, Validation Report, PRT Manifest, Integration Plan, Value Amplification Canvas, Release Review.
Templates de AGENTS.md e CLAUDE.md separados por origem, destino e política transversal.
Piloto documentado organIA → WeON, com métricas basais e retrospectiva da primeira transferência.