adi_dev_workflow 1.3.0 → 1.4.0

package/frameworks/commands/ministack/generate-tasks.md

@@ -1,212 +1,212 @@
----
-description: "Gera TASKS do miniStack a partir de INTENT e SCOPE aprovados. Params: <intent.md> <scope.md>"
-argument-hint: "<intent.md ex: docs/carrinho-compra/v1/intent.md> <scope.md ex: docs/carrinho-compra/v1/scope.md>"
----
-
-> **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `ministack` antes de salvar artefatos. Os paths abaixo sao exemplos — o path real vem do config.
-
-Use a skill **ministack-tasks-expert** para gerar as TASKS.
-
-## Contexto
-
-Voce deve seguir as regras e o processo definidos na skill ministack-tasks-expert.
-
-O $ARGUMENTS deve conter:
-1. **caminho do intent.md** (obrigatorio)
-2. **caminho do scope.md** (obrigatorio)
-
-O task_plan.md e as tasks individuais serao gerados no mesmo diretorio dos arquivos de entrada.
-
-## Regras Adicionais
-
-- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
-- **NUNCA** deduza escopo ou invente informacoes — na **DUVIDA PERGUNTE AO USUARIO**
-- Liste **TODOS** os arquivos envolvidos e as acoes (criar/modificar/remover) em cada task — economiza tokens e scans
-
----
-
-## Estrutura de Saida (Formato Modular)
-
-A skill gera **arquivos individuais** para cada task, nao um arquivo monolitico:
-
-```
-docs/[nome-feature]/vN/
-  task_plan.md       # Indice: macro-fases, grafo de dependencias, visao consolidada
-  tasks/
-    T1.md            # Task individual completa
-    T2.md
-    T3.md
-    ...
-```
-
----
-
-## Delegacao QA — Secao de Testes de cada Task
-
-A **secao de Testes** de cada task NAO deve ser preenchida pela skill. Voce DEVE delegar para o agente **qa-staff-engineer** que retorna um JSON estruturado. Depois, voce converte o resultado em markdown na secao de Testes.
-
-### Quando executar
-
-Para **cada task**, apos a skill preencher todas as secoes exceto Testes, **ANTES de salvar os arquivos finais**. Se varias tasks estao sendo criadas, voce pode disparar agentes QA em **paralelo** para maximizar eficiencia.
-
-### Passo 1: Preparar a lista de arquivos
-
-Monte a lista de `arquivos` que o agente deve ler para CADA task. Inclua:
-
-- **INTENT aprovada**: `docs/[nome-feature]/vN/intent.md`
-- **SCOPE aprovado**: `docs/[nome-feature]/vN/scope.md`
-- **Testes existentes**: busque arquivos de teste relacionados aos arquivos impactados pela task
-- **Codigo-fonte existente**: arquivos listados na task (a criar ou modificar)
-
-### Passo 2: Preparar as instrucoes
-
-Monte o campo `instrucoes` com:
-
-1. O conteudo completo da **task parcial** que a skill montou ate o momento
-2. Os **criterios de conclusao** da task
-3. Os **arquivos impactados** pela task — para o QA saber quais camadas testar
-4. O **tipo da task** (cria handler, cria service, cria repository, cria migracao, etc.)
-
-### Passo 3: Disparar o agente
-
-Lance o agente usando a ferramenta `Agent` com:
-
-- **subagent_type**: `qa-staff-engineer`
-- **description**: "QA gerar testes task TN"
-- **prompt**: Monte o prompt com os 3 parametros obrigatorios:
-
-```
-Voce foi invocado com os seguintes parametros:
-
-1. **modo**: GERAR_TESTES
-2. **arquivos**: [lista de caminhos dos arquivos preparados no Passo 1]
-3. **instrucoes**: [conteudo preparado no Passo 2]
-```
-
-### Passo 4: Converter JSON em formato tabular (secao Testes)
-
-O agente QA retorna um JSON com `casos_teste[]`. Voce DEVE converter para o formato **tabular** da secao de Testes usando o mapeamento abaixo:
-
-#### Mapeamento de tipos
-
-| Campo `tipo` no JSON | Subsecao destino |
-|---------------------|-----------------|
-| `UNITARIO` | **5.1 Testes Unitarios** |
-| `INTEGRACAO` | **5.2 Testes de Integracao** |
-| `E2E` | **5.3 Testes E2E** |
-| `SEGURANCA` | **5.4 Cenarios de Erro** |
-| `PERFORMANCE` | **5.4 Cenarios de Erro** |
-
-Alem dos testes tipo `SEGURANCA` e `PERFORMANCE`, inclua em 5.4 todos os `casos_teste` com `categoria` igual a: `tratamento_erro`, `caso_extremo`, `fronteira`.
-
-#### Formato de saida por subsecao
-
-O formato DEVE seguir o **formato tabular** do template de task individual. Isso garante clareza sobre o objetivo real de cada teste.
-
-Infira o nome do arquivo de teste a partir do componente testado:
-- Handler → `[nome]_handler_test.go`
-- Service → `[nome]_service_test.go`
-- Repository → `[nome]_repository_test.go`
-
-Infira o nome da funcao de teste a partir do titulo do CT:
-- Use formato `TestNomeMetodo_CenarioDescritivo` (Go convention)
-
-**5.1 Testes Unitarios** — formato tabular agrupado por componente:
-
-```markdown
-#### [Camada]: [NomeComponente] (`arquivo_test.go`)
-
-Mock: [interfaces mockadas]
-
-| CT | Teste | Objetivo | Input | Expected | Mock |
-|----|-------|----------|-------|----------|------|
-| CT-XX | TestMetodo_Cenario | Verificar que [comportamento] quando [condicao] | dados entrada | resultado esperado | dependencias mockadas |
-```
-
-**5.2 Testes de Integracao** — formato tabular com Setup:
-
-```markdown
-#### [CamadaA + CamadaB] (`arquivo_test.go`)
-
-Setup: [banco in-memory, migracoes, fixtures]
-
-| CT | Teste | Objetivo | Fluxo | Validacao |
-|----|-------|----------|-------|-----------|
-| CT-XX | TestIntegracao_Cenario | Verificar que [comportamento] quando [condicao] | Passos do fluxo | Assertions esperadas |
-```
-
-**5.3 Testes E2E** — formato descritivo por fluxo:
-
-```markdown
-#### Fluxo: [Nome do Fluxo] (CT-XX)
-- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
-- **Pre-condicoes**: (estado inicial do sistema)
-- **Passos**:
-  1. Passo 1
-  2. Passo 2
-- **Validacoes**: (assertions sobre dados e estado final)
-```
-
-**5.4 Cenarios de Erro** — formato tabular:
-
-```markdown
-| Cenario | Objetivo | Trigger | Codigo/Status | Log Esperado |
-|---------|----------|---------|---------------|-------------|
-| Descricao | Verificar que [constraint] impede [operacao] | Acao trigger | Codigo erro | Mensagem log |
-```
-
-#### Testes Existentes a Modificar
-
-Apos as subsecoes 5.1-5.4, adicione a tabela de testes existentes:
-
-```markdown
-#### Testes Existentes a Modificar
-| Arquivo | Motivo da Modificacao |
-|---------|----------------------|
-```
-
-Se nenhum: `> Nenhum teste existente impactado.`
-
-### Passo 5: Validar como engenheiro de tarefas
-
-Antes de integrar a secao de Testes na task:
-
-1. Verifique **coerencia** com os arquivos impactados (os componentes testados existem?)
-2. Verifique que os testes cobrem os **criterios de conclusao** da task
-3. Ajuste nomenclatura para seguir padroes do projeto
-4. Para tasks sem codigo (documentacao, configuracao): "N/A — task nao envolve codigo testavel"
-
-### Passo 6: Salvar e apresentar
-
-1. Salve cada task individual em `docs/[nome-feature]/vN/tasks/T[N].md`
-2. Salve o task plan em `docs/[nome-feature]/vN/task_plan.md`
-3. Apresente ao usuario para aprovacao
-
-**NAO peca aprovacao isolada da secao de testes** — apresente as tasks completas para validacao.
-
----
-
-## Estado do Pipeline (ministack_state.yaml)
-
-Apos salvar o task_plan.md e todas as tasks com sucesso, atualize o arquivo `ministack_state.yaml` no mesmo diretorio:
-
-```yaml
-# atualizar apenas estes campos:
-current_step: task_plan
-steps:
-  task_plan:
-    status: completed
-    summary: "<N tasks>, <M fases>, <P paralelizaveis>"
-  execution:
-    status: pending
-    tasks_total: <N>
-    tasks_completed: 0
-```
-
-Se o `ministack_state.yaml` nao existir, nao crie — o generate-intent e responsavel por criar.
-
-## Entrada
-
-Cole a INTENT e SCOPE aprovados:
-
-$ARGUMENTS
+---
+description: "Gera TASKS do miniStack a partir de INTENT e SCOPE aprovados. Params: <intent.md> <scope.md>"
+argument-hint: "<intent.md ex: docs/specs/carrinho-compra/v1/intent.md> <scope.md ex: docs/specs/carrinho-compra/v1/scope.md>"
+---
+
+> **Paths**: Leia `.claude/config/ai-framework-config.yaml` seção `ministack` antes de salvar artefatos. Os paths abaixo são exemplos — o path real vem do config.
+
+Use a skill **ministack-tasks-expert** para gerar as TASKS.
+
+## Contexto
+
+Você deve seguir as regras e o processo definidos na skill ministack-tasks-expert.
+
+O $ARGUMENTS deve conter:
+1. **caminho do intent.md** (obrigatório)
+2. **caminho do scope.md** (obrigatório)
+
+O task_plan.md e as tasks individuais serão gerados no mesmo diretório dos arquivos de entrada.
+
+## Regras Adicionais
+
+- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer dúvidas com o usuário
+- **NUNCA** deduza escopo ou invente informações — na **DÚVIDA PERGUNTE AO USUÁRIO**
+- Liste **TODOS** os arquivos envolvidos e as ações (criar/modificar/remover) em cada task — economiza tokens e scans
+
+---
+
+## Estrutura de Saída (Formato Modular)
+
+A skill gera **arquivos individuais** para cada task, não um arquivo monolítico:
+
+```
+docs/specs/[nome-feature]/[versão]/
+  task_plan.md       # Índice: macro-fases, grafo de dependências, visão consolidada
+  tasks/
+    T1.md            # Task individual completa
+    T2.md
+    T3.md
+    ...
+```
+
+---
+
+## Delegação QA — Seção de Testes de cada Task
+
+A **seção de Testes** de cada task NÃO deve ser preenchida pela skill. Você (comando orquestrador) DEVE delegar para o agente **qa-staff-engineer** que retorna um JSON estruturado. Depois, você converte o resultado em markdown na seção de Testes.
+
+### Quando executar
+
+Para **cada task**, após a skill preencher todas as seções exceto Testes, **ANTES de salvar os arquivos finais**. Se várias tasks estão sendo criadas, você pode disparar agentes QA em **paralelo** para maximizar eficiência.
+
+### Passo 1: Preparar a lista de arquivos
+
+Monte a lista de `arquivos` que o agente deve ler para CADA task. Inclua:
+
+- **INTENT aprovada**: `docs/specs/[nome-feature]/[versão]/intent.md`
+- **SCOPE aprovado**: `docs/specs/[nome-feature]/[versão]/scope.md`
+- **Testes existentes**: busque arquivos de teste relacionados aos arquivos impactados pela task
+- **Código-fonte existente**: arquivos listados na task (a criar ou modificar)
+
+### Passo 2: Preparar as instruções
+
+Monte o campo `instrucoes` com:
+
+1. O conteúdo completo da **task parcial** que a skill montou até o momento
+2. Os **critérios de conclusão** da task
+3. Os **arquivos impactados** pela task — para o QA saber quais camadas testar
+4. O **tipo da task** (cria handler, cria service, cria repository, cria migração, etc.)
+
+### Passo 3: Disparar o agente
+
+Lance o agente usando a ferramenta `Agent` com:
+
+- **subagent_type**: `qa-staff-engineer`
+- **description**: "QA gerar testes task TN"
+- **prompt**: Monte o prompt com os 3 parâmetros obrigatórios:
+
+```
+Você foi invocado com os seguintes parâmetros:
+
+1. **modo**: GERAR_TESTES
+2. **arquivos**: [lista de caminhos dos arquivos preparados no Passo 1]
+3. **instrucoes**: [conteúdo preparado no Passo 2]
+```
+
+### Passo 4: Converter JSON em formato tabular (seção Testes)
+
+O agente QA retorna um JSON com `casos_teste[]`. Você DEVE converter para o formato **tabular** da seção de Testes usando o mapeamento abaixo:
+
+#### Mapeamento de tipos
+
+| Campo `tipo` no JSON | Subseção destino |
+|---------------------|-----------------|
+| `UNITARIO` | **5.1 Testes Unitários** |
+| `INTEGRACAO` | **5.2 Testes de Integração** |
+| `E2E` | **5.3 Testes E2E** |
+| `SEGURANCA` | **5.4 Cenários de Erro** |
+| `PERFORMANCE` | **5.4 Cenários de Erro** |
+
+Além dos testes tipo `SEGURANCA` e `PERFORMANCE`, inclua em 5.4 todos os `casos_teste` com `categoria` igual a: `tratamento_erro`, `caso_extremo`, `fronteira`.
+
+#### Formato de saída por subseção
+
+O formato DEVE seguir o **formato tabular** do template de task individual. Isso garante clareza sobre o objetivo real de cada teste.
+
+Infira o nome do arquivo de teste a partir do componente testado:
+- Handler → `[nome]_handler_test.go`
+- Service → `[nome]_service_test.go`
+- Repository → `[nome]_repository_test.go`
+
+Infira o nome da função de teste a partir do título do CT:
+- Use formato `TestNomeMetodo_CenarioDescritivo` (Go convention)
+
+**5.1 Testes Unitários** — formato tabular agrupado por componente:
+
+```markdown
+#### [Camada]: [NomeComponente] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | Objetivo | Input | Expected | Mock |
+|----|-------|----------|-------|----------|------|
+| CT-XX | TestMetodo_Cenario | Verificar que [comportamento] quando [condição] | dados entrada | resultado esperado | dependências mockadas |
+```
+
+**5.2 Testes de Integração** — formato tabular com Setup:
+
+```markdown
+#### [CamadaA + CamadaB] (`arquivo_test.go`)
+
+Setup: [banco in-memory, migrações, fixtures]
+
+| CT | Teste | Objetivo | Fluxo | Validação |
+|----|-------|----------|-------|-----------|
+| CT-XX | TestIntegracao_Cenario | Verificar que [comportamento] quando [condição] | Passos do fluxo | Assertions esperadas |
+```
+
+**5.3 Testes E2E** — formato descritivo por fluxo:
+
+```markdown
+#### Fluxo: [Nome do Fluxo] (CT-XX)
+- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
+- **Pré-condições**: (estado inicial do sistema)
+- **Passos**:
+  1. Passo 1
+  2. Passo 2
+- **Validações**: (assertions sobre dados e estado final)
+```
+
+**5.4 Cenários de Erro** — formato tabular:
+
+```markdown
+| Cenário | Objetivo | Trigger | Código/Status | Log Esperado |
+|---------|----------|---------|---------------|--------------|
+| Descrição | Verificar que [constraint] impede [operação] | Ação trigger | Código erro | Mensagem log |
+```
+
+#### Testes Existentes a Modificar
+
+Após as subseções 5.1-5.4, adicione a tabela de testes existentes:
+
+```markdown
+#### Testes Existentes a Modificar
+| Arquivo | Motivo da Modificação |
+|---------|----------------------|
+```
+
+Se nenhum: `> Nenhum teste existente impactado.`
+
+### Passo 5: Validar como engenheiro de tarefas
+
+Antes de integrar a seção de Testes na task:
+
+1. Verifique **coerência** com os arquivos impactados (os componentes testados existem?)
+2. Verifique que os testes cobrem os **critérios de conclusão** da task
+3. Ajuste nomenclatura para seguir padrões do projeto
+4. Para tasks sem código (documentação, configuração): "N/A — task não envolve código testável"
+
+### Passo 6: Salvar e apresentar
+
+1. Salve cada task individual em `docs/specs/[nome-feature]/[versão]/tasks/T[N].md`
+2. Salve o task plan em `docs/specs/[nome-feature]/[versão]/task_plan.md`
+3. Apresente ao usuário para aprovação
+
+**NÃO peça aprovação isolada da seção de testes** — apresente as tasks completas para validação.
+
+---
+
+## Estado do Pipeline (ministack_state.yaml)
+
+Após salvar o task_plan.md e todas as tasks com sucesso, atualize o arquivo `ministack_state.yaml` no mesmo diretório:
+
+```yaml
+# atualizar apenas estes campos:
+current_step: task_plan
+steps:
+  task_plan:
+    status: completed
+    summary: "<N tasks>, <M fases>, <P paralelizáveis>"
+  execution:
+    status: pending
+    tasks_total: <N>
+    tasks_completed: 0
+```
+
+Se o `ministack_state.yaml` não existir, não crie — o generate-intent é responsável por criar.
+
+## Entrada
+
+Cole a INTENT e SCOPE aprovados:
+
+$ARGUMENTS

