@jhm1909/ag-kit 0.1.0

package/.agent/skills/qa-tester/references/e2e_testing.md

@@ -0,0 +1,46 @@
+# E2E Testing Insights & Patterns
+
+## Core Philosophy
+
+**"Simulate the Real User"**
+E2E tests don't care about your code; they care about your UI. They are the final gatekeeper before production.
+
+## The Page Object Model (POM)
+
+POM is mandatory for maintainable E2E suites. It decouples the _test logic_ from the _page structure_.
+
+- **Page Class**: Contains selectors (`this.submitBtn`) and actions (`async submit()`).
+- **Test File**: Reads like a user story (`await loginPage.login()`).
+
+## Resilient Selectors
+
+**Avoid Implementation Details**
+
+- ❌ `div > .btn-primary` (Brittle: breaks if CSS changes)
+- ✅ `getByRole('button', { name: 'Submit' })` (Resilient: relies on accessibility tree)
+- ✅ `getByTestId('submit-order')` (Explicit contract)
+
+## State Management
+
+- **Login**: Don't log in via UI for every test. Use API calls to set the session cookie, then visit the page.
+- **Data**: Create unique data per test (e.g., `user_${timestamp}`) to avoid collision.
+
+## Example (Playwright)
+
+```typescript
+// pages/CheckoutPage.ts
+export class CheckoutPage {
+  constructor(private page: Page) {}
+  async placeOrder() {
+    await this.page.getByRole("button", { name: "Place Order" }).click();
+  }
+}
+
+// tests/checkout.spec.ts
+test("Guest checkout flow", async ({ page }) => {
+  const checkout = new CheckoutPage(page);
+  await page.goto("/cart");
+  await checkout.placeOrder();
+  await expect(page.getByText("Thank you!")).toBeVisible();
+});
+```

package/.agent/skills/qa-tester/references/integration_testing.md

@@ -0,0 +1,39 @@
+# Integration Testing Insights & Patterns
+
+## Core Philosophy
+
+**"Verify the Handshake"**
+Integration tests ensure that your modules speak the same language. The most critical integration is usually between your **Logic Layer** and your **Persistence Layer**.
+
+## Scope of Integration
+
+1.  **Service + Database**: Does the ORM query actually work? adhere to constraints?
+2.  **Service + External API**: Does the adapter handle the 3rd party response format correctly?
+3.  **Controller + Service**: Does the HTTP layer correctly parse inputs before calling logic?
+
+## Testing Strategy
+
+1.  **Real Database (Containerized)**: Use a real Postgres/MySQL container. Mocks can lie; databases don't.
+2.  **Transactional Rollbacks**: If possible, wrap tests in transactions that rollback, or truncate tables between tests.
+3.  **Seed Data**: Use factories (e.g., `UserFactory.create()`) to set up complex states quickly.
+
+## Example (API + DB)
+
+```typescript
+describe("POST /api/register", () => {
+  it("should persist user and return 201", () => {
+    // Arrange
+    const payload = { email: "test@example.com" };
+
+    // Act
+    const response = await api.post("/register", payload);
+
+    // Assert (Response)
+    expect(response.status).toBe(201);
+
+    // Assert (Persistence)
+    const dbUser = await db.users.find({ email: payload.email });
+    expect(dbUser).not.toBeNull();
+  });
+});
+```

package/.agent/skills/qa-tester/references/performance_testing.md

@@ -0,0 +1,44 @@
+# Performance Testing Insights & Patterns
+
+## Core Philosophy
+
+**"Performance is a Feature"**
+A slow system is a broken system. Performance testing establishes the baseline and catches regressions before they crash production.
+
+## Metrics That Matter
+
+1.  **Latency**: Time to First Byte (TTFB) and Total Duration. (e.g., "95% of requests < 500ms")
+2.  **Throughput**: Requests Per Second (RPS) the system can handle.
+3.  **Error Rate**: Percentage of failed requests under load.
+
+## Testing Types
+
+1.  **Load Testing**: Simulating expected peak traffic. (Can we handle Black Friday?)
+2.  **Stress Testing**: Finding the breaking point. (At what RPS does the DB crash?)
+3.  **Soak Testing**: Running load for distinct periods (e.g., 24h) to find memory leaks.
+
+## Tools of Trade
+
+- **k6**: Developer-friendly, scriptable in JS.
+- **Artillery**: Good for testing Socket.io/WebSockets.
+
+## Example (k6 Script)
+
+```javascript
+import http from "k6/http";
+import { check, sleep } from "k6";
+
+export const options = {
+  vus: 100, // Virtual Users
+  duration: "30s",
+  thresholds: {
+    http_req_duration: ["p(95)<500"], // 95% of requests must be faster than 500ms
+  },
+};
+
+export default function () {
+  const res = http.get("https://api.myapp.com/products");
+  check(res, { "is status 200": (r) => r.status === 200 });
+  sleep(1);
+}
+```

