@athenaflow/plugin-e2e-test-builder 2.0.9 → 2.0.10

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "e2e-test-builder",
   "description": "Full-pipeline Playwright E2E test generation \u2014 explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
-  "version": "2.0.9",
+  "version": "2.0.10",
   "author": {
     "name": "Athenaflow"
   },

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "e2e-test-builder",
-  "version": "2.0.9",
+  "version": "2.0.10",
   "description": "Full-pipeline Playwright E2E test generation \u2014 explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
   "author": {
     "name": "Athenaflow"

package/dist/{2.0.8 → 2.0.10}/.agents/plugins/marketplace.json

@@ -4,7 +4,7 @@
   "plugins": [
     {
       "name": "e2e-test-builder",
-      "version": "2.0.8",
+      "version": "2.0.10",
       "source": {
         "source": "local",
         "path": "./codex/plugin"

package/dist/{2.0.9 → 2.0.10}/claude/plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "e2e-test-builder",
   "description": "Full-pipeline Playwright E2E test generation \u2014 explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
-  "version": "2.0.9",
+  "version": "2.0.10",
   "author": {
     "name": "Athenaflow"
   },

package/dist/{2.0.9 → 2.0.10}/claude/plugin/package.json

@@ -1,9 +1,15 @@
 {
   "name": "@athenaflow/plugin-e2e-test-builder",
-  "version": "2.0.9",
+  "version": "2.0.10",
   "description": "Full-pipeline Playwright E2E test generation — explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
   "license": "MIT",
   "publishConfig": {
     "access": "public"
-  }
+  },
+  "files": [
+    ".claude-plugin/",
+    ".codex-plugin/",
+    "skills/",
+    "dist/"
+  ]
 }

package/dist/{2.0.9 → 2.0.10}/claude/plugin/skills/add-e2e-tests/SKILL.md

@@ -8,7 +8,7 @@ description: >
   Delegates to sub-skills (analyze-test-codebase, plan-test-coverage, generate-test-cases,
   review-test-cases, write-test-code, review-test-code, fix-flaky-tests) internally — do NOT
   skip to sub-skills directly unless the user explicitly requests a narrow activity.
-  Iterative and resumable via tracker file. Uses subagent delegation to save context.
+  Uses subagent delegation to save context.
 allowed-tools: Read Write Edit Glob Grep Bash Task
 ---
 
@@ -22,34 +22,17 @@ Parse the target URL and feature description from: $ARGUMENTS
 
 Derive a **feature slug** from the feature description (e.g., "Login flow" → `login`, "Checkout with payment" → `checkout`). Use this slug for file naming throughout.
 
-## Session Protocol
-
-### 1. Orient: Understand the Project, the Product, and Your Capabilities
+## 1. Orient: Understand the Project, the Product, and Your Capabilities
 
 Before planning any work, build deep situational awareness. This step determines the quality of everything that follows — rushed orientation leads to missed test cases and wasted effort.
 
-**Check for existing progress:**
-- If `e2e-tracker.md` exists in the project root, read it and resume from where you left off — skip to **step 2 (Plan)** with the remaining work.
-- If no tracker exists, this is a fresh start. Proceed with orientation below.
-
-#### First: create initial tasks and tracker
-
-As soon as you parse the user's request:
-
-1. **Create the tracker** — write `e2e-tracker.md` with the goal (URL, feature, slug) and a skeleton plan.
-2. **Create high-level tasks** for the work ahead — analyze codebase, explore the product, plan coverage, generate test specs, write tests, verify tests.
-
-These are your starting skeleton. As you work through orientation and discover the actual shape of the work, refine both the tasks and the tracker — break tasks into granular sub-tasks, add new ones, remove ones that don't apply.
-
-Treat the task list as a visible milestone log. Keep it concise, but update it continuously. Do not leave broad tasks open until the end and then mark everything complete in one batch.
-
-#### 1a. Understand the codebase
+### Understand the codebase
 
 - Does a Playwright config exist (`playwright.config.{ts,js,mjs}`)? If not, you will need to scaffold one (see Scaffolding section).
 - Are there existing tests? What conventions do they follow — naming, locators, fixtures, page objects, auth?
 - Load the `analyze-test-codebase` skill and follow its methodology.
 
-#### 1b. Understand the product
+### Understand the product
 
 This is the most important part of orientation. You cannot write good tests for a product you don't understand.
 
@@ -59,7 +42,7 @@ This is the most important part of orientation. You cannot write good tests for
 
 Why this matters: absent explicit exploration, agents tend to write tests based on assumptions about how a product works rather than how it actually works. The result is tests that target imaginary behavior or miss critical real behavior. Spending time here prevents both.
 
-#### 1c. Know your skills
+### Know your skills
 
 You have access to specialized skills that contain deep domain knowledge. Load the relevant skill before performing each activity — skills prevent improvisation and encode best practices.
 
@@ -76,22 +59,11 @@ You have access to specialized skills that contain deep domain knowledge. Load t
 
 Before doing a substantial activity, load the skill that covers that activity so you can follow its workflow rather than improvising.
 
-#### 1d. Update the tracker with orientation findings
-
-After orienting, update the tracker with what you learned about the codebase and product, conventions discovered, and your refined plan. The tracker must always answer these four questions for anyone reading it cold:
-
-1. What is the goal?
-2. What has been done?
-3. What is remaining?
-4. What should I do next?
+## 2. Plan: Refine Tasks Into Granular Checkpoints
 
-See [references/tracker-template.md](references/tracker-template.md) for a concrete template.
+Refine the work into granular checkpoints based on what orientation revealed. The plan should flow from what you learned, not from a fixed template.
 
-### 2. Plan: Refine Tasks Into Granular Checkpoints
-
-By now you have initial tasks and a tracker from step 1. Refine tasks into granular checkpoints. The plan should flow from what you learned during orientation, not from a fixed template.
-
-#### Task granularity
+### Task granularity
 
 Think in small checkpoints, not big phases. Each task should represent a concrete, verifiable unit of progress.
 
@@ -117,11 +89,11 @@ Create tasks for verification steps too (running tests, checking coverage, brows
 
 Update task status as each checkpoint completes. A good pattern is: finish exploration and mark it complete, finish coverage/spec work and mark it complete, finish implementation and mark it complete, then finish review/execution and mark it complete. Do not keep all milestones open until session end.
 
-### 3. Execute
+## 3. Execute
 
 Work through your tasks. Load the relevant skill before each activity.
 
-#### Planning uses the browser heavily
+### Planning uses the browser heavily
 
 When planning what to test (coverage planning, test case generation), use the browser extensively. Don't just catalog elements — interact with the product to discover:
 - What validation messages appear for each field?
@@ -133,14 +105,14 @@ When planning what to test (coverage planning, test case generation), use the br
 
 Every test case you generate should trace back to something you actually observed or deliberately triggered in the browser. This is how you avoid introducing useless test cases (testing imaginary behavior) and avoid missing important ones (behavior you didn't think to check).
 
-#### Subagent delegation
+### Subagent delegation
 
 Delegate heavy browser exploration and test writing to subagents when that saves context for orchestration, verification, and debugging. When delegating:
 - Pass the relevant file paths (conventions, coverage plan, test specs)
 - Instruct the subagent to invoke the appropriate skill (subagents inherit access to plugin skills)
 - Specify concrete output expectations (file path, format, TC-ID conventions)
 
-#### Quality gates
+### Quality gates
 
 Two review gates and a test execution checkpoint are mandatory during execution. The review gates are review-only — they produce findings but do not modify files.
 
@@ -148,45 +120,26 @@ Two review gates and a test execution checkpoint are mandatory during execution.
 1. Load the `review-test-cases` skill and run it against `test-cases/<feature>.md`
 2. If verdict is **NEEDS REVISION** — address all blockers in the spec before proceeding to implementation
 3. If verdict is **PASS WITH WARNINGS** — address warnings if quick, otherwise note them and proceed
-4. Record the review verdict in the tracker
-
 **Gate 2: Review test code** (after `write-test-code`, before final test execution)
 1. Load the `review-test-code` skill and run it against the implemented test files
 2. If verdict is **NEEDS REVISION** — fix all blockers before running tests for signoff
 3. If verdict is **PASS WITH WARNINGS** — fix warnings that affect stability, proceed with execution
-4. Record the review verdict in the tracker
 
 **Checkpoint: Test execution**
 1. Run the tests: `npx playwright test <file> --reporter=list 2>&1`
-2. Record full output — green test output is the only proof of correctness
+2. Inspect the full output — green test output is the only proof of correctness
 3. If tests fail, load the `fix-flaky-tests` skill and follow its structured diagnostic approach. Do not guess-and-retry.
-4. Maximum 3 fix-and-rerun cycles per test. If stuck after 3 cycles, record the diagnostic output in the tracker and move on.
-
-**Test execution and coverage checks must never be delegated to subagents.** Run `npx playwright test` directly and record the output.
-
-#### Update the tracker as you work
-
-Do not wait until session end. After each meaningful chunk of progress (completing a step, discovering a blocker, producing an artifact), update the tracker. If your context window resets, only what's in the tracker survives.
-
-Keep the tracker and task list synchronized. If you record progress in the tracker, update the corresponding task status in the same phase of work.
-
-#### Error recovery
-
-If infrastructure failures occur (browser MCP unavailable, clone failures, npm install errors), see [references/error-recovery.md](references/error-recovery.md) for diagnostic steps. General pattern: diagnose, attempt one known fix, if still stuck record in tracker and ask the user.
+4. Maximum 3 fix-and-rerun cycles per test. If stuck after 3 cycles, move on with the diagnostic output.
 
-### 4. End of Session
+**Test execution and coverage checks must never be delegated to subagents.** Run `npx playwright test` directly.
 
-Before exiting:
-1. Ensure the tracker reflects all progress, discoveries, and blockers from this session
-2. Write clear instructions for what the next session should do
-3. If all work is complete and all tests pass with full TC-ID coverage: write `<!-- E2E_COMPLETE -->` as the last line of the tracker
-4. If an unrecoverable blocker prevents progress: write `<!-- E2E_BLOCKED: reason -->` as the last line
+### Error recovery
 
-Do not write terminal markers prematurely. Only after you are confident the work is truly done or truly stuck.
+If infrastructure failures occur (browser MCP unavailable, clone failures, npm install errors), see [references/error-recovery.md](references/error-recovery.md) for diagnostic steps. General pattern: diagnose, attempt one known fix, if still stuck ask the user.
 
 ## Scaffolding
 
-If Playwright is not set up in the target project, follow the procedure in [references/scaffolding.md](references/scaffolding.md) to clone the boilerplate, merge configuration, and install dependencies. Log all scaffolding steps in the tracker.
+If Playwright is not set up in the target project, follow the procedure in [references/scaffolding.md](references/scaffolding.md) to clone the boilerplate, merge configuration, and install dependencies.
 
 ## Authentication
 

package/dist/{2.0.8 → 2.0.10}/claude/plugin/skills/add-e2e-tests/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Run Full E2E Workflow"
   short_description: "Orchestrate browser-led E2E work from exploration to verified tests"
-  default_prompt: "Run the full E2E workflow for this feature: maintain a concise progress tracker, explore the live product first, then plan, spec, review, implement, and verify the Playwright tests."
+  default_prompt: "Run the full E2E workflow for this feature: explore the live product first, then plan, spec, review, implement, and verify the Playwright tests."
 
 dependencies:
   tools:

package/dist/{2.0.8 → 2.0.10}/claude/plugin/skills/add-e2e-tests/references/error-recovery.md

@@ -1,6 +1,6 @@
 # Error Recovery for Infrastructure Failures
 
-When infrastructure failures occur during E2E test building, follow the general pattern: diagnose, attempt one known fix, if still stuck record in tracker and ask the user.
+When infrastructure failures occur during E2E test building, follow the general pattern: diagnose, attempt one known fix, if still stuck ask the user.
 
 ## Browser MCP unavailable
 
@@ -8,7 +8,7 @@ The browser MCP server (`agent-web-interface`) must be running for site explorat
 
 1. Verify the MCP server is configured in the project (check `.mcp.json` or plugin config).
 2. Ask the user to confirm the MCP server is running or to restart it.
-3. If unreachable after user intervention, mark the session as blocked: `<!-- E2E_BLOCKED: browser MCP server unreachable -->`.
+3. If unreachable after user intervention, this is an unrecoverable blocker — inform the user that browser exploration cannot proceed.
 
 ## Boilerplate clone fails
 
@@ -40,4 +40,4 @@ For any infrastructure failure not listed above:
 
 1. **Diagnose** — read the error message carefully, check logs, identify the root cause.
 2. **Attempt one known fix** — apply the most likely solution based on the error.
-3. **If still stuck** — record the full error output and diagnostic steps taken in the tracker, then ask the user for help. Do not loop through multiple speculative fixes.
+3. **If still stuck** — ask the user for help with the full error output and diagnostic steps taken. Do not loop through multiple speculative fixes.

package/dist/{2.0.8/codex → 2.0.10/claude}/plugin/skills/add-e2e-tests/references/scaffolding.md

@@ -9,4 +9,4 @@ If Playwright is not set up in the target project, follow this procedure:
 4. Merge devDependencies into `package.json`.
 5. Run `npm install && npx playwright install --with-deps chromium`.
 6. Clean up the temp clone.
-7. Log all scaffolding steps in the tracker.
+7. Preserve the important scaffolding decisions in your working notes.

package/dist/{2.0.9 → 2.0.10}/claude/plugin/skills/fix-flaky-tests/SKILL.md

@@ -56,7 +56,7 @@ Investigate based on the classification:
 - Check if the test asserts before an API response arrives — search for missing `waitForResponse`
 - Look for animations/transitions that affect element state (CSS transitions, skeleton screens)
 - Check for `waitForTimeout` being used as a "fix" — this is a symptom, not a cure
-- Check if `networkidle` or `load` waitUntil would help for navigation
+- Check whether the test needs a more specific readiness signal: targeted `waitForResponse`, a URL/assertion change, a loading indicator disappearing, or a hydration marker becoming ready
 
 **State leakage:**
 - Run the failing test alone: `npx playwright test --grep "<test name>"`

package/dist/{2.0.8/codex → 2.0.10/claude}/plugin/skills/fix-flaky-tests/references/fix-patterns.md

@@ -17,8 +17,9 @@ await expect(element).toBeVisible();
 await expect(page.getByRole('progressbar')).toBeHidden();
 await expect(element).toBeVisible();
 
-// GOOD: wait for navigation to complete
-await page.goto('/page', { waitUntil: 'networkidle' });
+// GOOD: wait for a specific readiness signal after navigation
+await page.goto('/page');
+await expect(page.getByRole('heading', { name: /dashboard/i })).toBeVisible();
 
 // GOOD: use auto-retrying assertion (retries until timeout)
 await expect(page.getByText(/loaded/i)).toBeVisible({ timeout: 10000 });

package/dist/{2.0.9 → 2.0.10}/claude/plugin/skills/generate-test-cases/SKILL.md

@@ -80,7 +80,7 @@ Launch another subagent, or continue in the main thread if the flow is small, to
 
 ### Step 4: Reason About Additional Scenarios
 
-After exploration, reason about scenarios that could not be directly triggered but must be covered:
+After exploration, reason about scenarios that could not be directly triggered but may still need coverage:
 
 - **Network & Performance** — failure modes, slow responses, large data sets, offline behavior
 - **Accessibility (WCAG 2.1 AA)** — keyboard navigation, screen reader support, focus management, contrast
@@ -88,6 +88,12 @@ After exploration, reason about scenarios that could not be directly triggered b
 - **Cross-browser** — Safari/Firefox/mobile-specific behavioral differences
 - **Concurrent & Session** — session expiry, multi-tab conflicts, race conditions
 
+For scenarios that were not directly observed:
+- label them clearly as inferred, mock-required, or environment-dependent in the spec notes
+- avoid inventing exact UI text, validation copy, or server behavior you did not observe
+- phrase expected results at the right confidence level (for example, "shows an error state" rather than exact copy if the exact message was not seen)
+- prefer these scenarios when they are strongly implied by the architecture or are standard negative paths the implementation will need to simulate
+
 See [references/scenario-categories.md](references/scenario-categories.md) for detailed checklists within each category.
 
 ### Step 5: Generate Test Case Specifications
@@ -162,7 +168,7 @@ When generating specs that span multiple roles or test categories, recommend rol
 - Steps must be **concrete and unambiguous** — "click the Submit button" not "submit the form"
 - Expected results must be **observable and verifiable** — include actual error messages observed
 - Priority must be **justified** — Critical = blocks core journey, High = significant, Medium = secondary, Low = cosmetic
-- Every feature spec MUST include at minimum: one network error scenario (500/timeout), one empty state scenario, and one session/auth edge case (if the feature requires auth). These are non-negotiable — omitting them is a BLOCKER in the review-test-cases quality gate.
+- Include at minimum one network/server failure scenario, one empty state scenario, and one session/auth edge case when those scenarios meaningfully apply to the feature. If a category is not applicable, say so explicitly in the spec rather than inventing coverage.
 - **Test case count guidance:** Aim for 15-30 test cases per feature area as a baseline. Fewer than 10 suggests missing error paths or edge cases. More than 40 suggests the feature should be split into sub-features with separate spec files. Prioritize breadth of category coverage over depth within a single category.
 
 ## Blocking Conditions

package/dist/{2.0.9 → 2.0.10}/claude/plugin/skills/plan-test-coverage/SKILL.md

@@ -20,6 +20,7 @@ Plan what E2E tests to write for a feature by analyzing existing test coverage a
      ```
    - Identify what's already covered and what's missing
    - Note existing TC-IDs for the feature area to avoid conflicts
+   - Use the canonical TC-ID format `TC-<FEATURE>-<NNN>` for every planned test, regardless of category. Category belongs in the plan metadata, not the ID.
 
 3. **Quick site inspection** (lightweight, not full exploration, optional if browser tooling is unavailable):
    - If the current context has browser tools, follow the `agent-web-interface-guide` skill's browsing patterns (orient before acting, use `list_pages` for session awareness, close only pages you opened)
@@ -66,28 +67,28 @@ Plan what E2E tests to write for a feature by analyzing existing test coverage a
 #### P0 — Critical Path
 | TC-ID | Description | Why Critical |
 |-------|-------------|-------------|
-| TC-FEATURE-010 | Happy path: user completes full flow | Core revenue path |
+| TC-FEATURE-001 | Happy path: user completes full flow | Core revenue path |
 
 #### P1 — Validation & Errors
 | TC-ID | Description | Why Important |
 |-------|-------------|--------------|
-| TC-FEATURE-020 | Submit with empty required fields | Common user error |
+| TC-FEATURE-002 | Submit with empty required fields | Common user error |
 
 #### P2 — Edge Cases
 | TC-ID | Description | Notes |
 |-------|-------------|-------|
-| TC-FEATURE-030 | Special characters in search input | Unicode handling |
+| TC-FEATURE-003 | Special characters in search input | Unicode handling |
 
 #### Accessibility (include if project has accessibility requirements or WCAG compliance goals)
 | TC-ID | Description | WCAG Criterion |
 |-------|-------------|----------------|
-| TC-FEATURE-A01 | Keyboard-only navigation through flow | 2.1.1 Keyboard |
-| TC-FEATURE-A02 | Form errors announced to screen readers | 1.3.1 Info and Relationships |
+| TC-FEATURE-004 | Keyboard-only navigation through flow | 2.1.1 Keyboard |
+| TC-FEATURE-005 | Form errors announced to screen readers | 1.3.1 Info and Relationships |
 
 #### Visual Regression (if project has visual testing setup)
 | TC-ID | Description | Viewport |
 |-------|-------------|----------|
-| TC-FEATURE-V01 | Layout consistency at mobile width | 375x812 |
+| TC-FEATURE-006 | Layout consistency at mobile width | 375x812 |
 
 #### Cross-Browser Matrix (include if project runs tests across multiple browsers)
 | Browser | Priority | Reason |

package/dist/{2.0.8 → 2.0.10}/claude/plugin/skills/review-test-cases/SKILL.md

@@ -30,7 +30,6 @@ If no argument provided, search for `test-cases/*.md` files and review the most
 1. Read the test case spec file
 2. Read any related files for context:
    - `e2e-plan/conventions.md` or `e2e-plan/coverage-plan.md` if they exist
-   - `e2e-tracker.md` if it exists (to understand what was explored)
 3. Extract the target URL from the spec header
 
 ### Step 2: Run the Review Checklist
@@ -46,11 +45,11 @@ Evaluate every test case against each criterion. Track findings by severity:
 | Check | What to Look For |
 |-------|-----------------|
 | Happy path present | At least one Critical-priority test covers the primary success flow end-to-end |
-| Error paths covered (MINIMUM) | Every spec MUST have at least: (1) one server error test (500), (2) one network failure test (timeout/offline), (3) one empty state test. If auth is involved: (4) one session expiry test. Missing any of these is a BLOCKER, not a suggestion |
+| Error paths covered (when applicable) | For features that depend on backend retrieval/submission, expect coverage for meaningful server/network failures. For collection/data-driven UIs, expect empty-state coverage. For auth-gated features, expect session/auth edge cases. Missing an applicable category is a BLOCKER; a clearly documented non-applicable category is acceptable |
 | Boundary conditions | Min/max values, empty inputs, special characters, long strings |
 | Authentication edge cases | Session expiry, unauthorized access, role-based differences (if applicable) |
 | Navigation edge cases | Back/forward, direct URL access, refresh mid-flow |
-| Missing user actions | Every interactive element on the page should appear in at least one test case |
+| Missing critical user actions | Every user-critical action in scope should appear in at least one test case. Ancillary controls may be omitted if they are not material to the target journey |
 
 #### 2b. Specification Quality
 
@@ -59,7 +58,7 @@ Evaluate every test case against each criterion. Track findings by severity:
 | Steps are concrete | "Click the Submit button" not "submit the form"; "Enter 'test@example.com' in Email field" not "enter email" |
 | Expected results are observable | Specific text, URL change, element state — not "page updates" or "works correctly" |
 | Preconditions are explicit | Auth state, test data, feature flags, starting URL — nothing assumed |
-| TC-IDs are sequential | No gaps, no duplicates, correct feature prefix |
+| TC-IDs are sequential | No gaps, no duplicates, and use the canonical `TC-<FEATURE>-<NNN>` format |
 | Priority is justified | Critical = blocks core journey; not everything is Critical |
 | Categories are accurate | Happy Path vs Validation vs Edge Case — correctly classified |
 

package/dist/{2.0.8 → 2.0.10}/claude/plugin/skills/write-test-code/SKILL.md

@@ -95,7 +95,7 @@ Avoid `.first()` / `.nth()` unless a strong, documented reason exists — scope
 - If explicit waiting needed, wait for meaningful state: visibility, enabled, URL, specific network response, spinner gone
 
 ### Test Case IDs
-- Every test MUST have a unique TC-ID: `TC-<FEATURE>-<NUMBER>`
+- Every test MUST have a unique TC-ID: `TC-<FEATURE>-<NNN>`
 - Include in test title: `test('TC-LOGIN-001: User can log in with valid credentials', ...)`
 - Sequential within feature area, never reused
 - When adding to existing file, check existing IDs and continue the sequence
@@ -143,8 +143,9 @@ See [references/api-setup-teardown.md](references/api-setup-teardown.md) for ful
 
 ### Network Interception and Error Paths
 Use `page.route()` to mock server errors, patch responses, assert backend calls, or block
-heavy resources. Every feature needs error path tests: server error (500), network timeout,
-and empty state at minimum.
+heavy resources. Add error path tests when they meaningfully apply to the feature: for example,
+server/network failures for backend-driven flows, empty states for collection/data-driven UIs,
+and session/auth cases for gated features. If a category is not applicable, do not invent it.
 
 See [references/network-interception.md](references/network-interception.md) for full patterns with code examples.
 

package/dist/{2.0.8 → 2.0.10}/claude/plugin/skills/write-test-code/references/api-setup-teardown.md

@@ -80,4 +80,4 @@ export const test = base.extend<{ testTicket: { id: string; title: string } }>({
 
 For environments where individual deletion is impractical, tag test data (e.g., `title LIKE 'Test %'`) and delete in batch during `globalTeardown.ts`.
 
-If the cleanup API endpoint is unknown, do not invent one. Leave a clear `TODO` with the missing endpoint details, document the cleanup gap in the test file or tracker, and prefer fixture-scoped or environment reset strategies that you can verify. If cleanup is genuinely impossible (no API, no database access), document this as a known limitation in the test file header AND add an `afterEach` that logs a warning.
+If the cleanup API endpoint is unknown, do not invent one. Leave a clear `TODO` with the missing endpoint details, document the cleanup gap in the test file or working notes, and prefer fixture-scoped or environment reset strategies that you can verify. If cleanup is genuinely impossible (no API, no database access), document this as a known limitation in the test file header AND add an `afterEach` that logs a warning.

package/dist/{2.0.9 → 2.0.10}/codex/plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "e2e-test-builder",
-  "version": "2.0.9",
+  "version": "2.0.10",
   "description": "Full-pipeline Playwright E2E test generation \u2014 explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
   "author": {
     "name": "Athenaflow"

package/dist/{2.0.9 → 2.0.10}/codex/plugin/package.json

@@ -1,9 +1,15 @@
 {
   "name": "@athenaflow/plugin-e2e-test-builder",
-  "version": "2.0.9",
+  "version": "2.0.10",
   "description": "Full-pipeline Playwright E2E test generation — explores your live site via browser, detects existing test conventions, plans coverage gaps, produces reviewed test specs, writes production-grade test code with quality gates, and stabilizes flaky tests",
   "license": "MIT",
   "publishConfig": {
     "access": "public"
-  }
+  },
+  "files": [
+    ".claude-plugin/",
+    ".codex-plugin/",
+    "skills/",
+    "dist/"
+  ]
 }

package/dist/{2.0.9 → 2.0.10}/codex/plugin/skills/add-e2e-tests/SKILL.md

@@ -8,7 +8,7 @@ description: >
   Delegates to sub-skills (analyze-test-codebase, plan-test-coverage, generate-test-cases,
   review-test-cases, write-test-code, review-test-code, fix-flaky-tests) internally — do NOT
   skip to sub-skills directly unless the user explicitly requests a narrow activity.
-  Iterative and resumable via tracker file. Uses subagent delegation to save context.
+  Uses subagent delegation to save context.
 allowed-tools: Read Write Edit Glob Grep Bash Task
 ---
 
@@ -22,34 +22,17 @@ Parse the target URL and feature description from: $ARGUMENTS
 
 Derive a **feature slug** from the feature description (e.g., "Login flow" → `login`, "Checkout with payment" → `checkout`). Use this slug for file naming throughout.
 
-## Session Protocol
-
-### 1. Orient: Understand the Project, the Product, and Your Capabilities
+## 1. Orient: Understand the Project, the Product, and Your Capabilities
 
 Before planning any work, build deep situational awareness. This step determines the quality of everything that follows — rushed orientation leads to missed test cases and wasted effort.
 
-**Check for existing progress:**
-- If `e2e-tracker.md` exists in the project root, read it and resume from where you left off — skip to **step 2 (Plan)** with the remaining work.
-- If no tracker exists, this is a fresh start. Proceed with orientation below.
-
-#### First: create initial tasks and tracker
-
-As soon as you parse the user's request:
-
-1. **Create the tracker** — write `e2e-tracker.md` with the goal (URL, feature, slug) and a skeleton plan.
-2. **Create high-level tasks** for the work ahead — analyze codebase, explore the product, plan coverage, generate test specs, write tests, verify tests.
-
-These are your starting skeleton. As you work through orientation and discover the actual shape of the work, refine both the tasks and the tracker — break tasks into granular sub-tasks, add new ones, remove ones that don't apply.
-
-Treat the task list as a visible milestone log. Keep it concise, but update it continuously. Do not leave broad tasks open until the end and then mark everything complete in one batch.
-
-#### 1a. Understand the codebase
+### Understand the codebase
 
 - Does a Playwright config exist (`playwright.config.{ts,js,mjs}`)? If not, you will need to scaffold one (see Scaffolding section).
 - Are there existing tests? What conventions do they follow — naming, locators, fixtures, page objects, auth?
 - Load the `analyze-test-codebase` skill and follow its methodology.
 
-#### 1b. Understand the product
+### Understand the product
 
 This is the most important part of orientation. You cannot write good tests for a product you don't understand.
 
@@ -59,7 +42,7 @@ This is the most important part of orientation. You cannot write good tests for
 
 Why this matters: absent explicit exploration, agents tend to write tests based on assumptions about how a product works rather than how it actually works. The result is tests that target imaginary behavior or miss critical real behavior. Spending time here prevents both.
 
-#### 1c. Know your skills
+### Know your skills
 
 You have access to specialized skills that contain deep domain knowledge. Load the relevant skill before performing each activity — skills prevent improvisation and encode best practices.
 
@@ -76,22 +59,11 @@ You have access to specialized skills that contain deep domain knowledge. Load t
 
 Before doing a substantial activity, load the skill that covers that activity so you can follow its workflow rather than improvising.
 
-#### 1d. Update the tracker with orientation findings
-
-After orienting, update the tracker with what you learned about the codebase and product, conventions discovered, and your refined plan. The tracker must always answer these four questions for anyone reading it cold:
-
-1. What is the goal?
-2. What has been done?
-3. What is remaining?
-4. What should I do next?
+## 2. Plan: Refine Tasks Into Granular Checkpoints
 
-See [references/tracker-template.md](references/tracker-template.md) for a concrete template.
+Refine the work into granular checkpoints based on what orientation revealed. The plan should flow from what you learned, not from a fixed template.
 
-### 2. Plan: Refine Tasks Into Granular Checkpoints
-
-By now you have initial tasks and a tracker from step 1. Refine tasks into granular checkpoints. The plan should flow from what you learned during orientation, not from a fixed template.
-
-#### Task granularity
+### Task granularity
 
 Think in small checkpoints, not big phases. Each task should represent a concrete, verifiable unit of progress.
 
@@ -117,11 +89,11 @@ Create tasks for verification steps too (running tests, checking coverage, brows
 
 Update task status as each checkpoint completes. A good pattern is: finish exploration and mark it complete, finish coverage/spec work and mark it complete, finish implementation and mark it complete, then finish review/execution and mark it complete. Do not keep all milestones open until session end.
 
-### 3. Execute
+## 3. Execute
 
 Work through your tasks. Load the relevant skill before each activity.
 
-#### Planning uses the browser heavily
+### Planning uses the browser heavily
 
 When planning what to test (coverage planning, test case generation), use the browser extensively. Don't just catalog elements — interact with the product to discover:
 - What validation messages appear for each field?
@@ -133,14 +105,14 @@ When planning what to test (coverage planning, test case generation), use the br
 
 Every test case you generate should trace back to something you actually observed or deliberately triggered in the browser. This is how you avoid introducing useless test cases (testing imaginary behavior) and avoid missing important ones (behavior you didn't think to check).
 
-#### Subagent delegation
+### Subagent delegation
 
 Delegate heavy browser exploration and test writing to subagents when that saves context for orchestration, verification, and debugging. When delegating:
 - Pass the relevant file paths (conventions, coverage plan, test specs)
 - Instruct the subagent to invoke the appropriate skill (subagents inherit access to plugin skills)
 - Specify concrete output expectations (file path, format, TC-ID conventions)
 
-#### Quality gates
+### Quality gates
 
 Two review gates and a test execution checkpoint are mandatory during execution. The review gates are review-only — they produce findings but do not modify files.
 
@@ -148,45 +120,26 @@ Two review gates and a test execution checkpoint are mandatory during execution.
 1. Load the `review-test-cases` skill and run it against `test-cases/<feature>.md`
 2. If verdict is **NEEDS REVISION** — address all blockers in the spec before proceeding to implementation
 3. If verdict is **PASS WITH WARNINGS** — address warnings if quick, otherwise note them and proceed
-4. Record the review verdict in the tracker
-
 **Gate 2: Review test code** (after `write-test-code`, before final test execution)
 1. Load the `review-test-code` skill and run it against the implemented test files
 2. If verdict is **NEEDS REVISION** — fix all blockers before running tests for signoff
 3. If verdict is **PASS WITH WARNINGS** — fix warnings that affect stability, proceed with execution
-4. Record the review verdict in the tracker
 
 **Checkpoint: Test execution**
 1. Run the tests: `npx playwright test <file> --reporter=list 2>&1`
-2. Record full output — green test output is the only proof of correctness
+2. Inspect the full output — green test output is the only proof of correctness
 3. If tests fail, load the `fix-flaky-tests` skill and follow its structured diagnostic approach. Do not guess-and-retry.
-4. Maximum 3 fix-and-rerun cycles per test. If stuck after 3 cycles, record the diagnostic output in the tracker and move on.
-
-**Test execution and coverage checks must never be delegated to subagents.** Run `npx playwright test` directly and record the output.
-
-#### Update the tracker as you work
-
-Do not wait until session end. After each meaningful chunk of progress (completing a step, discovering a blocker, producing an artifact), update the tracker. If your context window resets, only what's in the tracker survives.
-
-Keep the tracker and task list synchronized. If you record progress in the tracker, update the corresponding task status in the same phase of work.
-
-#### Error recovery
-
-If infrastructure failures occur (browser MCP unavailable, clone failures, npm install errors), see [references/error-recovery.md](references/error-recovery.md) for diagnostic steps. General pattern: diagnose, attempt one known fix, if still stuck record in tracker and ask the user.
+4. Maximum 3 fix-and-rerun cycles per test. If stuck after 3 cycles, move on with the diagnostic output.
 
-### 4. End of Session
+**Test execution and coverage checks must never be delegated to subagents.** Run `npx playwright test` directly.
 
-Before exiting:
-1. Ensure the tracker reflects all progress, discoveries, and blockers from this session
-2. Write clear instructions for what the next session should do
-3. If all work is complete and all tests pass with full TC-ID coverage: write `<!-- E2E_COMPLETE -->` as the last line of the tracker
-4. If an unrecoverable blocker prevents progress: write `<!-- E2E_BLOCKED: reason -->` as the last line
+### Error recovery
 
-Do not write terminal markers prematurely. Only after you are confident the work is truly done or truly stuck.
+If infrastructure failures occur (browser MCP unavailable, clone failures, npm install errors), see [references/error-recovery.md](references/error-recovery.md) for diagnostic steps. General pattern: diagnose, attempt one known fix, if still stuck ask the user.
 
 ## Scaffolding
 
-If Playwright is not set up in the target project, follow the procedure in [references/scaffolding.md](references/scaffolding.md) to clone the boilerplate, merge configuration, and install dependencies. Log all scaffolding steps in the tracker.
+If Playwright is not set up in the target project, follow the procedure in [references/scaffolding.md](references/scaffolding.md) to clone the boilerplate, merge configuration, and install dependencies.
 
 ## Authentication