fp-update

name	fp-update
description	Update existing E2E tests to match current E2E_TESTS.md specifications

Update E2E Tests

Update existing E2E tests to match the current state of E2E_TESTS.md specifications. This is the primary maintenance command — use it after specs change to bring tests in sync.

Additional instructions from the user: "$ARGUMENTS". Ignore if empty.

This command has four phases. Complete all four in order.

Phase 1: Discover

1. Find all E2E_TESTS.md files by searching recursively from the project root. Read the root-level spec first to understand project-wide testing constraints.
2. If E2E tests already exist, run them first to establish a baseline of current pass/fail status. Note any pre-existing failures.
3. For each E2E_TESTS.md, extract:
   • All suites
   • For each suite: preconditions, features, postconditions, metadata
4. Find all existing E2E test files:
   • Files matching **/*.e2e.test.*
   • Files inside **/e2e/**/*.test.*
5. Read all existing test files to understand current coverage, patterns, and utilities.

Phase 2: Analyze

Map each spec element to existing tests. Build a coverage matrix and identify:

• Missing suites: Spec suites with no corresponding test file
• Missing features: Features within a suite with no corresponding test case
• Missing preconditions/postconditions: Setup or teardown described but not implemented
• Inconsistencies: Tests that don't match the current spec (wrong assertions, outdated behavior)
• Structural issues: Tests that violate isolation rules (shared state, ordering dependencies)

Present a summary:

• Total suites and features in spec
• Current coverage count
• List of gaps grouped by suite
• Any inconsistencies or structural issues

Ask the user if they want to proceed with all updates, or focus on specific suites/features.

Phase 3: Update

Apply changes following these rules:

General rules

• Follow existing patterns: Study existing E2E test files for code style, utilities, mock strategies, and structure. New/updated tests must be consistent.
• Test isolation: Every suite starts from a clean slate. No shared persistent state. Tests are order-independent.
• Mock only external dependencies: Mock CLI tools and external services. Use real file systems, real git repos.
• Use real test environments: Temporary directories, real git repositories, actual project files.
• File naming: Follow the existing <feature>.e2e.test.<ext> convention.

For missing suites

• Create new test files following existing patterns.
• Implement all features, preconditions, and postconditions.
• Reuse existing helpers and utilities.

For missing features

• Add new suite/group blocks and test cases in the appropriate existing test file (e.g., describe / it blocks in vitest/jest).
• Follow adjacent test case patterns.

For inconsistencies

• Update test assertions, setup, or structure to match the spec.
• The spec is the source of truth. Never change the spec to match tests.

For structural issues

• Refactor to eliminate ordering dependencies and shared state.
• Ensure proper per-test setup and teardown hooks (e.g., beforeEach / afterEach in vitest/jest).

Phase 4: Verify

1. Run E2E tests for each updated package.
2. If tests fail:
   • Read the failure output
   • Fix the test implementation (not the spec)
   • Re-run until passing
3. Once package-level tests pass, run the full project E2E suite to ensure no cross-package regressions.
4. Run the project's formatter on all modified files.
5. Present a final summary:
   • Suites and features added or updated
   • New test files created
   • Existing test files modified
   • Confirmation that all tests pass