package/.agent/skills/qa-tester/references/property_based_testing.md

@@ -0,0 +1,44 @@
+# Property-Based Testing Guide
+
+> Source: Trail of Bits — property-based-testing skill
+
+Use PBT when you detect patterns where it provides stronger coverage than example-based tests.
+
+## Auto-Detection Triggers
+
+| Pattern | Property | Priority |
+|---------|----------|----------|
+| encode/decode pair | Roundtrip: `decode(encode(x)) == x` | HIGH |
+| Pure function | Multiple properties | HIGH |
+| Validator | Valid after normalize | MEDIUM |
+| Sorting/ordering | Idempotence + ordering | MEDIUM |
+| Normalization | Idempotence: `f(f(x)) == f(x)` | MEDIUM |
+
+## Property Catalog
+
+| Property | Formula | When |
+|----------|---------|------|
+| **Roundtrip** | `decode(encode(x)) == x` | Serialization pairs |
+| **Idempotence** | `f(f(x)) == f(x)` | Normalization, formatting |
+| **Invariant** | Property holds before/after | Any transformation |
+| **Commutativity** | `f(a, b) == f(b, a)` | Set operations |
+| **Oracle** | `new_impl(x) == reference(x)` | Optimization, refactoring |
+| **No Exception** | No crash on valid input | Baseline property |
+
+**Strength hierarchy**: No Exception → Type Preservation → Invariant → Idempotence → Roundtrip
+
+## Libraries
+
+| Language | Library |
+|----------|---------|
+| Python | Hypothesis |
+| JavaScript | fast-check |
+| Rust | proptest |
+| Go | gopter |
+| Java | jqwik |
+
+## How to Suggest PBT
+
+> "I notice `encode_message`/`decode_message` is a serialization pair. PBT with roundtrip property would provide stronger coverage. Want me to use that approach?"
+
+If user declines → write good example-based tests, no further prompting.

package/.agent/skills/qa-tester/references/security_audit.md

@@ -0,0 +1,53 @@
+# Security Audit: Insecure Defaults Detection
+
+> Source: Trail of Bits — insecure-defaults skill
+
+Finds **fail-open** vulnerabilities where apps run insecurely with missing configuration.
+
+## Key Distinction
+- **Fail-open (CRITICAL):** `SECRET = env.get('KEY') or 'default'` → App runs with weak secret
+- **Fail-secure (SAFE):** `SECRET = env['KEY']` → App crashes if missing
+
+## Search Patterns
+
+**Fallback secrets:**
+- `getenv.*\) or ['"]` | `process\.env\.[A-Z_]+ \|\| ['"]` | `ENV\.fetch.*default:`
+
+**Hardcoded credentials:**
+- `password.*=.*['"][^'"]{8,}['"]` | `api[_-]?key.*=.*['"][^'"]+['"]`
+
+**Weak defaults:**
+- `DEBUG.*=.*true` | `AUTH.*=.*false` | `CORS.*=.*\*`
+
+**Weak crypto:**
+- `MD5|SHA1|DES|RC4|ECB` in security contexts
+
+## Workflow
+
+### 1. SEARCH — Find insecure defaults
+Focus on `**/config/`, `**/auth/`, `**/database/`, and env files.
+
+### 2. VERIFY — Check actual behavior
+- When is this code executed?
+- What happens if config variable is missing?
+- Is there validation enforcing secure configuration?
+
+### 3. CONFIRM — Production impact
+- Production config provides the variable → Lower severity
+- Production config missing → CRITICAL
+
+### 4. REPORT — With evidence
+```
+Finding: Hardcoded JWT Secret Fallback
+Location: src/auth/jwt.ts:15
+Pattern: const secret = process.env.JWT_SECRET || 'default';
+Verification: App starts without JWT_SECRET set
+Exploitation: Attacker forges JWTs using 'default'
+```
+
+## Rationalizations to Reject
+
+- "It's just a development default" → If it reaches production code, it's a finding
+- "The production config overrides it" → Verify prod config exists
+- "This would never run without proper config" → Prove it with code trace
+- "We'll fix it before release" → Document now; "later" rarely comes

