agentic-qe 3.8.2 → 3.8.3

package/.claude/skills/contract-testing/references/agent-commands.md

@@ -0,0 +1,103 @@
+# Contract Testing — Agent CLI Commands & Advanced Patterns
+
+Merged from `qe-contract-testing`. Use these when working with v3 agent-specific contract capabilities.
+
+## AQE CLI Commands
+
+```bash
+# Generate contract from API spec
+aqe contract generate --api openapi.yaml --output contracts/
+
+# Verify provider against contracts
+aqe contract verify --provider http://localhost:3000 --contracts contracts/
+
+# Check breaking changes between versions
+aqe contract breaking --old api-v1.yaml --new api-v2.yaml
+
+# Test GraphQL schema
+aqe contract graphql --schema schema.graphql --operations queries/
+```
+
+## Agent Workflow
+
+```typescript
+// Contract generation
+Task("Generate API contracts", `
+  Analyze the REST API and generate consumer contracts:
+  - Parse OpenAPI specification
+  - Identify critical endpoints
+  - Generate Pact contracts
+  - Include example requests/responses
+  Output to contracts/ directory.
+`, "qe-api-contract")
+
+// Breaking change detection
+Task("Check API compatibility", `
+  Compare API v2.0 against v1.0:
+  - Detect removed endpoints
+  - Check parameter changes
+  - Verify response schema changes
+  - Identify deprecations
+  Report breaking vs non-breaking changes.
+`, "qe-api-compatibility")
+```
+
+## GraphQL Contract Testing
+
+```typescript
+await graphqlTester.testContracts({
+  schema: 'schema.graphql',
+  operations: 'queries/**/*.graphql',
+  validation: {
+    queryValidity: true,
+    responseShapes: true,
+    nullability: true,
+    deprecations: true
+  }
+});
+```
+
+## Event Contract Testing
+
+```typescript
+await contractTester.eventContracts({
+  schema: 'events/schemas/',
+  events: {
+    'user.created': {
+      schema: 'UserCreatedEvent.json',
+      examples: ['examples/user-created.json']
+    },
+    'order.completed': {
+      schema: 'OrderCompletedEvent.json',
+      examples: ['examples/order-completed.json']
+    }
+  },
+  compatibility: 'backward'
+});
+```
+
+## Contract Report Interface
+
+```typescript
+interface ContractReport {
+  summary: { contracts: number; passed: number; failed: number; warnings: number };
+  consumers: { name: string; contracts: ContractResult[]; compatibility: 'compatible' | 'breaking' | 'unknown' }[];
+  breakingChanges: { type: string; location: string; description: string; impact: 'high' | 'medium' | 'low'; migration: string }[];
+  deprecations: { item: string; deprecatedIn: string; removeIn: string; replacement: string }[];
+}
+```
+
+## Pact Broker Integration
+
+```typescript
+await contractTester.withBroker({
+  brokerUrl: 'https://pact-broker.example.com',
+  auth: { token: process.env.PACT_TOKEN },
+  operations: { publish: true, canIDeploy: true, webhooks: true }
+});
+```
+
+## Coordination
+
+**Primary Agents**: qe-api-contract, qe-api-compatibility, qe-graphql-tester
+**Coordinator**: qe-contract-coordinator

package/.claude/skills/contract-testing/references/provider-states.md

@@ -0,0 +1,45 @@
+# Provider States Reference
+
+Provider states define the preconditions that must exist on the provider for a contract interaction to succeed.
+
+## Pattern: State Setup
+```javascript
+// provider-states.js
+const states = {
+  'a user exists': async () => {
+    await db.users.create({ id: 1, name: 'Test User', email: 'test@example.com' });
+  },
+  'no users exist': async () => {
+    await db.users.deleteAll();
+  },
+  'user 1 has 3 orders': async () => {
+    await db.users.create({ id: 1, name: 'Test User' });
+    await db.orders.bulkCreate([
+      { userId: 1, status: 'shipped' },
+      { userId: 1, status: 'pending' },
+      { userId: 1, status: 'delivered' }
+    ]);
+  }
+};
+```
+
+## Common Mistakes
+1. **State not cleaned up** — use transactions or truncate after each test
+2. **Hardcoded IDs** — use factories or fixtures that generate consistent IDs
+3. **Missing state** — provider test passes without state setup (no data = no error)
+4. **Overly specific states** — "user John with email john@..." couples to consumer
+
+## Pact Broker Webhook Setup
+```bash
+# Verify provider when consumer publishes new contract
+curl -X POST ${PACT_BROKER_URL}/webhooks \
+  -H "Content-Type: application/json" \
+  -d '{
+    "events": [{ "name": "contract_content_changed" }],
+    "request": {
+      "method": "POST",
+      "url": "${CI_TRIGGER_URL}",
+      "body": { "pact_url": "${pactbroker.pactUrl}" }
+    }
+  }'
+```

