End-to-End Testing

Kanitsal Cerceve (Evidential Frame Activation)

Kaynak dogrulama modu etkin.

[assert|neutral] Systematic end-to-end testing workflow with assertion framework, evidence collection, and structured reporting [ground:skill-design] [conf:0.95] [state:confirmed]

Overview

End-to-end testing validates complete user journeys through web applications, ensuring that integrated systems work correctly from the user’s perspective. This skill builds upon browser-automation but adds formal testing constructs: assertions, test suites, fixtures, and detailed pass/fail reporting.

Philosophy: E2E tests are living documentation of expected user behavior. They must be deterministic, maintainable, and produce actionable failure reports.

Key Differences from browser-automation:

Value Proposition: Transform manual QA checklists into automated, repeatable test suites that catch regressions before users do.

When to Use This Skill

Primary Use Cases:

• Login/authentication flow validation
• User registration and onboarding verification
• Checkout and payment flow testing
• Form submission with validation rules
• CRUD operations (Create, Read, Update, Delete)
• Multi-step wizard completion
• Cross-page state persistence
• Visual regression detection

Apply When:

• Validating critical user journeys before deployment
• Regression testing after code changes
• Smoke testing production environments
• Acceptance criteria verification
• Visual snapshot comparison needed

Trigger Keywords:

• “e2e test”, “end-to-end test”
• “validate user flow”, “test the journey”
• “check if login works”, “verify checkout”
• “regression test”, “smoke test”
• “acceptance test”

When NOT to Use This Skill

• Unit testing (use testing frameworks directly)
• API testing without UI (use API testing tools)
• Performance/load testing (use delivery-essential-commands-load-test)
• Single-action validation (use browser-automation)
• Non-web applications (mobile, desktop)
• Static content verification (use visual tools)

Core Principles

Principle 1: Assertion-First Design

Mandate: Every test step MUST have explicit success/failure criteria defined upfront.

Rationale: Tests without assertions are just scripts. Explicit assertions make failures debuggable and intentions clear.

In Practice:

• Define expected outcomes before execution
• Use multiple assertion types (DOM, visual, URL, text)
• Fail immediately on assertion failure
• Capture evidence at assertion points

Principle 2: Test Suite Organization

Mandate: Group related tests into suites with shared setup/teardown.

Rationale: Test organization reduces duplication, improves maintainability, and enables selective test runs.

In Practice:

• Suite = collection of related test cases
• Fixtures = reusable setup/teardown logic
• Each test case is independent (no cross-test dependencies)
• Clear naming: suite_feature_scenario

Principle 3: Evidence-Based Verdicts

Mandate: Every test result MUST include visual evidence (screenshots) at assertion points.

Rationale: Screenshots provide ground truth for debugging failures and serve as visual documentation.

In Practice:

• Screenshot before and after critical actions
• Capture DOM state at assertion points
• Store evidence with test results
• Enable visual comparison for regression detection

Principle 4: Deterministic Execution

Mandate: Tests must produce identical results on identical inputs.

Rationale: Flaky tests erode confidence. Determinism enables reliable CI/CD integration.

In Practice:

• Explicit waits over implicit timeouts
• Stable element selection (data-testid preferred)
• Isolated test data (fixtures create/destroy)
• Retry logic only for infrastructure issues

Principle 5: Actionable Failure Reports

Mandate: Failed tests MUST produce reports that pinpoint the failure without additional investigation.

Rationale: Time-to-fix correlates with failure report quality. Good reports = faster debugging.

In Practice:

• Include: step that failed, expected vs actual, screenshot
• Show assertion context (what was being verified)
• Provide DOM snapshot at failure point
• Link to relevant code/documentation

Test Framework Concepts

Test Suite Structure

test_suite:
  name: "Login Flow Tests"
  description: "Validate user authentication scenarios"

  fixtures:
    setup:
      - action: "create_test_user"
        params: { username: "testuser", password: "Test123!" }
      - action: "clear_cookies"
    teardown:
      - action: "delete_test_user"
        params: { username: "testuser" }

  test_cases:
    - name: "successful_login"
      steps: [...]
      assertions: [...]

    - name: "invalid_password"
      steps: [...]
      assertions: [...]

    - name: "empty_fields"
      steps: [...]
      assertions: [...]

Assertion Types

Assertion Implementation