package/.agent/skills/qa-tester/references/security_testing.md

@@ -0,0 +1,30 @@
+# Security Testing Insights & Patterns
+
+## Core Philosophy
+
+**"Trust No Input"**
+Assume every input field, header, and parameter is an attack vector. Security testing proactively seeks to exploit these vectors.
+
+## Key Attack Vectors
+
+1.  **XSS (Cross-Site Scripting)**:
+    - **Insight**: Browsers execute scripts reflected from the server.
+    - **Test**: Inject `<img src=x onerror=alert(1)>` into comments/profiles.
+2.  **SQL Injection (SQLi)**:
+    - **Insight**: Manipulating queries via input.
+    - **Test**: Input `' OR '1'='1` in search bars or login forms.
+3.  **IDOR (Insecure Direct Object References)**:
+    - **Insight**: Changing an ID in the URL (`/orders/5`) to access another user's data (`/orders/6`).
+    - **Test**: Login as User A, request User B's resource ID.
+
+## Automation
+
+- **SAST (Static Application Security Testing)**: Scan code for known vulnerabilities (e.g., `npm audit`, `SonarQube`).
+- **DAST (Dynamic Application Security Testing)**: Attack the running app (e.g., `OWASP ZAP`).
+
+## Checklist
+
+- [ ] Are dependencies patched? (`npm audit`)
+- [ ] Is Rate Limiting active?
+- [ ] Are sensitive headers (Authorization) leaked in logs?
+- [ ] Do 403 Forbidden errors leak implementation details?

package/.agent/skills/qa-tester/references/sharp_edges.md

@@ -0,0 +1,49 @@
+# Sharp Edges: API Footgun Analysis
+
+> Source: Trail of Bits — sharp-edges skill
+
+Evaluates whether APIs, configs, and interfaces are resistant to developer misuse.
+
+## Core Principle
+**The pit of success**: Secure usage should be the path of least resistance.
+
+## 6 Categories of Sharp Edges
+
+### 1. Algorithm/Mode Selection Footguns
+APIs that let devs choose algorithms invite choosing wrong ones.
+- Detection: `algorithm`, `mode`, `cipher`, `hash_type` parameters
+
+### 2. Dangerous Defaults
+Defaults that are insecure, or zero/empty values that disable security.
+- Ask: What happens with `timeout=0`? `max_attempts=0`? `key=""`?
+
+### 3. Primitive vs. Semantic APIs
+APIs exposing raw bytes instead of meaningful types invite confusion.
+- Detection: Functions taking `bytes`/`string` for distinct security concepts
+
+### 4. Configuration Cliffs
+One wrong setting creates catastrophic failure with no warning.
+- Detection: Boolean flags that disable security entirely
+
+### 5. Silent Failures
+Errors that don't surface, or success that masks failure.
+- Detection: Functions returning booleans instead of throwing on security failures
+
+### 6. Stringly-Typed Security
+Security-critical values as plain strings enable injection.
+- Detection: Permissions as comma-separated strings instead of enums
+
+## 3 Adversary Types
+
+1. **The Scoundrel** — Actively malicious (can they disable security via config?)
+2. **The Lazy Developer** — Copy-pastes examples (is the first example secure?)
+3. **The Confused Developer** — Misunderstands API (can parameters be swapped?)
+
+## Severity
+
+| Severity | Criteria |
+|----------|----------|
+| Critical | Default or obvious usage is insecure |
+| High | Easy misconfiguration breaks security |
+| Medium | Unusual but possible misconfiguration |
+| Low | Requires deliberate misuse |

package/.agent/skills/qa-tester/references/static_analysis.md

