Capacidade do Produto

Esta habilidade transforma a intenção do produto em restrições de engenharia explícitas.

Use-a quando a lacuna não for "o que devemos construir?", mas sim "o que exatamente deve ser verdade antes do início da implementação?"

Quando Usar

• Existe um PRD, item de roadmap, discussão ou nota do fundador, mas as restrições de implementação ainda são implícitas
• Uma funcionalidade abrange vários serviços, repositórios ou equipes e precisa de um contrato de capacidade antes da codificação
• A intenção do produto é clara, mas as implicações de arquitetura, dados, ciclo de vida ou políticas ainda são vagas
• Engenheiros seniores continuam repetindo as mesmas suposições ocultas durante a revisão
• Você precisa de um artefato reutilizável que possa sobreviver a diferentes ambientes e sessões

Artefato Canônico

Se o repositório tiver um arquivo de contexto de produto durável, como PRODUCT.md, docs/product/, ou um diretório de especificação de programa, atualize-o lá.

Se nenhum manifesto de capacidade existir ainda, crie um usando o modelo em:

• docs/examples/product-capability-template.md

O objetivo não é criar outra pilha de planejamento. O objetivo é tornar as restrições de capacidade ocultas duráveis e reutilizáveis.

Regras Inegociáveis

• Não invente a verdade do produto. Marque explicitamente as perguntas não resolvidas.
• Separe as promessas visíveis ao usuário dos detalhes de implementação.
• Destaque o que é política fixa, o que é preferência de arquitetura e o que ainda está em aberto.
• Se a solicitação entrar em conflito com as restrições existentes do repositório, diga isso claramente em vez de amenizar.
• Prefira um artefato de capacidade reutilizável em vez de notas ad hoc dispersas.

Entradas

Leia apenas o que for necessário:

1. Intenção do produto
   • issue, discussão, PRD, nota de roadmap, mensagem do fundador
2. Arquitetura atual
   • documentação relevante do repositório, contratos, esquemas, rotas, fluxos de trabalho existentes
3. Contexto de capacidade existente
   • PRODUCT.md, documentos de design, RFCs, notas de migração, documentos do modelo operacional
4. Restrições de entrega
   • autenticação, faturamento, conformidade, rollout, compatibilidade retroativa, desempenho, política de revisão

Fluxo de Trabalho Principal

1. Refaça a capacidade

Comprima a solicitação em uma declaração precisa:

• quem é o usuário ou operador
• qual nova capacidade existe após o lançamento
• qual resultado muda por causa disso

Se esta declaração for fraca, a implementação se desviará.

2. Resolva as restrições de capacidade

Extraia as restrições que devem ser atendidas antes da implementação:

• regras de negócio
• limites de escopo
• invariantes
• limites de confiança
• propriedade dos dados
• transições de ciclo de vida
• requisitos de rollout / migração
• expectativas de falha e recuperação

Estas são as coisas que muitas vezes vivem apenas na memória de engenheiros seniores.

3. Defina o contrato voltado para a implementação

Produza um plano de capacidade no estilo SRS com:

• resumo da capacidade
• não-metas explícitas
• atores e superfícies
• estados e transições necessários
• interfaces / entradas / saídas
• implicações do modelo de dados
• restrições de segurança / faturamento / políticas
• requisitos de observabilidade e operador
• perguntas abertas que bloqueiam a implementação

4. Traduza para execução

Termine com a entrega exata:

• pronto para implementação direta
• precisa de revisão de arquitetura primeiro
• precisa de esclarecimento do produto primeiro

Se útil, aponte para a próxima fila nativa do ECC:

• project-flow-ops
• workspace-surface-audit
• api-connector-builder
• dashboard-builder
• tdd-workflow
• verification-loop

Formato de Saída

Retorne o resultado nesta ordem:

CAPABILITY
- one-paragraph restatement

CONSTRAINTS
- fixed rules, invariants, and boundaries

IMPLEMENTATION CONTRACT
- actors
- surfaces
- states and transitions
- interface/data implications

NON-GOALS
- what this lane explicitly does not own

OPEN QUESTIONS
- blockers or product decisions still required

HANDOFF
- what should happen next and which ECC lane should take it

Bons Resultados

• A intenção do produto agora é concreta o suficiente para ser implementada sem redescobrir restrições ocultas no meio de um PR.
• A revisão de engenharia tem um artefato durável em vez de depender da memória ou do contexto do Slack.
• O plano resultante é reutilizável em superfícies de planejamento Claude Code, Codex, Cursor, OpenCode e ECC 2.0.