Req Agile Planning

Agile Planning

Transformar requisitos (documentados ou descritos) em um backlog ágil estruturado com Épicos, User Stories e Tasks, alinhado a DDD e Clean Architecture.

Fluxo completo (recomendado):

req-discovery → req-ddd-modeling → [req-migration-strategy] → delivery-profile.md → req-agile-planning
       ↓                              ↑ stack + superfícies por BC (obrigatório full-stack)
  backlog.md (EP-000 bootstrap inclui docker + cicd + web + mobile)
       ↓
openspec-propose "bootstrap-<nome>" → openspec-apply-change
  (config-project-fullstack orquestra: config-project-* + config-docker + config-cicd + config-shared-core)
       ↓
Por BC/épico: openspec-propose → openspec-apply-change → openspec-archive-change

Fluxo: o sistema fonte pode ter sido analisado em qualquer linguagem (PHP, Go, Python, etc. via req-discovery). As tasks do backlog sempre referenciam os skills deste repositório. Na implementação, o usuário escolhe TypeScript (sem sufixo), Kotlin (sufixo -kt), C# (sufixo -cs), Rust (sufixo -rs) ou Java (sufixo -java). Consultar req-discovery/references/ddd-clean-mapping.md.

Entrada

O skill aceita qualquer uma destas fontes:

Se nenhuma fonte for fornecida, pergunte:

"De onde vêm os requisitos? Me passe:\n> 1. O caminho de um requirements.md (gerado pelo req-discovery)\n> 2. Uma descrição do que precisa ser construído\n> 3. Uma URL de issues existentes"

Workflow

Fase 0 — Perfil de entrega full-stack (OBRIGATÓRIA)

Antes de escrever épicos ou tasks, definir como o sistema será entregue (não só o domínio).

1. Se delivery-profile.md não existir em <docsPath>/planning/<projeto>/:
   • Perguntar ao usuário (ou inferir do pedido) a matriz de stack:

• Backend: NestJS | Spring Boot | ASP.NET Core | Axum (Rust) - Web: Nenhum | Next.js | Angular | Vue 3 | Leptos (Rust) - Mobile: Nenhum | Flutter | Android | Dioxus (Rust)
  • Ler screens.md e requirements.md do discovery — listar telas web e apps mobile do legado.
  • Ler ddd-tactical-model.md — para cada BC do MVP, marcar colunas API | Web admin | Mobile e validar seções Apresentação — Web/Mobile (ver references/delivery-profile.md e req-ddd-modeling/references/client-presentation-model.md).
  • Criar <docsPath>/planning/<projeto>/delivery-profile.md.

2. Se já existir delivery-profile.md: validar que cobre todos os BCs do release planejado; atualizar se faltar superfície.

3. Regra: backlog com web ou mobile no perfil não pode ser “só backend”. EP-000 e cada US devem refletir o perfil.