package/.claude/skills/coverage-drop-investigator/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: coverage-drop-investigator
+description: "Use when test coverage has dropped and you need to find which changes caused it and what tests to add. Traces coverage regressions to specific commits and files."
+user-invocable: true
+---
+
+# Coverage Drop Investigator
+
+Runbook-style skill for investigating coverage regressions. Identifies which changes caused coverage to drop and recommends targeted tests.
+
+## Activation
+
+```
+/coverage-drop-investigator
+```
+
+## Investigation Flow
+
+### Step 1: Measure Current Coverage
+
+```bash
+# Generate coverage report
+npx jest --coverage --coverageReporters=json-summary
+
+# View summary
+cat coverage/coverage-summary.json | jq '.total'
+```
+
+### Step 2: Find When Coverage Dropped
+
+```bash
+# Compare coverage with main branch
+git stash && npx jest --coverage --coverageReporters=json-summary
+mv coverage/coverage-summary.json coverage/baseline.json
+git stash pop && npx jest --coverage --coverageReporters=json-summary
+
+# Compare
+jq -s '.[0].total.statements.pct as $baseline | .[1].total.statements.pct as $current | {baseline: $baseline, current: $current, delta: ($current - $baseline)}' coverage/baseline.json coverage/coverage-summary.json
+```
+
+### Step 3: Identify Uncovered Files
+
+```bash
+# Find files with lowest coverage
+cat coverage/coverage-summary.json | jq 'to_entries | map(select(.key != "total")) | sort_by(.value.statements.pct) | .[0:10] | .[] | {file: .key, statements: .value.statements.pct, branches: .value.branches.pct}'
+```
+
+### Step 4: Map to Recent Changes
+
+```bash
+# Find recently changed files with low coverage
+git diff --name-only main...HEAD | while read file; do
+  jq --arg f "$file" '.[$f] // empty | {file: $f, statements: .statements.pct}' coverage/coverage-summary.json
+done
+```
+
+### Step 5: Recommend Tests
+
+For each uncovered file, identify:
+1. **Uncovered functions** — need new test cases
+2. **Uncovered branches** — need conditional test cases (if/else paths)
+3. **Uncovered lines** — may indicate dead code or missing edge cases
+
+### Step 6: Report
+
+```markdown
+## Coverage Drop Report
+- **Current**: {{current_pct}}%
+- **Baseline (main)**: {{baseline_pct}}%
+- **Delta**: {{delta}}%
+- **Files causing drop**:
+  | File | Coverage | Changed Lines | Tests Needed |
+  |------|----------|--------------|-------------|
+  | {{file}} | {{pct}}% | {{lines}} | {{count}} |
+- **Recommended action**: {{write_tests / accept_drop / mark_as_excluded}}
+```
+
+## Composition
+
+After investigation:
+- **`/qe-test-generation`** — generate tests for uncovered files
+- **`/mutation-testing`** — verify existing tests actually catch bugs
+- **`/coverage-guard`** — prevent future drops
+
+## Gotchas
+
+- Coverage can drop because NEW code was added without tests, not because tests were removed
+- 100% coverage is not always the goal — focus on critical paths, not getters/setters
+- Branch coverage drops are more concerning than line coverage drops — branches indicate logic paths
+- Coverage tools may count generated code or type definitions — exclude with coveragePathIgnorePatterns

