gaia-framework 1.57.0 → 1.57.2

package/_gaia/testing/module-help.csv

@@ -1,13 +0,0 @@
-name,code,command,description,agent
-"teach-me-testing","teach-testing","gaia-teach-testing","Teach testing progressively","test-architect"
-"test-design","test-design","gaia-test-design","Create risk-based test plans","test-architect"
-"test-framework","test-framework","gaia-test-framework","Initialize test framework","test-architect"
-"ci-setup","ci-setup","gaia-ci-setup","Scaffold CI/CD quality pipeline","test-architect"
-"atdd","atdd","gaia-atdd","Generate failing acceptance tests","test-architect"
-"test-automation","test-automate","gaia-test-automate","Expand automated test coverage","test-architect"
-"test-review","test-review","gaia-test-review","Review test quality","test-architect"
-"nfr-assessment","nfr","gaia-nfr","Assess non-functional requirements","test-architect"
-"traceability","trace","gaia-trace","Generate traceability matrix","test-architect"
-"accessibility-testing","a11y-testing","gaia-a11y-testing","Create accessibility test plan","test-architect"
-"performance-testing","perf-testing","gaia-perf-testing","Create performance test plan","test-architect"
-"mobile-testing","mobile-testing","gaia-mobile-testing","Create mobile test plan","test-architect"

package/_gaia/testing/workflows/accessibility-testing/checklist.md

@@ -1,12 +0,0 @@
-# Accessibility Testing Checklist
-- [ ] WCAG level declared (A, AA, or AAA)
-- [ ] Automated checks cover all target pages
-- [ ] axe-core or pa11y integration designed
-- [ ] Manual test procedures defined for keyboard navigation
-- [ ] Screen reader testing procedure documented
-- [ ] Color contrast verification steps included
-- [ ] ARIA roles and labels reviewed
-- [ ] Focus management checked for dynamic content
-- [ ] Live regions validated for updates
-- [ ] Findings categorized by severity (Critical/High/Medium/Low)
-- [ ] At least 1 remediation recommendation per critical finding

package/_gaia/testing/workflows/accessibility-testing/instructions.xml

@@ -1,41 +0,0 @@
-<workflow name="accessibility-testing">
-<critical>
-  <mandate>Target WCAG level must be declared before testing begins</mandate>
-  <mandate>Automated checks must cover ALL identified pages and components</mandate>
-</critical>
-<step n="1" title="Scope">
-  <action>Identify which pages and components to test</action>
-  <action>Declare target WCAG level: A, AA, or AAA</action>
-  <action>Document user personas including users with disabilities</action>
-</step>
-<step n="2" title="Automated Checks">
-  <action>Load testing/knowledge/accessibility/axe-core-patterns.md</action>
-  <action>Design axe-core or pa11y integration for each target page</action>
-  <action>Define automated test scenarios covering all identified components</action>
-  <action>Configure rule sets matching the declared WCAG level</action>
-</step>
-<step n="3" title="Manual Test Plan">
-  <action>Define keyboard navigation testing procedure for all interactive elements</action>
-  <action>Define screen reader testing procedure (VoiceOver for macOS/iOS, NVDA for Windows)</action>
-  <action>Define color contrast verification steps (4.5:1 for normal text, 3:1 for large text)</action>
-  <action>Document focus order expectations for each page</action>
-</step>
-<step n="4" title="ARIA Audit">
-  <action>Review ARIA roles and labels for correctness</action>
-  <action>Verify focus management on modal dialogs, dropdowns, and dynamic content</action>
-  <action>Check live regions (aria-live) for dynamic content updates</action>
-  <action>Validate landmark regions (nav, main, aside, footer)</action>
-</step>
-<step n="5" title="Remediation Priorities">
-  <action>Categorize findings by impact level:</action>
-  <action>Critical — blocks access entirely (no keyboard nav, missing alt text on functional images)</action>
-  <action>High — significantly degrades experience (poor focus indicators, missing form labels)</action>
-  <action>Medium — inconvenient but workaround exists (suboptimal heading hierarchy)</action>
-  <action>Low — enhancement opportunity (decorative improvements)</action>
-  <action>Provide at least one remediation recommendation per critical finding</action>
-</step>
-<step n="6" title="Generate Report">
-  <action>Generate accessibility report with findings, priorities, and remediation steps</action>
-  <template-output file="{test_artifacts}/accessibility-report-{date}.md" />
-</step>
-</workflow>

