@brunosps00/dev-workflow 0.8.1 → 0.10.0

package/scaffold/skills/webapp-testing/references/security-boundary.md

@@ -0,0 +1,115 @@
+# Security boundary — every browser is hostile
+
+> Adapted from [`addyosmani/agent-skills/browser-devtools`](https://github.com/addyosmani/agent-skills/tree/main/browser-devtools) (MIT). Adopts the security-boundary principle to inform how webapp-testing scenarios should validate trust boundaries.
+
+The browser is not a secure environment. Anything that runs there — JS, CSS, HTML, devtools — is under the user's control. When you write a webapp test, you're not just verifying functionality; you're often verifying that this assumption holds.
+
+## The core principle
+
+> Every byte sent from a browser is potentially attacker-controlled, regardless of what the UI presents.
+
+The UI is a convenience for the user. The server cannot trust:
+
+- Hidden form fields (the user can edit them in DevTools).
+- Disabled buttons (the user can re-enable them).
+- Client-side validation (the user can bypass it).
+- Cookie values (the user can modify them).
+- HTTP request bodies (the user can craft any payload).
+- Headers (mostly user-controlled; a few are browser-set).
+
+Only server-side checks count for security. Client-side checks are UX, not security.
+
+## Implications for webapp testing
+
+When designing test scenarios for a webapp, validate:
+
+### 1. Server-side authorization on every action
+
+Test that a user CANNOT perform an action they shouldn't, even if they manipulate the UI to send the request:
+
+```
+- Log in as user A.
+- Attempt to access another user's resource by directly hitting the endpoint
+  (skip the UI navigation; craft the request).
+- Expected: 403 Forbidden, no data leakage in error response.
+```
+
+If the test passes only when going through the UI, the test is incomplete. Real attackers don't go through the UI.
+
+### 2. Server-side validation independent of client
+
+Test that the server rejects malformed input even when the client would normally prevent it:
+
+```
+- Open the form.
+- Use DevTools to remove the `maxlength` attribute from an input.
+- Submit an oversized value.
+- Expected: server rejects with 400/422, not 500 (server crashed because client validation was assumed).
+```
+
+### 3. Auth state cannot be forged
+
+Test that:
+
+- Modifying client-stored tokens (localStorage, sessionStorage) does not grant access.
+- Removing or modifying cookies does not grant access (or it gracefully de-authenticates).
+- Replaying captured requests after logout fails.
+
+### 4. CSRF / cross-origin protection
+
+Test that:
+
+- A request originating from a different origin (set `Origin: https://attacker.com` in test) is rejected for state-changing operations.
+- CSRF tokens (or SameSite cookie equivalents) are validated, not just included.
+
+### 5. No client-side secrets
+
+Audit the bundle for accidentally-shipped secrets:
+
+```
+- Build the production bundle.
+- grep for: API keys (hex strings, JWT structure), private endpoints, internal URLs,
+  source maps containing internal paths, debug flags left enabled.
+- Expected: nothing sensitive present.
+```
+
+## Common UI-as-security misconceptions
+
+| Misconception | Why it fails |
+|---------------|--------------|
+| "Hidden field hides the value" | Visible in HTML source / DevTools |
+| "Disabled button prevents action" | User can re-enable in DevTools |
+| "Client-side regex prevents bad input" | Bypassable with crafted request |
+| "Auth check on the page renders the wrong page" | Page didn't render but the API is still callable |
+| "We minified the code" | Reverse-engineering minified code is trivial |
+| "We obfuscated the API" | Network tab reveals the calls |
+| "Only our app calls this endpoint" | Anyone can call any URL |
+
+## Testing browser-side trust boundaries
+
+When using Playwright/Puppeteer/MCP for testing:
+
+- **Capture and replay attacks:** record a request, replay with modified payload, assert the server rejects.
+- **Session manipulation:** modify cookies/localStorage between actions, assert the server detects.
+- **Direct API calls:** skip the UI; call endpoints directly; assert correct authorization.
+- **Cross-origin simulation:** override `Origin` header; assert correct rejection.
+
+These tests catch bugs unit tests miss, because unit tests assume well-formed input. The browser-as-attacker tests assume malicious input.
+
+## Anti-patterns
+
+- Testing only the happy path through the UI.
+- Asserting "the button is disabled" without asserting "the API rejects the call."
+- Treating client-side validation messages as if they were security checks.
+- Relying on minification/obfuscation as defense.
+- Testing once, never re-testing after dependency updates that change the trust surface.
+
+## When this matters most
+
+- Auth flows, account changes, password resets.
+- Payment / billing operations.
+- Data export, account deletion, irreversible actions.
+- Multi-tenant boundaries (one user's data must not leak to another).
+- Admin endpoints (must reject non-admin users at the server, not just hide UI).
+
+These are the tests that catch real production incidents.

package/scaffold/skills/webapp-testing/references/three-workflow-patterns.md

@@ -0,0 +1,144 @@
+# Three workflow patterns for browser-based testing
+
+> Adapted from [`addyosmani/agent-skills/browser-devtools`](https://github.com/addyosmani/agent-skills/tree/main/browser-devtools) (MIT). The three workflows below organize webapp testing tasks by what's actually being verified.
+
+Most webapp testing tasks fall into one of three workflows. Each has different goals, different signals, and different failure modes. Don't conflate them.
+
+## Workflow 1 — UI bugs
+
+**Goal:** verify what the user sees matches what's expected.
+
+**Signals:**
+- Screenshot diff vs reference.
+- Element exists / does not exist in DOM.
+- Element has expected text / attributes.
+- Element is visible / styled correctly.
+- Click triggers expected navigation or state change.
+
+**Tools:**
+- Playwright / Puppeteer for navigation and interaction.
+- Visual regression (Percy, Chromatic, Playwright's `toHaveScreenshot`).
+- Accessibility checks (`axe-core`, Playwright's accessibility snapshot).
+
+**Common bugs caught:**
+- Layout shift after image loads.
+- Text wrapping that overflows containers.
+- Missing focus styles on interactive elements.
+- Hover/active states broken on touch devices.
+- Hydration mismatch (server-rendered ≠ client-rendered DOM).
+
+**Common bugs missed:**
+- Behavior bugs (click works but state is wrong).
+- Race conditions (UI state stable; network race underneath).
+- Security bugs (UI hides the action; server still accepts it).
+
+**When to use this workflow:**
+- After a CSS / component refactor.
+- Before / after design system migrations.
+- Smoke testing critical pages on every release.
+
+## Workflow 2 — Network issues
+
+**Goal:** verify the client-server contract is honored under various network conditions.
+
+**Signals:**
+- Request was sent with expected payload, headers, method, URL.
+- Response was received with expected status, body, headers.
+- Retries occurred when expected (and didn't when not).
+- Errors are surfaced to UI vs swallowed silently.
+- Requests don't fire when they shouldn't (e.g., debounced search).
+
+**Tools:**
+- Playwright `page.route()` to intercept and inspect / modify requests.
+- DevTools Network panel via MCP / inspection.
+- Mock server / MSW for controlled scenarios.
+- Network throttling (slow 3G, offline) for resilience tests.
+
+**Common bugs caught:**
+- N+1 requests on page load.
+- Missing error handling (200 success path tested; 500 path crashes UI).
+- Auth headers missing on retried requests.
+- Stale data shown after offline reconnect.
+- Race conditions when multiple requests resolve out of order.
+
+**Common bugs missed:**
+- Visual bugs that don't affect network (CSS issues).
+- Server-side bugs (test only checks request/response shape, not server logic).
+- Performance bugs at scale (single request looks fine; thousands per second don't).
+
+**When to use this workflow:**
+- After auth / API client refactor.
+- Verifying offline / connectivity-loss behavior.
+- Validating against contract tests / API mocks.
+- Reproducing user-reported "loading forever" bugs.
+
+## Workflow 3 — Performance investigation
+
+**Goal:** find why a page is slow and verify a fix.
+
+**Signals:**
+- Lighthouse scores (LCP, FID/INP, CLS, TTFB).
+- DevTools Performance flame graph timing.
+- Bundle analyzer output.
+- `web-vitals` library captures from real browser sessions.
+- Frame rate during interactions (`requestAnimationFrame` timing).
+
+**Tools:**
+- Playwright `tracing.start({ snapshots: true, screenshots: true })`.
+- Lighthouse CI for automated runs.
+- DevTools Performance tab via MCP.
+- WebPageTest for repeatable third-party measurement.
+- Bundle analyzer (`next-bundle-analyzer`, `webpack-bundle-analyzer`).
+
+**Common bugs caught:**
+- Render-blocking third-party scripts.
+- Unintended re-renders amplifying click handlers.
+- Large bundle from accidental lib import (e.g., `import _ from 'lodash'` instead of specific function).
+- Images larger than displayed size.
+- N+1 client-side renders (list of 1000 items each fetching).
+
+**Common bugs missed:**
+- Network correctness (perf can pass even when results are wrong).
+- Visual issues unrelated to render time.
+- Backend perf (this workflow looks at client-side; backend traces are needed too).
+
+**When to use this workflow:**
+- Performance regression alerts firing.
+- User-reported slowness.
+- Before / after a perf-targeted refactor.
+- Pre-launch validation against budget targets.
+
+## Choosing a workflow
+
+The first question for any test: what am I trying to verify?
+
+| Concern | Workflow |
+|---------|----------|
+| "Does the page look right?" | UI bugs |
+| "Does clicking this button do the right thing visually?" | UI bugs |
+| "Does the API get called correctly?" | Network issues |
+| "Does the UI handle errors gracefully?" | Network issues |
+| "Why is this page slow?" | Performance |
+| "Does this hit our perf budget?" | Performance |
+| "Does an attacker get blocked here?" | Network issues + security boundary (`security-boundary.md`) |
+
+Mixing workflows in a single test produces flaky, slow, or incomplete coverage. A test that asserts BOTH "the button is styled correctly" AND "Lighthouse score is >90" runs slowly and fails for unrelated reasons.
+
+## Anti-patterns
+
+- One mega-test that "checks everything" — fails fragilely, hard to debug.
+- UI tests that assert pixel-perfect layout in CI (CI rendering differs from local).
+- Network tests that mock the entire API (you stop testing the contract; you test the mock).
+- Performance tests run once during dev, never in CI (regressions land silently).
+- Skipping security workflow because "we have unit tests for auth" — unit tests don't catch UI/server-disagreement bugs.
+
+## How these compose
+
+A real webapp test suite has all three workflows running:
+
+- **Per commit (CI):** UI smoke tests + critical-path network tests.
+- **Per PR:** above + visual regression on changed components.
+- **Per release:** above + Lighthouse CI + extended network resilience tests.
+- **Periodically (nightly / weekly):** full perf baseline + security boundary checks.
+
+Different cadences match different cost profiles. UI smoke is cheap; full perf + security is expensive. Balance accordingly.

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

@@ -1,85 +0,0 @@
-<system_instructions>
-You are a quick task executor. This command exists to implement one-off changes with workflow guarantees (validation, atomic commit) without requiring a full PRD.
-
-<critical>This command is for small, well-defined changes. If the change needs multiple tasks, redirect to `/dw-create-prd`.</critical>
-<critical>ALWAYS run tests and validation before committing. Workflow guarantees are mandatory even for quick tasks.</critical>
-
-## When to Use
-- Use for small changes that don't justify the full pipeline (PRD -> TechSpec -> Tasks)
-- Use for hotfixes, config adjustments, dependency updates, one-off refactors
-- Use when invoked after `/dw-brainstorm --onepager` and the one-pager carries `[IMPROVES]` classification with an MVP Scope fitting in ≤3 files (skip-PRD path)
-- Do NOT use for new features with multiple requirements (use `/dw-create-prd`)
-- Do NOT use for complex bugs (use `/dw-bugfix`)
-
-## Pipeline Position
-**Predecessor:** (user's ad-hoc need) | **Successor:** `/dw-commit` (automatic)
-
-## Complementary Skills
-
-| Skill | Trigger |
-|-------|---------|
-| `dw-verify` | **ALWAYS** — invoked before the commit. Even small changes require a VERIFICATION REPORT PASS (minimal test + lint) before the atomic commit. |
-
-## Input Variables
-
-| Variable | Description | Example |
-|----------|-------------|---------|
-| `{{DESCRIPTION}}` | Description of the change to implement | "add loading spinner to dashboard" |
-
-## Required Behavior
-
-1. Read `.dw/rules/` to understand project patterns and conventions
-2. **If a one-pager exists** at `.dw/spec/ideas/<slug>.md` and was passed as input, read it first. If classification is `[IMPROVES]` and MVP Scope fits in ≤3 files, proceed. If `[NEW]` or `[CONSOLIDATES]` with larger scope, warn and redirect to `/dw-create-prd`.
-3. Summarize the change in 1-2 sentences and confirm scope with the user
-4. If the change seems too large (>3 files, >100 lines), warn and suggest `/dw-create-prd`
-5. Implement the change following project conventions
-6. Run relevant existing tests (unit, integration)
-7. Run lint if configured in the project
-8. Invoke `dw-verify` and include the VERIFICATION REPORT in the output before committing. Without PASS, DO NOT commit.
-9. Create atomic semantic commit with the change
-
-## GSD Integration
-
-<critical>When GSD is installed, delegation to /gsd-quick is MANDATORY for tracking.</critical>
-
-If GSD (get-shit-done-cc) is installed in the project:
-- Delegate to `/gsd-quick` for tracking in `.planning/quick/`
-- The task is registered in history for future lookup via `/dw-intel`
-
-If GSD is NOT installed:
-- Execute directly with Level 1 validation
-- No history tracking (only git log)
-
-## Codebase Intelligence
-
-If `.planning/intel/` exists, query before implementing:
-- Internally run: `/gsd-intel "implementation patterns in [target area]"`
-- Follow the patterns found
-
-If `.planning/intel/` does NOT exist:
-- Use only `.dw/rules/` as context
-
-## Response Format
-
-### 1. Scope
-- Change: [description]
-- Affected files: [list]
-- Estimate: [small/medium]
-
-### 2. Implementation
-- File-by-file changes
-
-### 3. Validation
-- Tests run: [result]
-- Lint: [result]
-
-### 4. Commit
-- Message: [semantic commit]
-
-## Closing
-
-At the end, inform:
-- Change implemented and committed
-- Whether to push or continue with more changes
-
-</system_instructions>

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

@@ -1,82 +0,0 @@
-<system_instructions>
-You are a session continuity assistant. This command exists to restore context from the last session and suggest the next workflow step.
-
-<critical>This command is read-only. Do NOT modify code, do NOT execute tasks, do NOT create files. Only analyze state and recommend the next step.</critical>
-
-## When to Use
-- Use when starting a new session to pick up where you left off
-- Use when unsure which command to run next
-- Do NOT use in the middle of a task or plan execution
-
-## Pipeline Position
-**Predecessor:** (session start) | **Successor:** any dw-* command
-
-## Complementary Skills
-
-| Skill | Trigger |
-|-------|---------|
-| `dw-memory` | **ALWAYS** — for each active PRD identified, read `.dw/spec/<prd>/MEMORY.md` (shared) to reconstitute constraints, decisions, and handoff notes from the prior session. Include in the summary presented to the user. |
-
-## Required Behavior
-
-<critical>BEFORE any analysis, check for an interrupted autopilot. Look for `autopilot-state.json` in ALL directories inside `.dw/spec/`. If you find one without `"status": "completed"`, autopilot resumption takes PRIORITY over any other suggestion.</critical>
-
-### Interrupted Autopilot Detection
-
-1. Search for `.dw/spec/*/autopilot-state.json`
-2. If you find a file with `"mode": "autopilot"` and no `"status": "completed"`:
-   - Present: original wish, step where it stopped, steps already completed
-   - Ask: **"Found an interrupted autopilot at step [N] ([step name]). Do you want to continue where you left off?"**
-   - If **YES**: run `/dw-autopilot` instructing it to resume from `current_step` using the state file. The autopilot must read the state and skip already completed steps.
-   - If **NO**: continue with the normal resume flow below
-
-### Normal Flow (no pending autopilot)
-
-1. Read `.dw/spec/` and identify PRDs with pending tasks (`- [ ]` checkboxes in tasks.md)
-2. Read `git log --oneline -10` to identify the last work performed
-3. Identify the active branch and whether there are uncommitted changes
-4. **Invoke `dw-memory`**: for the active PRD, read `.dw/spec/<prd>/MEMORY.md` and the next pending task's memory (`tasks/<N>_memory.md` if present). Extract durable decisions, cross-task constraints, and handoff notes.
-5. Cross-reference: last active PRD, last completed task, next pending task, memory context
-6. Present the summary in the format below (including a "From where we left off" bullet list based on memory)
-7. Suggest the next command to execute
-
-## GSD Integration
-
-<critical>When GSD is installed, delegation to /gsd-resume-work is MANDATORY, not optional.</critical>
-
-If GSD (get-shit-done-cc) is installed in the project:
-- Delegate to `/gsd-resume-work` for cross-session state restoration from `.planning/STATE.md`
-- Incorporate additional context: persistent threads, backlog, notes
-
-If GSD is NOT installed:
-- Use only `.dw/spec/` and git log as context sources
-- Full functionality, just without advanced cross-session persistence
-
-## Response Format
-
-### Session Summary
-- **Last work**: [time ago], branch [name]
-- **Active PRD**: [PRD name]
-- **Tasks**: [N completed] of [total]
-- **Last completed task**: [name]
-- **Next pending task**: [name]
-- **Blockers**: [unresolved dependencies, if any]
-- **Uncommitted changes**: [yes/no]
-
-### Suggested Next Step
-- Command: `/dw-[command] [arguments]`
-- Reason: [why this is the logical next step]
-
-## Heuristics
-
-- If there are uncommitted changes, suggest `/dw-commit` first
-- If all tasks are complete, suggest `/dw-code-review` or `/dw-run-qa`
-- If no active PRD, suggest `/dw-brainstorm` or `/dw-create-prd`
-- If there are pending tasks, suggest `/dw-run-task` or `/dw-run-plan`
-- If the last task failed, suggest investigating the error before continuing
-
-## Closing
-
-At the end, leave the user ready to execute the next command with a single copy-paste.
-
-</system_instructions>

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

@@ -1,85 +0,0 @@
-<system_instructions>
-Voce e um executor de tasks rapidas. Este comando existe para implementar mudancas pontuais com garantias do workflow (validacao, commit atomico) sem precisar de PRD completo.
-
-<critical>Este comando e para mudancas pequenas e bem definidas. Se a mudanca precisar de multiplas tasks, redirecione para `/dw-create-prd`.</critical>
-<critical>SEMPRE execute testes e validacao antes de commitar. Garantias do workflow sao obrigatorias mesmo para tasks rapidas.</critical>
-
-## Quando Usar
-- Use para mudancas pequenas que nao justificam o pipeline completo (PRD -> TechSpec -> Tasks)
-- Use para hotfixes, ajustes de config, atualizacoes de dependencias, refatoracoes pontuais
-- Use quando invocado apos `/dw-brainstorm --onepager` e o one-pager tem classificacao `[IMPROVES]` com MVP Scope cabendo em ≤3 arquivos (skip-PRD path)
-- NAO use para features novas com multiplos requisitos (use `/dw-create-prd`)
-- NAO use para bugs complexos (use `/dw-bugfix`)
-
-## Posicao no Pipeline
-**Antecessor:** (necessidade pontual do usuario) | **Sucessor:** `/dw-commit` (automatico)
-
-## Skills Complementares
-
-| Skill | Gatilho |
-|-------|---------|
-| `dw-verify` | **SEMPRE** — invocada antes do commit. Mesmo mudancas pequenas exigem VERIFICATION REPORT PASS (test + lint minimos) antes de commit atomico. |
-
-## Variaveis de Entrada
-
-| Variavel | Descricao | Exemplo |
-|----------|-----------|---------|
-| `{{DESCRIPTION}}` | Descricao da mudanca a implementar | "adicionar spinner de loading no dashboard" |
-
-## Comportamento Obrigatorio
-
-1. Leia `.dw/rules/` para entender padroes e convencoes do projeto
-2. **Se um one-pager existe** em `.dw/spec/ideas/<slug>.md` e foi passado como input, leia-o primeiro. Se classification for `[IMPROVES]` e MVP Scope cabe em ≤3 arquivos, prosseguir. Se for `[NEW]` ou `[CONSOLIDATES]` de escopo maior, alertar e redirecionar para `/dw-create-prd`.
-3. Resuma a mudanca em 1-2 frases e confirme escopo com o usuario
-4. Se a mudanca parecer grande demais (>3 arquivos, >100 linhas), alerte e sugira `/dw-create-prd`
-5. Implemente a mudanca seguindo convencoes do projeto
-6. Execute testes existentes relevantes (unit, integration)
-7. Execute lint se configurado no projeto
-8. Invoque `dw-verify` e inclua o VERIFICATION REPORT no output antes de commitar. Sem PASS, NAO commit.
-9. Crie commit atomico semantico com a mudanca
-
-## Integracao GSD
-
-<critical>Quando o GSD estiver instalado, a delegação para /gsd-quick é OBRIGATÓRIA para tracking.</critical>
-
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Delegue para `/gsd-quick` para tracking em `.planning/quick/`
-- A task fica registrada no historico para consulta futura via `/dw-intel`
-
-Se o GSD NAO estiver instalado:
-- Execute diretamente com validacao Level 1
-- Sem tracking historico (apenas git log)
-
-## Inteligencia do Codebase
-
-Se `.planning/intel/` existir, consulte antes de implementar:
-- Execute internamente: `/gsd-intel "implementation patterns in [target area]"`
-- Siga os padroes encontrados
-
-Se `.planning/intel/` NAO existir:
-- Use apenas `.dw/rules/` como contexto
-
-## Formato de Resposta
-
-### 1. Escopo
-- Mudanca: [descricao]
-- Arquivos afetados: [lista]
-- Estimativa: [pequena/media]
-
-### 2. Implementacao
-- Mudancas arquivo por arquivo
-
-### 3. Validacao
-- Testes executados: [resultado]
-- Lint: [resultado]
-
-### 4. Commit
-- Mensagem: [commit semantico]
-
-## Encerramento
-
-Ao final, informe:
-- Mudanca implementada e commitada
-- Se deseja fazer push ou continuar com mais mudancas
-
-</system_instructions>

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

@@ -1,82 +0,0 @@
-<system_instructions>
-Voce e um assistente de continuidade de sessao. Este comando existe para restaurar contexto da ultima sessao e sugerir o proximo passo do workflow.
-
-<critical>Este comando e somente leitura. NAO modifique codigo, NAO execute tasks, NAO crie arquivos. Apenas analise o estado e recomende o proximo passo.</critical>
-
-## Quando Usar
-- Use ao iniciar uma nova sessao para retomar de onde parou
-- Use quando nao souber qual comando executar em seguida
-- NAO use no meio de uma execucao de task ou plano
-
-## Posicao no Pipeline
-**Antecessor:** (inicio de sessao) | **Sucessor:** qualquer comando dw-*
-
-## Skills Complementares
-
-| Skill | Gatilho |
-|-------|---------|
-| `dw-memory` | **SEMPRE** — para cada PRD ativo identificado, ler `.dw/spec/<prd>/MEMORY.md` (shared) para reconstituir constraints, decisoes e handoff notes da sessao anterior. Incluir no resumo apresentado ao usuario. |
-
-## Comportamento Obrigatorio
-
-<critical>ANTES de qualquer analise, verifique se existe um autopilot interrompido. Procure por `autopilot-state.json` em TODOS os diretorios dentro de `.dw/spec/`. Se encontrar um com status diferente de "completed", a retomada do autopilot tem PRIORIDADE sobre qualquer outra sugestao.</critical>
-
-### Deteccao de Autopilot Interrompido
-
-1. Procure por `.dw/spec/*/autopilot-state.json`
-2. Se encontrar um arquivo com `"mode": "autopilot"` e sem `"status": "completed"`:
-   - Apresente: desejo original, etapa em que parou, etapas ja completadas
-   - Pergunte: **"Encontrei um autopilot interrompido na etapa [N] ([nome da etapa]). Deseja continuar de onde parou?"**
-   - Se **SIM**: execute `/dw-autopilot` informando que deve retomar a partir da etapa `current_step` usando o state file. O autopilot deve ler o state e pular as etapas ja completadas.
-   - Se **NAO**: continue com o fluxo normal de resume abaixo
-
-### Fluxo Normal (sem autopilot pendente)
-
-1. Leia `.dw/spec/` e identifique PRDs com tasks pendentes (checkboxes `- [ ]` em tasks.md)
-2. Leia `git log --oneline -10` para identificar o ultimo trabalho realizado
-3. Identifique a branch ativa e se ha mudancas nao commitadas
-4. **Invoque `dw-memory`**: para o PRD ativo, leia `.dw/spec/<prd>/MEMORY.md` e a memory da proxima task pendente (`tasks/<N>_memory.md` se existir). Extraia decisoes durables, constraints cross-task e handoff notes.
-5. Cruze: ultimo PRD ativo, ultima task completada, proxima task pendente, contexto de memory
-6. Apresente o resumo no formato abaixo (incluindo bullets de "Do ponto onde paramos" com base na memory)
-7. Sugira o proximo comando a executar
-
-## Integracao GSD
-
-<critical>Quando o GSD estiver instalado, a delegação para /gsd-resume-work é OBRIGATÓRIA, não opcional.</critical>
-
-Se o GSD (get-shit-done-cc) estiver instalado no projeto:
-- Delegue para `/gsd-resume-work` para restaurar estado cross-sessao de `.planning/STATE.md`
-- Incorpore contexto adicional: threads persistentes, backlog, notas
-
-Se o GSD NAO estiver instalado:
-- Use apenas `.dw/spec/` e git log como fontes de contexto
-- Funcionalidade completa, apenas sem persistencia cross-sessao avancada
-
-## Formato de Resposta
-
-### Resumo da Sessao
-- **Ultimo trabalho**: [tempo atras], branch [nome]
-- **PRD ativo**: [nome do PRD]
-- **Tasks**: [N completadas] de [total]
-- **Ultima task completada**: [nome]
-- **Proxima task pendente**: [nome]
-- **Bloqueios**: [dependencias nao resolvidas, se houver]
-- **Mudancas nao commitadas**: [sim/nao]
-
-### Proximo Passo Sugerido
-- Comando: `/dw-[comando] [argumentos]`
-- Motivo: [por que este e o proximo passo logico]
-
-## Heuristicas
-
-- Se ha mudancas nao commitadas, sugira `/dw-commit` primeiro
-- Se todas as tasks estao completas, sugira `/dw-code-review` ou `/dw-run-qa`
-- Se nao ha PRD ativo, sugira `/dw-brainstorm` ou `/dw-create-prd`
-- Se ha tasks pendentes, sugira `/dw-run-task` ou `/dw-run-plan`
-- Se a ultima task falhou, sugira investigar o erro antes de continuar
-
-## Encerramento
-
-Ao final, deixe o usuario pronto para executar o proximo comando com um unico copy-paste.
-
-</system_instructions>