PRD: Expand playground e2e coverage for selection context and MCP workflows

[jazelly]

Problem Statement

The playground e2e suite now proves one important happy path: selecting the profile email field captures a ProfileField source context and copy includes a source snippet. That is useful coverage, but it does not yet cover the main risk areas from the react-grab parity work: overlay hit testing, selector robustness, MCP tool responses, source-snippet negative paths, and graceful behavior when no selection exists.

Solution

Expand playground-side e2e coverage around observable selection behavior and MCP workflows. Tests should continue to use public browser/runtime interfaces and MCP tool calls rather than private module internals. The suite should lock down the behaviors that matter to users and reviewers while keeping the test matrix small enough to run locally during phased development.

User Stories

1. As a developer using the playground, I want selection mode to be exercised end-to-end, so that regressions are caught before release.
2. As an MCP client user, I want the MCP get last selection context tool to return the same useful context as the browser runtime, so that agent workflows are reliable.
3. As an MCP client user, I want the MCP copy last selection context tool to return a clear result, so that clipboard workflows can be automated safely.
4. As a user who has not selected anything yet, I want the MCP tool to report that no selection exists, so that agents can recover cleanly.
5. As a UI user, I want overlays and devtool surfaces to be ignored during selection, so that I can select the app element underneath.
6. As a user selecting an element with a stable id, I want the selector to use that stable id, so that future automation can find the same element.
7. As a user selecting an element without a stable id, I want the selector fallback to still identify the selected element, so that selection remains useful across real apps.
8. As a user selecting a Material UI-backed field, I want the app component to be reported over library internals, so that edit suggestions target authored code.
9. As a maintainer, I want source snippet tests to cover both successful and rejected paths, so that source boundaries are enforced over time.
10. As a contributor, I want each e2e test to describe one user-visible behavior, so that failures explain what capability regressed.
11. As a developer running the suite locally, I want Playwright to start the playground automatically, so that the tests are easy to run.
12. As a CI operator, I want the tests to be deterministic on a fixed port, so that failures are debuggable.
13. As a reviewer, I want the tests to cover the exact initiatives from the selection-context work, so that the branch does not drift into unverified functionality.
14. As a future implementer, I want fixture UI states in the playground that intentionally exercise hard DOM cases, so that coverage can grow without brittle selectors.
15. As a package maintainer, I want the test suite to stay scoped to development behavior, so that it does not imply production runtime support that is out of scope.

Implementation Decisions

• Keep the playground e2e suite as the primary user-visible integration test surface for selection context behavior.
• Add focused playground fixtures only where existing screens cannot express a necessary behavior.
• Exercise public browser runtime methods for direct runtime behavior.
• Exercise MCP tool calls for server-to-browser roundtrip behavior where practical.
• Keep one behavior per test case and avoid asserting private implementation details.
• Prefer stable semantic selectors in the playground fixture when asserting selection behavior.
• Keep the existing port convention unless the project adopts a broader port allocation strategy.

Testing Decisions

• Good tests should verify externally visible behavior: captured component names, selectors, resolved source summaries, source snippets, no-selection responses, and rejected source enrichment.
• Tests should not assert internal fiber traversal order unless that order is part of the public output contract.
• Add e2e coverage for no-selection MCP response, browser runtime copy behavior, MCP context enrichment, overlay hit testing, selector fallback, and source rejection.
• Reuse the existing selection-context e2e tests as prior art.
• Use TDD vertical slices: add one failing behavior test, implement or adjust only enough code to pass, then refactor.
• Keep broad cross-browser coverage out of the default suite unless a real browser-specific bug is found.

Out of Scope

• Full visual regression testing of the toolkit UI.
• Testing every supported React framework in the playground.
• Adding production build e2e coverage.
• Testing React internals directly.
• Replacing unit tests for path classification with slow browser tests.

Further Notes

This PRD complements the source hardening PRD. The source hardening work should define the boundary behavior, and this e2e expansion should prove that the boundary remains true through user-facing workflows.