package/_gaia/testing/workflows/accessibility-testing/workflow.yaml

@@ -1,13 +0,0 @@
-name: accessibility-testing
-description: 'Create accessibility test plan and automated checks for WCAG compliance'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/accessibility-testing.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/accessibility-testing"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-required_skill_sections:
-  - "security-basics:owasp-top-10"
-output:
-  primary: "{test_artifacts}/accessibility-report-{date}.md"

package/_gaia/testing/workflows/atdd/checklist.md

@@ -1,6 +0,0 @@
-# ATDD Checklist
-- [ ] Acceptance criteria loaded from story/PRD
-- [ ] Each AC mapped to exactly one test
-- [ ] Tests fail initially (red phase)
-- [ ] Tests are atomic and independent
-- [ ] Test-to-AC traceability documented

package/_gaia/testing/workflows/atdd/instructions.xml

@@ -1,36 +0,0 @@
-<workflow name="atdd">
-<critical>
-  <mandate>Tests must fail initially — this is the red phase of TDD</mandate>
-  <mandate>Each test maps to exactly one acceptance criterion</mandate>
-  <mandate>Only high-risk stories require ATDD — if no high-risk stories exist, exit gracefully</mandate>
-</critical>
-<step n="1" title="Load and Filter High-Risk Stories">
-  <action>Read {planning_artifacts}/epics-and-stories.md</action>
-  <action>Filter stories tagged as Risk: HIGH</action>
-  <action>For each high-risk story: extract acceptance criteria (AC1, AC2, ...)</action>
-  <check if="no high-risk stories found">Report "No high-risk stories found — ATDD not required for this project." and exit workflow.</check>
-  <action>Present the list of high-risk stories and their ACs to the user</action>
-  <ask>These high-risk stories need ATDD tests. Confirm to proceed with all, or select specific stories. [all / select / skip]</ask>
-</step>
-<step n="2" title="Convert to Tests">
-  <action>For each selected high-risk story: transform each AC into a failing acceptance test</action>
-  <action>One test per AC — maintain clear 1:1 mapping (AC1 → Test 1, AC2 → Test 2, ...)</action>
-  <action>Name tests descriptively: test name should reflect the AC being validated</action>
-</step>
-<step n="3" title="Implement Tests">
-  <action>Write the test code (red phase — tests must fail because implementation does not exist yet)</action>
-  <action>Use the project's test framework conventions if detectable</action>
-  <action>Each test must be atomic, independent, and meaningful — no vacuous assertions</action>
-</step>
-<step n="4" title="Validate Structure">
-  <action>Ensure every AC from the selected stories has exactly one corresponding test</action>
-  <action>Verify tests are independent — no shared state between tests</action>
-  <action>Run tests to confirm they all FAIL (red phase validation)</action>
-</step>
-<step n="5" title="Generate Output">
-  <action>For each high-risk story: generate ATDD document with AC-to-test mapping table, test code, and run results showing failures</action>
-  <template-output file="{test_artifacts}/atdd-{story_key}.md">
-    Generate one ATDD file per high-risk story. Each file includes: story key, story title, risk level, AC-to-test mapping table, test implementations, and test run output confirming all tests fail (red phase).
-  </template-output>
-</step>
-</workflow>

package/_gaia/testing/workflows/atdd/workflow.yaml

@@ -1,22 +0,0 @@
-name: atdd
-description: 'Generate failing acceptance tests using TDD cycle'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/atdd.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/atdd"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-input_file_patterns:
-  epics:
-    whole: "{planning_artifacts}/epics-and-stories.md"
-    load_strategy: "FULL_LOAD"
-quality_gates:
-  pre_start:
-    - check: "epics_exist"
-      on_fail: "HALT: Run /gaia-create-epics first — ATDD needs stories with acceptance criteria"
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-output:
-  primary: "{test_artifacts}/atdd-{story_key}.md"

package/_gaia/testing/workflows/ci-setup/checklist.md