@@ -0,0 +1,52 @@
+# Static Analysis with Semgrep
+
+> Source: Trail of Bits — static-analysis/semgrep skill
+
+Run Semgrep scan with language detection and parallel execution.
+
+## Essential Principles
+
+1. **Always use `--metrics=off`** — prevent telemetry data leakage
+2. **User must approve scan plan** — present rulesets before scanning
+3. **Third-party rulesets required** — Trail of Bits, 0xdea, Decurity rules catch vendor-missing vulns
+4. **Check for Semgrep Pro** — cross-file taint tracking catches ~250% more true positives
+
+## Scan Modes
+
+| Mode | Coverage | Findings |
+|------|----------|----------|
+| **Run all** | All rulesets, all severity | Everything |
+| **Important only** | Pre/post-filtered | Security vulns, medium-high confidence |
+
+## Quick Workflow
+
+### 1. Detect languages + check Pro
+```bash
+semgrep --version
+semgrep --pro --validate --config p/default 2>/dev/null && echo "Pro" || echo "OSS"
+```
+
+### 2. Select rulesets per language
+Include official + third-party rules for each detected language.
+
+### 3. Get user approval (HARD GATE)
+Present exact rulesets, target, engine, and mode — wait for "yes".
+
+### 4. Run parallel scans
+One scan per language/ruleset combination. All in parallel.
+
+### 5. Merge & report
+Merge SARIF outputs, summarize by severity and category.
+
+## Key Commands
+
+```bash
+# Basic scan
+semgrep --config p/security-audit --metrics=off --sarif -o results.sarif .
+
+# Important only
+semgrep --config p/security-audit --metrics=off --severity MEDIUM --severity HIGH --severity CRITICAL .
+
+# With third-party rules
+semgrep --config p/security-audit --config "https://semgrep.dev/p/trailofbits" --metrics=off .
+```

package/.agent/skills/qa-tester/references/supply_chain_audit.md

@@ -0,0 +1,54 @@
+# Supply Chain Risk Audit
+
+> Source: Trail of Bits — supply-chain-risk-auditor skill
+
+Systematically evaluate all dependencies to identify risk of exploitation or takeover.
+
+## Risk Criteria
+
+A dependency is high-risk if:
+
+| Factor | Description |
+|--------|-------------|
+| **Single maintainer** | Solo individual, not org-backed. Anonymous = higher risk |
+| **Unmaintained** | No updates for long period, archived, or seeking new maintainers |
+| **Low popularity** | Few GitHub stars/downloads relative to other deps |
+| **High-risk features** | FFI, deserialization, third-party code execution |
+| **Past CVEs** | High/critical severity CVEs, especially many relative to size |
+| **No security contact** | No SECURITY.md, no security email listed |
+
+## Workflow
+
+### 1. Initial Setup
+```bash
+# List all direct dependencies
+cat package.json | jq '.dependencies' # Node.js
+# or: pip list --format=json | jq '.[].name' # Python
+```
+
+### 2. For Each Dependency
+Use `gh` CLI to check:
+- Stars count, last commit date
+- Number of contributors
+- Open security issues
+- SECURITY.md presence
+
+### 3. Report
+For each high-risk dep:
+- Risk factors identified
+- Suggested alternatives (more popular, better maintained)
+- Short justification
+
+### 4. Summary
+- Total deps scanned
+- Count by risk factor
+- Executive summary of security posture
+- Top recommendations
+
+## Example Output
+```markdown
+| Dependency | Risk Factors | Alternative |
+|-----------|-------------|-------------|
+| tiny-parser | Single maintainer, 12⭐, no SECURITY.md | safer-parser (org-backed, 5k⭐) |
+| old-crypto | Unmaintained (2yr), 3 CVEs | node:crypto (built-in) |
+```

package/.agent/skills/qa-tester/references/test_case_standards.md