Erro típico (RetailOps EP-001): stack no cabeçalho do backlog (C# + Vue + Android) mas US sem tasks Frontend Entity/UseCase/Repository — causado por pular Fase 0 ou ignorar coluna Web/Mobile do perfil.

Fase 1 — Compreensão

1. Ler/receber os requisitos da fonte fornecida
2. Ler saída do req-ddd-modeling se existir — ddd-strategic-model.md (subdomínios, BCs, context map) e ddd-tactical-model.md (domínio por BC + seções Apresentação — Web admin / Apresentação — Mobile quando existirem) são a fonte mais rica
3. Senão, ler ddd-analysis.md se existir — os Bounded Contexts já mapeados viram Épicos diretamente
4. Identificar domínios/módulos — agrupar funcionalidades relacionadas (se nenhum modelo DDD existir, inferir Bounded Contexts dos requisitos)
5. Mapear dependências — quais funcionalidades dependem de outras
6. Identificar MVP — perguntar ao usuário o que é prioridade
7. Ler delivery-profile.md — para cada BC no MVP, anotar se a US exige bloco Web e/ou Mobile

Se os requisitos vierem do req-discovery, ler também screens.md, delivery-inventory.md e domain-model.md se existirem.

Fase 2 — Estruturação em Épicos (= Bounded Contexts)

Cada Bounded Context identificado na discovery vira 1 Épico. Se não houver ddd-analysis.md, inferir os contexts dos requisitos.

Adicionalmente, criar Épicos Técnicos (enablers) para infraestrutura compartilhada:

┌─────────────────────────────────────────────────────┐
│                  MAPA DE ÉPICOS                     │
├─────────────────────────────────────────────────────┤
│                                                     │
│  ┌──────────────┐                                   │
│  │ EP-000 [TECH]│  Setup projeto, shared kernel,    │
│  │  Bootstrap   │  config banco, CI/CD              │
│  └──────┬───────┘                                   │
│         │                                           │
│  ┌──────▼───────┐   ┌──────────────┐               │
│  │   EP-001     │   │   EP-002     │               │
│  │ BC: Auth &   │   │ BC: Catálogo │               │
│  │   Usuários   │   │   Produtos   │               │
│  └──────┬───────┘   └──────┬───────┘               │
│         │                  │                        │
│  ┌──────▼───────┐   ┌─────▼────────┐               │
│  │   EP-003     │   │   EP-004     │               │
│  │ BC: Carrinho │   │ BC: Pagamento│               │
│  └──────────────┘   └──────────────┘               │
│                                                     │
│  ──── = dependência                                 │
│  [TECH] = épico técnico (enabler)                   │
└─────────────────────────────────────────────────────┘

Regras para Épicos:

• Cada Bounded Context → 1 Épico funcional
• Infra compartilhada → Épico técnico [TECH] (bootstrap, shared, banco, CI)
• Um épico deve ser entregável de forma independente ou com dependências explícitas
• Estimativa de alto nível: P (pequeno), M (médio), G (grande), GG (muito grande)

Épico técnico de bootstrap (EP-000) deve sempre existir e incluir Docker + CI/CD no setup (não deixar para o final):

• Orquestração → config-project-fullstack (quando backend + frontend e/ou mobile)
• Backend → config-project / config-project-kt / config-project-cs / config-project-rs / config-project-java
• Frontend → config-project-angular / config-project-vue (se aplicável)
• Mobile → config-project-flutter / config-project-android (se aplicável)
• Docker produção → config-docker / config-docker-kt / config-docker-cs / config-docker-rs / config-docker-java
• CI/CD → config-cicd / config-cicd-kt / config-cicd-cs / config-cicd-rs / config-cicd-java
• Shared kernel → config-shared-core / config-shared-core-kt / config-shared-core-cs / config-shared-core-rs / config-shared-core-java
• Banco → config-prisma / config-jpa-kt / config-jpa-java / config-efcore-cs / config-sqlx-rs

Com OpenSpec: agrupar EP-000 na mudança bootstrap-<nome> via openspec-propose → openspec-apply-change.

Épico de auth (quando aplicável) deve usar:

• Auth core → Agent: Config Auth Core Basic | Config Auth Core Basic (Kotlin) | Config Auth Core (C#)
• Auth backend → Agent: Config Auth Backend Basic | Config Auth Backend Basic (Kotlin) | Config Auth Backend Basic (C#)
• Auth web (somente Next.js) → Agent: Config Auth Web Basic

Fase 3 — Quebra em User Stories

Para cada Épico, criar User Stories no formato:

Como <persona>,
quero <ação/funcionalidade>,
para que <benefício/valor>.

Regras para Stories:

• Cada story deve ser independente e testável
• Incluir critérios de aceitação (Given/When/Then ou checklist)
• Estimativa de complexidade: 1, 2, 3, 5, 8, 13 (Fibonacci)
• Prioridade: Must / Should / Could / Won't (MoSCoW)

Processo full-stack (caminho 1 + 3 — análise + backlog):

Quando delivery-profile.md marcar Web admin = Sim para o BC da story:

• Incluir subseção ### Telas e fluxos (web) com tabela ou lista: rota/tela, persona, ação, endpoints API, guards/menu (copiar de ddd-tactical-model.md → Apresentação — Web).
• Critérios de aceitação devem cobrir pelo menos uma tela da subseção (navegação, erro, permissão).

Quando Mobile = Sim:

• Incluir ### Telas e fluxos (mobile) (screens, navegação, endpoints).
• Critérios de aceitação para fluxo mobile quando aplicável.

Se o ddd-tactical-model.md não tiver apresentação e o perfil exigir web/mobile: parar e pedir completar modelagem (req-ddd-modeling) ou preencher a subseção manualmente na US — não gerar só tasks interface:page.

As subseções Telas e fluxos complementam as tasks interface:entity → … — não substituem a cadeia inside-out no cliente.

Fase 4 — Decomposição em Tasks (por camada DDD)

Para cada Story, criar Tasks técnicas tipadas por camada arquitetural, seguindo a ordem de dentro para fora da Clean Architecture:

Ordem de implementação (inside-out):
── BACKEND ──────────────────────────────────────────────────
1.  domain:vo              → core-value-object
2.  domain:entity          → core-entity
3.  domain:service         → core-domain-service
4.  domain:repository      → core-repository
5.  app:dto                → core-dto
6.  app:usecase            → core-use-case
7.  app:query              → core-query-cqrs
8.  infra:persistence      → backend-data (adapter de persistência)
9.  infra:migration        → config-db (schema/migration)
10. interface:controller   → backend-controller

── FRONTEND WEB (Clean Architecture completa) ───────────────
11. interface:entity       → frontend-entity-angular | frontend-entity-vue | frontend-entity-leptos
12. interface:usecase      → frontend-usecase-angular | frontend-usecase-vue | frontend-usecase-leptos
13. interface:repository   → frontend-repository-angular | frontend-repository-vue | frontend-repository-leptos
14. interface:page         → frontend-page-angular | frontend-page-vue | frontend-page-leptos
15. interface:form-web     → frontend-form-angular | frontend-form-vue | frontend-form-leptos
16. interface:form         → Frontend Form Schema (Next.js)

── MOBILE (Clean Architecture completa) ─────────────────────
17. interface:mobile-entity     → mobile-entity-flutter | mobile-entity-android
18. interface:mobile-usecase    → mobile-usecase-flutter | mobile-usecase-android
19. interface:mobile-repository → mobile-repository-flutter | mobile-repository-android
20. interface:mobile            → mobile-screen-flutter | mobile-screen-android
21. interface:mobile-form       → mobile-form-flutter | mobile-form-android

> **Leptos (Rust web)**: quando Web for **Leptos**, as tasks 11–15 usam `frontend-*-leptos` — mesmo chain entity → usecase → repository → page → form, no workspace Cargo do backend Axum.
.
> **Dioxus (Rust mobile)**: quando Mobile for **Dioxus**, a chain usa os skills Rust compartilhados `core-*-rs` (domain + application,) + `backend-dioxus-api-client-rs` (repository HTTP que preserva `{errors:[...]}`) + `core-dioxus-screen-rs`/`core-dioxus-widget-rs` (apresentação) + `core-dioxus-navigation-rs`/`core-dioxus-state-rs`; testes → `test-dioxus-unit-rs` (≥95%)/`test-dioxus-e2e-rs`. Bootstrap: `config-mobile-dioxus-rs` + `config-dioxus-cicd-rs`.

── QUALIDADE (meta: ≥95% domain + application) ──────────────
22. test:unit              → testes unitários (entity, VO, use case)
23. test:coverage          → validar cobertura ≥95% em domain + application
24. test:e2e               → teste de fluxo completo
25. quality:ci-verify     → pipeline CI verde (PR) — todas as stacks backend
26. quality:memory-leak   → **somente Rust**: vazamento de memória (LeakSanitizer/Valgrind)

Fechamento de épico: cada épico funcional deve terminar com as tasks 22–25 (e 26 se Rust). Não arquivar OpenSpec nem merge sem testes + coverage + E2E + CI verde.

OpenSpec: para features que envolvem múltiplas camadas (backend + frontend + mobile), recomenda-se usar openspec-propose antes de iniciar a implementação. O tasks.md deve copiar o formato do backlog (Agent + Prompt por task). O openspec-apply-change aciona cada Agent listado na ordem inside-out.

Checklist obrigatório — BC com web e/ou mobile

Antes de considerar o backlog (ou tasks.md) pronto para openspec-apply-change, validar:

1. Backend (se aplicável): domain:vo → domain:entity → domain:service → app:usecase → infra:persistence → interface:controller
2. Vue/Angular (se aplicável): todas as tasks interface:entity → interface:usecase → interface:repository → interface:page → interface:form-web (nunca só interface:page)
3. Android/Flutter (se aplicável): todas as tasks interface:mobile-entity → interface:mobile-usecase → interface:mobile-repository → interface:mobile (e interface:mobile-form se houver formulário)
4. Proibido: uma linha genérica “Template full-stack” ou “Aplicar template” sem expandir em tasks numeradas
5. Testes: test:unit + test:e2e do backend da stack; mais test:unit-web / test:unit-mobile quando houver UI nativa (ver tabela abaixo)
6. Cada task: prefixo de camada + Agent (display_name) + Prompt específico (classe, endpoint, comportamento)
7. Cada US com web/mobile no perfil: subseções Telas e fluxos (web) e/ou (mobile) preenchidas e alinhadas às tasks interface:* / interface:mobile-*

Um agente Frontend Page (Vue) não substitui entity/usecase/repository — ele só implementa a camada de apresentação. A subseção Telas e fluxos define o quê implementar; as tasks definem como (CA no cliente).

Formato de task — inclui o agent Cursor a acionar e o prompt sugerido:

Se a stack já foi definida (ex.: C#), gerar com agent e prompt específicos:

- [ ] `domain:entity` Criar entidade Customer com VOs CustomerName, Email, CPF (~2h)
  - **Agent:** `Core Entity (C#)`
  - **Prompt:** "Crie a entidade Customer em C# com os VOs CustomerName, Email e CPF. Aggregate root com método Create() retornando Result<T> e Equals/GetHashCode por Id."

- [ ] `domain:vo` Criar VO CustomerName com validação 2-100 chars (~1h)
  - **Agent:** `Core Value Object (C#)`
  - **Prompt:** "Crie o VO CustomerName em C# — record, construtor privado, Create() com Result<T>, validação: não vazio, trim, 2-100 chars."

- [ ] `app:usecase` Criar CreateCustomerUseCase (~2h)
  - **Agent:** `Core Use Case (C#)`
  - **Prompt:** "Crie o CreateCustomerUseCase em C# que verifica CPF duplicado via ICustomerRepository, cria Customer, persiste e retorna CustomerOutDto."

- [ ] `infra:persistence` Criar adapter CustomerEfRepository (~2h)
  - **Agent:** `Backend Data (C#)`
  - **Prompt:** "Crie CustomerEfRepository em C# implementando ICustomerRepository com EF Core. Separar CustomerDbo do domínio com mapeamentos ToDomain/FromDomain."

- [ ] `interface:controller` Criar POST /api/customers e GET /api/customers/{id} (~2h)
  - **Agent:** `Backend Controller (C#)`
  - **Prompt:** "Crie CustomerController em C# com POST /api/customers (CreateCustomerUseCase) e GET /api/customers/{id} (FindCustomerByIdQuery). Retornar 201 no POST e 404 quando não encontrado."

Se a stack não foi escolhida ainda, mostrar as 3 opções:

- [ ] `domain:entity` Criar entidade Customer com VOs Name e Email (~2h)
  - **Agent TS:** `Core Entity` | **KT:** `Core Entity (Kotlin)` | **CS:** `Core Entity (C#)`
  - **Prompt:** "Crie a entidade Customer com os VOs CustomerName e Email. Aggregate root."

Mapeamento: Prefixo de Task → Agent Cursor

test:unit-web / test:unit-mobile: não há skill Unit Tests (Vue) separado; use o agent do use case da stack com prompt explícito para Vitest/JUnit e mocks de repository. E2E de UI (Playwright) permanece em test:e2e apenas na stack TypeScript (E2E Tests (TypeScript)).

Regras para Tasks:

• Cada task deve ser completável em 1-4 horas
• Deve indicar a camada DDD como prefixo (domain:, app:, infra:, interface:, test:)
• Sempre incluir o nome exato do agent Cursor (display_name do agents/openai.yaml do skill) — nunca cite pasta de skill (core-entity, frontend-entity-vue) no lugar do Agent
• Em projetos full-stack, cada BC com frontend/mobile deve incluir todas as tasks interface:entity → interface:form-web e/ou interface:mobile-* (uma task por camada, cada uma com seu Agent)
• Sempre incluir um prompt sugerido — específico o suficiente para o agent entregar o código correto sem ambiguidade
• Se a stack foi definida pelo usuário, usar apenas o agent da stack escolhida
• O prompt deve incluir: nome da classe, VOs/dependências envolvidas, comportamento esperado
• Deve ser atribuível a uma pessoa

Nota: o sistema fonte analisado pode ser qualquer linguagem (PHP, Go, Python, etc.). As tasks sempre referenciam os skills deste repositório (TS, KT, CS, RS ou Java) porque o objetivo é reimplementar usando DDD/Clean Architecture. Em Rust: rust-namespace-layout.md. Em Java: java-namespace-layout.md — domínio puro em packages/<bc>/, Spring em apps/backend-java.

Fase 5 — Gate de Qualidade e Validação

Antes de finalizar o backlog.md, avalie cada Épico/User Story principal contra o checklist de prontidão e gere uma matriz de validação:

Checklist de Prontidão (Definition of Ready)

Para cada Épico/Story, avalie:

• Necessidade e benefício claros? (Sim/Não)
• Descrição clara e sem termos vagos? (Sim/Não)
• Critérios de aceite Given/When/Then definidos? (Sim/Não)
• Regras de negócio e exceções mapeadas? (Sim/Não)
• Dependências críticas identificadas? (Sim/Não)
• Dúvidas críticas resolvidas ou com plano de ação? (Sim/Não)
• Viabilidade técnica conhecida? (Sim/Não/N/A)
• Dados/integrações definidos? (Sim/Não/N/A)
• Prioridade confirmada (MoSCoW)? (Sim/Não)
• Validador identificado? (Sim/Não)

Veredito Final: [ PRONTO PARA DESENVOLVIMENTO | NÃO PRONTO (Motivo: ______) ]

Matriz de Validação

Gere uma tabela resumida para o Coordenador de TI:

Regras de preenchimento:

• "Com ressalva" deve explicar exatamente o que falta
• Não confunda validação da necessidade com confirmação de viabilidade técnica
• Itens pendentes precisam de próxima ação clara, não apenas de status
• Identifique quem tem conhecimento e autoridade sobre cada requisito

Fase 6 — Priorização e Roadmap

1. Ordenar épicos por valor de negócio e dependência
2. Sugerir agrupamento em sprints/releases (se o usuário quiser)
3. Identificar MVP — menor conjunto de épicos para primeira entrega

Diretório de Saída

Os artefatos são salvos no diretório do projeto consumidor (não do repositório de skills):

<projectRoot>/
├── <docsPath>/                          ← configurável via skills.config.json
│   └── planning/
│       └── <nome-do-projeto>/           ← kebab-case do nome do projeto
│           ├── backlog.md               ← backlog completo (obrigatório)
│           ├── epics-summary.md         ← visão executiva (opcional)
│           └── sprint-plan.md           ← plano de sprint (quando solicitado)

Resolução do caminho

O docsPath é resolvido pela precedência:

1. Argumento explícito do usuário: "salve em docs/planejamento"
2. skills.config.json → defaults.docsPath (ex.: "docs")
3. skills.config.local.json → override local
4. Fallback: docs

Exemplo concreto — se o projeto se chama "meu-erp" e docsPath = "docs":

meu-projeto/
├── docs/
│   ├── discovery/
│   │   └── meu-erp/
│   │       └── requirements.md          ← entrada (do req-discovery)
│   └── planning/
│       └── meu-erp/
│           ├── backlog.md
│           ├── epics-summary.md
│           └── sprint-plan.md
├── apps/
├── packages/
└── ...

Se o diretório <docsPath>/planning/ não existir, crie-o automaticamente.

Quando vem do req-discovery

Se o requirements.md veio do skill req-discovery, use o mesmo <nome-do-sistema> como <nome-do-projeto> para manter a rastreabilidade:

docs/discovery/meu-erp/requirements.md   ← requisitos
docs/discovery/meu-erp/ddd-analysis.md   ← análise DDD (bounded contexts, entities, VOs)
docs/planning/meu-erp/delivery-profile.md ← stack + superfícies API/Web/Mobile por BC (antes do backlog)
docs/planning/meu-erp/backlog.md          ← saída (épicos + stories + tasks por camada)

Artefatos de Saída

delivery-profile.md (obrigatório em full-stack — antes do backlog)

Ver template em references/delivery-profile.md. Sem este arquivo, não gerar backlog.md com tasks web/mobile incompletas.

backlog.md (obrigatório — documento unificado)

# Backlog — <Nome do Projeto>

**Baseado em**: <fonte dos requisitos>
**Análise DDD**: <ddd-analysis.md ou inferido>
**Data**: <data>
**Total**: <N> épicos (<B> bounded contexts + <T> técnicos), <M> stories, <P> tasks
**Perfil de entrega**: `<docsPath>/planning/<projeto>/delivery-profile.md`
**Stack**: <Backend> · <Web ou "Nenhum"> · <Mobile ou "Nenhum"> — **fixa** (não "agnóstico")

## Roadmap

### Release 0 — Bootstrap

- EP-000 [TECH]: Setup do projeto e infraestrutura base

### Release 1 — MVP

- EP-001: <Bounded Context 1>
- EP-002: <Bounded Context 2>

### Release 2 — Expansão

- EP-003: <Bounded Context 3>
- EP-004: <Bounded Context 4>

---

## EP-000 [TECH]: Bootstrap e Infraestrutura

**Descrição**: Setup inicial do projeto full-stack, shared kernel, Docker de produção e CI/CD
**Tamanho**: M
**Dependências**: nenhuma
**Release**: 0
**OpenSpec**: mudança sugerida `bootstrap-<nome-projeto>`

### US-000: Setup do Projeto

> Como desenvolvedor, quero o projeto configurado com Docker e CI/CD, para começar a implementar módulos com entrega contínua desde o início.

**Tasks**:

- [ ] `infra:fullstack` Orquestrar setup completo (~1h)
  - **Agent:** `Config Project Full-Stack`
  - **Prompt:** "Configure projeto <Nome>: backend <TS/KT/CS>, frontend <Angular/Vue/Next>, mobile <Flutter/Android/nenhum>. Docker e CI/CD no bootstrap. Usar OpenSpec."
- [ ] `infra:setup` Bootstrap backend + frontend (~2h)
  - **Agent TS:** `Config Project` / `Config Project (Angular)` / `Config Project (Vue)` | **KT:** `Config Project (Kotlin)` | **CS:** `Config Project (C#)`
  - **Prompt:** "Bootstrap monorepo com docker-compose dev (Postgres)."
- [ ] `infra:shell-web` Shell admin Tailwind (~1h)
  - **Agent Next.js:** `Config Shared Web` | **Angular:** `Config Shared Web (Angular)` | **Vue:** `Config Shared Web (Vue)`
  - **Prompt:** "Configure shell: sidebar colapsável, topbar, rodapé, dashboard vazio. Mescle rotas do shell."
- [ ] `infra:setup` Bootstrap mobile (se aplicável) (~2h)
  - **Agent:** `Config Project (Flutter)` ou `Config Project (Android)`
  - **Prompt:** "Configure app mobile apontando para API local."
- [ ] `infra:docker` Dockerfiles multi-stage de produção (~1h)
  - **Agent TS:** `Config Docker (TypeScript)` | **KT:** `Config Docker (Kotlin)` | **CS:** `Config Docker (C#)`
  - **Prompt:** "Crie Dockerfile multi-stage + docker-compose.prod.yml."
- [ ] `infra:cicd` Pipeline GitHub Actions (~2h)
  - **Agent TS:** `Config CI/CD (TypeScript)` | **KT:** `Config CI/CD (Kotlin)` | **CS:** `Config CI/CD (C#)`
  - **Prompt:** "CI em PR (lint + test + coverage ≥95% domain/app). CD em main (build Docker + deploy)."
- [ ] `domain:shared` Criar shared kernel (~2h)
  - **Agent TS:** `Config Shared Core` | **KT:** `Config Shared Core (Kotlin)` | **CS:** `Config Shared Core (C#)`
  - **Prompt:** "Configure Shared Kernel: Entity, ValueObject, Result<T>, IUseCase, IRepository."
- [ ] `infra:db` Configurar banco de dados (~1h)
  - **Agent TS:** `Config Prisma` | **KT:** `Config JPA (Kotlin)` | **CS:** `Config EF Core (C#)`
  - **Prompt:** "Configure Postgres + migrations iniciais."

---

## EP-001: <Nome do Bounded Context>

**Bounded Context**: BC-001
**Descrição**: <resumo do contexto de domínio>
**Tamanho**: M
**Dependências**: EP-000
**Release**: 1

### US-001: <Título da Story>

> Como <persona>, quero <ação>, para que <benefício>.

**Prioridade**: Must
**Estimativa**: 5 pontos
**Ref**: RF-001, RF-002

**Critérios de Aceitação**:

- [ ] Dado <contexto>, quando <ação>, então <resultado>
- [ ] Dado <contexto>, quando <ação>, então <resultado>
- [ ] (se web) Dado usuário em `<rota>`, quando <ação na UI>, então <resultado visível>
- [ ] (se mobile) Dado app em `<Screen>`, quando <ação>, então <resultado>

### Telas e fluxos (web)

> Obrigatório quando `delivery-profile` / `ddd-tactical-model` tiver **Web admin = Sim** para este BC. Omitir se Web = Não.

| Rota / tela | Persona | Ação | API | Form? |
|-------------|---------|------|-----|-------|
| `/<exemplo>` | <persona> | <ação> | `GET/POST …` | Sim/Não |

**Navegação**: <menu, guards, redirect login>

**Entidades / use cases UI** (alimentam tasks `interface:entity` … `interface:form-web`):

- `<EntidadeUI>` → `<UseCaseUI>` via `<IRepository>`

### Telas e fluxos (mobile)

> Obrigatório quando **Mobile = Sim**. Omitir se Mobile = Não.

| Tela | Persona | Ação | API | Form? |
|------|---------|------|-----|-------|
| `<Screen>` | <persona> | <ação> | `…` | Sim/Não |

**Navegação**: <tabs, deep links>

**Entidades / use cases UI**: <lista breve>

**Tasks (inside-out)**:

- [ ] `domain:vo` Criar VO <NomeVO> com validação (~1h)
  - **Agent TS:** `Core Value Object` | **KT:** `Core Value Object (Kotlin)` | **CS:** `Core Value Object (C#)`
  - **Prompt:** "Crie o VO <NomeVO> com validação: <regra>. Imutável, Create() com Result<T>."
- [ ] `domain:entity` Criar entidade <X> com VOs <lista> (~2h)
  - **Agent TS:** `Core Entity` | **KT:** `Core Entity (Kotlin)` | **CS:** `Core Entity (C#)`
  - **Prompt:** "Crie a entidade <X> com os VOs <lista>. Aggregate root. Método Create() com Result<T>."
- [ ] `domain:repository` Criar interface <X>Repository (~1h)
  - **Agent TS:** `Core Repository` | **KT:** `Core Repository (Kotlin)` | **CS:** `Core Repository (C#)`
  - **Prompt:** "Crie a interface I<X>Repository com operações: create, findById, <outras>."
- [ ] `app:dto` Criar Create<X>InDTO e <X>OutDTO (~1h)
  - **Agent TS:** `Core DTO` | **KT:** `Core DTO (Kotlin)` | **CS:** `Core DTO (C#)`
  - **Prompt:** "Crie Create<X>InDto (campos de entrada) e <X>OutDto (campos de saída)."
- [ ] `app:usecase` Criar Create<X>UseCase (~2h)
  - **Agent TS:** `Core Use Case` | **KT:** `Core Use Case (Kotlin)` | **CS:** `Core Use Case (C#)`
  - **Prompt:** "Crie Create<X>UseCase que <descrição do fluxo: validações, criação, persistência, retorno>."
- [ ] `app:query` Criar Find<X>ByIdQuery (~1h)
  - **Agent TS:** `Core Query CQRS` | **KT:** `Core Query CQRS (Kotlin)` | **CS:** `Core Query CQRS (C#)`
  - **Prompt:** "Crie Find<X>ByIdQuery retornando <X>OutDto por ID."
- [ ] `infra:persistence` Criar adapter de persistência (~2h)
  - **Agent TS:** `Backend Prisma Data` | **KT:** `Backend Data (Kotlin)` | **CS:** `Backend Data (C#)`
  - **Prompt:** "Crie o adapter <X>Repository implementando I<X>Repository. Separar entidade de persistência do domínio."
- [ ] `infra:migration` Criar migration/schema (~1h)
  - **Agent TS:** `Config Prisma` | **KT:** `Config JPA (Kotlin)` | **CS:** `Config EF Core (C#)`
  - **Prompt:** "Crie a migration para a tabela <X> com campos: <lista>."
- [ ] `interface:controller` Criar endpoints REST (~2h)
  - **Agent TS:** `Backend Controller` | **KT:** `Backend Controller (Kotlin)` | **CS:** `Backend Controller (C#)`
  - **Prompt:** "Crie <X>Controller com POST /api/<xs> e GET /api/<xs>/{id}. Usar Create<X>UseCase e Find<X>ByIdQuery."
- [ ] `interface:entity` Criar entidade frontend <X> (~1h)
  - **Agent Angular:** `Frontend Entity (Angular)` | **Vue:** `Frontend Entity (Vue)` | **Next.js:** `Frontend Form Schema`
  - **Prompt:** "Crie entidade <X> frontend com Result<T>, espelhando o domínio do backend."
- [ ] `interface:usecase` Criar use cases frontend (~2h)
  - **Agent Angular:** `Frontend UseCase (Angular)` | **Vue:** `Frontend UseCase (Vue)`
  - **Prompt:** "Crie Create<X>UseCase e List<X>sUseCase injetando I<X>Repository. Retornar Promise<Result>."
- [ ] `interface:repository` Criar repositório HTTP (~2h)
  - **Agent Angular:** `Frontend Repository (Angular)` | **Vue:** `Frontend Repository (Vue)`
  - **Prompt:** "Crie <X>HttpRepository implementando I<X>Repository. Mapear DTOs; try/catch → Result.err."
- [ ] `interface:page` Criar página de listagem (~2h)
  - **Agent Angular:** `Frontend Page (Angular)` | **Vue:** `Frontend Page (Vue)`
  - **Prompt:** "Listagem de <xs> injetando List<X>sUseCase. Tabela PrimeNG/PrimeVue; sem HTTP direto."
- [ ] `interface:form-web` Criar formulário de cadastro/edição (~2h)
  - **Agent Angular:** `Frontend Form (Angular)` | **Vue:** `Frontend Form (Vue)`
  - **Prompt:** "Formulário com validação; injeta Create<X>UseCase; exibe erros de negócio (Result)."
- [ ] `interface:mobile-entity` Criar entidade mobile <X> (~1h)
  - **Agent Flutter:** `Mobile Entity (Flutter)` | **Android:** `Mobile Entity (Android)`
  - **Prompt:** "Entidade <X> Dart/Kotlin pura com sealed Result."
- [ ] `interface:mobile-usecase` Criar use cases mobile (~2h)
  - **Agent Flutter:** `Mobile UseCase (Flutter)` | **Android:** `Mobile UseCase (Android)`
  - **Prompt:** "Create<X>UseCase e List<X>sUseCase injetando I<X>Repository."
- [ ] `interface:mobile-repository` Criar repositório HTTP mobile (~2h)
  - **Agent Flutter:** `Mobile Repository (Flutter)` | **Android:** `Mobile Repository (Android)`
  - **Prompt:** "RepositoryImpl com Dio/Retrofit; mapear DTOs; catch → Failure."
- [ ] `interface:mobile` Criar tela de listagem mobile (~2h)
  - **Agent Flutter:** `Mobile Screen (Flutter)` | **Android:** `Mobile Screen (Android)`
  - **Prompt:** "Tela de listagem de <xs>; notifier/ViewModel injeta UseCase; pull-to-refresh."
- [ ] `interface:mobile-form` Criar formulário mobile (~2h)
  - **Agent Flutter:** `Mobile Form (Flutter)` | **Android:** `Mobile Form (Android)`
  - **Prompt:** "Formulário de cadastro; trata result.when/onSuccess; exibe erros de negócio."
- [ ] `test:unit` Testes da entity, VOs e use case (~2h)
  - **Agent TS:** `Unit Tests (TypeScript)` | **KT:** `Unit Tests (Kotlin)` | **CS:** `Unit Tests (C#)`
  - **Prompt:** "Crie testes unitários para VOs, Entity e Create<X>UseCase. Mock repository. Cobrir fluxo feliz e erros de negócio."
- [ ] `test:coverage` Validar cobertura ≥95% em domain + application (~30min)
  - **Agent:** mesmo de test:unit
  - **Prompt:** "Execute testes com coverage. Ajuste até ≥95% lines em domain+application. CI usa scripts/check-coverage.mjs."
- [ ] `test:e2e` Teste do fluxo completo (~2h)
  - **Agent TS:** `E2E Tests (TypeScript)` | **KT:** `E2E Tests (Kotlin)` | **CS:** `E2E Tests (C#)` | **RS:** `E2E Tests (Rust)` | **Java:** `E2E Tests (Java)`
  - **Prompt:** "Crie E2E: API POST criar → GET buscar (Supertest/MockMvc/integration HTTP). Se houver UI, Playwright para fluxo principal."
- [ ] `quality:ci-verify` Validar pipeline CI verde (~30min)
  - **Agent:** `Config CI/CD` da stack
  - **Prompt:** "Push/PR: fmt, lint/clippy, test, coverage ≥95% domain+application. Corrigir falhas antes de fechar o épico."
- [ ] `quality:memory-leak` Verificar vazamento de memória (~30min) — **somente Rust**
  - **Agent:** `Config CI/CD (Rust)`
  - **Prompt:** "Rode bash config-cicd-rs/scripts/check-memory-rs.sh após test:e2e. Corrija Arc/tasks/pools. Confirme job memory-check no CI."

### US-002: <Título da Story>

...

---

## EP-002: <Nome do Épico>

...

epics-summary.md (opcional — visão executiva)

# Resumo de Épicos — <Nome do Projeto>

| ID     | Épico           | Tamanho | Stories | Tasks | Dep.   | Release |
| ------ | --------------- | ------- | ------- | ----- | ------ | ------- |
| EP-001 | Auth & Usuários | M       | 5       | 18    | -      | 1       |
| EP-002 | Catálogo        | G       | 8       | 30    | EP-001 | 1       |
| EP-003 | Carrinho        | M       | 4       | 14    | EP-002 | 2       |

**Totais**: X stories, Y tasks, ~Z horas estimadas

sprint-plan.md (opcional — quando o usuário pedir)

# Plano de Sprint — <Nome do Projeto>

## Sprint 1 (2 semanas)

**Objetivo**: <objetivo da sprint>
**Capacidade**: ~X pontos

| Story  | Pontos | Status |
| ------ | ------ | ------ |
| US-001 | 5      | To Do  |
| US-002 | 3      | To Do  |
| US-003 | 5      | To Do  |

**Total**: 13 pontos

Colaboração com o Usuário

Durante a criação do backlog, interaja ativamente:

1. Validar épicos: "Identifiquei N épicos. Faz sentido? Falta algo?"
2. Confirmar prioridades: "O que é MVP para você? Quais funcionalidades são obrigatórias na primeira entrega?"
3. Estimar capacidade: "Qual o tamanho do time? Sprints de quantas semanas?"
4. Ajustar granularidade: Se o usuário quiser mais ou menos detalhe nas tasks

Integração com Outros Skills

Antes (fontes):

• req-ddd-modeling → fornece ddd-strategic-model.md + ddd-tactical-model.md (domínio + apresentação web/mobile por BC — ver req-ddd-modeling/references/client-presentation-model.md)
• req-discovery → fornece requirements.md como entrada principal
• openspec-explore → investigação prévia do problema

Depois (implementação):

• config-project-fullstack → orquestra bootstrap (backend + frontend + mobile + docker + cicd)
• openspec-propose → criar proposta de change (bootstrap-<nome> ou ep-XXX-<bc>)
• openspec-apply-change → implementar tasks de uma story/épico
• openspec-archive-change → fechar mudança completada
• config-new-module / config-new-module-kt / config-new-module-cs → scaffolding de módulos

Ofereça essas integrações ao finalizar:

"Backlog criado! Próximos passos:\n> 1. Criar mudança de bootstrap (openspec-propose \"bootstrap-<nome>\") com docker + cicd\n> 2. Implementar via openspec-apply-change ou agents diretos\n> 3. Por BC: propose → apply → archive"

Formato de Exportação

Se o usuário pedir, o backlog pode ser convertido para:

• GitHub Issues: um issue por story, labels por épico e prioridade
• JSON estruturado: para importação em ferramentas externas
• CSV: para planilhas

Para GitHub Issues, usar:

gh issue create --title "US-001: <título>" --body "<corpo>" --label "epic:<nome>,priority:<must|should|could>"
``

…(truncated)