Epic: tornar Solution Landscape Research um gate do método Sky-Forge

[sraphaz]

Contexto

O Sky-Forge já possui market-scout e market-benchmark, mas a pesquisa atual está centrada em sinais de mercado, concorrentes, posicionamento e lacunas funcionais. Falta uma etapa metodológica explícita que investigue quais classes de solução, padrões arquiteturais, modelos operacionais, alternativas build/buy/adopt/integrate e classes de modelos computacionais ou de IA resolvem o tipo de problema antes da arquitetura-alvo ser proposta.

Spec inicial: docs/_meta/SOLUTION_LANDSCAPE_RESEARCH.md.

Resultado esperado

O fluxo passa a ser:

intake e intenção
→ framing do problema
→ requisitos e restrições
→ elevação + UX discovery
→ market benchmark
→ solution landscape research
→ composição de alternativas
→ gate de decisão humana/waiver
→ arquitetura C4 + ADRs + jornadas
→ arquitetura agêntica quando aplicável
→ segurança, testes, custos e craft
→ roadmap e plano de entrega
→ validação do pacote
→ export/publish/scaffold
→ outcome learning

Backlog de implementação

P0 — contrato e método

• Versionar schemas de solution-landscape.yaml, solution-options.yaml e solution-decision.md.
• Incluir os artefatos na sky-package.spec.yaml e nos profiles aplicáveis.
• Definir modos light, standard e deep e suas regras de seleção.
• Registrar procedência, data, recência, tipo de evidência e confiança.
• Distinguir fato, inferência e hipótese no contrato.

P0 — pipeline e gate

• Incluir solution-landscape-researcher antes de solutions-architect no sky-plan.
• Criar comando sky research-solutions -Slug <slug> ou incorporar etapa idempotente ao sky plan.
• Impedir arquitetura proposed sem decisão ou waiver documentado.
• Exigir pelo menos duas alternativas viáveis, salvo impossibilidade justificada.
• Converter gaps em requisito, pesquisa adicional, spike, ADR ou risco.

P0 — pesquisa e fontes

• Reutilizar research.md, market-signals.yaml e market-benchmark.yaml sem misturar adequação técnica com popularidade.
• Priorizar documentação oficial, padrões e fontes primárias.
• Registrar tecnologias descontinuadas, lock-in, soberania, privacidade e reversibilidade.
• Incluir alternativas não baseadas em IA.
• Definir freshness window por domínio e alertas de evidência obsoleta.

P1 — opções e decisão

• Gerar de 2 a 5 opções compostas com fronteiras, componentes, modelo build/buy/adopt, modelo operacional, custo/complexidade relativos e riscos.
• Criar matriz de decisão baseada em requisitos discriminantes.
• Integrar cost-tier-advisor, security-compliance e test-architect à avaliação.
• Gerar spikes/PoCs para hipóteses críticas.
• Registrar opção escolhida, rejeitadas, trade-offs aceitos e condições de reavaliação.

P1 — UX e showcase

• Exibir alternativas, evidências, confiança, decisão e gaps no projeto local.
• Permitir decisão guiada pelo sky-host, uma escolha por turno.
• Sanitizar fornecedores, preços, credenciais e dados de cliente no preview público.
• Mostrar claramente quando a arquitetura foi baseada em hipótese e não em experimento.

P1 — validação e fixtures

• Fixture que compare build, buy e hybrid.
• Fixture com alternativa não-IA vencendo uma alternativa de IA.
• Fixture regulada em modo deep.
• Testes de idempotência e reexecução com fontes atualizadas.
• Testes para waiver, fonte ausente, evidência vencida e opção única justificada.

P2 — memória e aprendizado

• Relacionar decisão com ADRs e outcomes.
• Permitir estado superseded quando contexto ou evidência mudar.
• Reutilizar aprendizados anteriores sem transformar decisão histórica em recomendação universal.
• Comparar previsão documental com resultados de spike e produção.

Critérios de aceite do epic

1. sky plan gera ou valida a pesquisa antes da arquitetura.
2. A arquitetura não avança sem decisão ou waiver auditável.
3. O pacote exporta os três artefatos novos.
4. Toda recomendação possui fonte, contexto, trade-off, confiança e validade.
5. Pelo menos uma fixture demonstra escolha contextual entre build, buy e hybrid.
6. Showcase e export para IA apresentam a decisão sem vazar dados sensíveis.
7. Documentação, roadmap, agentes e catálogo de skills refletem o fluxo novo.

Relação com backlog atual

• Hub local lê sessões + outputs: necessário para visualizar pesquisa privada e alternativas.
• Wizard export-para-IA: deve incluir os novos artefatos e checklist de sensibilidade.
• RFC em prática: mudanças futuras na rubrica/gate devem tramitar por RFC.
• Modo local/runtime agnóstico: importante para pesquisas com dados confidenciais.
• MCP/API: futuramente expõe pesquisa, alternativas e decisão como protocolo.
• Impacto verificado/calibração contínua: outcomes validarão se os modelos recomendados realmente funcionaram.
• Conexão Git local-first: permite sincronizar decisão, ADRs e spikes no repo da aplicação.