@@ -0,0 +1,96 @@
+# Test Case Standards & Templates
+
+To ensure "detailed and specific" test testing, all test cases must follow these standards.
+
+## 1. The Anatomy of a Perfect Test Case
+
+A test case is not just a sentence; it is a script that a machine or a human can execute without ambiguity.
+
+| Field               | Description                                  | Example                                                                        |
+| :------------------ | :------------------------------------------- | :----------------------------------------------------------------------------- |
+| **ID**              | Unique Identifier                            | `TC-AUTH-001`                                                                  |
+| **Title**           | Concise summary including Condition & Result | `Login - Valid Credentials - Redirects to Dashboard`                           |
+| **Priority**        | P0 (Critical), P1 (High), P2 (Medium)        | `P0`                                                                           |
+| **Type**            | Functional, Security, UI, Performance, API   | `Functional`                                                                   |
+| **Pre-conditions**  | State required _before_ the test starts      | 1. App is open<br>2. User is registered<br>3. User is logged out               |
+| **Test Data**       | Specific data values used                    | email: `test@example.com`, pass: `Correct123!`                                 |
+| **Steps**           | Numbered, atomic actions                     | 1. Click "Login" button<br>2. Enter email<br>3. Enter password<br>4. Submit    |
+| **Expected Result** | Verifiable outcome for _each_ critical step  | 1. Login form appears<br>4. Dashboard loads within 2s, "Welcome" toast appears |
+
+## 2. Granularity Rules
+
+- **One Action per Step**: Do not combine actions.
+  - ❌ _Bad_: "Enter credentials and click login."
+  - ✅ _Good_:
+    1. Enter "user@example.com" in Email field.
+    2. Enter "password" in Password field.
+    3. Click "Sign In" button.
+- **Specific Data**: Never use "valid data" or "random text".
+  - ❌ _Bad_: "Enter valid email."
+  - ✅ _Good_: "Enter `user_verified@domain.com`."
+- **Verifiable Results**: Avoid vague outcomes.
+  - ❌ _Bad_: "It works."
+  - ✅ _Good_: "URL changes to `/dashboard`, and 'Logout' button is visible."
+
+## 3. Test Case Templates
+
+### Template A: UI/Functional Test
+
+```markdown
+**ID**: TC-[Module]-[Number]
+**Title**: [Action] - [Condition] -> [Outcome]
+**Priority**: [P0/P1/P2]
+**Pre-conditions**:
+
+1. [State 1]
+2. [State 2]
+
+**Test Data**:
+
+- [Field 1]: [Value]
+- [Field 2]: [Value]
+
+**Steps**:
+
+1. [Step 1 execution]
+2. [Step 2 execution]
+
+**Expected Results**:
+
+- [Verification 1]
+- [Verification 2]
+```
+
+### Template B: API Test
+
+````markdown
+**ID**: API-[Endpoint]-[Number]
+**Title**: [Method] [Endpoint] - [Scenario]
+**Priority**: P1
+
+**Request**:
+
+- Method: POST
+- URL: `/api/v1/orders`
+- Headers: `Authorization: Bearer <token>`
+- Body:
+  ```json
+  { "item": "id_123", "qty": 1 }
+  ```
+````
+
+**Expected Response**:
+
+- Status Code: 201 Created
+- Body Schema Match: `OrderResponse`
+- DB Info: Record created in `orders` table
+
+```
+
+## 4. Writing Best Practices
+
+1. **Golden Path First**: Always write the "Happy Path" (Success case) first.
+2. **Negative Testing**: Immediately follow with failure cases (Validation errors, Timeout, Bad Auth).
+3. **Atomic Independence**: Tests should not depend on the "memory" of previous tests (unless explicitly an End-to-End flow).
+4. **Clean Up**: If a test creates data (e.g., "Create User"), define the cleanup or use ephemeral environments.
+```

package/.agent/skills/qa-tester/references/test_report_template.md

@@ -0,0 +1,32 @@
+# Test Execution Report
+
+**Date**: {{DATE}}
+**Environment**: {{ENVIRONMENT}} (e.g., Local, Staging)
+**Commit**: {{COMMIT_HASH}}
+
+## Executive Summary
+
+- **Total Tests**: {{TOTAL}}
+- **Passed**: {{PASSED}} ({{PASS_RATE}}%)
+- **Failed**: {{FAILED}}
+- **Skipped**: {{SKIPPED}}
+- **Critical Defects Found**: {{CRITICAL_COUNT}}
+
+## Failure Analysis
+
+| Test ID       | Failure Message                       | Root Cause                  | Resolution                            |
+| :------------ | :------------------------------------ | :-------------------------- | :------------------------------------ |
+| `TC-AUTH-002` | `Expected 'Dashboard', found 'Login'` | Auth token expiry logic bug | **Fixed**: Updated `auth.ts` logic    |
+| `TC-CART-005` | `Checkout button not clickable`       | Z-index overlap             | **Fixed**: Adjusted CSS in `cart.css` |
+
+## Bug Resolution Log
+
+(List of bugs fixed during this cycle)
+
+1. Found [Active Bug] during `TC-AUTH-002`. Fixed in [File Link]. Verified Pass.
+2. Found [Active Bug] during `TC-UI-009`. Fixed in [File Link]. Verified Pass.
+
+## Recommendations
+
+- [ ] Merge to production
+- [ ] Requires manual review of [Specific Feature]

package/.agent/skills/qa-tester/references/unit_testing.md