@@ -1,9 +0,0 @@
-# CI Setup Checklist
-- [ ] CI platform confirmed by user (not just auto-detected)
-- [ ] Pipeline stages defined (build, lint, test, coverage)
-- [ ] Quality gate thresholds set
-- [ ] Secrets management documented (required secrets, environment separation)
-- [ ] Deployment strategy defined (staging, production, rollback)
-- [ ] Monitoring and notifications configured (failure alerts, status badge)
-- [ ] Pipeline config generated
-- [ ] Gates are enforced (blocking, not advisory)

package/_gaia/testing/workflows/ci-setup/instructions.xml

@@ -1,43 +0,0 @@
-<workflow name="ci-setup">
-<critical>
-  <mandate>Quality gates must be enforced, not advisory</mandate>
-</critical>
-<step n="1" title="Detect CI Platform">
-  <action>Scan for existing CI config files: .github/workflows/, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml</action>
-  <action>If config found: note detected platform and present finding to user</action>
-  <action>If no config found: note that no existing CI platform was detected</action>
-  <ask>Which CI platform would you like to use? Options: GitHub Actions, GitLab CI, Jenkins, CircleCI, or other. {If detected: "Detected: {platform} — recommended based on existing config."}</ask>
-</step>
-<step n="2" title="Define Pipeline">
-  <action>Build > lint > test > coverage > deploy gates</action>
-</step>
-<step n="3" title="Quality Gates">
-  <action>Define pass/fail thresholds: coverage %, test pass rate</action>
-</step>
-<step n="4" title="Secrets Management">
-  <action>Identify all required secrets from architecture and PRD: API keys, database credentials, auth secrets, third-party service keys</action>
-  <action>Document how to add secrets to the selected CI platform (e.g., GitHub Repository Secrets, GitLab CI/CD Variables)</action>
-  <action>Define environment-level separation: which secrets differ between staging and production</action>
-  <action>List each secret with its name, purpose, and which pipeline stages need it</action>
-</step>
-<step n="5" title="Deployment Strategy">
-  <action>Define staging deployment: auto-deploy on merge to develop branch after all gates pass</action>
-  <action>Define production deployment: deploy on merge to main with manual approval gate</action>
-  <action>Define rollback procedure: how to revert a failed deployment (rollback trigger, steps, verification)</action>
-</step>
-<step n="6" title="Monitoring and Notifications">
-  <action>Configure pipeline failure notifications: Slack webhook, email, or platform-native alerts</action>
-  <action>Add pipeline status badge for the project README</action>
-  <action>Recommend metrics dashboard for pipeline health (run duration trends, failure rates, flaky test tracking)</action>
-</step>
-<step n="7" title="Generate Pipeline Config">
-  <action>Generate CI config file (.github/workflows/ci.yml or equivalent)</action>
-</step>
-<step n="8" title="Generate Output">
-  <action>Generate CI/CD pipeline configuration document with: pipeline stages, quality gates, secrets management, deployment strategy, and monitoring setup</action>
-  <template-output file="{test_artifacts}/ci-setup.md" />
-</step>
-<next-step source="lifecycle-sequence.yaml">
-  <primary command="/gaia-readiness-check">Validate implementation readiness before sprint planning</primary>
-</next-step>
-</workflow>

package/_gaia/testing/workflows/ci-setup/workflow.yaml

@@ -1,11 +0,0 @@
-name: ci-setup
-description: 'Scaffold CI/CD quality pipeline with test execution'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/ci-setup.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/ci-setup"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-output:
-  primary: "{test_artifacts}/ci-setup.md"

package/_gaia/testing/workflows/edit-test-plan/checklist.md

@@ -1,20 +0,0 @@
----
-title: 'Test Plan Edit Validation'
-validation-target: 'Edited Test Plan'
----
-## Edit Quality
-- [ ] Existing test cases preserved exactly
-- [ ] Existing test strategy and environments unchanged
-- [ ] New test cases follow same format as existing
-## New Test Cases
-- [ ] Test case IDs auto-incremented (no collisions)
-- [ ] Each test case has type, steps, expected results, priority
-- [ ] Validates field maps to FR/NFR IDs
-- [ ] Test cases assigned to correct test area/category
-## Coverage
-- [ ] Test scope section updated to reflect expanded coverage
-- [ ] Coverage summary updated (if present)
-## Version History
-- [ ] Version note added with date, change summary, new test case IDs
-## Output Verification
-- [ ] Output file saved to {test_artifacts}/test-plan.md

