@brunosps00/dev-workflow 0.4.1 → 0.4.3

package/lib/constants.js

@@ -1,7 +1,7 @@
 const COMMANDS = {
   en: [
     { name: 'dw-analyze-project', description: 'Analyze repository stack, patterns, and conventions to generate project rules' },
-    { name: 'dw-autopilot', description: 'Full pipeline orchestrator: from a wish to a PR with minimal intervention (research, PRD, tasks, execution, QA, review, commit)' },
+    { name: 'dw-autopilot', description: 'Full pipeline orchestrator from a wish to a PR with minimal intervention (research, PRD, tasks, execution, QA, review, commit)' },
     { name: 'dw-brainstorm', description: 'Explore ideas and directions before starting implementation' },
     { name: 'dw-bugfix', description: 'Analyze and fix bugs with automatic triage (bug vs feature vs scope)' },
     { name: 'dw-code-review', description: 'Formal code review (Level 3) with persisted report' },
@@ -26,7 +26,7 @@ const COMMANDS = {
   ],
   'pt-br': [
     { name: 'dw-analyze-project', description: 'Analisa stack, patterns e convencoes do repositorio para gerar regras do projeto' },
-    { name: 'dw-autopilot', description: 'Orquestrador completo: de um desejo ate o PR com minima intervencao (pesquisa, PRD, tasks, execucao, QA, review, commit)' },
+    { name: 'dw-autopilot', description: 'Orquestrador completo de um desejo ate o PR com minima intervencao (pesquisa, PRD, tasks, execucao, QA, review, commit)' },
     { name: 'dw-brainstorm', description: 'Explorar ideias e direcoes antes de comecar a implementacao' },
     { name: 'dw-bugfix', description: 'Analisar e corrigir bugs com triagem automatica (bug vs feature vs escopo)' },
     { name: 'dw-code-review', description: 'Code review formal (Nivel 3) com relatorio persistido' },
@@ -56,7 +56,7 @@ const PLATFORMS = {
     dir: '.claude/skills',
     wrapperTemplate: (name, description) => `---
 name: ${name}
-description: ${description}
+description: "${description.replace(/"/g, '\\"')}"
 ---
 
 Read and follow ALL instructions in \`.dw/commands/${name}.md\`.
@@ -66,7 +66,7 @@ Read and follow ALL instructions in \`.dw/commands/${name}.md\`.
     dir: '.agents/skills',
     wrapperTemplate: (name, description) => `---
 name: ${name}
-description: ${description}
+description: "${description.replace(/"/g, '\\"')}"
 ---
 <system_instructions>
 Source of truth: \`.dw/commands/${name}.md\`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brunosps00/dev-workflow",
-  "version": "0.4.1",
+  "version": "0.4.3",
   "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-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-redesign-ui.md

@@ -4,6 +4,7 @@ You are a frontend redesign specialist for the current workspace. This command e
 <critical>Do NOT redesign without first auditing the current implementation. Always read the code and capture the visual state before proposing changes.</critical>
 <critical>ALWAYS propose design directions and wait for user approval before implementing any changes.</critical>
 <critical>Preserve existing functionality. Redesign is visual/UX, not behavioral. If the change alters behavior, redirect to `/dw-create-prd`.</critical>
+<critical>MOBILE FIRST is MANDATORY. Every design proposal MUST include both mobile AND desktop versions. Implementation MUST start with mobile and then adapt for desktop. Do NOT present only the desktop layout — if the proposal does not show how it looks on mobile, it is incomplete.</critical>
 
 ## When to Use
 - Use for rebuild/modernization of existing pages or components
@@ -57,10 +58,10 @@ Use diagnostic tools based on the project's framework:
 1. Identify the target: page, component, or route to be redesigned.
 2. **AUDIT**: read the current implementation, identify the CSS stack (Tailwind, CSS Modules, styled-components, etc.), capture screenshot if `webapp-testing` is available, run react-doctor if React project.
 3. Ask 3 to 5 questions about redesign goals: style direction, brand constraints, inspirations, target audience, priority devices.
-4. **PROPOSE**: present 2 to 3 design directions using `ui-ux-pro-max` — each with color palette, typography pairing, layout style, and rationale.
+4. **PROPOSE**: present 2 to 3 design directions using `ui-ux-pro-max` — each with color palette, typography pairing, layout style, and rationale. For EACH direction, explicitly describe the mobile layout (<=768px) and desktop layout (>=1024px), including how elements reorganize, stack, or hide between breakpoints.
 5. Wait for explicit user approval before implementing.
-6. **IMPLEMENT**: apply the chosen design respecting the existing stack. Use `vercel-react-best-practices` for React/Next.js. Maintain the project's CSS methodology.
-7. **VALIDATE**: capture after-state, compare before/after, verify accessibility (WCAG 2.2 via `ui-ux-pro-max`), run react-doctor `--diff` if React.
+6. **IMPLEMENT**: apply the chosen design with a mobile-first approach — implement the mobile layout first, then add media queries/breakpoints for tablet and desktop. Respect the existing stack. Use `vercel-react-best-practices` for React/Next.js. Maintain the project's CSS methodology.
+7. **VALIDATE**: capture after-state in BOTH resolutions (mobile and desktop), compare before/after, verify accessibility (WCAG 2.2 via `ui-ux-pro-max`), run react-doctor `--diff` if React. If `webapp-testing` is available, capture screenshots at 375px viewport (mobile) and 1440px viewport (desktop).
 8. **PERSIST CONTRACT**: if the user approved a direction, generate `design-contract.md` in the PRD directory (`.dw/spec/prd-[name]/design-contract.md`) with: approved direction, color palette, typography pairing, layout rules, accessibility rules, and component rules. This contract will be read by `dw-run-task` and `dw-run-plan` to ensure visual consistency.
 
 ## GSD Integration
@@ -107,7 +108,8 @@ If GSD is NOT installed:
 - Prefer incremental changes that can be reviewed visually
 - When in doubt about style direction, ask — don't assume
 - If the page has no tests, flag regression risk before changing
-- Mobile responsiveness is mandatory unless explicitly scoped out by the user
+- Mobile-first is the default — implement mobile first, adapt for desktop after
+- Validate at least 2 breakpoints: mobile (375px) and desktop (1440px)
 - In Angular projects, respect Angular component patterns (style encapsulation, ViewEncapsulation)
 
 ## Useful Outputs

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`
@@ -216,7 +222,20 @@ Use `browser_snapshot` to verify labels and semantic structure.
 - Capture screenshots of main screens with `browser_take_screenshot` and save to `{{PRD_PATH}}/QA/screenshots/`
 - Check layouts in different states (empty, with data, error, loading)
 - Document visual inconsistencies found
-- Check responsiveness if applicable (different viewports)
+
+### 6.1. Mobile Validation (Required)
+
+<critical>ALL visual checks MUST include tests at mobile viewport (375px) IN ADDITION to desktop (1440px). QA approval REQUIRES that BOTH resolutions are functional and visually acceptable. If the mobile layout is broken, unusable, or visually degraded, QA CANNOT be approved.</critical>
+
+- Capture screenshots at 375px viewport (mobile) for EACH tested screen
+- Capture screenshots at 1440px viewport (desktop) for comparison
+- Verify: elements do not overlap, text is readable, buttons are tappable (min 44x44px), no horizontal scroll, forms are usable
+- Save screenshots with suffix: `[screen]-mobile.png` and `[screen]-desktop.png`
+
+If mobile FAILS visual validation:
+- Document issues in `{{PRD_PATH}}/QA/bugs.md` with severity **High** and tag `[MOBILE]`
+- In the final report, recommend `/dw-redesign-ui` as the next step to fix the mobile layout with a mobile-first approach
+- QA CANNOT be approved with broken mobile
 
 ### 7. Bug Documentation (If issues found)
 

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-redesign-ui.md

@@ -4,6 +4,7 @@ Você é um especialista em redesign de frontend para o workspace atual. Este co
 <critical>NÃO redesenhe sem antes auditar a implementação atual. Sempre leia o código e capture o estado visual antes de propor mudanças.</critical>
 <critical>SEMPRE proponha direções de design e espere aprovação do usuário antes de implementar qualquer mudança.</critical>
 <critical>Preserve a funcionalidade existente. Redesign é visual/UX, não comportamental. Se a mudança alterar comportamento, redirecione para `/dw-create-prd`.</critical>
+<critical>MOBILE FIRST é OBRIGATÓRIO. Toda proposta de design DEVE incluir versão mobile E desktop. A implementação DEVE começar pelo mobile e depois adaptar para desktop. NÃO apresente apenas o layout desktop — se a proposta não mostrar como fica no mobile, está incompleta.</critical>
 
 ## Quando Usar
 - Use para rebuild/modernização visual de páginas ou componentes existentes
@@ -57,10 +58,10 @@ Utilize ferramentas de diagnóstico conforme o framework do projeto:
 1. Identifique o alvo: página, componente ou rota que será redesenhada.
 2. **AUDITAR**: leia a implementação atual, identifique stack CSS (Tailwind, CSS Modules, styled-components, etc.), capture screenshot se `webapp-testing` disponível, rode react-doctor se projeto React.
 3. Faça 3 a 5 perguntas sobre objetivos do redesign: direção de estilo, constraints de marca, inspirações, público-alvo, dispositivos prioritários.
-4. **PROPOR**: apresente 2 a 3 direções de design usando `ui-ux-pro-max` — cada uma com paleta de cores, par tipográfico, estilo de layout e racional.
+4. **PROPOR**: apresente 2 a 3 direções de design usando `ui-ux-pro-max` — cada uma com paleta de cores, par tipográfico, estilo de layout e racional. Para CADA direção, descreva explicitamente o layout mobile (<=768px) e o layout desktop (>=1024px), incluindo como os elementos se reorganizam, empilham ou escondem entre breakpoints.
 5. Espere aprovação explícita do usuário antes de implementar.
-6. **IMPLEMENTAR**: aplique o design escolhido respeitando a stack existente. Use `vercel-react-best-practices` para React/Next.js. Mantenha a metodologia CSS do projeto.
-7. **VALIDAR**: capture estado depois, compare antes/depois, verifique acessibilidade (WCAG 2.2 via `ui-ux-pro-max`), rode react-doctor `--diff` se React.
+6. **IMPLEMENTAR**: aplique o design escolhido com abordagem mobile-first — implemente primeiro o layout mobile e depois adicione media queries/breakpoints para tablet e desktop. Respeite a stack existente. Use `vercel-react-best-practices` para React/Next.js. Mantenha a metodologia CSS do projeto.
+7. **VALIDAR**: capture estado depois em AMBAS as resoluções (mobile e desktop), compare antes/depois, verifique acessibilidade (WCAG 2.2 via `ui-ux-pro-max`), rode react-doctor `--diff` se React. Se `webapp-testing` disponível, capture screenshots em viewport 375px (mobile) e 1440px (desktop).
 8. **PERSISTIR CONTRATO**: se o usuário aprovou uma direção, gere `design-contract.md` no diretório do PRD (`.dw/spec/prd-[nome]/design-contract.md`) com: direção aprovada, paleta de cores, par tipográfico, regras de layout, regras de acessibilidade e regras de componentes. Este contrato será lido por `dw-run-task` e `dw-run-plan` para garantir consistência visual.
 
 ## Integração GSD
@@ -107,7 +108,8 @@ Se o GSD NÃO estiver instalado:
 - Prefira mudanças incrementais que possam ser revisadas visualmente
 - Quando em dúvida sobre direção de estilo, pergunte — não assuma
 - Se a página não tem testes, sinalize risco de regressão antes de alterar
-- Responsividade mobile é mandatória salvo escopo explícito do usuário
+- Mobile-first é o padrão — implemente mobile primeiro, adapte para desktop depois
+- Valide em pelo menos 2 breakpoints: mobile (375px) e desktop (1440px)
 - Em projetos Angular, respeite os padrões de componentes do Angular (encapsulação de estilos, ViewEncapsulation)
 
 ## Saídas Úteis

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`
@@ -216,7 +222,20 @@ Use `browser_snapshot` para verificar labels e estrutura semântica.
 - Capturar screenshots das telas principais com `browser_take_screenshot` e salvar em `{{PRD_PATH}}/QA/screenshots/`
 - Verificar layouts em diferentes estados (vazio, com dados, erro, loading)
 - Documentar inconsistências visuais encontradas
-- Verificar responsividade se aplicável (diferentes viewports)
+
+### 6.1. Validação Mobile (Obrigatório)
+
+<critical>TODA verificação visual DEVE incluir testes em viewport mobile (375px) ALÉM do desktop (1440px). A aprovação do QA REQUER que AMBAS as resoluções estejam funcionais e visualmente aceitáveis. Se o layout mobile estiver quebrado, inutilizável ou visualmente degradado, o QA NÃO pode ser aprovado.</critical>
+
+- Capture screenshots em viewport 375px (mobile) para CADA tela testada
+- Capture screenshots em viewport 1440px (desktop) para comparação
+- Verifique: elementos não se sobrepõem, texto é legível, botões são clicáveis (min 44x44px), scroll horizontal não existe, formulários são usáveis
+- Salve screenshots com sufixo: `[tela]-mobile.png` e `[tela]-desktop.png`
+
+Se o mobile FALHAR na validação visual:
+- Documente os problemas em `{{PRD_PATH}}/QA/bugs.md` com severidade **Alta** e tag `[MOBILE]`
+- No relatório final, recomende `/dw-redesign-ui` como próximo passo para corrigir o layout mobile com abordagem mobile-first
+- O QA NÃO pode ser aprovado com mobile quebrado
 
 ### 7. Documentação de Bugs (Se encontrar problemas)