Clintonrocha98/exemplo-pratico.md Secret

## exemplo-pratico.md

      
    Raw
  

              exemplo-pratico.md
            
          
    Cenário: Planejando uma Refatoração

/generate-plan "refatorar módulo de pagamentos para suportar múltiplos gateways"

Passo 1: Campo de Contexto Livre

O Octto abre um campo de texto livre no browser como primeira ação:
+-------------------------------------------------------------+
|                                                             |
| Descreva com detalhes o que voce quer planejar.             |
| Inclua contexto, motivacao, restricoes e qualquer           |
| informacao relevante.                                       |
|                                                             |
| +-------------------------------------------------------+   |
| |                                                       |   |
| | O modulo de pagamentos atual esta fortemente          |   |
| | acoplado ao PagSeguro. Precisamos suportar o          |   |
| | Stripe tambem para atender clientes internacionais.   |   |
| | O prazo e de 2 sprints. Nao podemos quebrar           |   |
| | integracoes existentes. O time de financas            |   |
| | precisa validar antes do deploy.                      |   |
| |                                                       |   |
| +-------------------------------------------------------+   |
|                                                             |
| [ ENVIAR ]                                                  |
|                                                             |
+-------------------------------------------------------------+

Passo 2: Octto Abre Interface de Brainstorm

Com o contexto já coletado, o browser exibe perguntas estruturadas em branches:
+-------------------------------------------------------------+
| OCTTO - Brainstorm                                          |
|                                                             |
| +-------------------------------------------------------+   |
| | BRANCH: Motivacao & Objetivos                         |   |
| |                                                       |   |
| | . Por que a mudanca e necessaria agora?               |   |
| | [___________________________________________]         |   |
| |                                                       |   |
| | . Quais gateways precisam ser suportados?             |   |
| | [___________________________________________]         |   |
| +-------------------------------------------------------+   |
|                                                             |
| +-------------------------------------------------------+   |
| | BRANCH: Requisitos & Restricoes                       |   |
| |                                                       |   |
| | . Quais funcionalidades sao criticas?                 |   |
| | [___________________________________________]         |   |
| |                                                       |   |
| | . Ha requisitos de performance?                       |   |
| | [___________________________________________]         |   |
| +-------------------------------------------------------+   |
|                                                             |
| +-------------------------------------------------------+   |
| | BRANCH: Riscos & Dependencias                         |   |
| |                                                       |   |
| | . Quais sao os maiores riscos tecnicos?               |   |
| | [___________________________________________]         |   |
| |                                                       |   |
| | . Quais sistemas serao impactados?                    |   |
| | [___________________________________________]         |   |
| +-------------------------------------------------------+   |
|                                                             |
| [ ENVIAR RESPOSTAS ]                                        |
|                                                             |
+-------------------------------------------------------------+

Passo 3: Plano Inicial Gerado

Arquivo criado: docs/plans/2026-03-08-refatorar-modulo-pagamentos.md.
# Refatoração do Módulo de Pagamentos

## Contexto

O módulo atual está acoplado ao PagSeguro.

Precisamos suportar múltiplos gateways (Stripe, PagSeguro, futuro: PIX).

## Objetivos

- Abstrair interface de gateway
- Permitir troca via configuração
- Manter retrocompatibilidade

## Requisitos
### Funcionais

- Suportar Stripe e PagSeguro
- Configuração por ambiente

### Não-funcionais

- Latência < 500ms
- 99.9% disponibilidade

## Restrições

- 2 sprints de prazo
- Não quebrar integrações existentes
  
## Riscos Identificados

- Diferenças nas APIs dos gateways
- Migração de dados de transações
  
## Próximos Passos

- Definir interface abstrata
- Implementar adapter PagSeguro
- Implementar adapter Stripe

Passo 4: Refinamento Técnico

O /refine-plan faz duas rodadas de perguntas no chat e expande o plano com arquitetura e diagramas:
## Arquitetura Proposta

### Diagrama de Componentes

+--------------------------------------------------+
| PaymentService                                   |
|                                                  |
| +--------------------------------------------+  |
| | PaymentGatewayInterface                    |  |
| |                                            |  |
| | + processPayment(amount, card): Result     |  |
| | + refund(transactionId): RefundResult      |  |
| | + getStatus(transactionId): Status         |  |
| +--------------------------------------------+  |
|                    ^                             |
|                    |                             |
|         +----------+----------+                  |
|         |          |          |                  |
| +-------+----+ +---+------+ +-+--------+         |
| | PagSeguro  | | Stripe   | | PIX      |         |
| | Adapter    | | Adapter  | | Adapter  |         |
| +------------+ +----------+ +----------+         |
|                                                  |
+--------------------------------------------------+

### Fluxo de Pagamento

+----------+   +--------------+   +-------------+
| Checkout |-->| PaymentSvc   |-->| Gateway     |
+----------+   +------+-------+   | Interface   |
                      |           +------+------+
                      |                  |
                      |           +------+------+
                      |           | Resolve     |
                      |           | Adapter     |
                      |           +------+------+
                      |                  |
                      |           +------v------+
                      |           | PagSeguro   |
                      |           | ou          |
                      |           | Stripe      |
                      |           +------+------+
                      |                  |
                      |<-----------------+
                      v
               +-------------+
               | Resultado   |
               +-------------+