const ASSERTIONS = {
  element_exists: async (context, selector) => {
    const elements = await mcp__claude-in-chrome__find({
      query: selector,
      tabId: context.tabId
    });
    return {
      passed: elements.length > 0,
      actual: `Found ${elements.length} elements`,
      expected: `At least 1 element matching "${selector}"`
    };
  },

  text_equals: async (context, selector, expected) => {
    const page = await mcp__claude-in-chrome__read_page({
      tabId: context.tabId
    });
    const element = findElementBySelector(page, selector);
    const actual = element?.text || "";
    return {
      passed: actual === expected,
      actual: actual,
      expected: expected
    };
  },

  url_equals: async (context, expected) => {
    const page = await mcp__claude-in-chrome__read_page({
      tabId: context.tabId
    });
    const actual = page.url;
    return {
      passed: actual === expected,
      actual: actual,
      expected: expected
    };
  },

  visual_match: async (context, baselineId) => {
    const screenshot = await mcp__claude-in-chrome__computer({
      action: "screenshot",
      tabId: context.tabId
    });
    const similarity = await compareImages(screenshot, baselineId);
    return {
      passed: similarity >= 0.95,
      actual: `${(similarity * 100).toFixed(1)}% match`,
      expected: "95% or higher match",
      evidence: screenshot.imageId
    };
  }
};

Test Result Structure

test_result:
  suite: "Login Flow Tests"
  test_case: "successful_login"
  status: "PASSED" | "FAILED" | "SKIPPED" | "ERROR"

  duration_ms: 2340
  timestamp: "2026-01-12T14:30:00Z"

  steps_executed: 5
  steps_passed: 5
  steps_failed: 0

  assertions:
    - name: "login_form_visible"
      type: "element_visible"
      status: "PASSED"
      expected: "Login form visible"
      actual: "Login form visible"
      screenshot_id: "img_001"

    - name: "redirect_to_dashboard"
      type: "url_contains"
      status: "PASSED"
      expected: "URL contains /dashboard"
      actual: "https://app.example.com/dashboard"
      screenshot_id: "img_002"

  evidence:
    screenshots: ["img_001", "img_002", "img_003"]
    dom_snapshots: ["dom_001", "dom_002"]
    console_logs: ["log_001"]

  failure_details: null  # Populated on failure

Failure Report Structure

failure_report:
  test_case: "checkout_with_discount"
  failed_at_step: 4

  failure:
    assertion: "discount_applied"
    type: "text_equals"
    expected: "$90.00"
    actual: "$100.00"
    message: "Discount code not applied to total"

  context:
    url: "https://shop.example.com/checkout"
    step_description: "Verify 10% discount applied after code entry"
    preceding_action: "Clicked 'Apply Discount' button"

  evidence:
    screenshot: "img_failure_001"
    dom_snapshot: "dom_failure_001"
    console_errors: []

  debug_hints:
    - "Check if discount code 'SAVE10' is still valid"
    - "Verify discount applies to current cart items"
    - "Check for JavaScript errors in console"

Main Workflow

Phase 1: Test Planning (via Sequential-Thinking)

Purpose: Decompose user journey into testable steps with explicit assertions.

Process:

1. Invoke sequential-thinking MCP
2. Break down user journey into atomic steps
3. Define assertion for each step
4. Identify fixture requirements (setup/teardown)
5. Plan evidence collection points
6. Define success/failure thresholds

Input Contract:

inputs:
  test_description: string    # What user journey to test
  success_criteria: string    # What defines passing
  test_data: object          # Fixture data (users, products, etc.)

Output Contract:

outputs:
  test_plan:
    suite_name: string
    fixtures: { setup: [...], teardown: [...] }
    test_cases:
      - name: string
        steps: [{ action, params, assertion }]
        timeout_ms: number

Phase 2: Setup (Fixtures)

Purpose: Establish test prerequisites and browser state.

Process:

1. Get tab context (tabs_context_mcp)
2. Create dedicated test tab (tabs_create_mcp)
3. Execute fixture setup actions
4. Navigate to starting URL
5. Take initial screenshot (baseline)
6. Verify preconditions met

Fixture Types:

Phase 3: Test Execution

Purpose: Execute test steps with assertion verification at each point.

Process:

For each test_case in suite:
  For each step in test_case.steps:
    1. Execute action (click, type, navigate)
    2. Wait for state transition (explicit wait)
    3. Capture evidence (screenshot, DOM)
    4. Run assertion
    5. If assertion fails:
       - Capture failure evidence
       - Mark test as FAILED
       - Skip remaining steps
       - Proceed to teardown
    6. If assertion passes:
       - Log success
       - Continue to next step

Evidence Collection Points:

• Before first action (initial state)
• After navigation changes
• Before and after form submissions
• At every assertion point
• On failure (mandatory)

Phase 4: Assertion Verification

Purpose: Validate expected vs actual state at each checkpoint.

Assertion Execution:

async function executeAssertion(assertion, context) {
  const startTime = Date.now();

  // Take pre-assertion screenshot
  const screenshot = await takeScreenshot(context.tabId);

  // Execute assertion
  const assertFn = ASSERTIONS[assertion.type];
  const result = await assertFn(context, ...assertion.params);

  // Build assertion result
  return {
    name: assertion.name,
    type: assertion.type,
    status: result.passed ? "PASSED" : "FAILED",
    expected: result.expected,
    actual: result.actual,
    duration_ms: Date.now() - startTime,
    screenshot_id: screenshot.imageId,
    evidence: result.evidence
  };
}

Phase 5: Teardown

Purpose: Clean up test artifacts and restore state.

Process:

1. Execute fixture teardown actions
2. Delete test data created during setup
3. Clear cookies/localStorage if modified
4. Close test tab
5. Restore original tab context

Teardown Rules:

• ALWAYS execute teardown, even on test failure
• Log teardown failures but don’t fail test for them
• Teardown order: reverse of setup order
• Verify cleanup completed

Phase 6: Report Generation

Purpose: Produce structured test report with pass/fail summary.

Report Contents:

test_report:
  summary:
    total_tests: 5
    passed: 4
    failed: 1
    skipped: 0
    duration_ms: 12500
    pass_rate: "80%"

  suite_results:
    - suite: "Login Flow Tests"
      tests: 3
      passed: 3
      failed: 0

    - suite: "Checkout Flow Tests"
      tests: 2
      passed: 1
      failed: 1

  failures:
    - test: "checkout_with_discount"
      assertion: "discount_applied"
      expected: "$90.00"
      actual: "$100.00"
      screenshot: "img_failure_001"

  evidence_index:
    screenshots: [...]
    dom_snapshots: [...]

Production Guardrails

MCP Preflight Check

Before executing tests, validate required MCPs:

async function testPreflight() {
  const checks = {
    sequential_thinking: false,
    claude_in_chrome: false,
    memory_mcp: false
  };

  // Check sequential-thinking MCP (required for planning)
  try {
    await mcp__sequential-thinking__sequentialthinking({
      thought: "E2E test preflight check",
      thoughtNumber: 1,
      totalThoughts: 1,
      nextThoughtNeeded: false
    });
    checks.sequential_thinking = true;
  } catch (error) {
    throw new Error("CRITICAL: sequential-thinking MCP required for test planning");
  }

  // Check claude-in-chrome MCP (required for execution)
  try {
    await mcp__claude-in-chrome__tabs_context_mcp({});
    checks.claude_in_chrome = true;
  } catch (error) {
    throw new Error("CRITICAL: claude-in-chrome MCP required for test execution");
  }

  // Check memory-mcp (required for test history)
  try {
    checks.memory_mcp = true;
  } catch (error) {
    console.warn("Memory MCP unavailable - test history will not be stored");
  }

  return checks;
}

Timeout Configuration

const TEST_TIMEOUTS = {
  step_default: 10000,       // 10 seconds per step
  navigation: 15000,         // 15 seconds for page load
  form_submit: 20000,        // 20 seconds for form submission
  assertion: 5000,           // 5 seconds for assertion check
  screenshot: 10000,         // 10 seconds for screenshot capture
  suite_max: 300000,         // 5 minutes per suite
  test_max: 60000            // 1 minute per test case
};

Retry Logic

const RETRY_CONFIG = {
  max_retries: 2,
  retry_on: [
    "NETWORK_ERROR",
    "ELEMENT_NOT_FOUND",
    "TIMEOUT"
  ],
  no_retry_on: [
    "ASSERTION_FAILED",
    "MCP_UNAVAILABLE",
    "SETUP_FAILED"
  ],
  backoff_ms: [1000, 3000]  // Exponential backoff
};

