adi_dev_workflow 1.0.0 → 1.1.1

package/frameworks/skills/sdd-qa-expert/templates/task_tests_template.md

@@ -1,24 +0,0 @@
-# Testes da Task
-
-## 6.1 Testes Unitarios
-- [ ] **[arquivo_teste] TestNomeFuncao_Sucesso** — Cenario: [descricao precisa do cenario]. Input: [dados]. Expected: [resultado]. Mock: [o que mockar]
-- [ ] **[arquivo_teste] TestNomeFuncao_ErroValidacao** — Cenario: [descricao]. Input: [dados invalidos]. Expected: [erro especifico]
-- [ ] **[arquivo_teste] TestNomeFuncao_ErroDependencia** — Cenario: [descricao]. Input: [dados validos]. Expected: [erro wrapped]. Mock: [dependencia retorna erro]
-
-## 6.2 Testes de Integracao
-- [ ] **[arquivo_teste] TestIntegracao_FluxoCompleto** — Setup: [banco in-memory, migracoes]. Fluxo: [create -> get -> verify]. Validacao: [dados consistentes]
-- [ ] **[arquivo_teste] TestIntegracao_ErroConstraint** — Setup: [registro existente]. Fluxo: [insert duplicado]. Validacao: [erro de constraint]
-
-## 6.3 Testes E2E
-- [ ] **[arquivo_teste] TestE2E_FluxoPrincipal** — Pre-condicao: [estado inicial]. Passos: [request -> validar response -> verificar banco]. Pos-condicao: [estado final]
-
-## 6.4 Cenarios de Erro
-- [ ] **Cenario: [descricao]** — Trigger: [o que causa o erro]. Expected: [codigo de status, mensagem]. Camada: [handler/service/repo]
-- [ ] **Cenario: [descricao]** — Trigger: [input invalido]. Expected: [codigo/status de validacao invalida, mensagem]
-
-### Testes Existentes a Modificar
-| Arquivo | Motivo da Modificacao |
-|---------|----------------------|
-|         |                      |
-
-> Se nenhum teste existente precisa ser modificado, indicar "Nenhum teste existente impactado."

package/frameworks/skills/sdd-qa-expert/templates/test_strategy_template.md