## Decisões Técnicas

### Por que Strategy Pattern?
- **Problema:** Código acoplado a um gateway específico
- **Solução:** Interface abstrata + adapters
- **Alternativas consideradas:**
  - Factory simples (rejeitado: menos flexível)
  - Service Locator (rejeitado: anti-pattern)
- **Impacto:** Novo gateway = novo adapter, zero mudança no core

Passo 5: Revisão Visual

O Plannotator abre a interface de revisão:
+-------------------------------------------------------------+
| PLANNOTATOR - Revisao                                       |
|                                                             |
| +-------------------------------------------------------+   |
| | # Refatoracao do Modulo de Pagamentos                 |   |
| |                                                       |   |
| | ## Contexto [+ Anotar]                                |   |
| | O modulo atual esta acoplado ao PagSeguro...          |   |
| |                                                       |   |
| | ## Arquitetura Proposta [+ Anotar]                    |   |
| | [Diagrama de componentes...]                          |   |
| |                                                       |   |
| | ## Decisoes Tecnicas [+ Anotar]                       |   |
| | ### Por que Strategy Pattern?                         |   |
| | [Justificativas...]                                   |   |
| |                                                       |   |
| +-------------------------------------------------------+   |
|                                                             |
| +-------------------------------------------------------+   |
| | ANOTACOES:                                            |   |
| |                                                       |   |
| | . Arquitetura: "Considerar tambem webhooks"           |   |
| |                                                       |   |
| +-------------------------------------------------------+   |
|                                                             |
| [ APROVAR ]                    [ SOLICITAR MUDANCAS ]       |
|                                                             |
+-------------------------------------------------------------+

Resultado Final

Após aprovação, o plano está completo e documentado em:

docs/plans/2026-03-08-refatorar-modulo-pagamentos.md


## prompt-generate-plan.md

      
    Raw
  

              prompt-generate-plan.md
            
          
    ANTES DE QUALQUER OUTRA COISA:
Use a ferramenta ask_text para abrir um campo de texto livre com a pergunta:
"Descreva com detalhes o que você quer planejar. Inclua contexto, motivação, restrições e qualquer informação relevante."
Aguarde a resposta do usuário. Use esse texto como contexto principal para todas as etapas seguintes.

Execute a coleta estruturada de contexto para: $ARGUMENTS
Use o Octto (ferramentas create_brainstorm e await_brainstorm_complete) para:


Criar branches de exploração cobrindo:

Motivação e "porquê" da mudança
Requisitos funcionais
Requisitos não-funcionais
Restrições técnicas
Riscos e mitigações


Aguardar respostas do usuário


Sintetizar as respostas em um plano inicial


Antes de salvar, verifique se o diretório docs/plans/ existe no projeto atual.
Se não existir, crie-o com: mkdir -p docs/plans/
Em seguida, salve o plano em: docs/plans/YYYY-MM-DD-.md


O nome do arquivo deve ser gerado automaticamente baseado em:

Data atual (YYYY-MM-DD)
Slug derivado do objetivo (ex: "refatorar autenticação" → "refatorar-autenticacao")

OBJETIVO DO PLANEJAMENTO:
$ARGUMENTS

  
## refine-plan.md

      
    Raw
  

              refine-plan.md
            
          
    Leia o plano mais recente em docs/plans/ e expanda-o com detalhes técnicos.
PROCESSO DE REFINAMENTO:


Análise do plano atual

Leia o arquivo do plano existente
Identifique lacunas e áreas que precisam de detalhamento


Primeira rodada de perguntas (mínimo 5 perguntas)

Esclareça objetivos e restrições
Entenda premissas e contexto do problema
Use a ferramenta de perguntas interativas
Perguntas refinadas e estratégicas
Elimine ambiguidades
Confirme decisões arquiteturais


Expansão técnica
Adicione ao plano:

Diagramas de fluxo de sistema (ASCII art)
Arquitetura de componentes
Fluxos de usuário
Interações entre serviços/APIs


Documentação de decisões
Para cada decisão técnica, explique:

Qual problema está sendo resolvido
Por que a mudança é necessária
Impactos arquiteturais ou de produto
Alternativas consideradas


FORMATO DOS DIAGRAMAS:
ASCII art:
┌──────────┐     ┌──────────┐
│ Entrada  │────▶│ Decisão  │
└──────────┘     └────┬─────┘
                      │
              ┌───────┴───────┐
              ▼               ▼
        ┌──────────┐   ┌──────────┐
        │ Ação 1   │   │ Ação 2   │
        └──────────┘   └──────────┘

Atualize o arquivo do plano com as expansões técnicas.
Se $ARGUMENTS for fornecido, use como caminho do arquivo. Caso contrário, use o plano mais recente em docs/plans/.
No results found