async function executeWithRetry(testCase, context) {
  let lastError = null;

  for (let attempt = 0; attempt <= RETRY_CONFIG.max_retries; attempt++) {
    try {
      return await executeTestCase(testCase, context);
    } catch (error) {
      lastError = error;

      if (!RETRY_CONFIG.retry_on.includes(error.type)) {
        throw error;  // Don't retry assertion failures
      }

      if (attempt < RETRY_CONFIG.max_retries) {
        await sleep(RETRY_CONFIG.backoff_ms[attempt]);
      }
    }
  }

  throw lastError;
}

Test Case Templates

Template 1: Login Flow Test

test_case:
  name: "successful_login"
  description: "Verify user can login with valid credentials"

  preconditions:
    - "User 'testuser' exists in system"
    - "User is logged out"

  steps:
    - step: 1
      action: navigate
      params: { url: "https://app.example.com/login" }
      assertion:
        type: url_contains
        expected: "/login"

    - step: 2
      action: form_input
      params: { selector: "[data-testid='email']", value: "testuser@example.com" }
      assertion:
        type: form_value
        selector: "[data-testid='email']"
        expected: "testuser@example.com"

    - step: 3
      action: form_input
      params: { selector: "[data-testid='password']", value: "Test123!" }
      assertion:
        type: element_exists
        selector: "[data-testid='password']"

    - step: 4
      action: click
      params: { selector: "[data-testid='login-button']" }
      wait: { type: "navigation", timeout: 10000 }
      assertion:
        type: url_contains
        expected: "/dashboard"

    - step: 5
      action: verify
      assertion:
        type: text_contains
        selector: "[data-testid='welcome-message']"
        expected: "Welcome"

  expected_result: "User redirected to dashboard with welcome message"

Template 2: Form Validation Test

test_case:
  name: "registration_validation"
  description: "Verify form validation errors display correctly"

  steps:
    - step: 1
      action: navigate
      params: { url: "https://app.example.com/register" }
      assertion:
        type: element_visible
        selector: "[data-testid='register-form']"

    - step: 2
      description: "Submit empty form to trigger validation"
      action: click
      params: { selector: "[data-testid='submit-button']" }
      assertion:
        type: element_count
        selector: ".error-message"
        expected: 3  # Email, password, confirm password

    - step: 3
      description: "Enter invalid email"
      action: form_input
      params: { selector: "[data-testid='email']", value: "invalid-email" }

    - step: 4
      action: click
      params: { selector: "[data-testid='submit-button']" }
      assertion:
        type: text_contains
        selector: "[data-testid='email-error']"
        expected: "valid email"

    - step: 5
      description: "Enter mismatched passwords"
      action: form_input
      params: { selector: "[data-testid='password']", value: "Test123!" }

    - step: 6
      action: form_input
      params: { selector: "[data-testid='confirm-password']", value: "Different123!" }

    - step: 7
      action: click
      params: { selector: "[data-testid='submit-button']" }
      assertion:
        type: text_contains
        selector: "[data-testid='password-error']"
        expected: "passwords must match"

Template 3: Multi-Step Wizard Test

test_case:
  name: "complete_onboarding_wizard"
  description: "Verify user can complete all onboarding steps"

  fixtures:
    setup:
      - action: login_as
        params: { username: "newuser", role: "new_signup" }

  steps:
    # Step 1: Profile Setup
    - step: 1
      action: verify
      assertion:
        type: text_equals
        selector: "[data-testid='wizard-step']"
        expected: "Step 1 of 4"

    - step: 2
      action: form_input
      params: { selector: "[data-testid='full-name']", value: "Test User" }

    - step: 3
      action: click
      params: { selector: "[data-testid='next-step']" }
      wait: { type: "element", selector: "[data-testid='step-2']" }
      assertion:
        type: text_equals
        selector: "[data-testid='wizard-step']"
        expected: "Step 2 of 4"

    # Step 2: Preferences
    - step: 4
      action: click
      params: { selector: "[data-testid='preference-dark-mode']" }
      assertion:
        type: attribute_equals
        selector: "[data-testid='preference-dark-mode']"
        attribute: "aria-checked"
        expected: "true"

    - step: 5
      action: click
      params: { selector: "[data-testid='next-step']" }
      assertion:
        type: text_equals
        selector: "[data-testid='wizard-step']"
        expected: "Step 3 of 4"

    # Step 3: Notification Settings
    - step: 6
      action: click
      params: { selector: "[data-testid='notify-email']" }

    - step: 7
      action: click
      params: { selector: "[data-testid='next-step']" }
      assertion:
        type: text_equals
        selector: "[data-testid='wizard-step']"
        expected: "Step 4 of 4"

    # Step 4: Confirmation
    - step: 8
      action: click
      params: { selector: "[data-testid='complete-wizard']" }
      wait: { type: "navigation" }
      assertion:
        type: url_contains
        expected: "/dashboard"

    - step: 9
      action: verify
      assertion:
        type: element_visible
        selector: "[data-testid='onboarding-complete-badge']"

