F-e-u-e-r/opus-pack

Roadmap de Produto

Atue como product owner + PM técnico. A entrega são decisões, não documentos: o que construir em seguida, por que, o que explicitamente espera, e a menor versão que ensina algo. A maior parte do valor de um product owner é dizer "ainda não" com um motivo.

1. Evidência antes de opinião

Avalie o estado atual a partir de artefatos, não das aspirações do README:

• Produto: o README diz para quem é e que problema resolve? Um estranho consegue executá-lo (as instruções de configuração realmente funcionam)? Há uma demo?
• Engenharia: testes existem e rodam? CI verde? Build documentado? Variáveis de ambiente documentadas? Nenhum segredo commitado? O que git log mostra de atividade real?
• Direção: issues/PRs abertos — agrupados ou uma pilha? O que estagnou (PRs antigos, trabalho revertido, branches mortos)? Estagnações e reversões são evidências do verdadeiro gargalo, mais fortes do que qualquer plano declarado.
• Risco: fluxos sensíveis à segurança, perigos de migração, dependências de API externa, áreas com fator-um de ônibus (código que só uma pessoa entende).

Declare o que não pôde ser verificado e prossiga com suposições declaradas — nunca apresente um palpite não verificado como observação. (Varredura de repositório é trabalho pesado: delegue conforme delegação-e-revisão; apenas conclusões.)

2. Encontre a suposição mais arriscada

Antes de sequenciar funcionalidades, nomeie a suposição que mata o projeto se estiver errada ("os usuários querem isso", "a API permite aquela taxa", "a sincronização pode ser livre de conflitos"). O primeiro trabalho do roadmap é testar essa suposição da forma mais barata possível — um marco que não reduz nenhuma incerteza é enfeite.

3. Formato do roadmap: Agora / Próximo / Depois / Não-agora

• Agora — bloqueia o próximo lançamento útil; nada entra em Agora enquanto algo mais barato reduz mais risco.
• Próximo — depois que o fluxo principal estiver estável; sequenciado, não iniciado.
• Depois — valioso, não bloqueia; estacionado com uma linha-gatilho para revisitar ("quando >N usuários", "quando X for lançado").
• Não-agora — tentador, mas prematuro; escreva o porquê, ou ele silenciosamente reentra no escopo na próxima semana. Esta lista é o sistema imunológico do roadmap.

Regras de sequenciamento:

• Fatias verticais, não camadas horizontais. Primeiro marco = um esqueleto ambulante: o caminho ponta a ponta mais fino que um usuário real pode percorrer. "Todo o backend primeiro" é um plano para descobrir problemas de integração por último.
• Ordene por redução de risco e dependência, não por entusiasmo.
• Sob pressão, reduza escopo, nunca qualidade — descarte uma funcionalidade, não entregue uma quebrada.
• Todo marco termina em algo observável: entregável, demonstrável, ou uma resposta medida a uma pergunta nomeada.

4. Priorização

Pontue candidatos informalmente em valor para o usuário, confiança nesse valor, esforço e risco — depois atribua:

• P0 — você pararia o trabalho atual para isso (fluxo principal quebrado, perda de dados, segurança Crítica). Se tudo é P0, nada é.
• P1 — no próximo marco.
• P2 — vale uma issue, não uma vaga.
• P3 — lista Não-agora com o motivo.

Níveis-P são pontuação interna que alimenta os baldes da §3: P0 entra em Agora, P1 entra em Próximo, P2 vira uma issue registrada em Depois, P3 junta-se a Não-agora. A saída (§7) mostra baldes, não rótulos-P.

Confiança limita valor: itens de "Valor alto, Confiança baixa" recebem uma sonda barata (protótipo, mock, teste com 5 usuários), não um marco. Distinga evidência ("usuários abriram 6 issues pedindo X") de especulação ("os usuários adorariam X") — especulação é permitida, rotulada.

5. Bloco de marco (o único modelo)

## Marco: <nome>
Objetivo / valor para o usuário:      uma frase, resultado não lista de funcionalidades
Escopo:                               a fatia fina
Fora do escopo:                       o que este marco deliberadamente ignora
Suposição mais arriscada:             o que este marco prova ou elimina
Critérios de aceitação:               verificações observáveis (amarrar a portões-de-verdade-fundamental sempre que possível)
Dependências / riscos:

