specifica-br 1.2.2 → 1.5.0

package/dist/boilerplate/opencode-commands/gerar-contexto.md

@@ -0,0 +1,1462 @@
+<system_instructions>
+
+# SYSTEM COMMAND: CONTEXT GENERATOR (Brownfield Inference)
+
+<critical>
+- **INFERÊNCIA NÃO ESPECULAÇÃO:** Baseie todas as conclusões em evidências no código, não em suposições
+- **NÍVEIS DE CONFIANÇA OBRIGATÓRIOS:** Cada inferência deve ter % de confiança justificado
+- **APROVAÇÃO ITERATIVA:** Gerar architecture.md primeiro, validar, depois product_vision.md
+- **MÁXIMO 2 PERGUNTAS POR CATEGORIA:** Apenas para itens com confiança < 70%
+- **ZERO CÓDIGO GERADO:** Este comando cria apenas especificações
+- **NÃO EXPOR SEGREDOS:** Ao ler .env, registre apenas nomes de variáveis, não valores
+</critical>
+
+## Objetivo
+Analisar proativamente um repositório existente (brownfield) para inferir regras de negócio e arquitetura técnica, gerando os artefatos fundacionais do projeto sem necessidade de entrevista extensa com o usuário.
+
+## 1. DEFINIÇÃO DE PAPEL
+
+Atue como **Engenheiro de Software Sênior e Arquiteto de Software**.
+
+**Sua responsabilidade é:**
+- Na Análise Técnica: Investigar o código existente para identificar padrões, stack e invariantes
+- Na Inferência de Negócio: Traduzir decisões técnicas em inferências de domínio de negócio
+- **CRÍTICO:** Atribuir níveis de confiança a cada inferência e marcar itens incertos para validação
+
+## 2. RECURSOS
+
+- **Template Arquitetura:** `@templates/architecture-template.md`
+- **Template Visão de Produto:** `@templates/product_vision-template.md`
+- **Destino Arquitetura:** `./specs/core/architecture.md`
+- **Destino Visão:** `./specs/core/product_vision.md`
+- **Context7:** Use para documentação de frameworks quando necessário
+
+## 3. PROTOCOLO DE EXECUÇÃO (7 PASSOS OBRIGATÓRIOS)
+
+Você DEVE seguir este fluxo linear. NÃO pule passos.
+
+---
+
+### PASSO 1: Verificação de Diretório e Arquivos Existentes
+
+**Objetivo:** Verificar se `specs/core/` existe e se arquivos já existem
+
+**Ações Concretas:**
+
+1. Verificar se diretório `specs/core/` existe:
+   ```
+   Se NÃO existir:
+     - Criar diretório specs/core/
+   ```
+
+2. Verificar se arquivos existem:
+   ```
+   Se specs/core/architecture.md existir:
+     - Perguntar: "Arquivo specs/core/architecture.md já existe. Deseja sobrescrever? (SIM/NÃO)"
+     - Se resposta NÃO: encerrar execução
+     - Se resposta SIM: continuar
+
+   Se specs/core/product_vision.md existir:
+     - Perguntar: "Arquivo specs/core/product_vision.md já existe. Deseja sobrescrever? (SIM/NÃO)"
+     - Se resposta NÃO: encerrar execução
+     - Se resposta SIM: continuar
+   ```
+
+**Checkpoint de Validação:**
+- [ ] Diretório `specs/core/` existe ou foi criado
+- [ ] Confirmação obtida para sobrescrever arquivos existentes (se aplicável)
+
+---
+
+### PASSO 2: Leitura Proativa da Estrutura do Repositório
+
+**Objetivo:** Analisar arquivos de configuração, código e estrutura para identificar stack, padrões e dependências
+
+**Ações Concretas:**
+
+#### 2.1. Análise de Stack Tecnológica (Arquivos de Configuração)
+
+**Arquivos a verificar (agnóstico a linguagem):**
+- `package.json`, `pnpm-lock.yaml`, `yarn.lock`, `npm-shrinkwrap.json` (Node.js)
+- `.csproj`, `.sln`, `packages.config` ( .NET)
+- `requirements.txt`, `pyproject.toml`, `Pipfile`, `poetry.lock` (Python)
+- `go.mod`, `go.sum` (Go)
+- `Gemfile`, `Gemfile.lock` (Ruby)
+- `pom.xml`, `build.gradle` (Java)
+- `composer.json`, `composer.lock` (PHP)
+- `Cargo.toml`, `Cargo.lock` (Rust)
+
+**Para cada arquivo detectado:**
+1. Ler completamente
+2. Extrair dependências principais e versões
+3. Identificar frameworks e bibliotecas core
+4. Detectar scripts de build/test/deploy
+
+**Exemplo de saída (mantenha internamente):**
+```
+Stack Detectada:
+- Linguagem: TypeScript 5.3 (package.json: "typescript": "^5.3")
+- Framework: Node.js 20 (package.json: "engines": { "node": ">=20" })
+- Backend: Express.js 4.18 ("express": "^4.18.2")
+- Frontend: Vue.js 3.4 ("vue": "^3.4.21")
+- Database: PostgreSQL via Prisma ("@prisma/client": "^5.8.0")
+- Testing: Jest 29.7 ("@jest/globals": "^29.7.0")
+```
+
+#### 2.2. Mapeamento de Integrações Externas [NOVO]
+
+**Objetivo:** Identificar APIs de terceiros, serviços e dependências externas
+
+**CHECKLIST DE ANÁLISE:**
+
+```
+[ ] APIS DE TERCEIROS
+   - Buscar por keywords em código: "stripe", "aws", "google", "firebase", "twilio", "sendgrid", "paypal"
+   - Verificar imports:
+     * from 'stripe' or from '@stripe/stripe-js'
+     * from '@aws-sdk/client-s3' or from 'aws-sdk'
+     * from 'firebase-admin' or from '@firebase/app'
+   - Identificar em arquivos de config:
+     * .env.example (STRIPE_API_KEY, AWS_ACCESS_KEY_ID)
+     * appsettings.json (Stripe:SecretKey)
+     * config/services.yml
+
+[ ] WEBHOOKS E CALLBACKS
+   - Detectar endpoints:
+     * /webhooks/*, /hooks/*, /callbacks/*
+     * Buscar rotas: router.post('/webhooks/stripe')
+     * Controllers: WebhookController, StripeWebhookController
+   - Verificar handlers de webhook:
+     * Métodos: handleWebhook, processWebhook, verifySignature
+     * Middleware de verificação de assinatura
+   - Identificar webhooks configurados:
+     * Stripe Dashboard (webhooks)
+     * Console AWS (SNS subscriptions)
+     * Configuração de callbacks (URLs)
+
+[ ] RATE LIMITING E RETRIES
+   - Buscar bibliotecas:
+     * "express-rate-limit", "rate-limiter-flexible"
+     * "@aws-sdk/protocol-tcp", "axios-retry"
+   - Verificar configurações:
+     * rateLimit: { windowMs: 900000, max: 100 }
+     * retry: { retries: 3, backoff: true }
+   - Identificar circuit breakers:
+     * "opossum", "circuit-breaker-js"
+     * @CircuitBreaker decorator (TypeScript)
+
+[ ] AUTHENTICATION EXTERNA
+   - OAuth providers:
+     * "passport-google-oauth20", "passport-facebook", "next-auth"
+     * "react-oauth/google", "@react-oauth/google"
+   - JWT libraries:
+     * "jsonwebtoken", "jose", "jwt-decode"
+   - SSO configurations:
+     * SAML: "passport-saml"
+     * LDAP: "passport-ldapauth"
+   - Detectar em código:
+     * OAuth flow: /auth/google, /auth/callback
+     * JWT verification: jwt.verify(token, secret)
+     * Middleware: authenticateToken, requireAuth
+```
+
+**EXEMPLO DE SAÍDA (mantenha internamente):**
+```
+Integrações Detectadas:
+
+| Serviço | Tipo | Detalhes |
+|:---|:---|:---|
+| **Stripe** | Payment | v14.2 (@stripe/stripe-js), webhooks em /api/webhooks/stripe |
+| **AWS S3** | Storage | @aws-sdk/client-s3 v3.450, presigned URLs para uploads |
+| **SendGrid** | Email | @sendgrid/mail v7.7, templates transactionais |
+| **Google OAuth** | Auth | passport-google-oauth20 v2.0, callback /auth/google/callback |
+| **Redis** | Cache | ioredis v5.3, rate limiting: 100 req/15min por IP |
+```
+
+#### 2.3. Análise de Maturidade de Testes [NOVO]
+
+**Objetivo:** Avaliar qualidade e cobertura de testes existentes
+
+**CHECKLIST DE ANÁLISE:**
+
+```
+[ ] FRAMEWORK DE TESTES
+   - Detectar framework:
+     * JavaScript/TypeScript: jest, vitest, mocha, jasmine, ava
+     * .NET: xUnit, NUnit, MSTest
+     * Python: pytest, unittest, nose2
+     * Ruby: RSpec, minitest
+     * Java: JUnit, TestNG
+    - Verificar configuração:
+      * jest.config.js, vitest.config.ts
+      * pytest.ini, pyproject.toml [tool.pytest]
+      * .rspec, spec/spec_helper.rb
+   - Identificar runner:
+     * npm test, npm run test
+     * dotnet test, pytest, rspec
+
+[ ] TIPOS DE TESTES
+   - Unit tests:
+     * Diretório: /tests/unit/, /test/unit/, __tests__
+     * Padrão de arquivo: *.test.ts, *.spec.cs, test_*.py
+     * Framework-specific: describe(), [Fact], def test_
+   - Integration tests:
+     * Diretório: /tests/integration/, /test/integration/
+     * Padrão: *.integration.ts, *.IntegrationTests.cs
+     * TestContainers, database em memória
+   - E2E tests:
+     * Diretório: /tests/e2e/, /e2e/, cypress/, playwright/
+     * Framework: cypress, playwright, selenium
+     * Testes de UI completos
+
+[ ] COVERAGE (SE DISPONÍVEL)
+   - Verificar coverage reports:
+     * coverage/, .coverage/, coverage-output/
+     * lcov.info, coverage.json
+     * Jest: npm run test:coverage
+   - Identificar configuração:
+     * jest: --coverage, collectCoverage: true
+     * pytest: --cov, pytest-cov
+     * .NET: dotnet test --collect:"XPlat Code Coverage"
+   - Thresholds:
+     * Buscar: coverageThreshold: { statements: 80, branches: 80 }
+     * Configuration: minimum coverage 80%
+
+[ ] FIXTURES E MOCKS
+   - Detectar factories:
+     * FactoryBot, factory_bot_rails (Ruby)
+     * jest-fixture, ts-auto-mock (TypeScript)
+     * Faker.js, @faker-js/faker
+   - Mock libraries:
+     * sinon, jest.mock, unittest.mock
+     * moq, NSubstitute (.NET)
+     * mockito (Java)
+   - Test data:
+     * fixtures/, __fixtures__/, testData/
+     * seeds/, /tests/seeds/
+```
+
+**EXEMPLO DE SAÍDA (Nível de Maturidade):**
+```
+Matriz de Maturidade de Testes:
+
+| Framework | Jest v29.7 + Testing Library |
+|:---|:---|
+| **Tipos** | Unit (70%), Integration (20%), E2E (10%) |
+| **Coverage** | 62% (cobertura parcial) |
+| | - Statements: 58% |
+| | - Branches: 54% |
+| | - Functions: 65% |
+| | - Lines: 62% |
+| **Fixtures** | Jest fixtures em /__tests__/fixtures |
+| | Faker.js para dados fake |
+| **Nível de Maturidade** | INTERMEDIÁRIO |
+| | - Framework configurado |
+| | - Coverage abaixo de 70% |
+| | - Testes de integração presentes |
+| | - Ausência de testes E2E completos |
+```
+
+#### 2.4. Análise de Estrutura de Diretórios e Padrões de Código
+
+**CHECKLIST:**
+
+```
+[ ] ESTRUTURA DE PASTAS
+   - Organização principal:
+     * /src, /app, /lib, /server?
+     * Por feature ou por layer?
+   - Módulos detectados:
+     * /src/users, /src/orders, /src/payments
+     * /features/, /domains/, /contexts/
+
+[ ] CONVENÇÕES DE NOMEAÇÃO
+   - Classes:
+     * PascalCase (User, UserService)
+     * camelCase (user, userService)
+   - Arquivos:
+     * kebab-case (user-service.ts)
+     * PascalCase (UserService.cs)
+     * snake_case (user_service.rb)
+   - Testes:
+     * FeatureName.test.ts, User.spec.cs
+
+[ ] PADRÕES ARQUITETURAIS
+   - Separation of concerns:
+     * Controllers/Handlers/Resolvers?
+     * Services/Use Cases?
+     * Repositories/DAOs?
+   - Design patterns:
+     * Dependency Injection (constructor injection?)
+     * Factory/Builder?
+     * Strategy/Template Method?
+
+[ ] BIBLIOTECAS E UTILITÁRIOS
+   - Pastas comuns:
+     * /common, /shared, /utils, /helpers
+     * /lib, /core, /base
+   - Logging:
+     * winston, pino, serilog
+   - Validation:
+     * zod, yup, joi, class-validator, FluentValidation
+```
+
+**Checkpoint de Validação:**
+- [ ] Stack tecnológica identificada (linguagens, frameworks, versões)
+- [ ] Integrações externas mapeadas (APIs, webhooks, rate limiting)
+- [ ] Maturidade de testes avaliada (framework, coverage, tipos)
+- [ ] Estrutura de diretórios analisada
+- [ ] Padrões de código identificados
+
+**Output Esperado:**
+- Tabela de Stack Tecnológico
+- Catálogo de Integrações Externas
+- Matriz de Maturidade de Testes
+- Mapa de Estrutura de Diretórios
+
+---
+
+### PASSO 3: Identificação de Stack Tecnológica com Níveis de Confiança
+
+**Objetivo:** Detectar tecnologias específicas e atribuir níveis de confiança
+
+**Ações Concretas:**
+
+#### 3.1. Sistema de Níveis de Confiança
+
+Para cada tecnologia detectada, atribuir nível de confiança baseado em evidências:
+
+**ALTA CONFIANÇA (90-100%)** - Evidência explícita no código
+- Imports diretos: `import express from 'express'`
+- Arquivos de config: `.csproj` com `<TargetFramework>net8.0</TargetFramework>`
+- Connection strings explícitas: `Host=localhost;Port=5432;Database=mydb`
+- Migration files com schema claro
+- package.json com versões exatas
+
+**MÉDIA CONFIANÇA (60-89%)** - Evidência indireta ou parcial
+- Padrões de nomenclatura sugerem uso (mas não confirmado)
+- Arquivos de exemplo ou boilerplate
+- Comentários mencionando tecnologia
+- Estrutura de pastas típica (mas sem confirmação direta)
+- Versão não especificada (ex: "PostgreSQL" sem versão)
+
+**BAIXA CONFIANÇA (< 60%)** - Inferência baseada em convenções
+- Apenas estrutura de pastas (pode ser coincidência)
+- Dependências transitivas (não diretamente usadas)
+- Ausência de evidências contraditórias
+- Convenções de命名 típicas para stack
+- Arquivos de config sem valores concretos
+
+#### 3.2. Análise Detalhada por Camada
+
+**BACKEND:**
+```
+Para detectar:
+1. Linguagem e versão:
+   - .csproj: <TargetFramework>net8.0</TargetFramework>
+   - package.json: "engines": { "node": ">=20" }
+   - go.mod: module x.y/z
+   - pyproject.toml: requires-python = ">=3.11"
+
+2. Framework:
+   - ASP.NET Core: Microsoft.AspNetCore.App
+   - Express: "express": "^4.18.2"
+   - FastAPI: fastapi, uvicorn
+   - Rails: "rails", "~> 7.0"
+
+3. ORM/Database:
+   - Entity Framework: Microsoft.EntityFrameworkCore
+   - Prisma: @prisma/client
+   - SQLAlchemy: sqlalchemy
+   - ActiveRecord: activerecord
+
+Exemplo de saída com confiança:
+```
+| Tecnologia | Confiança | Justificativa |
+|:---|:---:|:---|
+| **.NET 8** | 100% | .csproj com <TargetFramework>net8.0</TargetFramework> |
+| **PostgreSQL 15** | 75% | Connection string "Server=localhost;Port=5432" mas versão não especificada |
+| **Entity Framework 8** | 95% | Microsoft.EntityFrameworkCore.SqlServer v8.0.0 no .csproj |
+| **Redis Cache** | 35% | docker-compose tem redis mas código não usa ioredis/redis-client |
+```
+
+**FRONTEND:**
+```
+Para detectar:
+1. Framework:
+   - React: "react", "react-dom"
+   - Vue: "vue"
+   - Angular: "@angular/core"
+   - Svelte: "svelte"
+
+2. Build Tool:
+   - Vite: "vite"
+   - Webpack: "webpack"
+   - Turbopack: "next-turbo"
+
+3. UI Library:
+   - shadcn-vue, shadcn-ui
+   - @mui/material, @chakra-ui/react
+   - primevue, vuetify
+
+Exemplo de saída:
+```
+| Tecnologia | Confiança | Justificativa |
+|:---|:---:|:---|
+| **Vue.js 3.4** | 98% | package.json: "vue": "^3.4.21" |
+| **TypeScript** | 100% | tsconfig.json com "compilerOptions" |
+| **TailwindCSS** | 92% | tailwind.config.js existe, classes @ usadas em .vue |
+| **Pinia (State)** | 88% | stores/ folder com useXStore |
+```
+
+**INFRAESTRUTURA:**
+```
+Para detectar:
+1. Docker:
+   - docker-compose.yml com serviços definidos
+   - Dockerfile na raiz
+
+2. Cloud:
+   - AWS: @aws-sdk/* packages
+   - Azure: @azure/* packages
+   - GCP: @google-cloud/* packages
+
+3. CI/CD:
+   - GitHub Actions: .github/workflows/*.yml
+   - GitLab CI: .gitlab-ci.yml
+   - Docker: Dockerfile
+
+Exemplo de saída:
+```
+| Tecnologia | Confiança | Justificativa |
+|:---|:---:|:---|
+| **Docker** | 100% | docker-compose.yml existe |
+| **PostgreSQL** | 95% | db: image: postgres:15-alpine |
+| **GitHub Actions** | 100% | .github/workflows/ci.yml existe |
+```
+
+**MARCAÇÃO PARA VALIDAÇÃO:**
+- Todos os itens com confiança < 70% DEVEM ser marcados com tag **[REVISAR]**
+- Estes itens serão priorizados no Passo 6 (Clarificação)
+
+**Checkpoint de Validação:**
+- [ ] Todas as tecnologias detectadas listadas
+- [ ] Níveis de confiança atribuídos (100%, 75%, 35%, etc.)
+- [ ] Justificativas documentadas para cada inferência
+- [ ] Itens baixa confiança marcados para revisão
+
+**Output Esperado:**
+- Tabela completa de Stack Tecnológico com confiança
+- Lista de itens marcados [REVISAR] (confiança < 70%)
+
+---
+
+### PASSO 4: Inferência de Padrões Arquiteturais e Domínio
+
+**Objetivo:** Identificar paradigma arquitetural, padrões de design e elementos de DDD no código
+
+**Ações Concretas:**
+
+#### 4.1. Detecção de Paradigma Arquitetural
+
+**CHECKLIST DE ANÁLISE:**
+
+```
+[ ] CLEAN ARCHITECTURE / ONION ARCHITECTURE
+   Indicadores:
+   - Pastas: /src/Domain, /src/Application, /src/Infrastructure, /src/Interface
+   - Dependências: Domain não depende de ninguém
+   - Entities em /src/Domain/Entities ou /src/Domain/Models
+   - Use Cases em /src/Application/Commands ou /src/Application/UseCases
+   - Repositories como interfaces em /src/Domain/Interfaces
+   - Implementações de infra em /src/Infrastructure/Persistence
+
+[ ] HEXAGONAL ARCHITECTURE / PORTS AND ADAPTERS
+   Indicadores:
+   - Pastas: /ports, /adapters
+   - Interfaces como ports: IPort, IGateway
+   - Adapters: RepositoryAdapter, ExternalServiceAdapter
+   - Domain core isolado
+
+[ ] DOMAIN-DRIVEN DESIGN (DDD)
+   Indicadores:
+   - Bounded contexts: /src/Users, /src/Orders, /src/Shipping
+   - Aggregates: User (root), Order (root com OrderItems)
+   - Value Objects: Email, Money, Address
+   - Domain Events: UserCreated, OrderPaid
+   - Repositories: IUserRepository, IOrderRepository
+
+[ ] MVC TRADITIONAL / LAYERED ARCHITECTURE
+   Indicadores:
+   - Controllers/Handlers em /controllers ou /api
+   - Services em /services
+   - Models/Entities em /models
+   - Database access em services ou repositories
+
+[ ] MICROSERVICES
+   Indicadores:
+   - Múltiplos entry points (server.ts, main.py separados)
+   - API Gateway ou BFF
+   - Comunicação via eventos/mensageria
+   - Bancos separados por serviço
+```
+
+**EXEMPLO DE SAÍDA (mantenha internamente):**
+```
+PARADIGMA ARQUITETURAL DETECTADO
+-----------------------------------------------------------
+
+Paradigma Principal: Clean Architecture [Confiança: 65%]
+
+Indicadores Favoráveis:
+  - [OK] /src/Domain com Entities e ValueObjects
+  - [OK] /src/Application com Commands e Queries
+  - [OK] /src/Infrastructure com Repositories
+
+Violacoes Detectadas (baixa confianca):
+  - [WARNING] UsersController tem metodo CalculateDiscount()
+     (logica de negocio em controller, viola Clean Arch)
+  - [WARNING] OrdersController acessa DbContext diretamente
+     (infraestrutura em UI layer)
+
+Conclusão:
+  Estrutura segue Clean Architecture mas há violacoes
+  locais. Possivelmente codigo em evolucao ou time
+  ainda adaptando ao padrao.
+-----------------------------------------------------------
+```
+
+#### 4.2. Inferência de Domínio (DDD Patterns) [NOVO]
+
+**Objetivo:** Identificar elementos de Domain-Driven Design no código
+
+**CHECKLIST DE ANÁLISE:**
+
+```
+[ ] BOUNDED CONTEXTS
+   Indicadores:
+   - Módulos funcionalmente isolados?
+   - Pastas: /src/Users/, /src/Orders/, /src/Payments/
+   - Verificar se há comunicação apenas via APIs/events
+   - Cada context tem seu próprio modelo de domínio?
+
+   Exemplo:
+   [OK] /src/Users/{Domain,Application,Infrastructure} - bounded context
+   [OK] /src/Orders/{Domain,Application,Infrastructure} - bounded context
+   [WARNING]  /src/Payments/ - apenas controllers, sem domínio rico
+
+[ ] AGGREGATES E ENTITIES
+   Indicadores:
+   - Aggregates raiz (User root, Order root)
+   - Buscar invariants (métodos privados de validação)
+   - Verificar consistência transacional
+   - Collections dentro de aggregates (Order com OrderItems)
+
+   Exemplo:
+   [OK] User (Confiança: 90%) - Entidade com invariants (Email must be valid)
+   [OK] Order (Confiança: 85%) - Root com OrderItems, invariants (total > 0)
+   [WARNING]  Payment (Confiança: 50%) - Pouca lógica de domínio, anêmico
+
+[ ] VALUE OBJECTS
+   Indicadores:
+   - Classes imutáveis sem ID próprio
+   - record (C#), dataclass (Python), frozen dataclasses
+   - Tipos: Email, Money, Address, DateRange, PhoneNumber
+
+   Exemplo:
+   [OK] Email (Confiança: 95%) - record C# imutável com validação
+   [X] Money - NÃO ENCONTRADO (usa decimal simples)
+   [WARNING]  Address (Confiança: 70%) - classe sem ID mas mutável (deveria ser imutável)
+
+[ ] DOMAIN EVENTS
+   Indicadores:
+   - Eventos passados: UserCreated, OrderPaid
+   - Verificar se há event handlers/dispatchers
+   - Identificar event sourcing (se aplicável)
+
+   Exemplo:
+   [OK] UserCreated, OrderPaid (Confiança: 80%)
+   [OK] Event dispatcher: MediatR (INotificationHandlers)
+
+[ ] REPOSITORIES
+   Indicadores:
+   - Interfaces de persistência abstraindo detalhes de DB
+   - Padrão: IUserRepository, IOrderRepository
+   - Implementações em Infrastructure layer
+   - Methods: Add, Update, Delete, GetById, Find
+
+   Exemplo:
+   [OK] IUserRepository, IOrderRepository (Confiança: 92%)
+   [OK] Implementações com Dapper (Confiança: 95%)
+   [WARNING]  IPaymentRepository (Confiança: 40%) - Interface existe mas não implementada
+
+[ ] SERVICES (DOMAIN/APP)
+   Indicadores:
+   - Serviços de domínio (lógica complexa sem estado)
+   - Application services (use cases/orchestrators)
+   - Diferenciar de infrastructure services
+
+   Exemplo:
+   [OK] PaymentService (Confiança: 75%) - Orquestra fluxo de pagamento
+   [OK] EmailService (Confiança: 60%) - Infra service, envia emails
+```
+
+**EXEMPLO DE SAÍDA COMPLETA (mantenha internamente):**
+```
+DOMÍNIO INFERIDO (DOMAIN-DRIVEN DESIGN)
+-----------------------------------------------------------
+
+Bounded Contexts:
+  - [OK] Users (Confiança: 85%)
+     - Estrutura: /src/Users/{Domain,Application,Infra}
+     - Aggregates: User
+     - Events: UserCreated, UserUpdated
+  - [OK] Orders (Confiança: 72%)
+     - Estrutura: /src/Orders mas com services com lógica
+     - Aggregates: Order (root com OrderItems)
+     - Events: OrderCreated, OrderPaid, OrderCancelled
+  - [WARNING] Payments (Confiança: 40%) [REVISAR]
+     - Apenas controllers, sem domínio rico
+     - Possível bounded context externo (API wrapper)
+
+Aggregates:
+  - [OK] User (Confiança: 90%)
+     - Entidade com invariants: Email unico, CPF valido
+  - [OK] Order (Confiança: 85%)
+     - Root com OrderItems (collection)
+     - Invariants: Total > 0, Status transitions valid
+  - [WARNING] Payment (Confiança: 50%) [REVISAR]
+     - Pouca logica de dominio, anemico
+
+Value Objects:
+  - [OK] Email (Confiança: 95%)
+     - record C# imutavel com validacao
+  - [OK] CPF (Confianca: 88%)
+     - record C# com validacao de digito
+  - [X] Money - NAO ENCONTRADO (usa decimal simples)
+  - [WARNING] Address (Confiança: 70%) [REVISAR]
+     - classe sem ID mas mutavel (deveria ser imutavel)
+
+Domain Events:
+  - [OK] UserCreated, UserUpdated (Confiança: 80%)
+  - [OK] OrderCreated, OrderPaid, OrderCancelled (Confiança: 82%)
+  - [X] Payment-related events - NAO ENCONTRADOS
+  - [OK] Event dispatcher: MediatR (INotificationHandlers)
+
+Repositories:
+  - [OK] IUserRepository, IOrderRepository (Confiança: 92%)
+     - Interfaces em /src/Domain/Interfaces
+  - [OK] Implementacoes com Dapper (Confiança: 95%)
+     - /src/Infrastructure/Persistence/DapperUserRepository
+  - [WARNING] IPaymentRepository (Confiança: 40%) [REVISAR]
+     - Interface existe mas nao implementada
+
+Domain Services:
+  - [OK] PaymentService (Confiança: 75%)
+     - Orquestra fluxo: Valida -> Processa -> Atualiza
+  - [WARNING] DiscountService (Confiança: 65%) [REVISAR]
+     - Logica complexa em controller (deveria ser em dominio)
+
+Nivel de Maturidade DDD: INTERMEDIARIO
+  - [OK] Bounded contexts definidos
+  - [OK] Aggregates e entities identificadas
+  - [WARNING] Value_objects parciais (nem todos imutaveis)
+  - [OK] Domain events implementados via MediatR
+  - [OK] Repositories pattern aplicado
+  - [WARNING] Alguns servicos de dominio em camada errada
+  - [X] Faltam: Specifications, Domain Services explicitos
+```
+
+**Checkpoint de Validação:**
+- [ ] Paradigma arquitetural identificado (Clean Arch, DDD, MVC, etc.)
+- [ ] Nível de confiança atribuído ao paradigma
+- [ ] Bounded contexts mapeados (se aplicável)
+- [ ] Aggregates e entities catalogados
+- [ ] Value objects identificados
+- [ ] Domain events listados
+- [ ] Repositories e services classificados
+- [ ] Itens com baixa confiança marcados [REVISAR]
+
+**Output Esperado:**
+- Paradigma arquitetural com confiança
+- Mapa completo de domínio (DDD)
+- Lista de itens [REVISAR] (confiança < 70%)
+
+---
+
+### PASSO 5: Geração Iterativa - architecture.md
+
+**Objetivo:** Gerar rascunho de arquitetura baseado em fatos detectados e validar rapidamente
+
+**Ações Concretas:**
+
+#### 5.1. Gerar Rascunho de architecture.md
+
+1. **Criar diretório se não existir:**
+   ```
+   ./specs/core/
+   ```
+
+2. **Usar template** `@templates/architecture-template.md`
+
+3. **Preencher seções** baseado em análise dos Passos 2-4:
+   - Seção 1: Paradigma Arquitetural (do Passo 4.1)
+   - Seção 2: Stack Tecnológico (do Passo 3)
+   - Seção 3: Padrões de Design e Convenções (do Passo 2.4)
+   - Seção 4: Estrutura de Diretórios (do Passo 2.4)
+   - Seção 5: Contratos e Interfaces (detectar de controllers/endpoints)
+   - Seção 6: Pipeline de CI/CD (se detectado)
+   - **Seção 7: Integrações Externas [NOVO]** (do Passo 2.2)
+   - **Seção 8: Maturidade de Testes [NOVO]** (do Passo 2.3)
+   - **Seção 9: Domínio Inferido [NOVO]** (do Passo 4.2)
+
+4. **Marcar itens com baixa confiança:**
+   - Para cada inferência com confiança < 70%, adicionar tag **[REVISAR]**
+   - Adicionar justificativa da baixa confiança
+
+5. **Preencher campos de metadados:**
+   - Status: DRAFT
+   - Data: Data atual
+   - Nível de Profundidade: Detalhado automaticamente
+
+6. **Salvar arquivo:**
+   ```
+   ./specs/core/architecture.md
+   ```
+
+#### 5.2. Apresentar para Validação Rápida
+
+**Apresentar resumo executivo (focado em itens críticos):**
+
+```
+[ARQUITETURA]  RASCUNHO DE ARQUITETURA GERADO
+
+ARQUIVO: ./specs/core/architecture.md
+
+-----------------------------------------------------------
+
+STACK TECNOLÓGICA DETECTADA:
+ - Backend: .NET 8 (C# 12) [OK] Confiança: 100%
+ - Database: PostgreSQL 15 [WARNING]  Confiança: 75% [REVISAR]
+   - Motivo: Versão não explicitada em config
+ - ORM: Entity Framework Core 8.0 [OK] Confiança: 95%
+ - Frontend: Vue.js 3.4 + TypeScript [OK] Confiança: 98%
+
+PARADIGMA ARQUITETURAL:
+ - Clean Architecture [WARNING]  Confiança: 65% [REVISAR]
+  -[OK] Indicadores: Domain/Application/Infrastructure separados
+  -[WARNING]  Violações: Controllers com lógica de negócio detectados
+   - Motivo: UsersController.CalculateDiscount() em UI layer
+ - Separação de camadas: [OK] Presente
+
+INTEGRAÇÕES EXTERNAS:
+ - Stripe (Payments) [OK] v14.2, webhooks configurados
+ - AWS S3 (Storage) [OK] presigned URLs implementados
+ - SendGrid (Email) [OK] templates transactionais
+ - Redis (Cache) [WARNING]  Confiança: 35% [REVISAR]
+    - Motivo: docker-compose tem redis mas código não usa
+
+MATURIDADE DE TESTES: INTERMEDIÁRIO
+ - Framework: Jest [OK] v29.7 configurado
+ - Coverage: [WARNING]  62% (abaixo do ideal 70%)
+   - Statements: 58%
+   - Branches: 54%
+   - Functions: 65%
+ - Tipos: [OK] Unit (70%), Integration (20%), E2E (10%)
+ - Fixtures: [OK] Jest fixtures + Faker.js
+
+DOMÍNIO INFERIDO (DDD):
+ - Bounded Contexts: 3 detectados [OK]
+   - Users (85%), Orders (72%), Payments (40% [REVISAR])
+ - Aggregates: User (90%), Order (85%), Payment (50% [REVISAR])
+ - Value Objects:
+  -[OK] Email (95%), CPF (88%)
+  -[WARNING]  Address (70% [REVISAR] - mutável, deveria ser imutável)
+  -[X] Money - NÃO ENCONTRADO (usa decimal simples)
+ - Domain Events: [OK] MediatR implementado (UserCreated, OrderPaid)
+
+-----------------------------------------------------------
+
+ITENS MARCADOS [REVISAR] (5 itens):
+1. PostgreSQL 15 (75%) - versão inferida, não confirmada
+2. Clean Architecture (65%) - violações detectadas
+3. Redis Cache (35%) - configurado mas não usado em código
+4. Payments Bounded Context (40%) - sem domínio rico
+5. Payment Aggregate (50%) - anêmico, sem lógica
+
+TEMPO ESTIMADO DE REVISÃO: 2 minutos
+
+-----------------------------------------------------------
+
+QUAL SUA DECISÃO?
+
+A) APROVAR [OK]
+   -> Confirmo que a arquitetura inferida está correta
+   -> Prosseguir para gerar product_vision.md
+
+B) REVISAR
+   -> Quero abrir o arquivo e fazer ajustes manualmente
+   -> Após revisão, voltarei para confirmar
+
+C) REGER [REVISAR] itens específicos
+   -> Quero corrigir as inferências com baixa confiança
+   -> Especificar quais itens corrigir (máx 3)
+
+D) CANCELAR [X]
+   -> Encerrar sem salvar alterações
+```
+
+**Aguardar resposta do usuário.**
+
+#### 5.3. Processar Resposta do Usuário
+
+**SE resposta APROVAR:**
+1. Atualizar status de `./specs/core/architecture.md` para `APPROVED`
+2. Prosseguir para Passo 6 (se houver itens [REVISAR]) ou Passo 7 (se não houver)
+3. Registrar aprovação com timestamp
+
+**SE resposta REVISAR:**
+1. Permitir que usuário abra o arquivo `./specs/core/architecture.md`
+2. Aguardar usuário fazer edições
+3. Após edição, reapresentar resumo atualizado
+4. Repetir pergunta de aprovação
+
+**SE resposta REGER:**
+1. Solicitar ao usuário especificar quais itens corrigir (máx 3)
+2. Para cada item:
+   - Re-analisar seções específicas do código
+   - Atualizar inferências com nova evidência
+   - Recalcular nível de confiança
+3. Regerar rascunho de `architecture.md` com correções
+4. Repetir apresentação para validação
+
+**SE resposta CANCELAR:**
+1. Informar que arquivo foi salvo em `./specs/core/architecture.md` (status DRAFT)
+2. Usuário pode revisar posteriormente
+3. Encerrar execução
+
+**Checkpoint de Validação:**
+- [ ] Arquivo `architecture.md` gerado
+- [ ] Resumo executivo apresentado ao usuário
+- [ ] Usuário tomou decisão (Aprovar/Revisar/Regenerar/Cancelar)
+- [ ] Status do arquivo atualizado conforme decisão
+
+**Output Esperado:**
+- Arquivo `./specs/core/architecture.md` gerado (DRAFT ou APPROVED)
+- Resumo executivo apresentado
+- Decisão do usuário registrada
+
+---
+
+### PASSO 6: Validação e Clarificação (Apenas itens baixa confiança)
+
+**Objetivo:** Focar perguntas APENAS em itens com confiança < 70% e que bloqueiam a inferência de negócio
+
+**CRÍTICO:** Este passo só deve ser executado se houver itens [REVISAR] marcados no Passo 5. Se todos os itens tiverem confiança >= 70%, PULE para o Passo 7.
+
+**Ações Concretas:**
+
+#### 6.1. Filtrar e Priorizar Itens Baixa Confiança
+
+1. **Filtrar itens** com confiança < 70% do Passo 5
+2. **Agrupar por categoria:**
+   - DOMÍNIO (bounded contexts, aggregates, value objects)
+   - ARQUITETURA (paradigma, padrões, separação de camadas)
+   - STACK (tecnologias, versões, bibliotecas)
+3. **Priorizar por impacto:**
+   - ALTO IMPACTO: Bloqueia inferência de negócio (ex: bounded context ausente)
+   - MÉDIO IMPACTO: Impacta arquitetura mas não bloqueia negócio (ex: Redis não usado)
+   - BAIXO IMPACTO: Detalhe técnico (ex: versão exata do PostgreSQL)
+
+#### 6.2. Preparar Perguntas (Máximo 2 por categoria)
+
+**Regras:**
+- **MÁXIMO 2 perguntas por categoria** (total max 6 perguntas)
+- **Focar em itens com ALTO ou MÉDIO impacto**
+- **Itens BAIXO impacto devem ser documentados como "Nota de Decisão"**
+- **Cada pergunta deve fornecer contexto específico do código analisado**
+
+**Modelo de Pergunta Efetiva:**
+
+```
+[LACUNA: CATEGORIA - NÍVEL DE IMPACTO]
+
+Item: [Nome do item inferido]
+Confiança: [X%] - [Justificativa da baixa confiança]
+
+CONTEXTO (do código analisado):
+[Descrever o que foi encontrado no código]
+[Evidências parciais ou contraditórias]
+
+ANÁLISE:
+[Por que a confiança é baixa]
+[O que está faltando para aumentar confiança]
+
+PERGUNTA [NÚMERO]/[TOTAL]:
+[Pergunta clara e específica com 3-4 opções]
+
+OPÇÕES:
+A) [Opção 1 - baseada em evidências]
+B) [Opção 2 - alternativa plausível]
+C) [Opção 3 - confirmar análise atual]
+D) [Outro: descrever]
+```
+
+**Exemplos Práticos de Perguntas:**
+
+**Exemplo 1: Paradigma Arquitetural (ALTO IMPACTO)**
+```
+[LACUNA: ARQUITETURA - ALTO IMPACTO]
+
+Item: Paradigma Clean Architecture
+Confiança: 55% (detectado Domain/Application mas há violações)
+
+CONTEXTO:
+Análise detectou estrutura de pastas típica de Clean Architecture:
+- /src/Domain (Entities, ValueObjects)
+- /src/Application (Commands, Queries)
+- /src/Infrastructure (Repositories)
+
+Porém, também detectei violações:
+- UsersController tem método CalculateDiscount() (lógica de negócio em UI)
+- OrdersController acessa DbContext diretamente (infra em UI layer)
+- PaymentService está em /src/Services (não em /src/Application)
+
+ANÁLISE:
+Estrutura segue Clean Architecture mas implementação tem inconsistências.
+Possíveis causas: código em evolução, time ainda adaptando, ou paradigma diferente.
+
+PERGUNTA 1/2 (ARQUITETURA):
+Este projeto segue Clean Architecture ou há outro paradigma em uso?
+
+A) Clean Architecture (vou documentar violações como debt técnico)
+B) MVC tradicional com pastas organizadas por feature (não é Clean Arch)
+C) Layered Architecture sem separação estrita entre camadas
+D) Outro paradigma: [descrever]
+
+IMPACTO:
+Esta decisão afeta:
+- Como documentar separação de responsabilidades
+- Quais padrões esperar para novas features
+- Como classificar a arquitetura no architecture.md
+```
+
+**Exemplo 2: Bounded Context (ALTO IMPACTO)**
+```
+[LACUNA: DOMÍNIO - ALTO IMPACTO]
+
+Item: Bounded Context "Payments"
+Confiança: 40% (apenas controllers, sem domínio rico)
+
+CONTEXTO:
+Detectei /src/Payments/ com:
+- PaymentsController (endpoints de pagamento)
+- PaymentService (regras de validação e processamento)
+
+Porém, NÃO encontrei:
+- Payment aggregate/entity (classe de domínio)
+- Domain events para pagamentos (PaymentProcessed, PaymentFailed)
+- Value objects típicos (Money, CardNumber)
+
+ANÁLISE:
+Possible que Payments seja:
+A) Bounded context anêmico (CRUD simples, sem domínio rico)
+B) Contexto externo (API wrapper para serviço terceiro)
+C) Domínio ainda em evolução (não implementado ainda)
+
+PERGUNTA 2/2 (DOMÍNIO):
+Payments é um bounded context com domínio rico ou apenas um wrapper/CRUD?
+
+A) Domínio rico (vou inferir entidades/VOs baseado em endpoints)
+B) CRUD simples (vou documentar como "anêmico" no architecture.md)
+C) Contexto externo/API wrapper (vou documentar integração)
+D) Outro: [descrever]
+
+IMPACTO:
+Esta decisão afeta:
+- Como inferir casos de uso de negócio para Payments
+- Quais entidades documentar em product_vision.md
+- Como classificar maturidade DDD do projeto
+```
+
+**Exemplo 3: Stack Tecnológica (MÉDIO IMPACTO)**
+```
+[LACUNA: STACK - MÉDIO IMPACTO]
+
+Item: Redis Cache
+Confiança: 35% (docker-compose tem redis mas código não usa)
+
+CONTEXTO:
+Detectei Redis em docker-compose.yml:
+```yaml
+redis:
+  image: redis:7-alpine
+  ports: ["6379:6379"]
+```
+
+Porém, NÃO encontrei no código:
+- Imports de redis-client, ioredis, @redis/client
+- Uso de cache em queries ou services
+- Configuração de Redis em .env ou appsettings
+
+ANÁLISE:
+Redis pode estar:
+A) Configurado para uso futuro (não implementado ainda)
+B) Usado por serviço externo (não no código analisado)
+C) Esquecimento do docker-compose (serviço não necessário)
+
+PERGUNTA 1/2 (STACK):
+Redis deve ser documentado como parte da stack atual?
+
+A) SIM, faz parte (planejado para futuro ou uso externo)
+B) NÃO, remover (não é usado no código atual)
+C) Manter como "opcional/futuro" com nota
+
+IMPACTO:
+Baixo - não afeta inferência de negócio, apenas documentação técnica.
+```
+
+#### 6.3. Apresentar Perguntas ao Usuário
+
+**Formato de apresentação:**
+```
+[PERGUNTA] CLARIFICAÇÕES NECESSÁRIAS (6 perguntas máx)
+
+Foram detectados 5 itens com baixa confiança que impactam a arquitetura.
+Por favor, responda para refinar as inferências.
+
+-----------------------------------------------------------
+
+CATEGORIA 1: ARQUITETURA (2 perguntas)
+
+[LACUNA: ARQUITETURA - ALTO IMPACTO]
+
+Item: Paradigma Clean Architecture
+Confiança: 55% (detectado Domain/Application mas há violações)
+
+CONTEXTO:
+[... mesmo contexto do exemplo acima ...]
+
+PERGUNTA 1/2 (ARQUITETURA):
+Este projeto segue Clean Architecture ou há outro paradigma em uso?
+
+A) Clean Architecture (vou documentar violações como debt técnico)
+B) MVC tradicional com pastas organizadas por feature
+C) Layered Architecture sem separação estrita
+D) Outro: [descrever]
+
+Sua resposta: [Aguardando input]
+
+-----------------------------------------------------------
+
+[Segunda pergunta de arquitetura, se houver]
+
+-----------------------------------------------------------
+
+CATEGORIA 2: DOMÍNIO (2 perguntas)
+
+[LACUNA: DOMÍNIO - ALTO IMPACTO]
+
+Item: Bounded Context "Payments"
+Confiança: 40% (apenas controllers, sem domínio rico)
+
+[... mesmo formato da pergunta acima ...]
+
+Sua resposta: [Aguardando input]
+
+-----------------------------------------------------------
+
+[Segunda pergunta de domínio, se houver]
+
+-----------------------------------------------------------
+
+CATEGORIA 3: STACK (2 perguntas)
+
+[LACUNA: STACK - MÉDIO IMPACTO]
+[... mesma estrutura ...]
+
+-----------------------------------------------------------
+
+INSTRUÇÕES:
+- Responda cada pergunta com A, B, C ou D
+- Para D (Outro), forneça detalhes
+- Após responder todas, vou regerar architecture.md
+```
+
+**Aguardar respostas do usuário.**
+
+#### 6.4. Processar Respostas e Regenerar
+
+**Para cada resposta recebida:**
+
+1. **SE resposta for A, B ou C:**
+   - Atualizar inferência com base na opção escolhida
+   - Aumentar confiança para 90-100% (usuário confirmou)
+   - Remover tag [REVISAR]
+
+2. **SE resposta for D (Outro):**
+   - Solicitar detalhes adicionais se necessário
+   - Re-analisar código com nova informação
+   - Atualizar inferência e aumentar confiança
+
+3. **Após todas as respostas:**
+   - Regerar arquivo `./specs/core/architecture.md` com correções
+   - Atualizar status para `APPROVED`
+   - Prosseguir para Passo 7
+
+**Checkpoint de Validação:**
+- [ ] Apenas itens baixa confiança foram questionados
+- [ ] Máximo 2 perguntas por categoria
+- [ ] Máximo total de 6 perguntas
+- [ ] Perguntas priorizadas por impacto (Alto > Médio > Baixo)
+- [ ] Respostas obtidas antes de prosseguir
+- [ ] architecture.md regenerado com correções
+
+**Output Esperado:**
+- architecture.md atualizado (sem tags [REVISAR])
+- Todas as inferências com confiança >= 90%
+- Arquivo pronto para usar como base para product_vision.md
+
+---
+
+### PASSO 7: Geração Final - product_vision.md
+
+**Objetivo:** Inferir visão de negócio a partir de padrões técnicos validados no architecture.md
+
+**Ações Concretas:**
+
+#### 7.1. Mapeamento Técnico -> Negócio
+
+Usar `architecture.md` aprovado como fonte de verdade para inferir negócio:
+
+**TABELA DE MAPEAMENTO:**
+
+| DETECAO TECNICA | INFERENCIA DE NEGOCIO |
+|:---|:---|
+| **Bounded Contexts** | Subdominios de negocio |
+| /Users, /Orders, /Payments | "Gestao de Usuarios", "Pedidos", "Pagamentos" |
+| **Aggregates** | Entidades principais |
+| User, Order, Payment | "Usuario", "Pedido", "Pagamento" |
+| **Webhooks (Stripe)** | Eventos de negocio criticos |
+| | "Pagamentos assincronos" |
+| **Integration Tests** | Fluxos complexos |
+| (Order flow) | "Ciclo de vida do pedido" |
+| **Rate Limiting** | Alto volume/requisicoes |
+| (Redis, 100/15min) | "Sistema em escala" |
+| **JWT + OAuth** | Multi-tenant/SSO |
+| | "Autenticacao corporativa" |
+| **SendGrid Templates** | Comunicacao transacional |
+| | "Notificacoes ao usuario" |
+ | **Controllers/Actions** | Casos de uso |
+ | CreateOrder, ProcessPayment | "Criar pedido", "Processar pagamento" |
+ | -CreateOrder            | "Criar pedido" |
+ | -ProcessPayment         | "Processar pagamento" |
+
+#### 7.2. Inferir Elementos de Negócio
+
+**1. PERSONAS (baseado em aggregates e controllers):**
+```
+DE: User aggregate, UsersController, AdminController
+PARA:
+- Persona 1: "Cliente Final" (usuário do sistema)
+  - Cria pedidos, faz pagamentos, gerencia perfil
+- Persona 2: "Administrador" (gestor do sistema)
+  - Gerencia usuários, visualiza relatórios, configura sistema
+```
+
+**2. PROBLEMA CENTRAL (baseado em webhooks, events, integrations):**
+```
+DE: Stripe webhooks, PaymentFailed events, Retry logic
+PARA:
+"Gerenciar ciclo de vida de pedidos com pagamentos assíncronos,
+garantindo consistência mesmo quando pagamentos falham ou são
+processados em background."
+```
+
+**3. CASOS DE USO PRINCIPAIS (baseado em controllers/endpoints):**
+```
+DE: UsersController.Create, OrdersController.PlaceOrder
+PARA:
+- UC1: "Cadastrar novo usuário no sistema"
+- UC2: "Criar pedido com múltiplos itens"
+- UC3: "Processar pagamento de forma assíncrona"
+- UC4: "Notificar usuário sobre status do pedido"
+```
+
+**4. MÉTRICAS DE SUCESSO (baseado em monitoring/logging):**
+```
+DE: Prometheus metrics, error tracking, coverage reports
+PARA:
+- "Taxa de sucesso de pagamentos" (monitorado via PaymentFailed events)
+- "Tempo de processamento de pedidos" (trackeado em logs)
+- "Disponibilidade do sistema" (uptime monitoring)
+```
+
+**5. ESCOPO (IN/OUT) (baseado em bounded contexts):**
+```
+DE: Bounded Contexts: Users, Orders, Payments
+PARA:
+IN-SCOPE:
+- Gestão de usuários e autenticação
+- Ciclo completo de pedidos
+- Processamento de pagamentos
+
+OUT-OF-SCOPE:
+- Gestão de estoque (não detectado como bounded context)
+- Sistema de notificações push (apenas email via SendGrid)
+- Analytics e dashboards (não detectado)
+```
+
+**6. PROPOSTA DE VALOR (baseado em integrações):**
+```
+DE: Stripe (pagamentos), AWS S3 (storage), SendGrid (email),
+     Rate limiting (escala), Webhooks (assíncrono)
+PARA:
+"Plataforma de e-commerce em escala com processamento
+assíncrono de pagamentos, notificações transacionais e
+infraestrutura elástica para alto volume."
+```
+
+#### 7.3. Preencher product_vision-template.md
+
+**Ações:**
+
+1. **Ler architecture.md aprovado** como referência
+2. **Para cada seção do template**, fazer inferências:
+   - **Declaração do Problema:** Baseada em webhooks/events/errors
+   - **Personas:** Baseadas em aggregates/controllers
+   - **Proposta de Valor:** Baseada em integrações/infra
+   - **Métricas:** Baseadas em monitoring/logging
+   - **Escopo:** Baseada em bounded contexts
+   - **Jornada do Usuário:** Baseada em integration tests
+   - **Riscos:** Baseada em baixa cobertura, debt técnico
+
+3. **Adicionar seção especial** "Inferências do Código Legado":
+   ```markdown
+   ## 10. Inferências do Código Legado
+
+   <!-- Esta seção documenta como a visão de negócio foi inferida -->
+
+   | Inferência de Negócio | Fonte Técnica | Confiança |
+   |:---|:---|:---:|
+   | **Multi-tenant SaaS** | JWT com tenant_id em todos os tokens | 85% |
+   | **Pagamentos assíncronos** | Stripe webhooks, background jobs | 95% |
+   | **Sistema em escala** | Rate limiting (Redis), load balancer | 78% |
+   | **E-commerce B2C** | Catalog de produtos, checkout flow | 90% |
+   ```
+
+4. **Status:** DRAFT (ou IN_PROGRESS se houver ajustes)
+
+5. **Salvar em:**
+   ```
+   ./specs/core/product_vision.md
+   ```
+
+#### 7.4. Apresentar Resumo Final
+
+```
+  - [OK] ARTEFATOS FUNDACIONAIS CRIADOS
+
+Arquivos gerados:
+  - [ARQUITETURA] ./specs/core/architecture.md (APPROVED)
+     - Stack: .NET 8 + Vue.js 3 + PostgreSQL 15
+     - Paradigma: Clean Architecture
+     - Integrações: Stripe, AWS S3, SendGrid
+
+  - [DOCUMENTO] ./specs/core/product_vision.md (DRAFT)
+     - Problema: Gestão de pedidos com pagamentos assincronos
+     - Personas: Cliente Final, Administrador
+     - Proposta: Plataforma e-commerce em escala
+     - Escopo: Usuarios, Pedidos, Pagamentos
+
+-----------------------------------------------------------
+
+INFERÊNCIAS REALIZADAS:
+
+Domínio de Negócio:
+ - Detectados: 3 bounded contexts (Users, Orders, Payments)
+ - Entidades: 5 aggregates principais
+ - Casos de uso: 8 inferidos de controllers/endpoints
+ - Confiança média: 82%
+
+Arquitetura Técnica:
+ - Stack completa: Backend, Frontend, Database, Infra
+ - Paradigma: Clean Architecture (com violações documentadas)
+ - Integrações: 4 serviços externos mapeados
+ - Confiança média: 88%
+
+Próximos Passos:
+1. Revise product_vision.md para validar inferências de negócio
+2. Use /gerar-prd para criar requisitos de novas features
+   (lerá product_vision.md para contexto de negócio)
+3. Use /gerar-techspec para especificações técnicas
+   (lerá architecture.md para validar decisões técnicas)
+
+-----------------------------------------------------------
+
+Status: Fundação do projeto estabelecida [OK]
+
+Para revisar os arquivos:
+- architecture.md: vim ./specs/core/architecture.md
+- product_vision.md: vim ./specs/core/product_vision.md
+```
+
+**Checkpoint de Validação:**
+- [ ] architecture.md lido como base para inferências
+- [ ] Mapeamento técnico -> negócio realizado
+- [ ] Personas inferidas de aggregates/controllers
+- [ ] Problema inferido de events/webhooks
+- [ ] Casos de uso inferidos de endpoints
+- [ ] Métricas inferidas de monitoring
+- [ ] Escopo delimitado por bounded contexts
+- [ ] Seção "Inferências do Código Legado" adicionada
+- [ ] Arquivo `product_vision.md` gerado
+- [ ] Resumo final apresentado ao usuário
+
+**Output Esperado:**
+- Arquivo `./specs/core/product_vision.md` (DRAFT)
+- Resumo executivo das inferências
+- Orientações sobre próximos passos
+
+---
+
+## 4. CHECKLIST DE QUALIDADE FINAL
+
+Antes de finalizar o comando, confirme:
+
+### Artefatos Gerados
+- [ ] `./specs/core/architecture.md` existe e está APPROVED
+- [ ] `./specs/core/product_vision.md` existe e está DRAFT
+- [ ] Diretório `specs/core/` criado (se não existia)
+
+### Qualidade das Inferências
+- [ ] Todas as tecnologias detectadas têm nível de confiança
+- [ ] Itens com confiança < 70% foram marcados [REVISAR]
+- [ ] Itens [REVISAR] foram questionados no Passo 6 (se existirem)
+- [ ] Paradigma arquitetural identificado com justificativa
+- [ ] Bounded contexts mapeados (se aplicável)
+- [ ] Integrações externas catalogadas
+- [ ] Maturidade de testes avaliada
+
+### Mapeamento Técnico -> Negócio
+- [ ] Personas inferidas de aggregates/controllers
+- [ ] Problema inferido de events/webhooks/errors
+- [ ] Casos de uso inferidos de endpoints
+- [ ] Métricas inferidas de monitoring/logging
+- [ ] Escopo delimitado por bounded contexts
+- [ ] Seção "Inferências do Código Legado" preenchida
+
+### Validação de Usuário
+- [ ] architecture.md apresentado para aprovação rápida (2 min)
+- [ ] Perguntas limitadas a itens baixa confiança (máx 6)
+- [ ] Respostas incorporadas nas inferências finais
+- [ ] Usuário informado sobre próximos passos
+
+---
+
+## 5. EXEMPLOS DE BOAS E MÁS INFERÊNCIAS
+
+### Exemplo 1: Inferência de Paradigma Arquitetural
+
+**Detectado no código:**
+```
+/src
+  /Domain
+    /Entities
+      User.cs
+      Order.cs
+  /Application
+    /Commands
+      CreateOrderCommand.cs
+  /Infrastructure
+    /Persistence
+      SqlUserRepository.cs
+  /API
+    /Controllers
+      UsersController.cs (com método CalculateDiscount())
+```
+
+**[X] MÁ INFERÊNCIA:**
+"Paradigma: Clean Architecture perfeitamente implementado."
+
+**[OK] BOA INFERÊNCIA:**
+"Paradigma: Clean Architecture (Confiança: 65%)
+- Indicadores favoráveis: Domain/Application/Infrastructure separados
+- Violações detectadas: UsersController.CalculateDiscount() (lógica em UI)
+- Conclusão: Estrutura segue Clean Arch mas há violações locais (debt técnico)"
+
+---
+
+### Exemplo 2: Inferência de Domínio de Negócio
+
+**Detectado no código:**
+```
+Stripe webhook em /api/webhooks/stripe
+PaymentFailed event em background jobs
+Retry logic em PaymentService
+```
+
+**[X] MÁ INFERÊNCIA:**
+"O sistema processa pagamentos."
+
+**[OK] BOA INFERÊNCIA:**
+"Problema Central: Gestão de pedidos com pagamentos assíncronos
+- Confiança: 88%
+- Fontes: Stripe webhooks, PaymentFailed events, Retry logic
+- Inferência: Sistema lida com processamento assíncrono, falhas de
+  pagamento e reprocessamento, o que indica complexidade de
+  consistência distribuída."
+
+---
+
+### Exemplo 3: Inferência de Persona
+
+**Detectado no código:**
+```
+UsersController (create, update, delete)
+AdminsController (banUser, viewReports)
+```
+
+**[X] MÁ INFERÊNCIA:**
+"Usuários do sistema."
+
+**[OK] BOA INFERÊNCIA:**
+"Personas:
+1. Cliente Final (Confiança: 95%)
+   - Fonte: UsersController com CRUD completo
+   - Ações: Cria conta, gerencia perfil, faz pedidos
+
+2. Administrador (Confiança: 90%)
+   - Fonte: AdminsController com métodos de ban/report
+   - Ações: Gerencia usuários, visualiza relatórios, configura sistema"
+
+---
+
+## 6. NOTAS DE IMPLEMENTAÇÃO
+
+### Sistema de Confiança
+- Sempre atribuir % de confiança baseado em evidências concretas
+- 90-100%: Evidência explícita (imports, configs, migrations)
+- 60-89%: Evidência indireta (estrutura, padrões)
+- < 60%: Inferência fraca (convenções, ausência de contradições)
+
+### Abordagem Iterativa
+- **CRÍTICO:** Gerar architecture.md PRIMEIRO, validar, depois product_vision.md
+- Não pular validação rápida (2 min)
+- Usuário pode interromper a qualquer momento
+
+### Máximo de Perguntas
+- **MÁXIMO 2 perguntas por categoria** (Domínio, Arquitetura, Stack)
+- Total máximo: 6 perguntas
+- Apenas itens com confiança < 70%
+- Apenas itens com ALTO ou MÉDIO impacto
+
+### Separação de Artefatos
+- architecture.md: ZERO menções a funcionalidades de negócio
+- product_vision.md: ZERO menções a frameworks/bancos
+- Crossing: "Inferências do Código Legado" (seção em product_vision.md)
+
+---
+
+**Command Version:** 0.1.0
+</system_instructions>