@brunosps00/dev-workflow 0.0.3 → 0.0.5

package/scaffold/en/commands/{run-qa.md → dw-run-qa.md}

@@ -1,6 +1,14 @@
 <system_instructions>
 You are an AI assistant specialized in Quality Assurance. Your task is to validate that the implementation meets all requirements defined in the PRD, TechSpec, and Tasks by executing E2E tests, accessibility checks, and visual analysis.
 
+## When to Use
+- Use when validating that implementation meets all requirements from PRD, TechSpec, and Tasks through E2E tests, accessibility checks, and visual analysis
+- Do NOT use when only unit/integration tests are needed (use the project's test runner directly)
+- Do NOT use when requirements have not been defined yet (create PRD first)
+
+## Pipeline Position
+**Predecessor:** `/dw-run-plan` or `/dw-run-task` | **Successor:** `/dw-fix-qa` (if bugs) or `/dw-code-review`
+
 <critical>Use the Playwright MCP to execute all E2E tests</critical>
 <critical>Verify ALL requirements from the PRD and TechSpec before approving</critical>
 <critical>QA is NOT complete until ALL checks pass</critical>
@@ -20,7 +28,7 @@ When available in the project under `./.agents/skills/`, use these skills as ope
 
 | Variable | Description | Example |
 |----------|-------------|---------|
-| `{{PRD_PATH}}` | Path to the PRD folder | `ai/spec/prd-user-onboarding` |
+| `{{PRD_PATH}}` | Path to the PRD folder | `.dw/spec/prd-user-onboarding` |
 
 ## Objectives
 
@@ -37,8 +45,9 @@ When available in the project under `./.agents/skills/`, use these skills as ope
 - PRD: `{{PRD_PATH}}/prd.md`
 - TechSpec: `{{PRD_PATH}}/techspec.md`
 - Tasks: `{{PRD_PATH}}/tasks.md`
-- Project Rules: `ai/rules/`
-- QA Test Credentials: `ai/rules/qa-test-credentials.md`
+- Project Rules: `.dw/rules/`
+- QA Test Credentials: `.dw/templates/qa-test-credentials.md`
+- Playwright Patterns: `.dw/references/playwright-patterns.md`
 - Evidence folder (required): `{{PRD_PATH}}/QA/`
 - Output Report: `{{PRD_PATH}}/QA/qa-report.md`
 - Bugs found: `{{PRD_PATH}}/QA/bugs.md`
@@ -56,7 +65,7 @@ Identify the projects with a testable frontend via Playwright by checking the pr
 | Web frontend | `http://localhost:3000` | (check project config) |
 | Admin frontend | `http://localhost:4000` | (check project config) |
 
-Refer to `ai/rules/` for project-specific URLs and frameworks.
+Refer to `.dw/rules/` for project-specific URLs and frameworks.
 
 ## Process Steps
 
@@ -83,13 +92,13 @@ Refer to `ai/rules/` for project-specific URLs and frameworks.
   - `{{PRD_PATH}}/QA/screenshots/`
   - `{{PRD_PATH}}/QA/logs/`
   - `{{PRD_PATH}}/QA/scripts/`
-- Read `ai/rules/qa-test-credentials.md` and choose the appropriate user/profile for the scenario
+- Read `.dw/templates/qa-test-credentials.md` and choose the appropriate user/profile for the 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`
 - If persistent session, auth import, network inspection beyond MCP, or browser-first reproduction is needed, complement with `agent-browser`
 
-### 2.5 Menu Page Verification (Required -- Execute BEFORE RF tests)
+### 3. Menu Page Verification (Required -- Execute BEFORE RF tests)
 
 <critical>BEFORE testing individual RFs, verify that EACH menu item in the module leads to a FUNCTIONAL and UNIQUE page. This verification is blocking -- if it fails, QA CANNOT be approved.</critical>
 
@@ -117,7 +126,16 @@ For each menu item in the module:
 - Capture screenshot with suffix `-STUB-FAIL.png`
 - QA CANNOT have APPROVED status while stub pages exist in the menu
 
-### 3. E2E Tests with Playwright MCP (Required)
+**Menu Verification Decision Flow:**
+```dot
+digraph menu_check {
+  "Check Menu Items" -> "All functional?" [shape=diamond];
+  "All functional?" -> "Proceed to RF tests" [label="yes"];
+  "All functional?" -> "Report STUB BUG\nFAIL QA" [label="no"];
+}
+```
+
+### 4. E2E Tests with Playwright MCP (Required)
 
 Use Playwright MCP tools to test each flow:
 
@@ -150,7 +168,7 @@ For each functional requirement from the PRD:
 <critical>It is not enough to validate only the happy path. Each requirement must be exercised against its boundary states and most likely regressions</critical>
 <critical>If a requirement cannot be fully validated via E2E, QA must be marked as REJECTED or BLOCKED, never APPROVED</critical>
 
-### 3.1. Required Minimum Matrix per Requirement
+### 4.1. Required Minimum Matrix per Requirement
 
 For each RF, QA must explicitly answer:
 
@@ -172,7 +190,7 @@ Examples of edge cases that must be considered whenever relevant:
 - re-entrance/repeated actions
 - API failures, loading, and intermediate states
 
-### 4. Accessibility Checks (Required)
+### 5. Accessibility Checks (Required)
 
 Verify for each screen/component (WCAG 2.2):
 
@@ -188,14 +206,14 @@ Verify for each screen/component (WCAG 2.2):
 Use `browser_press_key` to test keyboard navigation.
 Use `browser_snapshot` to verify labels and semantic structure.
 
-### 5. Visual Checks (Required)
+### 6. Visual Checks (Required)
 
 - 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. Bug Documentation (If issues found)
+### 7. Bug Documentation (If issues found)
 
 For each bug found, create an entry in `{{PRD_PATH}}/QA/bugs.md`:
 
@@ -214,7 +232,7 @@ For each bug found, create an entry in `{{PRD_PATH}}/QA/bugs.md`:
 - **Status:** Open
 ```
 
-### 7. QA Report (Required)
+### 8. QA Report (Required)
 
 Generate report in `{{PRD_PATH}}/QA/qa-report.md`:
 
@@ -283,7 +301,8 @@ Generate report in `{{PRD_PATH}}/QA/qa-report.md`:
 - Check API calls with `browser_network_requests` and save in `QA/logs/network.log`
 - Save executed E2E test scripts in `QA/scripts/` for reuse and audit
 - For projects using shadcn/ui + Tailwind, verify components follow the design system
-- Use `ai/rules/qa-test-credentials.md` as the official source of login credentials for QA
+- Use `.dw/templates/qa-test-credentials.md` as the official source of login credentials for QA
+- See `.dw/references/playwright-patterns.md` for common test patterns
 - Do not mark a requirement as validated based solely on unit tests, integration tests, code inference, or partial execution
 - If the implementation requires historical data or specific state to validate an edge case, prepare that state and execute the case
 - If there is insufficient time or environment to fully cover a requirement, record it explicitly as a blocker and reject QA

package/scaffold/en/commands/{run-task.md → dw-run-task.md}

@@ -4,20 +4,30 @@ You are an AI assistant responsible for implementing software development tasks.
 <critical>You must not rush to finish the task. Always check the necessary files, verify the tests, and go through a reasoning process to ensure both understanding and correct execution.</critical>
 <critical>THE TASK CANNOT BE CONSIDERED COMPLETE UNTIL ALL TESTS ARE PASSING</critical>
 
+## When to Use
+- Use when executing a single task from a PRD's tasks.md with built-in Level 1 validation
+- Do NOT use when you need to execute ALL tasks sequentially (use `/dw-run-plan` instead)
+- Do NOT use when fixing a bug report (use `/dw-bugfix` instead)
+
+## Pipeline Position
+**Predecessor:** `/dw-create-tasks` | **Successor:** `/dw-run-task` (next task) or `/dw-review-implementation`
+
 ## Complementary Skills
 
 When available in the project at `./.agents/skills/`, use these skills as specialized support without replacing this command:
 
-- `vercel-react-best-practices`: use when the task touches React/Next.js, especially for rendering, data fetching, hydration, bundle, cache, and performance
-- `webapp-testing`: use when the task requires functional frontend validation in a real browser
-- `agent-browser`: use when UI validation requires persistent session, operational navigation inspection, or complementary visual evidence
+| Skill | Trigger |
+|-------|---------|
+| `vercel-react-best-practices` | Task touches React rendering, hydration, data fetching, bundle, cache, or performance |
+| `webapp-testing` | Task has interactive frontend needing E2E validation in a real browser |
+| `agent-browser` | UI validation requires persistent session, operational navigation inspection, or complementary visual evidence |
 
 ## File Locations
 
 - PRD: `./spec/prd-[feature-name]/prd.md`
 - Tech Spec: `./spec/prd-[feature-name]/techspec.md`
 - Tasks: `./spec/prd-[feature-name]/tasks.md`
-- Project Rules: `ai/rules/`
+- Project Rules: `.dw/rules/`
 
 ## Steps to Execute
 
@@ -35,7 +45,7 @@ When available in the project at `./.agents/skills/`, use these skills as specia
 Analyze considering:
 - Main objectives of the task
 - How the task fits into the project context
-- Alignment with project rules and patterns (`ai/rules/`)
+- Alignment with project rules and patterns (`.dw/rules/`)
 - Possible solutions or approaches
 - If React/Next.js is in scope, explicitly incorporate relevant heuristics from `vercel-react-best-practices`
 
@@ -72,7 +82,7 @@ After providing the summary and approach, **begin implementation immediately**:
 
 **YOU MUST** start the implementation right after the process above.
 
-<critical>Use the Context7 MCP to look up documentation for the language, frameworks, and libraries involved in the implementation</critical>
+<critical>Use the Context7 MCP to look up framework/library documentation for the language, frameworks, and libraries involved in the implementation</critical>
 
 ## Important Notes
 
@@ -105,7 +115,7 @@ pnpm test   # or npm test
 - [ ] Code compiles without errors
 - [ ] Lint passes
 - [ ] Multi-tenancy respected (if applicable)
-- [ ] Project patterns followed (`ai/rules/`)
+- [ ] Project patterns followed (`.dw/rules/`)
 
 ### Functional UI Verification (for tasks with frontend)
 <critical>Placeholder/stub pages are NOT acceptable deliverables for user interaction FRs.</critical>

package/scaffold/en/references/playwright-patterns.md

@@ -0,0 +1,136 @@
+# Playwright Test Patterns
+
+Reference for `/dw-run-qa` and `/dw-functional-doc`. Common E2E patterns.
+
+## 1. Authenticated Navigation
+
+```typescript
+import { test, expect } from "@playwright/test";
+
+test("navigate authenticated route", async ({ page }) => {
+  // Login
+  await page.goto("/login");
+  await page.getByLabel("Email").fill("user@test.com");
+  await page.getByLabel("Password").fill("password123");
+  await page.getByRole("button", { name: "Sign in" }).click();
+  
+  // Wait for redirect
+  await page.waitForURL("/dashboard");
+  await expect(page.getByRole("heading", { name: /dashboard/i })).toBeVisible();
+});
+```
+
+## 2. Form Submission with Validation
+
+```typescript
+test("submit form with validation errors", async ({ page }) => {
+  await page.goto("/users/new");
+
+  // Submit empty → validation errors
+  await page.getByRole("button", { name: "Save" }).click();
+  await expect(page.getByText("Name is required")).toBeVisible();
+  await expect(page.getByText("Email is required")).toBeVisible();
+
+  // Fill and submit → success
+  await page.getByLabel("Name").fill("Jane Doe");
+  await page.getByLabel("Email").fill("jane@example.com");
+  await page.getByRole("button", { name: "Save" }).click();
+  
+  await expect(page.getByText("User created successfully")).toBeVisible();
+});
+```
+
+## 3. Table with Filtering and Pagination
+
+```typescript
+test("filter and paginate table", async ({ page }) => {
+  await page.goto("/users");
+
+  // Verify initial load
+  const rows = page.locator("table tbody tr");
+  await expect(rows).toHaveCount(10); // default page size
+
+  // Filter
+  await page.getByPlaceholder("Search...").fill("admin");
+  await expect(rows).toHaveCount(2); // filtered results
+
+  // Clear and paginate
+  await page.getByPlaceholder("Search...").clear();
+  await page.getByRole("button", { name: "Next" }).click();
+  await expect(page.getByText("Page 2")).toBeVisible();
+});
+```
+
+## 4. Modal / Dialog Interaction
+
+```typescript
+test("open modal, fill form, confirm", async ({ page }) => {
+  await page.goto("/projects");
+
+  // Open modal
+  await page.getByRole("button", { name: "New Project" }).click();
+  const dialog = page.getByRole("dialog");
+  await expect(dialog).toBeVisible();
+
+  // Fill modal form
+  await dialog.getByLabel("Project Name").fill("My Project");
+  await dialog.getByRole("button", { name: "Create" }).click();
+
+  // Modal closes, item appears in list
+  await expect(dialog).not.toBeVisible();
+  await expect(page.getByText("My Project")).toBeVisible();
+});
+```
+
+## 5. Permission / Access Denied
+
+```typescript
+test("restricted user sees access denied", async ({ page }) => {
+  // Login as restricted user
+  await page.goto("/login");
+  await page.getByLabel("Email").fill("restricted@test.com");
+  await page.getByLabel("Password").fill("password123");
+  await page.getByRole("button", { name: "Sign in" }).click();
+
+  // Try to access admin route
+  await page.goto("/admin/settings");
+  
+  // Verify access denied
+  await expect(page.getByText(/access denied|forbidden|not authorized/i)).toBeVisible();
+  // OR redirect to dashboard
+  await expect(page).toHaveURL(/dashboard/);
+});
+```
+
+## 6. API Error Handling
+
+```typescript
+test("handles API error gracefully", async ({ page }) => {
+  // Intercept API to simulate error
+  await page.route("**/api/users", (route) =>
+    route.fulfill({ status: 500, body: "Internal Server Error" })
+  );
+
+  await page.goto("/users");
+
+  // Verify error state
+  await expect(page.getByText(/error|something went wrong/i)).toBeVisible();
+  
+  // Verify retry button works
+  await page.unroute("**/api/users");
+  await page.getByRole("button", { name: /retry|try again/i }).click();
+  await expect(page.locator("table tbody tr")).toHaveCount(10);
+});
+```
+
+## Evidence Capture Pattern
+
+```typescript
+// Use in any test to capture evidence
+await test.step("Capture evidence", async () => {
+  await page.screenshot({ 
+    path: `evidence/screenshots/${testInfo.title}-${Date.now()}.png`, 
+    fullPage: true 
+  });
+});
+```

package/scaffold/en/references/refactoring-catalog.md

@@ -0,0 +1,167 @@
+# Refactoring Catalog — Before/After Examples
+
+Reference for `/dw-refactoring-analysis`. Based on Fowler's refactoring catalog.
+
+## 1. Long Function → Extract Function
+
+**Smell:** Function with >15 lines of logic, multiple responsibilities.
+
+```typescript
+// ❌ BEFORE: 30+ lines doing validation, transformation, and persistence
+async function processOrder(order: Order) {
+  if (!order.items.length) throw new Error("Empty order");
+  if (order.total < 0) throw new Error("Invalid total");
+  if (!order.customer) throw new Error("No customer");
+  
+  const discount = order.customer.isPremium 
+    ? order.total * 0.1 
+    : order.total > 100 ? order.total * 0.05 : 0;
+  const tax = (order.total - discount) * 0.15;
+  const finalTotal = order.total - discount + tax;
+  
+  order.discount = discount;
+  order.tax = tax;
+  order.total = finalTotal;
+  order.status = "processed";
+  
+  await db.orders.update(order.id, order);
+  await emailService.send(order.customer.email, "Order processed", { order });
+}
+
+// ✅ AFTER: Each function has one responsibility
+async function processOrder(order: Order) {
+  validateOrder(order);
+  const pricing = calculatePricing(order);
+  const processed = applyPricing(order, pricing);
+  await persistOrder(processed);
+  await notifyCustomer(processed);
+}
+```
+
+## 2. Feature Envy → Move Method
+
+**Smell:** Function accesses another object's data more than its own.
+
+```typescript
+// ❌ BEFORE: calculateShipping knows too much about Address
+function calculateShipping(order: Order) {
+  const addr = order.address;
+  if (addr.country === "US" && addr.state === "CA") return 5.99;
+  if (addr.country === "US") return 9.99;
+  return 19.99 + (addr.isRemote ? 10 : 0);
+}
+
+// ✅ AFTER: Address owns its shipping logic
+class Address {
+  getShippingCost(): number {
+    if (this.country === "US" && this.state === "CA") return 5.99;
+    if (this.country === "US") return 9.99;
+    return 19.99 + (this.isRemote ? 10 : 0);
+  }
+}
+```
+
+## 3. Primitive Obsession → Value Object
+
+**Smell:** Using raw strings/numbers for domain concepts (emails, money, dates).
+
+```typescript
+// ❌ BEFORE: email is just a string everywhere
+function sendEmail(to: string, subject: string) {
+  if (!to.includes("@")) throw new Error("Invalid email");
+  // ...
+}
+
+// ✅ AFTER: Email is a value object with built-in validation
+class Email {
+  constructor(private readonly value: string) {
+    if (!value.includes("@")) throw new Error("Invalid email");
+  }
+  toString() { return this.value; }
+}
+
+function sendEmail(to: Email, subject: string) { /* ... */ }
+```
+
+## 4. Duplicated Logic → Extract Shared Utility
+
+**Smell:** Same 3+ lines of logic appear in multiple places.
+
+```typescript
+// ❌ BEFORE: date formatting repeated in 4 components
+const formatted = `${date.getFullYear()}-${String(date.getMonth()+1).padStart(2,"0")}-${String(date.getDate()).padStart(2,"0")}`;
+
+// ✅ AFTER: single utility
+function formatDate(date: Date): string {
+  return date.toISOString().split("T")[0];
+}
+```
+
+## 5. God Component → Split by Responsibility
+
+**Smell:** React component with 200+ lines, multiple useEffects, mixed concerns.
+
+```tsx
+// ❌ BEFORE: UserDashboard handles data fetching, filtering, rendering, modals
+function UserDashboard() {
+  // 50 lines of state + effects
+  // 30 lines of handlers
+  // 120 lines of JSX with inline conditions
+}
+
+// ✅ AFTER: Split into container + presentation + hook
+function useUserDashboard() { /* data fetching + state */ }
+function UserFilters({ filters, onChange }) { /* filter UI */ }
+function UserTable({ users, onSelect }) { /* table UI */ }
+function UserDashboard() {
+  const { users, filters, setFilters } = useUserDashboard();
+  return (
+    <>
+      <UserFilters filters={filters} onChange={setFilters} />
+      <UserTable users={users} />
+    </>
+  );
+}
+```
+
+## 6. Complex Conditional → Strategy Pattern / Early Return
+
+**Smell:** Nested if/else chains with 4+ branches.
+
+```typescript
+// ❌ BEFORE: nested conditionals
+function getPrice(user: User, product: Product) {
+  if (user.type === "premium") {
+    if (product.category === "electronics") {
+      return product.price * 0.8;
+    } else {
+      return product.price * 0.9;
+    }
+  } else if (user.type === "wholesale") {
+    return product.price * 0.7;
+  } else {
+    return product.price;
+  }
+}
+
+// ✅ AFTER: strategy map + early return
+const DISCOUNT_STRATEGIES: Record<string, (p: Product) => number> = {
+  premium: (p) => p.category === "electronics" ? 0.8 : 0.9,
+  wholesale: () => 0.7,
+  standard: () => 1.0,
+};
+
+function getPrice(user: User, product: Product) {
+  const discount = DISCOUNT_STRATEGIES[user.type] ?? DISCOUNT_STRATEGIES.standard;
+  return product.price * discount(product);
+}
+```
+
+## Priority Assessment Guide
+
+| Severity | Criteria | Action |
+|----------|----------|--------|
+| **P0 - Critical** | Security risk, data corruption, breaking API contract | Fix immediately |
+| **P1 - High** | >3 duplications, god objects, untestable code | Fix in current sprint |
+| **P2 - Medium** | Long functions, primitive obsession, feature envy | Schedule for refactoring |
+| **P3 - Low** | Minor naming issues, small duplications, style | Fix opportunistically |

package/scaffold/en/templates/brainstorm-matrix.md

@@ -0,0 +1,44 @@
+# Brainstorm: {{TOPIC}}
+
+## Context
+
+{{CONTEXT_DESCRIPTION}}
+
+## Options Matrix
+
+| Criteria | Option A: {{NAME_A}} | Option B: {{NAME_B}} | Option C: {{NAME_C}} |
+|----------|----------------------|----------------------|----------------------|
+| **Approach** | | | |
+| **Effort** | Low / Medium / High | Low / Medium / High | Low / Medium / High |
+| **Risk** | Low / Medium / High | Low / Medium / High | Low / Medium / High |
+| **Scalability** | | | |
+| **Maintainability** | | | |
+| **Dependencies** | | | |
+
+## Trade-offs
+
+### Option A: {{NAME_A}}
+- **Pros:** 
+- **Cons:** 
+- **Best when:** 
+
+### Option B: {{NAME_B}}
+- **Pros:** 
+- **Cons:** 
+- **Best when:** 
+
+### Option C: {{NAME_C}}
+- **Pros:** 
+- **Cons:** 
+- **Best when:** 
+
+## Recommendation
+
+**Recommended:** Option {{X}}
+
+**Rationale:** {{WHY}}
+
+## Next Steps
+
+- [ ] Validate with stakeholders
+- [ ] Create PRD: `/dw-create-prd`

package/scaffold/en/templates/functional-doc/case-matrix.md

@@ -0,0 +1,5 @@
+# Case Matrix
+
+| ID | Feature | Case Type | Preconditions | Actions | Expected Result | Expected Message | Status | Evidence |
+|----|---------|-----------|---------------|---------|-----------------|------------------|--------|----------|
+{{rows}}

package/scaffold/en/templates/functional-doc/e2e-runbook.md

@@ -0,0 +1,3 @@
+# E2E Runbook
+
+{{steps}}

package/scaffold/en/templates/functional-doc/features.md

@@ -0,0 +1,3 @@
+# Features
+
+{{features}}

package/scaffold/en/templates/functional-doc/overview.md

@@ -0,0 +1,21 @@
+# Functional Dossier
+
+- **Project:** {{projectName}}
+- **Target:** {{target}}
+- **Type:** {{targetType}}
+- **Detected framework:** {{framework}}
+- **Base URL:** {{baseUrl}}
+- **E2E Runner:** {{playwrightStatus}}
+- **Generated at:** {{generatedAt}}
+
+## Summary
+
+{{summary}}
+
+## Analyzed Sources
+
+{{sources}}
+
+## Blockers
+
+{{blockers}}

package/scaffold/en/templates/functional-doc/playwright.spec.ts.tpl

@@ -0,0 +1,19 @@
+import { test, expect } from "@playwright/test";
+
+const BASE_URL = process.env.BASE_URL ?? "{{baseUrl}}";
+
+test("{{testTitle}}", async ({ page }) => {
+  const evidence = [] as string[];
+
+  await test.step("Open target route", async () => {
+    await page.goto(`${BASE_URL}{{routePath}}`);
+    await expect(page).toHaveURL(new RegExp("{{routeRegex}}"));
+    evidence.push("navigation");
+  });
+
+{{testSteps}}
+
+  await test.step("Record final context", async () => {
+    expect(evidence.length).toBeGreaterThan(0);
+  });
+});

package/scaffold/en/templates/pr-bugfix-template.md

@@ -0,0 +1,28 @@
+## Summary
+
+- **Bug:** {{ORIGINAL_PROBLEM}}
+- **Root Cause:** {{WHY_IT_HAPPENED}}
+- **Solution:** {{WHAT_WAS_FIXED}}
+
+## Changes
+
+{{CHANGES_LIST}}
+
+## Test Evidence
+
+- **Before fix:** {{SCREENSHOT_OR_ERROR_BEFORE}}
+- **After fix:** {{SCREENSHOT_OR_RETEST_PASS}}
+- **Related unit tests:** {{TEST_LIST}}
+
+## Test Plan
+
+- [ ] Unit tests pass
+- [ ] Build succeeds
+- [ ] Lint passes
+- [ ] Manually tested the fix scenario
+- [ ] Verified no regression in related features
+
+## Related
+
+- Issue: {{ISSUE_LINK}}
+- Bugfix analysis: `.dw/spec/bugfix-{{NAME}}/prd.md` (if applicable)

package/scaffold/en/templates/qa-test-credentials.md

@@ -0,0 +1,37 @@
+# QA Test Credentials
+
+## Credential Profiles
+
+| Profile | Login | Password | Role | Scope | Use When |
+|---------|-------|----------|------|-------|----------|
+| **Admin** | admin@test.com | {{PASSWORD}} | Administrator | Full access | Testing admin flows, user management, settings |
+| **Standard User** | user@test.com | {{PASSWORD}} | User | Standard access | Testing happy paths, main user flows |
+| **Restricted** | restricted@test.com | {{PASSWORD}} | Viewer | Read-only | Testing permission blocks, access denied scenarios |
+| **Multi-tenant A** | tenant-a@test.com | {{PASSWORD}} | User | Tenant A | Testing tenant isolation, data segregation |
+| **Multi-tenant B** | tenant-b@test.com | {{PASSWORD}} | User | Tenant B | Testing cross-tenant access blocks |
+
+## Password Fallback Order
+
+If the primary password fails, try in order:
+1. `{{PRIMARY_PASSWORD}}`
+2. `{{FALLBACK_1}}`
+3. `{{FALLBACK_2}}`
+
+If all fail, mark authentication as **BLOCKED** in the manifest.
+
+## Login Method
+
+- **URL:** {{LOGIN_URL}}
+- **Auth provider:** {{AUTH_PROVIDER}} (e.g., Keycloak, Auth0, NextAuth)
+- **Login field:** Email / Username / CPF (choose based on provider)
+- **Notes:** {{NOTES}}
+
+## Selection Guide
+
+| Bug / Flow Type | Recommended Profile | Why |
+|-----------------|--------------------|----|
+| Happy path testing | Standard User | Represents typical usage |
+| Permission denied tests | Restricted | Validates access control |
+| Admin features | Admin | Full access needed |
+| Multi-tenant isolation | Tenant A + Tenant B | Tests data boundaries |
+| Auth/login flow | All profiles | Tests each access level |

package/scaffold/en/templates/tasks-template.md

@@ -31,4 +31,4 @@ Each task follows this flow:
 1. `/execute-task [N]_task.md` - Implements the task
 2. Unit tests included in the implementation
 3. Commit at the end of each task (no push)
-4. Next task or `/generate-pr [target-branch]` when all tasks are completed
+4. Next task or `/dw-generate-pr [target-branch]` when all tasks are completed