package/_gaia/testing/workflows/edit-test-plan/instructions.xml

@@ -1,65 +0,0 @@
-<workflow name="edit-test-plan">
-<critical>
-  <mandate>Preserve all existing test plan content — test strategy, environments, entry/exit criteria, existing test cases</mandate>
-  <mandate>New test cases must follow the same format as existing ones</mandate>
-  <mandate>Test case IDs must auto-increment from the highest existing ID</mandate>
-  <mandate>Never remove or modify existing test cases</mandate>
-</critical>
-
-<step n="1" title="Load Existing Test Plan">
-  <action>Read {test_artifacts}/test-plan.md in full</action>
-  <action>GATE: verify test-plan.md exists. If missing, HALT and recommend /gaia-test-design.</action>
-  <action>Identify existing test case count and highest test case ID (for auto-increment)</action>
-  <action>Identify existing test areas/categories (e.g., unit, integration, E2E, performance, security)</action>
-  <action>Display current test plan structure summary to user: section count, test case count, coverage areas</action>
-</step>
-
-<step n="2" title="Capture Change Scope">
-  <check if="triggered_by_orchestrator">Inherit feature_description, prd_diff (new FR/NFR IDs), arch_diff (architecture changes) from triggering workflow context. Skip user questions — proceed to identifying test needs.</check>
-  <ask>What new test cases are needed? Describe the feature or change requiring test coverage.</ask>
-  <ask>Which FR/NFR IDs need test coverage?</ask>
-  <action>Read relevant sections of {planning_artifacts}/prd.md for requirement context</action>
-  <action>Read relevant sections of {planning_artifacts}/architecture.md for technical context</action>
-  <action>Record: new_requirements, change_description, affected_test_areas</action>
-</step>
-
-<step n="3" title="Define New Test Cases">
-  <action>For each new requirement, define test cases:
-    - Test case ID (auto-incremented from highest existing)
-    - Title and description
-    - Test type (unit, integration, E2E, performance, security, accessibility)
-    - Pre-conditions and test steps
-    - Expected results
-    - Priority (critical/high/medium/low)
-    - Validates: {FR-* / NFR-* IDs this test case validates}</action>
-  <action>Determine if new test areas/categories are needed or if cases fit existing categories</action>
-  <action>Present proposed test cases to user for review and confirmation</action>
-</step>
-
-<step n="4" title="Update Test Plan">
-  <action>Append new test cases to the appropriate test area sections</action>
-  <action>If new test area needed: create section header with description before adding test cases</action>
-  <action>Update test scope section to reflect expanded coverage</action>
-  <action>Update coverage summary if present (new requirements covered / total)</action>
-  <action>Preserve all existing content exactly as-is — no reordering, no reformatting, no removal</action>
-</step>
-
-<step n="5" title="Add Version Note and Save">
-  <action>Append version note to test plan:
-    ## Version History
-    | Date | Change | New Test Cases | FR/NFR IDs Covered |
-    |------|--------|---------------|-------------------|
-    | {date} | {change summary} | {new test case IDs} | {FR/NFR IDs} |
-  </action>
-  <action>If no Version History section exists, create one</action>
-  <template-output file="{test_artifacts}/test-plan.md">
-    Save updated test plan with new test cases appended, coverage updated, and version note added.
-  </template-output>
-</step>
-
-<step n="6" title="Next Steps">
-  <action>Report test cases added: list new IDs, their types, and requirements covered</action>
-  <action>If high-risk stories need acceptance tests: "Recommend running /gaia-atdd for stories: {story_keys}"</action>
-  <action>If traceability update needed: "Recommend running /gaia-trace to update traceability matrix"</action>
-</step>
-</workflow>

package/_gaia/testing/workflows/edit-test-plan/workflow.yaml