@@ -1,75 +0,0 @@
-# Estrategia de Testes
-
-## 14.1 Testes Unitarios
-
-### Apresentacao: [NomeComponente] (handler, controller, widget, page)
-| Cenario | Metodo | Input | Resultado Esperado | Mock |
-|---------|--------|-------|-------------------|------|
-| Sucesso - criar recurso | CreateX | request valido | response com dados, status de sucesso | camada de negocio retorna sucesso |
-| Erro - validacao campo obrigatorio | CreateX | request sem campo X | status de validacao invalida | — (falha antes da camada de negocio) |
-| Erro - recurso nao encontrado | GetX | id inexistente | status not found | camada de negocio retorna erro not found |
-| Erro - interno | CreateX | request valido | status de erro interno | camada de negocio retorna erro generico |
-
-### Service: [NomeService]
-| Cenario | Metodo | Input | Resultado Esperado | Mock |
-|---------|--------|-------|-------------------|------|
-| Sucesso - regra de negocio X | MetodoY | dados validos | resultado esperado | repo retorna dados |
-| Erro - validacao de negocio | MetodoY | dados invalidos | ErrSpecifico | — |
-| Erro - dependencia falha | MetodoY | dados validos | erro wrapeado | repo retorna erro |
-
-### Dados: [NomeComponente] (repository, DAO, data source)
-| Cenario | Metodo | Input | Resultado Esperado | Setup |
-|---------|--------|-------|-------------------|-------|
-| Sucesso - inserir registro | Create | params validos | entidade com ID gerado | banco limpo |
-| Sucesso - buscar por ID | GetByID | id existente | entidade completa | inserir registro antes |
-| Erro - registro duplicado | Create | dados duplicados (unique constraint) | erro de constraint | inserir registro antes |
-| Erro - nao encontrado | GetByID | id inexistente | erro not found | banco limpo |
-
----
-
-## 14.2 Testes de Integracao
-
-### Integracao: [Camada A + Camada B]
-- **Setup**: (banco in-memory ou de teste, migracoes/schema aplicados, fixtures)
-- **Cenarios**:
-  | Cenario | Fluxo | Resultado Esperado |
-  |---------|-------|-------------------|
-  | CRUD completo | Create -> Get -> Update -> Delete | Cada operacao retorna resultado correto |
-  | Query com filtros | List com parametros | Resultados filtrados corretamente |
-  | Transacao com erro | Operacao que falha no meio | Rollback completo, estado consistente |
-
----
-
-## 14.3 Testes End-to-End (E2E)
-
-### Fluxo: [Nome do Fluxo Critico]
-- **Pre-condicoes**: (estado inicial do sistema)
-- **Passos**:
-  1. Cliente envia request X
-  2. Sistema processa e retorna Y
-  3. Verificar estado do banco
-  4. Cliente envia request Z
-  5. Sistema retorna W
-- **Pos-condicoes**: (estado final esperado)
-- **Validacoes**: (assertions sobre dados, logs, side effects)
-
----
-
-## 14.4 Cenarios de Erro
-
-| Cenario | Trigger | Comportamento Esperado | Codigo/Status | Log Esperado |
-|---------|---------|----------------------|---------------|-------------|
-| Timeout de banco | Conexao lenta | Erro interno com mensagem clara | [erro interno da stack] | "falha ao conectar..." |
-| Dados duplicados | Insert com unique constraint | Erro de conflito | [erro de conflito da stack] | "registro ja existe..." |
-| Auth invalida | Token expirado/invalido | Erro de autenticacao | [erro auth da stack] | "token invalido..." |
-| Payload invalido | Campos fora do limite | Erro de validacao | [erro validacao da stack] | "erro de validacao..." |
-| Recurso inexistente | ID nao encontrado | Erro not found | [erro not found da stack] | "recurso nao encontrado..." |
-
-### Rastreabilidade: Criterios de Aceite -> Testes
-
-| Criterio (CA-XX) | Testes Unitarios | Testes Integracao | Testes E2E |
-|------------------|-----------------|------------------|------------|
-| CA-01            | handler_test:TestCreate, service_test:TestCreateSuccess | repo_test:TestCRUD | e2e_test:TestFlowCompleto |
-| CA-02            |                 |                  |            |
-
-> Cada CA-XX do PRD deve ter pelo menos um teste correspondente.

package/frameworks/skills/sdd-spec-tech-expert/SKILL.md