package/frameworks/commands/sdd/generate-task-plan.md

@@ -1,6 +1,6 @@
 ---
 description: "Gera TASK PLAN + tasks individuais do SDD a partir de SPEC_TECH aprovado. Param: caminho do spec_tech.md"
-argument-hint: "<spec_tech.md ex: docs/feature-user/v1/spec_tech.md>"
+argument-hint: "<spec_tech.md ex: docs/specs/feature-user/v1/spec_tech.md>"
 ---
 
 > **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `sdd` antes de salvar artefatos. Os paths abaixo sao exemplos — o path real vem do config.
@@ -12,7 +12,7 @@ Use a skill **sdd-task-plan-expert** para gerar o TASK PLAN e as tasks individua
 Voce deve atuar como um **Engenheiro de Software Senior** especializado em decomposicao de tarefas e seguir todo o processo interativo definido na skill sdd-task-plan-expert.
 
 O $ARGUMENTS deve conter:
-1. **caminho do spec_tech.md** (obrigatorio) — ex: `docs/feature-user/v1/spec_tech.md`
+1. **caminho do spec_tech.md** (obrigatorio) — ex: `docs/specs/feature-user/v1/spec_tech.md`
 
 O task_plan.md e as tasks individuais serao gerados no mesmo diretorio do spec_tech.md. O PRD sera localizado a partir de referencia interna no spec_tech.md.
 