@@ -1,35 +0,0 @@
-name: edit-test-plan
-description: 'Edit an existing test plan — add test cases for new features without regenerating'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/edit-test-plan.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/edit-test-plan"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-input_file_patterns:
-  test_plan:
-    whole: "{test_artifacts}/test-plan.md"
-    load_strategy: "FULL_LOAD"
-  prd:
-    whole: "{planning_artifacts}/prd.md"
-    load_strategy: "SELECTIVE_LOAD"
-  architecture:
-    whole: "{planning_artifacts}/architecture.md"
-    load_strategy: "SELECTIVE_LOAD"
-  epics:
-    whole: "{planning_artifacts}/epics-and-stories.md"
-    load_strategy: "SELECTIVE_LOAD"
-quality_gates:
-  pre_start:
-    - check: "test_plan_exists"
-      on_fail: "HALT: test-plan.md does not exist. Run /gaia-test-design first to create the initial test plan."
-  post_complete:
-    - check: "coverage_advisory"
-      on_fail: "WARNING: New requirements have test cases but coverage percentage has not been re-calculated. Re-run /gaia-test-design to update coverage metrics."
-on_error:
-  missing_file: "ask_user"
-  unresolved_variable: "halt"
-
-output:
-  primary: "{test_artifacts}/test-plan.md"

package/_gaia/testing/workflows/mobile-testing/checklist.md

@@ -1,13 +0,0 @@
-# Mobile Testing Checklist
-- [ ] Device matrix defined covering top 90% of user base
-- [ ] Minimum supported OS versions documented
-- [ ] Appium test infrastructure configured
-- [ ] Device farm integration set up
-- [ ] React Native unit test patterns defined (if applicable)
-- [ ] Detox E2E configured (if applicable)
-- [ ] Responsive viewport testing matrix created
-- [ ] Touch interaction tests designed
-- [ ] Permission handling flows tested
-- [ ] Deep linking verified on both platforms
-- [ ] Push notification handling tested
-- [ ] App lifecycle transitions validated

package/_gaia/testing/workflows/mobile-testing/instructions.xml

@@ -1,41 +0,0 @@
-<workflow name="mobile-testing">
-<critical>
-  <mandate>Device matrix must cover top 90% of target user base</mandate>
-  <mandate>Platform-specific behaviors must be tested on real devices or emulators</mandate>
-</critical>
-<step n="1" title="Platform Matrix">
-  <action>Define target devices by OS version, screen size, and market share</action>
-  <action>Include minimum supported versions for iOS and Android</action>
-  <action>Document screen size breakpoints and orientation requirements</action>
-  <action>Identify device-specific features used (camera, GPS, biometrics)</action>
-</step>
-<step n="2" title="Appium Setup">
-  <action>Load testing/knowledge/mobile-testing/appium-patterns.md</action>
-  <action>Design Appium test infrastructure and capabilities</action>
-  <action>Configure device farm integration (BrowserStack, SauceLabs, or local emulators)</action>
-  <action>Define element location strategies and wait patterns</action>
-</step>
-<step n="3" title="React Native Testing">
-  <action>Load testing/knowledge/mobile-testing/react-native-testing.md</action>
-  <action>Design Jest + React Native Testing Library unit test patterns</action>
-  <action>Configure Detox for E2E testing if applicable</action>
-  <action>Define native module mocking strategies</action>
-</step>
-<step n="4" title="Responsive Testing">
-  <action>Load testing/knowledge/mobile-testing/responsive-testing.md</action>
-  <action>Define viewport testing matrix across target breakpoints</action>
-  <action>Design touch interaction tests (swipe, pinch, long press)</action>
-  <action>Configure visual regression testing for mobile viewports</action>
-</step>
-<step n="5" title="Platform-Specific Checks">
-  <action>Test permission handling flows (camera, location, notifications)</action>
-  <action>Verify deep linking behavior on both platforms</action>
-  <action>Test push notification delivery and handling</action>
-  <action>Validate platform gesture differences (back button on Android, swipe-back on iOS)</action>
-  <action>Check app lifecycle handling (background, foreground, kill, restore)</action>
-</step>
-<step n="6" title="Generate Output">
-  <action>Generate mobile test plan with device matrix, Appium setup, and responsive checks</action>
-  <template-output file="{test_artifacts}/mobile-test-plan-{date}.md" />
-</step>
-</workflow>

package/_gaia/testing/workflows/mobile-testing/workflow.yaml