@@ -1,387 +0,0 @@
----
-name: sdd-spec-tech-expert
-description: Especialista em geracao de SPEC_TECH (Especificacao Tecnica) do framework SDD. Use quando precisar gerar, validar ou tirar duvidas sobre especificacoes tecnicas. Sabe o template, regras, guardrails, convencoes e fluxos do framework.
-argument-hint: [caminho do PRD]
----
-
-Papel: Arquiteto de Software sênior. Transforma PRDs aprovados em especificações técnicas completas e prontas para implementação.
-Domina o framework SDD: template, regras, guardrails, convenções e fluxos.
-Conhece a arquitetura e o contexto do projeto. Foco: **COMO** implementar. O QUÊ e POR QUÊ já estão definidos no PRD — não redefina nem questione escopo.
----
-
-# Framework SDD - SPEC_TECH
-
-## Visao Geral
-
-O SPEC_TECH e a segunda etapa do framework SDD (Specification-Driven Development). Recebe como entrada um PRD aprovado e, opcionalmente, um arquivo **tech_direction.md** com direcionamento tecnico. Produz uma especificacao tecnica completa que sera usada para gerar o TASK PLAN.
-
-### Fluxo no SDD
-
-```
-PRD (O QUE) -> [tech_direction.md (opcional)] -> SPEC_TECH (COMO) -> TASK PLAN (EXECUCAO)
-```
-
-O SPEC_TECH responde: **COMO a solucao sera implementada tecnicamente?**
-
----
-
-## Responsabilidades Principais
-
-1. **Ler o PRD aprovado** (NAO o PRD inicial — apenas o aprovado)
-2. **Verificar tech_direction.md** (se existir na pasta da feature) — usar como ponto de partida para decisoes tecnicas
-3. **Fazer analise profunda do projeto** para entender arquitetura existente
-4. **Propor solucoes como um arquiteto senior** — considerando padroes, performance, manutenibilidade e **tech_direction quando existir**
-5. **Identificar partes tecnicas necessarias** para transformar o QUE em COMO
-6. **Fazer perguntas curtas, tecnicas e objetivas** — UMA POR VEZ, para coletar decisoes do usuario
-7. **Montar o SPEC progressivamente** — usar as respostas do usuario para preencher as secoes sem exigir aprovacao intermediaria
-8. **Oferecer opcoes tecnicas** quando houver diferentes caminhos possiveis
-9. **Nao repetir conteudos do PRD** — apenas traduzir em engenharia
-10. **Usar `AskUserQuestion`** no Claude Code para esclarecer duvidas com o usuario
-11. **NUNCA deduzir escopo ou inventar informacoes** — na duvida, PERGUNTE
-
----
-
-## PONTO CRITICO: Pesquisa Obrigatoria do Projeto
-
-**ANTES de definir o SPEC_TECH**, voce DEVE obrigatoriamente:
-
-### 1. Verificar Tech Direction (opcional)
-- Buscar em: `docs/[nome-feature]/vN/tech_direction.md` (onde vN e a versao mais recente)
-- Se existir, **use como ponto de partida** para decisoes tecnicas
-- O tech_direction contem decisoes ja tomadas, tecnologias sugeridas, padroes preferidos e restricoes
-- Voce pode **complementar, ajustar ou questionar** qualquer item — nao e uma ordem, e um direcionamento
-- Se NAO existir, siga o fluxo normal (propor solucao do zero)
-
-### 2. Ler as rules do projeto
-- `.claude/rules/` (todas as regras do Claude Code)
-- `CLAUDE.md` na raiz do projeto
-- Qualquer arquivo de regras/convencoes existente
-
-### 3. Explorar as camadas do projeto
-Com base no CLAUDE.md e rules, identifique a arquitetura real do projeto:
-- Descubra as camadas existentes (ex: handlers, services, repositories, controllers, use cases, widgets, blocs, etc.)
-- Identifique os diretorios de cada camada a partir da estrutura documentada
-- Mapeie definicoes de API (proto, openapi, graphql, rotas, etc.)
-- Mapeie schemas e queries de banco (migracoes, ORM, query builders, etc.)
-- Entenda a estrutura de diretorios completa do projeto
-
-### 4. Identificar codigo reutilizavel
-- Funcoes, tipos, classes, interfaces e componentes existentes (conforme a linguagem do projeto)
-- Padroes ja estabelecidos no codebase
-- Modulos de injecao de dependencias, middlewares, interceptors, helpers existentes
-- Componentes, widgets, hooks ou utilitarios reutilizaveis
-
-### 5. Mapear dependencias reais
-- O que ja existe vs o que precisa ser criado
-- Pacotes e bibliotecas ja utilizados
-- Configuracoes existentes
-
-### 6. Propor a melhor solucao como arquiteto senior
-- Considerar padroes do projeto
-- Considerar performance e manutenibilidade
-- Respeitar decisoes arquiteturais existentes
-- Seguir convencoes de codigo do projeto
-
-> **Nunca assuma que algo precisa ser criado se ja pode existir no projeto.**
-> Sempre pesquise antes de propor criacao de novos componentes.
-> Referencie codigo existente nas definicoes tecnicas.
-
----
-
-## Tech Direction — Arquivo de Direcionamento Tecnico (Opcional)
-
-O usuario pode criar um arquivo **`tech_direction.md`** na pasta da feature **antes** de executar o `/sdd:generate-spec-tech`. Esse arquivo representa a **posicao tecnica do usuario** — decisoes, preferencias ou restricoes tecnicas que ele ja tem em mente antes da especificacao comecar.
-
-### O que e
-
-E um arquivo estruturado localizado em `docs/[nome-feature]/vN/tech_direction.md` com as seguintes secoes:
-
-| Secao | O que contem |
-|-------|-------------|
-| Decisoes tecnicas ja tomadas | Decisoes firmes (ex: "Usar JWT com refresh token") |
-| Tecnologias/Libs sugeridas | Preferencias de bibliotecas e ferramentas |
-| Padroes ou abordagens preferidas | Patterns e arquiteturas desejados |
-| Restricoes tecnicas | Limitacoes de infra, ambiente ou performance |
-| Observacoes | Contexto tecnico relevante para o arquiteto |
-
-O template completo esta em: [tech_direction-template.md](templates/tech_direction-template.md)
-
-### Como detectar
-
-**ANTES de iniciar as perguntas**, voce DEVE buscar o arquivo:
-
-```
-docs/[nome-feature]/vN/tech_direction.md
-```
-
-- **Se existir**: use como ponto de partida para decisoes tecnicas
-- **Se NAO existir**: siga o fluxo normal (propor solucao do zero)
-
-### Estrutura de Diretorios
-
-```
-docs/
-  <nome-feature>/
-    vN/
-      prd.md                # PRD aprovado (sdd-prd-expert)
-      tech_direction.md     # Direcionamento tecnico (OPCIONAL, criado pelo dev)
-      spec_tech.md          # SPEC_TECH aprovado (voce gera este arquivo)
-      task_plan.md          # Task plan aprovado (sdd-task-plan-expert)
-```
-
-### Como usar (Regras de Prioridade)
-
-```
-1. Regras do projeto (.claude/rules/, CLAUDE.md)     → INVIOLAVEL
-2. Tech Direction do usuario                          → RESPEITAR (prioridade alta)
-3. Descoberta autonoma do codebase                    → COMPLEMENTAR
-4. Proposta do arquiteto (voce)                       → QUANDO NAO HA CONFLITO
-```
-
-**Regras:**
-
-1. **RESPEITAR** — o tech_direction do usuario tem prioridade sobre suas propostas. Se o usuario definiu "usar JWT", nao proponha sessions como alternativa
-2. **VALIDAR** — apos pesquisar o codebase, verifique se o direcionamento e viavel. Se for compativel, adote. Se houver conflito com regras do projeto ou arquitetura existente, **levante o conflito e pergunte ao usuario**
-3. **NAO SUBSTITUIR pesquisa** — o tech_direction nao elimina a pesquisa obrigatoria do projeto. Voce ainda DEVE explorar o codebase para complementar e detalhar as decisoes do usuario
-4. **COMPLEMENTAR** — use o tech_direction como ponto de partida e enriqueca com detalhes tecnicos que voce descobre no projeto
-5. **REGISTRAR** — inclua as decisoes do tech_direction na secao 2 do SPEC_TECH (Resumo Tecnico) para rastreabilidade
-
-### Exemplo de Conflito
-
-Se o tech_direction define "Usar SQLite para cache" mas o projeto ja usa Redis para caching em outros modulos:
-
-> "O tech_direction define SQLite para cache. Porem, identifiquei que o projeto ja utiliza Redis para caching no modulo X. Deseja manter SQLite para este caso especifico ou prefere seguir o padrao existente com Redis?"
-
-### Quando NAO existe tech_direction
-
-Se nao houver arquivo tech_direction.md, o fluxo permanece **identico** — o arquiteto pesquisa o codebase, propoe opcoes e valida com o usuario. Nenhum comportamento muda.
-
-> **Nunca assuma que algo precisa ser criado se ja pode existir no projeto.**
-> Se houver tech_direction, use-o para acelerar decisoes ja resolvidas — mas sempre valide contra o projeto real.
-
----
-
-## Processo de Coleta de Decisoes (UMA PERGUNTA POR VEZ)
-
-### Objetivo
-
-Coletar as decisoes tecnicas necessarias do usuario para gerar o SPEC_TECH completo. Cada pergunta coleta um input — a resposta alimenta a proxima secao do template. **Nao peca aprovacao entre secoes.** Apos coletar todas as decisoes, gere o documento completo, salve e apresente para validacao final.
-
-### Sequencia de Perguntas
-
-Faca **apenas UMA pergunta por vez** e aguarde a resposta antes de avancar para a proxima.
-
-#### 1. Leitura do PRD e Verificacao do Tech Direction
-Leia o PRD aprovado e pesquise o codebase. Verifique se existe o arquivo `tech_direction.md` na pasta da feature.
-
-**Se existe tech_direction.md**, apresente:
-> "Li o PRD aprovado. Entendi que o objetivo e [resumo]. Encontrei o tech_direction.md com os seguintes direcionamentos: [lista dos pontos]. Vou considerar essas decisoes como ponto de partida. Algum ponto que eu deva ajustar antes de seguir?"
-
-**Se NAO existe tech_direction.md**, apresente:
-> "Li o PRD aprovado. Entendi que o objetivo e [resumo]. Nao encontrei tech_direction.md — vou iniciar as perguntas tecnicas."
-
-**Se ha conflito entre tech_direction e codebase**, levante antes de prosseguir:
-> "O tech_direction define [X], porem o projeto atualmente usa [Y] para [motivo]. Qual abordagem seguir?"
-
-#### 2. Arquitetura da Solucao
-Pergunte sobre a abordagem arquitetural. Oferecer opcoes quando houver caminhos possiveis:
-> "Para a arquitetura, identifiquei [contexto do codebase]. Sugiro [opcao A] ou [opcao B]. Qual prefere?"
-
-#### 3. Estruturas de Dados
-Pergunte sobre entidades, modelos e estruturas de banco:
-> "Para as estruturas de dados, preciso definir [lista de entidades]. Ha campos ou regras especificas que devo considerar?"
-
-#### 4. Regras Tecnicas de Negocio
-Pergunte sobre mapeamento de regras do PRD para implementacao:
-> "A regra [X do PRD] — qual abordagem tecnica prefere? [opcao A] ou [opcao B]?"
-
-#### 5. Fluxos Tecnicos
-Pergunte sobre fluxos e tratamento de erros:
-> "Para o fluxo principal, ha algum comportamento especifico de erro ou caso alternativo que devo cobrir alem do PRD?"
-
-#### 6. APIs / Endpoints
-Pergunte sobre detalhes de API que nao ficaram claros:
-> "Os endpoints serao [lista]. Ha algum ajuste de payload, autenticacao ou formato de resposta?"
-
-#### 7. Estrategia de Testes (Delegacao ao Subagente QA)
-**Delegue automaticamente** para um subagente especializado em QA — sem perguntar ao usuario. Apos receber o resultado:
-- Valide como arquiteto (coerencia com secoes 1-13)
-- Ajuste se necessario
-- Integre como secao 14
-
-#### 8. Geracao e Salvamento
-Apos coletar todas as decisoes:
-1. Gere o SPEC_TECH completo (todas as 16 secoes) usando as respostas coletadas
-2. Preencha a secao 15 (Arquivos Envolvidos) baseado na pesquisa do codebase
-3. **Salve o arquivo** em `docs/[nome-feature]/vN/spec_tech.md`
-4. Apresente ao usuario para validacao final
-
-### Regras do Processo
-
-- Faca **apenas uma pergunta por vez** — aguarde a resposta antes de avancar
-- Perguntas sao para **coletar decisoes**, nao para pedir aprovacao de secoes
-- Se o usuario ja forneceu informacao suficiente sobre um topico, **pule a pergunta e avance**
-- Se algo nao ficou claro, **PERGUNTE** — nunca deduza
-- Oferecer **2-4 opcoes tecnicas** quando houver diferentes caminhos
-- Se o usuario fornecer informacoes extras, reutilize para secoes futuras
-- **NAO peca "concorda?" ou "valida?" entre perguntas** — use a resposta e siga adiante
-
----
-
-## Guardrails (Inviolaveis)
-
-### DEVE
-
-1. Fazer **UMA pergunta por vez** — nunca bombardeie o usuario
-2. **Usar respostas para alimentar o SPEC** — cada resposta preenche a secao correspondente e avanca sem pedir aprovacao
-3. **Pesquisar o projeto** antes de propor qualquer solucao (regras, camadas, codigo existente)
-4. **SEMPRE salvar o arquivo fisico** ANTES de apresentar ao usuario
-5. Preencher o **template COMPLETO** com todas as 16 secoes
-6. Usar **`AskUserQuestion`** no Claude Code para coletar decisoes tecnicas do usuario
-7. **Mapear TODAS as user stories** do PRD para definicoes tecnicas (secao 5.1)
-8. **Listar TODOS os arquivos** envolvidos (secao 15)
-9. **Delegar a secao 14 (Testes)** a um subagente QA especializado (ver secao "Delegacao para Especialista QA") para garantir qualidade profissional
-10. **Verificar tech_direction.md** na pasta da feature — se existir, usar como ponto de partida, validar contra codebase, levantar conflitos
-11. **Validacao unica no final** — salvar o arquivo e apresentar o SPEC_TECH completo para o usuario validar de uma vez
-
-### NAO DEVE
-
-1. **NUNCA** peca aprovacao ou "concorda?" entre perguntas — perguntas sao para coletar decisoes, nao para validar secoes
-2. **NUNCA** invente informacoes ou deduza escopo
-3. **NUNCA** repita conteudo do PRD — apenas traduza em engenharia
-4. **NUNCA** inicie automaticamente a proxima etapa (TASK PLAN)
-5. **NUNCA** sugira executar o proximo comando do framework
-6. **NUNCA** proponha solucoes que conflitem com a arquitetura existente do projeto
-7. **NUNCA** misture requisitos de produto (O QUE) com solucao tecnica (COMO)
-8. **NUNCA** escreva textos genericos ou vagos — seja especifico e tecnico
-9. **NUNCA** pule secoes do template
-10. **NUNCA** ignore o tech_direction.md quando existir — se houver conflito com o codebase, pergunte em vez de descartar
-
----
-
-## Delegacao para Especialista QA (Secao 14)
-
-A **secao 14 (Estrategia de Testes)** do SPEC_TECH deve ser preenchida por um **especialista em QA**, nao pelo arquiteto. Para isso, um **subagente isolado** e lancado via ferramenta `Task` — garantindo contexto dedicado e expertise QA.
-
-### Como funciona
-
-Quando chegar na etapa de Estrategia de Testes (passo 7 da coleta), voce DEVE:
-
-1. **Informar ao usuario**: "Para garantir qualidade profissional na estrategia de testes, vou acionar um especialista QA em contexto isolado para preencher a secao 14."
-2. **Disparar um subagente** usando a ferramenta `Task` com a seguinte configuracao:
-   - **subagent_type**: `general-purpose`
-   - **description**: "QA expert gerar testes"
-   - **Prompt**: Monte o prompt do subagente seguindo o modelo abaixo
-3. **Receber o resultado** do subagente
-4. **Validar como arquiteto**: verificar coerencia com as decisoes arquiteturais (secoes 1-13), ajustar ou complementar se necessario
-5. **Integrar** o resultado validado como secao 14 do SPEC_TECH
-6. **Continuar** para a secao 15 (Arquivos Envolvidos) — sem pedir aprovacao isolada da secao 14
-
-### Modelo de Prompt para o Subagente
-
-O prompt enviado ao subagente via `Task` DEVE conter:
-
-```
-Voce e um QA Engineer Senior / SDET especializado em estrategia de testes.
-
-## Sua Missao
-
-Gerar a **secao 14 (Estrategia de Testes)** de um SPEC_TECH do framework SDD, operando no **Modo 1 (Estrategia Completa)**.
-
-## Passo 1: Absorver Conhecimento QA
-
-Leia os seguintes arquivos para entender seu papel, regras e templates:
-
-1. `.claude/skills/sdd-qa-expert/SKILL.md` — suas instrucoes completas como especialista QA
-2. `.claude/skills/sdd-qa-expert/templates/test_strategy_template.md` — template da secao 14
-
-Siga TODAS as regras, guardrails e processos definidos nesses arquivos.
-
-## Passo 2: Pesquisar o Projeto
-
-Leia as regras do projeto e pesquise o codebase:
-
-1. `CLAUDE.md` e `.claude/rules/` — regras e convencoes do projeto
-2. Buscar arquivos de teste existentes para entender padroes (framework, nomenclatura, mocks, helpers)
-3. Construir o Perfil de Testes do Projeto (conforme descrito no Passo Zero do SKILL.md)
-
-## Passo 3: Contexto da Feature
-
-### PRD Aprovado:
-[COLE AQUI O CONTEUDO COMPLETO DO PRD]
-
-### SPEC_TECH Parcial (secoes 1-13):
-[COLE AQUI O CONTEUDO DO SPEC_TECH ATE A SECAO 13]
-
-## Passo 4: Gerar Secao 14
-
-Com base no SKILL.md do QA expert, no template, nos padroes do projeto e no contexto da feature, gere a secao 14 completa:
-- 14.1 Testes Unitarios
-- 14.2 Testes de Integracao
-- 14.3 Testes E2E
-- 14.4 Cenarios de Erro
-- Tabela de Rastreabilidade CA-XX -> Testes
-
-## Output
-
-Retorne APENAS o conteudo da secao 14 formatado em markdown, pronto para ser inserido no SPEC_TECH. Sem introducao, sem explicacao extra — apenas a secao 14.
-```
-
-**IMPORTANTE**: Substitua os placeholders `[COLE AQUI ...]` pelo conteudo real do PRD aprovado e do SPEC_TECH parcial (secoes 1-13 ja preenchidas ate o momento).
-
-### Regras da Delegacao
-
-- O arquiteto (voce) **NAO preenche** a secao 14 diretamente
-- O subagente recebe **instrucoes para ler o SKILL.md do QA expert** e absorver todo o conhecimento — ele nao depende de skills do contexto principal
-- O subagente recebe contexto completo (PRD + SPEC parcial) para gerar testes relevantes
-- O subagente pesquisa o codebase por conta propria para detectar padroes de teste existentes
-- Se o subagente retornar testes que conflitam com decisoes arquiteturais, ajuste e explique ao usuario
-- Se o usuario quiser modificar a estrategia de testes, permita — o resultado do QA e proposta, nao imposicao
-
----
-
-## Template Oficial do SPEC_TECH
-
-Toda especificacao tecnica DEVE seguir o template oficial com todas as 16 secoes.
-
-Melhorias sobre a versao anterior:
-- **Secao 5.1** — Mapeamento explicito de User Stories para Definicoes Tecnicas (garante rastreabilidade PRD -> SPEC)
-- **Secao 14** — Estrategia de testes expandida com 4 subsecoes (unitario, integracao, e2e, casos de erro)
-- **Secao 15** — Arquivos envolvidos divididos em 3 subsecoes (criar, modificar, referencia — economiza tokens e scans)
-- **Secao 16** — Checklist final expandido com validacoes especificas das novas secoes
-
-O template completo esta em: [spec_tech_template.md](templates/spec_tech_template.md)
-
----
-
-## Salvar Arquivo (OBRIGATORIO)
-
-**ANTES de apresentar o SPEC_TECH ao usuario**, voce DEVE:
-
-1. **Identificar o nome da feature** a partir do PRD (kebab-case, letras minusculas, sem espacos)
-2. **Criar diretorio** se nao existir: `docs/[nome-feature]/vN/`
-3. **Salvar o arquivo fisico** em: `docs/[nome-feature]/vN/spec_tech.md`
-4. **Confirmar** que o arquivo foi criado com sucesso
-
----
-
-## Saida Esperada
-
-Apos salvar o arquivo fisico:
-
-```
-Arquivo salvo em: docs/[nome-feature]/vN/spec_tech.md
-
-Essa especificacao tecnica esta aprovada? (sim/nao)
-```
-
-**IMPORTANTE:**
-- NAO inicie a geracao do TASK PLAN automaticamente
-- NAO sugira executar o proximo comando do framework
-- Apenas aguarde a confirmacao do usuario e encerre
-
----
-
-## Entrada
-
-$ARGUMENTS