@@ -0,0 +1,50 @@
+# Unit Testing Insights & Patterns
+
+## Core Philosophy
+
+**"Test Behavior, Not Implementation"**
+Unit tests should verify _what_ the code does, not _how_ it does it. This makes refactoring safer.
+
+## The AAA Pattern (Arrange, Act, Assert)
+
+This is the gold standard for readability.
+
+1.  **Arrange**: meticulous setup of inputs and mocks.
+2.  **Act**: A single line of code triggering the function.
+3.  **Assert**: Clear verification of the output.
+
+## Dealing with Dependencies
+
+**Mock Everything External**
+
+- Database calls? Mock them.
+- API requests? Mock them.
+- File system? Mock it.
+  If you touch the database, it's not a unit test (it's integration).
+
+## Best Practices
+
+1.  **Descriptive Naming**: `it('should return 400 if email is invalid')` is better than `it('test error')`.
+2.  **One Concept Per Test**: Don't test validation and success in the same `it` block.
+3.  **Boundary Value Analysis**: Always test `0`, `1`, `Max`, `Max+1`, `null`, `undefined`.
+
+## Example (Vitest)
+
+```typescript
+import { describe, it, expect, vi } from "vitest";
+import { calculateDiscount } from "./pricing.utils";
+
+describe("Pricing Utils", () => {
+  it("should apply 10% discount for VIP users", () => {
+    // Arrange
+    const user = { type: "VIP" };
+    const price = 100;
+
+    // Act
+    const finalPrice = calculateDiscount(user, price);
+
+    // Assert
+    expect(finalPrice).toBe(90);
+  });
+});
+```

package/.agent/skills/qa-tester/references/visual_testing.md

@@ -0,0 +1,32 @@
+# Visual Regression Testing
+
+> **Optional Module**: Consult this guide when pixel-perfect UI stability is required.
+
+## Purpose
+
+Detect unintended visual changes (layout shifts, color changes, broken assets) that functional tests might miss.
+
+## Strategy
+
+1. **Golden Snapshots**: Commit "approved" screenshots of UI states to the repo.
+2. **Comparison**: On test run, capture new screenshot and diff pixel-by-pixel.
+3. **Threshold**: Allow a small % (e.g., 0.1%) difference for anti-aliasing noise.
+
+## Implementation (Playwright)
+
+```typescript
+test("profile card looks correct", async ({ page }) => {
+  await page.goto("/profile/123");
+
+  // Mask dynamic content (dates, usernames) to prevent flakes
+  await expect(page).toHaveScreenshot("profile-card.png", {
+    mask: [page.locator(".timestamp")],
+    maxDiffPixelRatio: 0.01,
+  });
+});
+```
+
+## Best Practices
+
+- **Dockerize**: Run visual tests in Docker to ensure font rendering consistency across OSs.
+- **Component Level**: Prefer Visual Testing at the Storybook/Component level (using Percy/Chromatic) over full page E2E screenshots.

package/.agent/skills/qa-tester/templates/uat-plan.md

@@ -0,0 +1,34 @@
+# User Acceptance Test (UAT) Plan
+
+## 1. Overview
+
+- **Feature**: ...
+- **Version**: ...
+- **Testers**: [List of Business Users]
+- **Environment**: Staging / UAT Sandbox
+
+## 2. Test Strategy
+
+- **Scope**: Verification of "Happy Path" and key business rules.
+- **Out of Scope**: Load testing, Security penetration testing.
+- **Entry Criteria**: QA Pass, Critical bugs fixed.
+- **Exit Criteria**: 100% Critical cases passed, Sign-off from Product Owner.
+
+## 3. Test Cases
+
+| ID     | Description      | Steps                                  | Expected Result                   | Actual Result | Status (Pass/Fail) |
+| :----- | :--------------- | :------------------------------------- | :-------------------------------- | :------------ | :----------------- |
+| UAT-01 | Login successful | 1. Enter valid creds<br>2. Click Login | Redirect to Dashboard             |               |                    |
+| UAT-02 | Purchase item    | 1. Add to cart<br>2. Checkout          | Order Confirmation Email received |               |                    |
+
+## 4. Defect Log (Template)
+
+| Defect ID | Severity | Description                         | Steps to Reproduce | Assigned To |
+| :-------- | :------- | :---------------------------------- | :----------------- | :---------- |
+| BUG-101   | High     | Checkout crashes on currency switch | ...                | Dev Team    |
+
+## 5. Sign-off
+
+- [ ] I confirm the system meets business requirements.
+- **Name**: ...
+- **Date**: ...