package/.claude/skills/coverage-guard/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: coverage-guard
+description: "Use when you want to prevent coverage regressions during development. Activate with /coverage-guard to warn when coverage drops below threshold after code changes."
+user-invocable: true
+---
+
+# Coverage Guard Mode
+
+When activated, checks coverage after test runs and warns if it drops below the configured threshold.
+
+## What It Does
+
+After any test execution (via Bash tool), compares coverage to the threshold in config.json. Warns (doesn't block) if coverage decreased.
+
+## Activation
+
+```
+/coverage-guard
+```
+
+## Configuration
+
+Edit `config.json` in this skill directory to set thresholds:
+
+```json
+{
+  "thresholds": {
+    "statements": 80,
+    "branches": 70,
+    "functions": 75,
+    "lines": 80
+  },
+  "coverageCommand": "npx jest --coverage --coverageReporters=json-summary",
+  "coverageFile": "coverage/coverage-summary.json"
+}
+```
+
+## Hook Configuration
+
+```json
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Bash",
+        "hook": ".claude/skills/coverage-guard/scripts/check-coverage.sh",
+        "condition": "command contains 'jest' OR command contains 'vitest' OR command contains 'npm test'"
+      }
+    ]
+  }
+}
+```
+
+## Enforcement Logic
+
+```bash
+#!/bin/bash
+# check-coverage.sh
+COVERAGE_FILE="coverage/coverage-summary.json"
+THRESHOLD=80
+
+if [ -f "$COVERAGE_FILE" ]; then
+  STATEMENTS=$(jq '.total.statements.pct' "$COVERAGE_FILE")
+  BRANCHES=$(jq '.total.branches.pct' "$COVERAGE_FILE")
+
+  if (( $(echo "$STATEMENTS < $THRESHOLD" | bc -l) )); then
+    echo "WARNING: Statement coverage ($STATEMENTS%) below threshold ($THRESHOLD%)"
+    echo "Coverage dropped — check which files lost coverage."
+  fi
+
+  if (( $(echo "$BRANCHES < 70" | bc -l) )); then
+    echo "WARNING: Branch coverage ($BRANCHES%) below 70%"
+  fi
+fi
+```
+
+## Gotchas
+
+- Coverage check runs AFTER the test command — if tests crash, no coverage report is generated
+- Coverage-summary.json must be configured as a reporter — default Jest config may not include it
+- Threshold comparisons use floating point — `79.999%` will trigger below `80%` threshold
+- Branch coverage is typically 10-15% lower than line coverage — set thresholds accordingly

package/.claude/skills/coverage-guard/scripts/check-coverage.sh

@@ -0,0 +1,42 @@
+#!/bin/bash
+# check-coverage.sh — Coverage Guard hook
+# Checks coverage after test runs and warns if below threshold.
+# Called by PostToolUse hook on Bash commands containing jest/vitest/npm test
+
+COVERAGE_FILE="coverage/coverage-summary.json"
+THRESHOLD=${COVERAGE_THRESHOLD:-80}
+BRANCH_THRESHOLD=${BRANCH_COVERAGE_THRESHOLD:-70}
+
+if [ ! -f "$COVERAGE_FILE" ]; then
+  # No coverage report generated — skip silently
+  exit 0
+fi
+
+# Extract coverage percentages
+STATEMENTS=$(node -e "console.log(require('./$COVERAGE_FILE').total.statements.pct)" 2>/dev/null)
+BRANCHES=$(node -e "console.log(require('./$COVERAGE_FILE').total.branches.pct)" 2>/dev/null)
+FUNCTIONS=$(node -e "console.log(require('./$COVERAGE_FILE').total.functions.pct)" 2>/dev/null)
+
+if [ -z "$STATEMENTS" ]; then
+  exit 0
+fi
+
+EXIT_CODE=0
+
+# Check statement coverage
+if [ "$(echo "$STATEMENTS < $THRESHOLD" | bc -l 2>/dev/null)" = "1" ]; then
+  echo "WARNING: Statement coverage (${STATEMENTS}%) below threshold (${THRESHOLD}%)"
+  EXIT_CODE=1
+fi
+
+# Check branch coverage
+if [ -n "$BRANCHES" ] && [ "$(echo "$BRANCHES < $BRANCH_THRESHOLD" | bc -l 2>/dev/null)" = "1" ]; then
+  echo "WARNING: Branch coverage (${BRANCHES}%) below threshold (${BRANCH_THRESHOLD}%)"
+  EXIT_CODE=1
+fi
+
+if [ $EXIT_CODE -eq 0 ]; then
+  echo "Coverage OK: statements=${STATEMENTS}%, branches=${BRANCHES}%, functions=${FUNCTIONS}%"
+fi
+
+exit $EXIT_CODE

package/.claude/skills/database-testing/SKILL.md

@@ -58,14 +58,6 @@ When testing database operations:
 | **Transaction** | ACID properties | Concurrent access |
 | **Performance** | Query speed | Optimization |
 
-### ACID Properties
-| Property | Test Focus |
-|----------|------------|
-| **Atomicity** | All or nothing (rollback on error) |
-| **Consistency** | Constraints always valid |
-| **Isolation** | Concurrent transactions don't interfere |
-| **Durability** | Committed data persists |
-
 ---
 
 ## Schema Testing
@@ -242,8 +234,6 @@ const dbFleet = await FleetManager.coordinate({
 
 ## Remember
 
-**Database bugs are catastrophic.** Data loss is unrecoverable. Corruption spreads silently. Performance issues compound.
-
 **Test migrations before production:** Forward works, rollback works, data preserved, performance acceptable. Never deploy untested migrations.
 
 **With Agents:** `qe-test-data-architect` generates realistic test data with referential integrity. `qe-test-executor` validates migrations automatically in CI/CD.

package/.claude/skills/debug-loop/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: debug-loop
-description: Hypothesis-driven autonomous debugging with real command validation
+description: "Use when debugging a failing test or runtime error with hypothesis-driven investigation, autonomous command validation, and systematic root cause elimination."
 trust_tier: 0
 domain: debugging
 ---

package/.claude/skills/e2e-flow-verifier/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: e2e-flow-verifier
+description: "Use when verifying complete user flows end-to-end with Playwright, recording video evidence, and asserting state at each step. For product verification with real browser automation."
+user-invocable: true
+---
+
+# E2E Flow Verifier
+
+Product verification skill that drives user flows with Playwright, asserts state at each step, and records video evidence.
+
+## Activation
+
+```
+/e2e-flow-verifier [flow-name]
+```
+
+## Flow Verification Pattern
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+test.describe('{{Flow Name}}', () => {
+  // Record video for evidence
+  test.use({
+    video: 'on',
+    screenshot: 'on',
+    trace: 'on',
+  });
+
+  test('complete user journey', async ({ page }) => {
+    // Step 1: Navigate
+    await page.goto('{{base_url}}');
+    await expect(page).toHaveTitle(/{{expected_title}}/);
+
+    // Step 2: Authenticate (if needed)
+    await page.fill('[data-testid="email"]', '{{test_user}}');
+    await page.fill('[data-testid="password"]', '{{test_password}}');
+    await page.click('[data-testid="login-btn"]');
+    await expect(page.locator('[data-testid="dashboard"]')).toBeVisible();
+
+    // Step 3: Perform action
+    await page.click('[data-testid="{{action_element}}"]');
+    await expect(page.locator('[data-testid="{{result_element}}"]')).toContainText('{{expected_text}}');
+
+    // Step 4: Verify state change
+    // Assert both UI state AND backend state
+    const apiResponse = await page.request.get('/api/{{resource}}');
+    expect(apiResponse.status()).toBe(200);
+    const data = await apiResponse.json();
+    expect(data.{{field}}).toBe('{{expected_value}}');
+  });
+});
+```
+
+## Evidence Collection
+
+After each flow verification:
+1. **Video** — `test-results/{{flow-name}}/video.webm`
+2. **Screenshots** — at each assertion point
+3. **Trace** — `test-results/{{flow-name}}/trace.zip` (open with `npx playwright show-trace`)
+4. **Network log** — HAR file with all API calls
+
+## Common Flows to Verify
+
+| Flow | Steps | Critical Assertions |
+|------|-------|-------------------|
+| Sign-up | Register → Verify email → Login | Account created, session valid |
+| Purchase | Browse → Add to cart → Checkout → Pay | Order created, payment processed |
+| Profile | Login → Edit profile → Save | Changes persisted, shown on reload |
+| Search | Enter query → Filter → Select result | Results relevant, filters work |
+
+## Gotchas
+
+- Agent writes Playwright tests but doesn't run them — always execute and check video evidence
+- Selectors break on deployment — use `data-testid` attributes, never CSS classes
+- Tests pass locally but fail in CI — headless browser behavior differs, use `--headed` for debugging
+- Auth tokens in E2E tests expire — use fresh login per test, not shared tokens
+- Video evidence is large — clean up after verification, keep only failure videos

package/.claude/skills/enterprise-integration-testing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: enterprise-integration-testing
-description: "Orchestration skill for enterprise integration testing across SAP, middleware, WMS, and backend systems. Covers E2E enterprise flows, SAP-specific patterns (RFC, BAPI, IDoc, OData, Fiori), cross-system data validation, and enterprise quality gates."
+description: "Use when testing enterprise integrations across SAP, middleware, WMS, or backend systems, validating E2E enterprise flows, testing SAP-specific patterns (RFC, BAPI, IDoc, OData, Fiori), or enforcing cross-system quality gates."
 category: enterprise-integration
 priority: high
 tokenEstimate: 2000

package/.claude/skills/exploratory-testing-advanced/SKILL.md

@@ -201,3 +201,11 @@ const exploratoryFleet = await FleetManager.coordinate({
 Not random clicking. Structured, skilled investigation guided by heuristics and oracles. Document discoveries in real-time. Pair testing amplifies findings.
 
 **With Agents:** Agents generate variations, recognize patterns, and maintain session notes while humans apply judgment and intuition. Combine agent thoroughness with human insight.
+
+## Gotchas
+
+- Agent treats exploratory testing as scripted test execution — remind it: exploration means learning + adapting in real-time
+- Session notes from agents lack the "why I tried this" reasoning — explicitly ask for decision rationale
+- 90-minute sessions cause context overflow — cap at 45 minutes with explicit debrief
+- Agent defaults to happy-path exploration — explicitly assign "Bad Neighborhood" or "Saboteur" tours for negative testing
+- SFDIPOT heuristics are misapplied when agent doesn't understand the domain — provide domain context upfront

package/.claude/skills/exploratory-testing-advanced/references/heuristic-cheatsheet.md

@@ -0,0 +1,48 @@
+# Exploratory Testing Heuristic Cheat Sheet
+
+## SFDIPOT (What to Test)
+| Factor | Questions to Ask |
+|--------|-----------------|
+| **Structure** | What is it made of? What are the components? |
+| **Function** | What does it do? What are all the features? |
+| **Data** | What data does it process? Boundary values? |
+| **Interfaces** | How does it connect to other things? APIs? UI? |
+| **Platform** | What does it depend on? OS? Browser? Network? |
+| **Operations** | How will it be used? By whom? How often? |
+| **Time** | What changes over time? Timeouts? Scheduling? |
+
+## FEW HICCUPPS (How to Recognize Problems)
+| Oracle | What to Compare Against |
+|--------|----------------------|
+| **Familiar** | Does it work like similar products I know? |
+| **Explainable** | Can I explain what it does to someone? |
+| **World** | Does it match how the real world works? |
+| **History** | Is it consistent with previous versions? |
+| **Image** | Does it match the organization's brand/values? |
+| **Comparable** | How does it compare to competitors? |
+| **Claims** | Does it match specs, docs, marketing? |
+| **Users** | Does it serve the actual users' needs? |
+| **Product** | Is it internally consistent? |
+| **Purpose** | Does it fulfill its reason for existing? |
+| **Standards** | Does it meet relevant standards (WCAG, RFC)? |
+
+## Test Tours (How to Explore)
+| Tour | Strategy |
+|------|----------|
+| **Guidebook** | Follow the documentation exactly |
+| **Money** | Test the revenue-critical features |
+| **Landmark** | Navigate between major features |
+| **Bad Neighborhood** | Focus on historically buggy areas |
+| **Intellectual** | Test the most complex features |
+| **FedEx** | Follow data through the system |
+| **Garbage Collector** | Navigate to least-used features |
+| **Saboteur** | Try to break things intentionally |
+
+## Session Charter Template
+```
+CHARTER: Explore [target area]
+WITH: [resources/tools/heuristics]
+TO DISCOVER: [what we're looking for]
+TIME BOX: [45/60/90 minutes]
+PRIORITY: [P0/P1/P2]
+```

package/.claude/skills/freeze-tests/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: freeze-tests
+description: "Use when refactoring production code and you want to ensure test files are not modified. Activate with /freeze-tests to block all edits to test files for safe refactoring."
+user-invocable: true
+---
+
+# Freeze Tests Mode
+
+When activated, blocks all modifications to test files. Use during refactoring to ensure behavior (as captured by tests) is preserved.
+
+## What It Does
+
+Blocks Write and Edit operations on any file matching test patterns:
+- `**/*.test.{ts,js,tsx,jsx}`
+- `**/*.spec.{ts,js,tsx,jsx}`
+- `**/__tests__/**`
+- `**/tests/**`
+
+## Activation
+
+```
+/freeze-tests
+```
+
+Deactivate with `/freeze-tests off`.
+
+## Hook Configuration
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hook": ".claude/skills/freeze-tests/scripts/block-test-edits.sh",
+        "condition": "file matches **/*.test.* OR **/*.spec.* OR **/__tests__/** OR **/tests/**"
+      }
+    ]
+  }
+}
+```
+
+## Enforcement Logic
+
+```bash
+#!/bin/bash
+# block-test-edits.sh
+FILE="$1"
+
+if echo "$FILE" | grep -qP '\.(test|spec)\.(ts|js|tsx|jsx)$|__tests__|/tests/'; then
+  echo "BLOCKED: Test files are frozen during refactoring."
+  echo "If tests need updating, deactivate with: /freeze-tests off"
+  exit 1
+fi
+```
+
+## When to Use
+
+1. **Refactoring**: Changing code structure without changing behavior
+2. **Performance optimization**: Making code faster without changing logic
+3. **Dependency updates**: Upgrading libraries while preserving behavior
+
+## Gotchas
+
+- Frozen tests can't be fixed if they break during refactoring — that's the point (the refactoring broke behavior)
+- If a refactoring requires test changes, it's not a pure refactoring — deactivate and treat as a feature change
+- This doesn't prevent running tests — only modifying test files

package/.claude/skills/freeze-tests/scripts/block-test-edits.sh

@@ -0,0 +1,27 @@
+#!/bin/bash
+# block-test-edits.sh — Freeze Tests hook
+# Blocks all modifications to test files during refactoring.
+# Called by PreToolUse hook on Write/Edit targeting test files.
+
+FILE="$1"
+
+if [ -z "$FILE" ]; then
+  exit 0
+fi
+
+# Check if file matches test patterns
+if echo "$FILE" | grep -qP '\.(test|spec)\.(ts|js|tsx|jsx)$' 2>/dev/null; then
+  echo "BLOCKED: Test files are frozen during refactoring."
+  echo "File: $FILE"
+  echo "Deactivate with: /freeze-tests off"
+  exit 1
+fi
+
+if echo "$FILE" | grep -qP '__tests__/|/tests/' 2>/dev/null; then
+  echo "BLOCKED: Test directories are frozen during refactoring."
+  echo "File: $FILE"
+  echo "Deactivate with: /freeze-tests off"
+  exit 1
+fi
+
+exit 0

package/.claude/skills/localization-testing/SKILL.md

@@ -49,19 +49,6 @@ When testing multi-language/region support:
 - Before international releases
 - After UI changes
 
-### i18n vs l10n
-| Term | Full Name | Focus |
-|------|-----------|-------|
-| **i18n** | Internationalization | Building for localization |
-| **l10n** | Localization | Adapting for specific locale |
-
-### Common Locale Formats
-| Type | US (en-US) | UK (en-GB) | Japan (ja-JP) |
-|------|------------|------------|---------------|
-| **Date** | 10/24/2025 | 24/10/2025 | 2025/10/24 |
-| **Currency** | $1,234.56 | £1,234.56 | ¥1,235 |
-| **Number** | 1,234.56 | 1,234.56 | 1,234.56 |
-
 ---
 
 ## Translation Coverage Testing
@@ -219,8 +206,4 @@ const l10nFleet = await FleetManager.coordinate({
 
 ## Remember
 
-**Don't hardcode. Externalize all user-facing strings.** Every string visible to users must come from translation files, not code.
-
-**Test with native speakers, not just translation files.** Machine translations and translation files can have context issues that only native speakers catch.
-
 **With Agents:** Agents validate translation coverage, detect hardcoded strings, test locale-specific formatting, and verify RTL layouts automatically across all supported languages.