@@ -39,8 +39,8 @@ Para **cada task**, apos preencher as secoes 1-5 e 7-8, **ANTES de salvar o arqu
 
 Monte a lista de `arquivos` que o subagente deve ler para CADA task. Inclua:
 
-- **PRD aprovado**: `docs/[nome-feature]/vN/prd.md`
-- **SPEC_TECH aprovado**: `docs/[nome-feature]/vN/spec_tech.md`
+- **PRD aprovado**: `docs/specs/[nome-feature]/[versao]/prd.md`
+- **SPEC_TECH aprovado**: `docs/specs/[nome-feature]/[versao]/spec_tech.md`
 - **Regras do projeto**: `CLAUDE.md`, `.claude/rules/*.md`
 - **Migracoes**: `internal/db/migrations/*.sql` (relacionadas a task)
 - **Queries SQLC**: `internal/db/queries/*.sql` (relacionadas a task)

package/frameworks/commands/sdd/generate-tech-direction.md

@@ -1,6 +1,6 @@
 ---
 description: "Gera TECH DIRECTION do SDD a partir de PRD aprovado. Param: caminho do prd.md"
-argument-hint: "<prd.md ex: docs/feature-user/v1/prd.md>"
+argument-hint: "<prd.md ex: docs/specs/feature-user/v1/prd.md>"
 ---
 
 > **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `sdd` antes de salvar artefatos. Os paths abaixo sao exemplos — o path real vem do config.