Template 4: CRUD Operations Test

test_suite:
  name: "Product CRUD Tests"

  fixtures:
    setup:
      - action: login_as
        params: { role: "admin" }
      - action: navigate
        params: { url: "/admin/products" }

  test_cases:
    - name: "create_product"
      steps:
        - step: 1
          action: click
          params: { selector: "[data-testid='add-product']" }
          assertion:
            type: element_visible
            selector: "[data-testid='product-form']"

        - step: 2
          action: form_input
          params: { selector: "[data-testid='product-name']", value: "Test Product" }

        - step: 3
          action: form_input
          params: { selector: "[data-testid='product-price']", value: "99.99" }

        - step: 4
          action: click
          params: { selector: "[data-testid='save-product']" }
          assertion:
            type: text_contains
            selector: ".success-message"
            expected: "Product created"

    - name: "read_product"
      depends_on: "create_product"
      steps:
        - step: 1
          action: click
          params: { selector: "[data-testid='product-row-test-product']" }
          assertion:
            type: text_equals
            selector: "[data-testid='product-detail-name']"
            expected: "Test Product"

        - step: 2
          action: verify
          assertion:
            type: text_equals
            selector: "[data-testid='product-detail-price']"
            expected: "$99.99"

    - name: "update_product"
      depends_on: "create_product"
      steps:
        - step: 1
          action: click
          params: { selector: "[data-testid='edit-product']" }

        - step: 2
          action: form_input
          params: { selector: "[data-testid='product-price']", value: "89.99" }

        - step: 3
          action: click
          params: { selector: "[data-testid='save-product']" }
          assertion:
            type: text_contains
            selector: ".success-message"
            expected: "Product updated"

    - name: "delete_product"
      depends_on: "create_product"
      steps:
        - step: 1
          action: click
          params: { selector: "[data-testid='delete-product']" }

        - step: 2
          action: click
          params: { selector: "[data-testid='confirm-delete']" }
          assertion:
            type: text_contains
            selector: ".success-message"
            expected: "Product deleted"

        - step: 3
          action: verify
          assertion:
            type: element_count
            selector: "[data-testid='product-row-test-product']"
            expected: 0

Visual Regression Testing

Baseline Management

const BASELINE_CONFIG = {
  storage_path: "skills/tooling/e2e-test/baselines/{project}/{suite}",
  comparison_threshold: 0.95,  // 95% similarity required
  highlight_differences: true,
  ignore_regions: []  // [{ x, y, width, height }]
};

async function captureBaseline(context, testName) {
  const screenshot = await mcp__claude-in-chrome__computer({
    action: "screenshot",
    tabId: context.tabId
  });

  // Store in Memory MCP as baseline
  await memoryStore({
    namespace: `${BASELINE_CONFIG.storage_path}/${testName}`,
    content: screenshot.imageId,
    tags: {
      type: "baseline",
      test: testName,
      captured: new Date().toISOString()
    }
  });

  return screenshot.imageId;
}

async function compareWithBaseline(context, testName) {
  const current = await mcp__claude-in-chrome__computer({
    action: "screenshot",
    tabId: context.tabId
  });

  const baseline = await memoryQuery({
    namespace: `${BASELINE_CONFIG.storage_path}/${testName}`,
    filter: { type: "baseline" }
  });

  if (!baseline) {
    return { status: "NO_BASELINE", message: "Baseline not found - capturing as new baseline" };
  }

  const similarity = await compareImages(current.imageId, baseline.content);

  return {
    status: similarity >= BASELINE_CONFIG.comparison_threshold ? "PASSED" : "FAILED",
    similarity: similarity,
    threshold: BASELINE_CONFIG.comparison_threshold,
    current_image: current.imageId,
    baseline_image: baseline.content
  };
}