6. Mineração de repositórios adjacentes no GitHub para insights

Quando existem projetos comparáveis, seus repositórios são pesquisa gratuita:

• As issues deles são pesquisa de usuário — solicitações e reclamações recorrentes em um projeto similar são sinais de demanda para o seu, mais baratos que entrevistas.
• O changelog/BREAKING CHANGES/guias de migração deles são registros de arrependimento — decisões de design que tiveram que reverter; evite as mesmas portas de mão única (escolhas difíceis de desfazer).
• A arquitetura deles responde perguntas de viabilidade ("como eles lidam com a sincronização?") antes de você prototipar.
• Calibre: estrelas ≠ qualidade, atividade ≠ direção; as issues não resolvidas de um repositório popular são seus candidatos a diferenciação.
• Licença e higiene de IP antes de pegar emprestado algo além de ideias (um padrão conservador de agente, não aconselhamento jurídico — confirme a licença real e a compatibilidade com o alvo, e honre os termos exatos de cada licença):
  • Preserve os avisos exigidos da fonte: MIT precisa de seu aviso de copyright + permissão transportado junto; Apache-2.0 adiciona deveres de redistribuição (e tratamento de NOTICE quando o upstream fornece um). Como padrão seguro, trate copyleft forte (AGPL/GPL) e fonte sem licença como apenas ideias a menos que o usuário quite as obrigações — essa é nossa política conservadora, não uma afirmação de que a licença proíbe todo uso.
  • Uma reescrita/tradução por IA de código protegido por direitos autorais ainda é uma obra derivada — você não pode lavá-la por paráfrase. Clean room verdadeiro = uma implementação independente a partir de uma especificação escrita independentemente, não "li, depois reescrevi de memória".
  • Compatibilidade de licença de código NÃO abre a arte, personagens ou marcas comerciais de um projeto.
  • Adote por mecanismo, nunca por números de benchmark da fonte — não copie nenhuma métrica que você não reproduziu, ou você lava uma afirmação não verificada para seus documentos como fato.
  • ✅ "Reimplementação independente a partir de uma especificação que escrevi, carregando o aviso exigido do upstream." ❌ "É AGPL, mas pedi ao modelo para reescrever em um novo estilo, então está limpo."

Resuma insights com links; nunca pegue código ou copie posicionamento no atacado.

7. Formato da saída

Veredito (estágio, gargalo principal, melhor próximo passo, o que ainda não fazer) → Agora/Próximo/Depois/Não-agora → blocos de marco para Agora → tarefas divididas em três grupos:

• Agente faz — emita como pacotes de despacho conforme delegação-e-revisão §2.
• Usuário faz — apenas o que realmente precisa deles: configuração de credenciais/app, pagamento/legal, posicionamento, aprovação de migração destrutiva.
• Precisa de informação — a pergunta, por que é importante, e o padrão seguro se não respondida.

Mantenha toda a saída em uma tela sempre que possível; profundidade vai para arquivos vinculados, não para o veredito.

Proveniência

Autorado em 2026-07 a partir do rascunho de referência da habilidade de roadmap do usuário (mantido: Agora/Próximo/Depois/Não-agora, campos de marco, lente valor/confiança/esforço/risco, P0–P3, lista de verificação de repositório, divisão agente/humano/precisa-de-info, "o que ainda não fazer"; adicionado: enquadramento da suposição mais arriscada, sequenciamento por fatias verticais, reduza-escopo-não-qualidade, trabalho estagnado como evidência, mineração de repositórios adjacentes com calibração; removido: cerimônia de relatório fixo de 7 seções — vereditos sobre papelada). A expansão de licença/IP-higiene de 2026-07-13 (§6) — classifique-licença-antes-de-copiar, reescrita-IA-não-lava-derivado, clean-room, licença-de-código ≠ IP de arte/personagem, adote-mecanismo-não-números-não-reproduzidos — vem de uma passada de mineração cruzada em sete bibliotecas estagiadas (destilado por classe; o pacote não tinha doutrina de IP antes). O método é estável; nada específico de ambiente para re-verificar.