@@ -23,7 +23,7 @@ Antes de iniciar, verifique se `.claude/rules/project-profile.md` existe. Se NAO
 - Pesquise o codebase ANTES de fazer perguntas (regras, padroes, libs)
 - Faca **UMA pergunta por vez**, aguardando a resposta antes de avancar
 - **SEMPRE** salve o arquivo fisico antes de apresentar ao usuario
-- O arquivo deve ser salvo no mesmo diretorio do PRD: `docs/[nome-feature]/vN/tech_direction.md`
+- O arquivo deve ser salvo no mesmo diretorio do PRD: `docs/specs/[nome-feature]/[versao]/tech_direction.md`
 
 ## Estado do Pipeline (sdd_state.yaml)
 

package/frameworks/commands/sdd/generate-tech-spec.md

@@ -1,6 +1,6 @@
 ---
 description: "Gera SPEC_TECH completo do SDD a partir de PRD aprovado. Param: caminho do prd.md"
-argument-hint: "<prd.md ex: docs/feature-user/v1/prd.md>"
+argument-hint: "<prd.md ex: docs/specs/feature-user/v1/prd.md>"
 ---
 
 > **Paths**: Leia `.claude/config/ai-framework-config.yaml` secao `sdd` antes de salvar artefatos. Os paths abaixo sao exemplos — o path real vem do config.