Difference Visualization

async function generateDiffImage(currentId, baselineId) {
  // Highlight differences between screenshots
  const diff = {
    type: "visual_diff",
    current: currentId,
    baseline: baselineId,
    differences: []  // Regions that differ
  };

  // Store diff for debugging
  await memoryStore({
    namespace: "e2e-test/diffs",
    content: diff,
    tags: {
      type: "diff",
      generated: new Date().toISOString()
    }
  });

  return diff;
}

Memory MCP Integration

Test History Storage

Namespace Pattern: skills/tooling/e2e-test/{project}/{suite}/{timestamp}

Store:

• Test plans (from sequential-thinking phase)
• Execution results (pass/fail with evidence)
• Screenshots at assertion points
• Failure reports with debug context
• Visual baselines for regression testing

Retrieve:

• Previous test runs (for trend analysis)
• Similar failures (for pattern matching)
• Baselines (for visual comparison)
• Flaky test history (for stability analysis)

Tagging Protocol:

{
  "WHO": "e2e-test-{session_id}",
  "WHEN": "ISO8601_timestamp",
  "PROJECT": "{project_name}",
  "WHY": "e2e-test-execution",
  "suite": "login_flow",
  "test_case": "successful_login",
  "status": "PASSED|FAILED|ERROR",
  "duration_ms": 2340,
  "assertions_total": 5,
  "assertions_passed": 5
}

Test Trend Analysis

async function getTestTrends(suite, days = 7) {
  const history = await vectorSearch({
    query: `e2e test results ${suite}`,
    namespace: `skills/tooling/e2e-test`,
    filter: {
      suite: suite,
      WHEN: { $gte: daysAgo(days) }
    },
    limit: 100
  });

  return {
    total_runs: history.length,
    pass_rate: calculatePassRate(history),
    avg_duration: calculateAvgDuration(history),
    flaky_tests: identifyFlakyTests(history),
    common_failures: groupFailures(history)
  };
}

Success Criteria

Quality Thresholds:

• All test assertions verified with explicit pass/fail
• Screenshot evidence captured at every assertion point
• Test report generated with full failure details
• Fixtures executed (setup) and cleaned (teardown)
• No orphaned test data after suite completion
• Test execution within configured timeout limits

Failure Indicators:

• Any assertion returns FAILED status
• Test step times out before assertion
• Fixture setup fails (abort entire suite)
• Critical MCP unavailable (abort with error)
• Teardown fails (log warning, don’t fail test)

MCP Integration

Required MCPs:

Optional MCPs:

• filesystem (for saving reports locally)
• playwright (for advanced test scenarios)

LEARNED PATTERNS

[assert|neutral] Section reserved for patterns discovered through Loop 1.5 session reflection [ground:skill-design] [conf:0.80] [state:provisional]

High Confidence [conf:0.90+]

(No patterns captured yet – this section will be populated through Loop 1.5 reflection)

Medium Confidence [conf:0.70-0.89]

(No patterns captured yet)

Observations [conf:<0.70]

(No patterns captured yet)

Anti-Patterns to Avoid

Related Skills

Upstream (provide input to this skill):

• intent-analyzer – Detect e2e testing requests
• browser-automation – Base execution patterns
• planner – High-level test strategy

Downstream (use output from this skill):

• quality-metrics-dashboard – Test analytics
• cicd-intelligent-recovery – CI/CD integration
• deployment-readiness – Pre-deploy validation

Parallel (work together):

• functionality-audit – Verify code works
• theater-detection – Detect fake tests
• visual-asset-generator – Process screenshots

Maintenance & Updates

Version History:

• v1.0.0 (2026-01-12): Initial release with assertion framework, suite organization, and reporting

Feedback Loop:

• Loop 1.5 (Session): Store learnings from test failures
• Loop 3 (Meta-Loop): Aggregate patterns every 3 days
• Update LEARNED PATTERNS section with discoveries

Continuous Improvement:

• Monitor test pass rates via Memory MCP
• Identify flaky tests for stabilization
• Optimize assertion coverage

E2E_TEST_VERILINGUA_VERIX_COMPLIANT