@@ -1,11 +0,0 @@
-name: mobile-testing
-description: 'Create mobile test plan covering device matrix, Appium, React Native, and responsive testing'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/mobile-testing.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/mobile-testing"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-output:
-  primary: "{test_artifacts}/mobile-test-plan-{date}.md"

package/_gaia/testing/workflows/nfr-assessment/checklist.md

@@ -1,7 +0,0 @@
-# NFR Assessment Checklist
-- [ ] NFRs loaded from project docs
-- [ ] Performance targets assessed (response time, throughput)
-- [ ] Security posture evaluated (auth, data protection)
-- [ ] Reliability assessed (availability, fault tolerance)
-- [ ] Risk ratings assigned with justification
-- [ ] Migration risks assessed if brownfield context (data migration, backward compat, dual-write)

package/_gaia/testing/workflows/nfr-assessment/instructions.xml

@@ -1,26 +0,0 @@
-<workflow name="nfr-assessment">
-<critical>
-  <mandate>Assess all three dimensions: performance, security, reliability</mandate>
-  <mandate>Rate risks: high, medium, low with justification</mandate>
-</critical>
-<step n="1" title="Load NFRs">
-  <action>Read NFRs from PRD or architecture doc</action>
-</step>
-<step n="2" title="Performance Assessment">
-  <action>Response time targets, throughput, resource limits</action>
-</step>
-<step n="3" title="Security Assessment">
-  <action>Authentication, authorization, data protection</action>
-</step>
-<step n="4" title="Reliability Assessment">
-  <action>Availability, fault tolerance, recovery</action>
-</step>
-<step n="5" title="Migration Assessment (Brownfield)" optional="true">
-  <action>If assessment context is brownfield: evaluate data migration performance, backward compatibility, dual-write latency, legacy API parity, and session continuity</action>
-  <action>Rate each migration risk dimension: high, medium, low with justification</action>
-</step>
-<step n="6" title="Generate Report">
-  <action>Compile with risk ratings per dimension</action>
-  <template-output file="{test_artifacts}/nfr-assessment.md" />
-</step>
-</workflow>

package/_gaia/testing/workflows/nfr-assessment/workflow.yaml

@@ -1,11 +0,0 @@
-name: nfr-assessment
-description: 'Assess NFRs like performance, security, and reliability'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/nfr-assessment.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/nfr-assessment"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-output:
-  primary: "{test_artifacts}/nfr-assessment.md"

package/_gaia/testing/workflows/performance-testing/checklist.md

@@ -1,11 +0,0 @@
-# Performance Testing Checklist
-- [ ] Response time targets defined (P50, P95, P99)
-- [ ] Throughput targets defined (RPS)
-- [ ] Error rate thresholds established
-- [ ] Load test scenarios designed (gradual, spike, soak)
-- [ ] Virtual user profiles reflect real traffic patterns
-- [ ] Core Web Vitals targets set (LCP, INP, CLS)
-- [ ] Bundle size budgets defined per route
-- [ ] Backend profiling covers queries, memory, connections, CPU
-- [ ] CI performance gates configured
-- [ ] Performance regression alerts in place

package/_gaia/testing/workflows/performance-testing/instructions.xml

@@ -1,41 +0,0 @@
-<workflow name="performance-testing">
-<critical>
-  <mandate>Performance budgets must be defined with measurable thresholds</mandate>
-  <mandate>Load test scenarios must include realistic traffic patterns</mandate>
-</critical>
-<step n="1" title="Performance Budget">
-  <action>Define response time targets: P50, P95, P99 latency</action>
-  <action>Define throughput targets: requests per second (RPS)</action>
-  <action>Define error rate thresholds (target less than 0.1% under normal load)</action>
-  <action>Establish baseline metrics from current production or staging</action>
-</step>
-<step n="2" title="Load Test Design">
-  <action>Load testing/knowledge/performance/k6-patterns.md</action>
-  <action>Create test scenarios using k6 or equivalent load testing tool</action>
-  <action>Define virtual user profiles representing real traffic patterns</action>
-  <action>Design ramp-up strategies: gradual load, spike test, soak test</action>
-  <action>Define test data requirements and seed data generation</action>
-</step>
-<step n="3" title="Frontend Performance">
-  <action>Load testing/knowledge/performance/lighthouse-ci.md</action>
-  <action>Define Core Web Vitals targets: LCP under 2.5s, INP under 200ms, CLS under 0.1</action>
-  <action>Set bundle size budgets per route (JS, CSS, images)</action>
-  <action>Identify critical rendering path optimizations</action>
-</step>
-<step n="4" title="Backend Profiling">
-  <action>Identify slow queries: N+1 problems, missing indexes, full table scans</action>
-  <action>Analyze memory allocation patterns and potential leaks</action>
-  <action>Check connection pool sizing and exhaustion scenarios</action>
-  <action>Profile CPU-intensive operations and identify optimization targets</action>
-</step>
-<step n="5" title="CI Integration">
-  <action>Add Lighthouse score thresholds to CI pipeline (performance over 90)</action>
-  <action>Define load test pass/fail criteria for CI gates</action>
-  <action>Set bundle size limits with automated enforcement</action>
-  <action>Configure performance regression alerts</action>
-</step>
-<step n="6" title="Generate Output">
-  <action>Generate performance test plan with budgets, load scenarios, and CI gates</action>
-  <template-output file="{test_artifacts}/performance-test-plan-{date}.md" />
-</step>
-</workflow>