@@ -12,7 +12,7 @@ Use a skill **sdd-tech-spec-expert** para gerar o SPEC_TECH.
 Voce deve atuar como um **Arquiteto de Software Senior** e seguir todo o processo interativo definido na skill sdd-tech-spec-expert para transformar o PRD aprovado em uma especificacao tecnica completa.
 
 O $ARGUMENTS deve conter:
-1. **caminho do prd.md** (obrigatorio) — ex: `docs/feature-user/v1/prd.md`
+1. **caminho do prd.md** (obrigatorio) — ex: `docs/specs/feature-user/v1/prd.md`
 
 O spec_tech.md sera gerado no mesmo diretorio do prd.md.
 
@@ -35,7 +35,7 @@ Antes de iniciar, verifique se existe um arquivo `tech_direction.md` no mesmo di
 - Liste **TODOS** os arquivos envolvidos e as acoes (criar/modificar/referencia) — economiza tokens e scans
 - Mapeie cada **User Story do PRD** para definicoes tecnicas correspondentes
 
-O arquivo deve ser salvo no diretorio `docs/[nome-feature]/vN/spec_tech.md`
+O arquivo deve ser salvo no diretorio `docs/specs/[nome-feature]/[versao]/spec_tech.md`
 
 ---
 
@@ -51,7 +51,7 @@ Apos coletar todas as decisoes tecnicas e preencher as secoes 1-13 do SPEC_TECH,
 
 Monte a lista de `arquivos` que o subagente deve ler. Inclua TODOS os caminhos relevantes:
 
-- **PRD aprovado**: `docs/[nome-feature]/vN/prd.md`
+- **PRD aprovado**: `docs/specs/[nome-feature]/[versao]/prd.md`
 - **Regras do projeto**: `CLAUDE.md`, `.claude/rules/*.md`
 - **Migracoes**: `internal/db/migrations/*.sql` (relacionadas a feature)
 - **Queries SQLC**: `internal/db/queries/*.sql` (relacionadas a feature)