@brunosps00/dev-workflow 0.4.0 → 0.4.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brunosps00/dev-workflow",
-  "version": "0.4.0",
+  "version": "0.4.2",
   "description": "AI-driven development workflow commands for any project. Scaffolds a complete PRD-to-PR pipeline with multi-platform AI assistant support.",
   "bin": {
     "dev-workflow": "./bin/dev-workflow.js"

package/scaffold/en/commands/dw-autopilot.md

@@ -56,18 +56,23 @@ Evaluate whether the topic requires deep research:
 
 If executed, use `standard` mode by default. Incorporate findings into subsequent steps.
 
-### Step 3: Brainstorm
+### Step 3: Brainstorm (Interactive)
 
 Run `/dw-brainstorm` with accumulated context (intel + research).
 - Generate 3 directions
 - Automatically converge on the most pragmatic option for the project context
 - Do NOT wait for user approval (brainstorm is automatic in autopilot)
 
-### Step 4: PRD
+### Step 4: PRD (Interactive — 7+ Questions)
+
+<critical>The PRD MUST include an interactive interview with the user. Ask AT LEAST 7 clarification questions BEFORE writing the PRD. Do NOT answer questions automatically based on context — the user MUST respond.</critical>
 
 Run `/dw-create-prd` using brainstorm findings.
-- Follow all command instructions (clarification questions answered based on accumulated context)
-- Generate the complete PRD in `.dw/spec/prd-[name]/prd.md`
+- Follow ALL command instructions, especially the clarification questions section
+- Ask at least 7 questions about: problem, target users, critical features, scope, constraints, design, integration
+- In each question, present a recommendation grounded in brainstorm and deep-research findings (if executed). E.g.: "Based on the research, I recommend X because [evidence]. Do you agree or prefer a different direction?"
+- Wait for user responses to each question
+- Only after receiving all responses, write the complete PRD in `.dw/spec/prd-[name]/prd.md`
 
 ### === GATE 1: PRD Approval ===
 
@@ -78,11 +83,16 @@ Present to the user:
 
 **Wait for explicit approval.** If the user requests changes, adjust and re-present.
 
-### Step 5: TechSpec
+### Step 5: TechSpec (Interactive — 7+ Questions)
+
+<critical>The TechSpec MUST include an interactive interview with the user. Ask AT LEAST 7 technical clarification questions BEFORE writing the TechSpec. Do NOT answer questions automatically — the user MUST respond.</critical>
 
 Run `/dw-create-techspec` from the approved PRD.
-- Follow all command instructions
-- Generate in `.dw/spec/prd-[name]/techspec.md`
+- Follow ALL command instructions, especially the clarification questions section
+- Ask at least 7 questions about: preferred architecture, existing vs new libs, testing strategy, integration with existing systems, infrastructure constraints, performance, security
+- In each question, present a technical recommendation grounded in brainstorm, deep-research, and approved PRD findings. E.g.: "Research indicated lib X has better performance for this case [source]. Want to use X or have another preference?"
+- Wait for user responses to each question
+- Only after receiving all responses, generate in `.dw/spec/prd-[name]/techspec.md`
 
 ### Step 6: Tasks
 
@@ -115,6 +125,16 @@ Run `/dw-run-plan` with the PRD path.
 
 ### Step 9: Implementation Review (Loop)
 
+<critical>BEFORE the PRD compliance review, run the project's build and lint. If they fail, fix and re-run until they pass. The implementation review CANNOT start with broken build or lint.</critical>
+
+Run the project's build and lint:
+1. Identify build and lint commands in `package.json` (scripts `build`, `lint`, `lint:fix`, `type-check`, etc.)
+2. Run lint with `--fix` enabled (e.g., `npm run lint -- --fix` or `npx eslint . --fix`) to auto-correct what's possible
+3. Run build (e.g., `npm run build` or `npx tsc --noEmit`)
+4. If any fail after `--fix`: analyze errors, fix manually, and re-run
+5. Repeat until both build AND lint pass without errors
+6. Only then proceed to the review
+
 Run `/dw-review-implementation` to verify PRD compliance (Level 2).
 - If gaps found: fix automatically and re-run the review
 - Maximum 3 correction cycles
@@ -134,6 +154,13 @@ If QA found bugs:
 
 ### Step 12: Implementation Review (Post-QA)
 
+<critical>BEFORE the post-QA review, run build and lint again with --fix. QA fixes may have introduced new issues.</critical>
+
+Run the project's build and lint (same sequence as Step 9):
+1. Lint with `--fix` enabled
+2. Build
+3. If any fail: fix and re-run until they pass
+
 Run `/dw-review-implementation` again to confirm QA fixes did not break PRD compliance.
 - If gaps found: fix and re-run
 - Maximum 3 cycles

package/scaffold/en/commands/dw-code-review.md

@@ -273,6 +273,20 @@ Save to `{{PRD_PATH}}/dw-code-review.md`:
 
 **REJECTED**: Tests failing, RFs not implemented, serious rules violations, security issues, or CRITICAL issues.
 
+## Next Steps by Status
+
+<critical>The suggested next step MUST match the review status. NEVER suggest /dw-fix-qa after code-review — that command is exclusively for bugs found by /dw-run-qa.</critical>
+
+- **APPROVED**: Suggest `/dw-commit` followed by `/dw-generate-pr`
+- **APPROVED WITH CAVEATS**: List the caveats. Suggest fixing the caveats, re-running build + lint with --fix, then re-running `/dw-code-review`
+- **REJECTED**: List the findings that caused rejection. The correct flow is:
+  1. Fix the findings listed in the report
+  2. Run build and lint with `--fix` until they pass
+  3. Re-run `/dw-code-review`
+  4. Repeat until APPROVED
+  - Do NOT suggest `/dw-fix-qa` (that is for visual QA bugs)
+  - Do NOT suggest `/dw-run-qa` before resolving code-review findings
+
 **Approval Decision Flow:**
 ```dot
 digraph approval {

package/scaffold/en/commands/dw-run-qa.md

@@ -97,7 +97,13 @@ Refer to `.dw/rules/` for project-specific URLs and frameworks.
   - `{{PRD_PATH}}/QA/screenshots/`
   - `{{PRD_PATH}}/QA/logs/`
   - `{{PRD_PATH}}/QA/scripts/`
-- Read `.dw/templates/qa-test-credentials.md` and choose the appropriate user/profile for the scenario
+<critical>BEFORE executing any test involving login or authentication, search for test credentials in the codebase. Look for (in priority order):
+1. `.dw/templates/qa-test-credentials.md`
+2. Any file with "credenciais", "credentials", "test-users", "test-accounts", "auth", "login", "usuarios-teste" in the name (recursive glob search)
+3. Environment variables in `.env.test`, `.env.local`, `.env.development`
+4. Documentation in README or docs/ mentioning test users
+If NO credentials are found, STOP and ask the user before continuing. Do NOT guess credentials or use fake data.</critical>
+- Choose the appropriate user/profile for the test scenario
 - Verify the application is running on localhost
 - Use `browser_navigate` from Playwright MCP to access the application
 - Confirm the page loaded correctly with `browser_snapshot`

package/scaffold/pt-br/commands/dw-autopilot.md

@@ -56,18 +56,23 @@ Avalie se o topico necessita de pesquisa profunda:
 
 Se executar, use modo `standard` por padrao. Incorpore os findings nas etapas seguintes.
 
-### Etapa 3: Brainstorm
+### Etapa 3: Brainstorm (Interativo)
 
 Execute `/dw-brainstorm` com o contexto acumulado (intel + pesquisa).
 - Gere 3 direcoes
 - Convirja automaticamente na opcao mais pragmatica para o contexto do projeto
 - NAO aguarde aprovacao do usuario (brainstorm e automatico no autopilot)
 
-### Etapa 4: PRD
+### Etapa 4: PRD (Interativo — 7+ Perguntas)
+
+<critical>O PRD DEVE incluir entrevista interativa com o usuario. Faca NO MINIMO 7 perguntas de esclarecimento ANTES de redigir o PRD. NAO responda as perguntas automaticamente com base no contexto — o usuario DEVE responder.</critical>
 
 Execute `/dw-create-prd` usando os findings do brainstorm.
-- Siga todas as instrucoes do comando (perguntas de esclarecimento respondidas com base no contexto acumulado)
-- Gere o PRD completo em `.dw/spec/prd-[nome]/prd.md`
+- Siga TODAS as instrucoes do comando, especialmente a secao de perguntas de esclarecimento
+- Faca pelo menos 7 perguntas ao usuario sobre: problema, usuarios-alvo, funcionalidades criticas, escopo, restricoes, design, integracao
+- Em cada pergunta, apresente uma recomendacao embasada nos findings do brainstorm e do deep-research (se executado). Ex: "Com base na pesquisa, recomendo X porque [evidencia]. Concorda ou prefere outra direcao?"
+- Aguarde as respostas do usuario para cada pergunta
+- So apos receber todas as respostas, redija o PRD completo em `.dw/spec/prd-[nome]/prd.md`
 
 ### ═══ GATE 1: Aprovacao do PRD ═══
 
@@ -78,11 +83,16 @@ Apresente ao usuario:
 
 **Aguarde aprovacao explicita.** Se o usuario pedir mudancas, ajuste e reapresente.
 
-### Etapa 5: TechSpec
+### Etapa 5: TechSpec (Interativo — 7+ Perguntas)
+
+<critical>O TechSpec DEVE incluir entrevista interativa com o usuario. Faca NO MINIMO 7 perguntas de esclarecimento tecnico ANTES de redigir o TechSpec. NAO responda as perguntas automaticamente — o usuario DEVE responder.</critical>
 
 Execute `/dw-create-techspec` a partir do PRD aprovado.
-- Siga todas as instrucoes do comando
-- Gere em `.dw/spec/prd-[nome]/techspec.md`
+- Siga TODAS as instrucoes do comando, especialmente a secao de perguntas de esclarecimento
+- Faca pelo menos 7 perguntas ao usuario sobre: arquitetura preferida, libs existentes vs novas, estrategia de testes, integracao com sistemas existentes, restricoes de infraestrutura, performance, seguranca
+- Em cada pergunta, apresente uma recomendacao tecnica embasada nos findings do brainstorm, deep-research e PRD aprovado. Ex: "A pesquisa indicou que a lib X tem melhor performance para este caso [fonte]. Quer usar X ou tem outra preferencia?"
+- Aguarde as respostas do usuario para cada pergunta
+- So apos receber todas as respostas, gere em `.dw/spec/prd-[nome]/techspec.md`
 
 ### Etapa 6: Tasks
 
@@ -115,6 +125,16 @@ Execute `/dw-run-plan` com o path do PRD.
 
 ### Etapa 9: Review de Implementacao (Loop)
 
+<critical>ANTES do review de PRD compliance, execute build e lint do projeto. Se falharem, corrija e re-execute ate passar. O review de implementacao NAO pode comecar com build ou lint quebrados.</critical>
+
+Execute build e lint do projeto:
+1. Identifique os comandos de build e lint em `package.json` (scripts `build`, `lint`, `lint:fix`, `type-check`, etc.)
+2. Execute lint com `--fix` habilitado (ex: `npm run lint -- --fix` ou `npx eslint . --fix`) para auto-corrigir o que for possivel
+3. Execute build (ex: `npm run build` ou `npx tsc --noEmit`)
+4. Se algum falhar apos o `--fix`: analise os erros, corrija manualmente, e re-execute
+5. Repita ate que build E lint passem sem erros
+6. So entao prossiga para o review
+
 Execute `/dw-review-implementation` para verificar PRD compliance (Level 2).
 - Se encontrar gaps: corrija automaticamente e re-execute o review
 - Maximo 3 ciclos de correcao
@@ -134,6 +154,13 @@ Se o QA encontrou bugs:
 
 ### Etapa 12: Review de Implementacao (Pos-QA)
 
+<critical>ANTES do review pos-QA, execute build e lint novamente com --fix. Correcoes do QA podem ter introduzido novos problemas.</critical>
+
+Execute build e lint do projeto (mesma sequencia da Etapa 9):
+1. Lint com `--fix` habilitado
+2. Build
+3. Se falhar: corrija e re-execute ate passar
+
 Execute `/dw-review-implementation` novamente para confirmar que as correcoes do QA nao quebraram PRD compliance.
 - Se encontrar gaps: corrija e re-execute
 - Maximo 3 ciclos

package/scaffold/pt-br/commands/dw-code-review.md

@@ -253,6 +253,20 @@ Salvar em `{{PRD_PATH}}/dw-code-review.md`:
 
 **REPROVADO**: Testes falhando, RFs não implementados, violação grave de rules, problemas de segurança, ou CRITICAL issues.
 
+## Próximos Passos por Status
+
+<critical>O próximo passo sugerido DEVE corresponder ao status do review. NUNCA sugira /dw-fix-qa após code-review — esse comando é exclusivo para bugs encontrados pelo /dw-run-qa.</critical>
+
+- **APROVADO**: Sugira `/dw-commit` seguido de `/dw-generate-pr`
+- **APROVADO COM RESSALVAS**: Liste as ressalvas. Sugira corrigir as ressalvas, re-executar build + lint com --fix, e então re-executar `/dw-code-review`
+- **REPROVADO**: Liste os findings que causaram a reprovação. O fluxo correto é:
+  1. Corrigir os findings listados no relatório
+  2. Executar build e lint com `--fix` até passar
+  3. Re-executar `/dw-code-review`
+  4. Repetir até APROVADO
+  - NÃO sugira `/dw-fix-qa` (esse é para bugs de QA visual)
+  - NÃO sugira `/dw-run-qa` antes de resolver os findings do code-review
+
 **Fluxo de Decisão de Aprovação:**
 ```dot
 digraph approval {

package/scaffold/pt-br/commands/dw-run-qa.md

@@ -97,7 +97,13 @@ Consulte `.dw/rules/` para URLs e frameworks específicos do projeto.
   - `{{PRD_PATH}}/QA/screenshots/`
   - `{{PRD_PATH}}/QA/logs/`
   - `{{PRD_PATH}}/QA/scripts/`
-- Ler `.dw/templates/qa-test-credentials.md` e escolher o usuário/perfil apropriado para o cenário
+<critical>ANTES de executar qualquer teste que envolva login ou autenticação, busque credenciais de teste no codebase. Procure por (em ordem de prioridade):
+1. `.dw/templates/qa-test-credentials.md`
+2. Qualquer arquivo com "credenciais", "credentials", "test-users", "test-accounts", "auth", "login", "usuarios-teste" no nome (busca recursiva com glob)
+3. Variáveis de ambiente em `.env.test`, `.env.local`, `.env.development`
+4. Documentação em README ou docs/ que mencione usuários de teste
+Se NENHUMA credencial for encontrada, PARE e pergunte ao usuário antes de continuar. NÃO tente adivinhar credenciais ou usar dados falsos.</critical>
+- Escolher o usuário/perfil apropriado para o cenário de teste
 - Verificar se a aplicação está rodando em localhost
 - Usar `browser_navigate` do Playwright MCP para acessar a aplicação
 - Confirmar que a página carregou corretamente com `browser_snapshot`