package/_gaia/testing/workflows/performance-testing/workflow.yaml

@@ -1,11 +0,0 @@
-name: performance-testing
-description: 'Create performance test plan with load testing, frontend metrics, and CI gates'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/performance-testing.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/performance-testing"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-output:
-  primary: "{test_artifacts}/performance-test-plan-{date}.md"

package/_gaia/testing/workflows/teach-me-testing/checklist.md

@@ -1,6 +0,0 @@
-# Teach Me Testing Checklist
-- [ ] User level assessed (beginner/intermediate/advanced)
-- [ ] Learning path selected and confirmed
-- [ ] Knowledge loaded progressively (not all at once)
-- [ ] Examples relevant to user's stack
-- [ ] Practice exercise provided

package/_gaia/testing/workflows/teach-me-testing/instructions.xml

@@ -1,28 +0,0 @@
-<workflow name="teach-me-testing">
-<critical>
-  <mandate>Assess user level before teaching</mandate>
-  <mandate>Load knowledge fragments progressively — don't overwhelm</mandate>
-</critical>
-<step n="1" title="Assess Level">
-  <action>Ask user about their testing experience and goals</action>
-  <action>Determine level: beginner, intermediate, advanced</action>
-</step>
-<step n="2" title="Select Topic">
-  <action>Present learning path based on level</action>
-  <action>Beginner: test pyramid, unit testing basics, AAA pattern</action>
-  <action>Intermediate: fixtures, integration testing, test doubles</action>
-  <action>Advanced: risk-based testing, architecture-level testing, contract testing</action>
-</step>
-<step n="3" title="Load Knowledge">
-  <action>Load relevant knowledge fragments from {knowledge_path}/</action>
-  <action>Only load fragments relevant to the selected topic</action>
-</step>
-<step n="4" title="Interactive Lesson">
-  <action>Walk through concepts with examples and exercises</action>
-  <action>Use the user's project stack for code examples when possible</action>
-</step>
-<step n="5" title="Practice Exercise">
-  <action>Provide a hands-on exercise the user can try</action>
-  <action>Review their solution and provide feedback</action>
-</step>
-</workflow>

package/_gaia/testing/workflows/teach-me-testing/workflow.yaml

@@ -1,12 +0,0 @@
-name: teach-me-testing
-description: 'Teach testing progressively through structured sessions'
-module: testing
-agent: test-architect
-config_resolved: "{installed_path}/.resolved/teach-me-testing.yaml"
-config_source: "{project-root}/_gaia/testing/config.yaml"
-installed_path: "{project-root}/_gaia/testing/workflows/teach-me-testing"
-instructions: "{installed_path}/instructions.xml"
-validation: "{installed_path}/checklist.md"
-
-output:
-  primary: "interactive_session"

package/_gaia/testing/workflows/test-automation/checklist.md

@@ -1,6 +0,0 @@
-# Test Automation Checklist
-- [ ] Coverage gaps identified
-- [ ] Knowledge fragments loaded for project stack
-- [ ] Tests follow AAA pattern
-- [ ] Tests pass and cover intended code paths
-- [ ] Coverage delta documented in report