retestkit 1.4.1

package/openspec/changes/archive/2025-12-18-add-mcp-server-foundation/specs/mcp-server-core/spec.md

@@ -0,0 +1,183 @@
+## ADDED Requirements
+
+### Requirement: MCP Server Initialization
+
+The system SHALL provide an MCP server that initializes with proper identification and connects to the configured transport.
+
+#### Scenario: Server starts with stdio transport
+
+- **GIVEN** the environment variable `TRANSPORT` is set to `stdio` or not set
+- **WHEN** the server entry point is executed
+- **THEN** it SHALL identify itself with name "testing-mcp" and version from package.json
+- **AND** it SHALL connect to stdio transport for communication
+
+#### Scenario: Server starts with HTTP transport
+
+- **GIVEN** the environment variable `TRANSPORT` is set to `http`
+- **AND** the environment variable `PORT` is set to a valid port number
+- **WHEN** the server entry point is executed
+- **THEN** it SHALL start a Streamable HTTP server on the specified port
+- **AND** it SHALL accept MCP protocol connections over HTTP
+
+#### Scenario: Server handles graceful shutdown
+
+- **GIVEN** the server is running
+- **WHEN** the process receives SIGINT or SIGTERM
+- **THEN** the server SHALL disconnect gracefully
+- **AND** the process SHALL exit with code 0
+
+### Requirement: Configuration Validation
+
+The system SHALL validate configuration at startup using Zod schemas and fail fast on invalid configuration.
+
+#### Scenario: Valid configuration starts server
+
+- **GIVEN** all required environment variables are valid
+- **WHEN** the server starts
+- **THEN** configuration SHALL be parsed and validated
+- **AND** the server SHALL proceed with initialization
+
+#### Scenario: Invalid configuration fails fast
+
+- **GIVEN** an environment variable has an invalid value (e.g., `PORT=invalid`)
+- **WHEN** the server attempts to start
+- **THEN** it SHALL log a descriptive error message
+- **AND** the process SHALL exit with a non-zero code
+
+### Requirement: Pluggable Transport Layer
+
+The system SHALL support multiple transport types through a pluggable architecture with transport selection via environment configuration.
+
+#### Scenario: Transport factory selects stdio
+
+- **GIVEN** the transport configuration specifies `stdio`
+- **WHEN** the transport factory is invoked
+- **THEN** it SHALL return a configured StdioServerTransport instance
+
+#### Scenario: Transport factory selects HTTP
+
+- **GIVEN** the transport configuration specifies `http` with a port
+- **WHEN** the transport factory is invoked
+- **THEN** it SHALL return a configured StreamableHTTPServerTransport instance
+
+### Requirement: Self-Describing Tool Registry
+
+The system SHALL maintain a tool registry where each tool exports a standard interface including name, description, Zod input schema, and async handler function.
+
+#### Scenario: Tool is registered and discoverable
+
+- **GIVEN** a tool is added to the registry
+- **WHEN** an MCP client requests the tool list
+- **THEN** the tool SHALL appear in the list with its name and description
+- **AND** the input JSON Schema SHALL be generated from the Zod schema
+
+#### Scenario: New tool follows registry pattern
+
+- **GIVEN** a developer creates a new tool
+- **WHEN** the tool exports `{ name, description, inputSchema, handler }`
+- **AND** the tool is added to the registry index
+- **THEN** it SHALL be automatically registered with the MCP server
+
+### Requirement: Hello Tool Implementation
+
+The system SHALL provide a "hello" demonstration tool that accepts a name parameter and returns a greeting message, serving as a reference implementation of the tool pattern.
+
+#### Scenario: Hello tool returns greeting
+
+- **GIVEN** the hello tool is registered
+- **WHEN** called with input `{ "name": "World" }`
+- **THEN** it SHALL return content with text "Hello, World!"
+
+#### Scenario: Hello tool validates input
+
+- **GIVEN** the hello tool is registered
+- **WHEN** called without required name parameter
+- **THEN** it SHALL return a validation error
+
+### Requirement: Structured Logging
+
+The system SHALL provide structured JSON logging with configurable log levels and automatic redaction of sensitive fields.
+
+#### Scenario: Log output is structured JSON
+
+- **GIVEN** the server is running
+- **WHEN** a log event occurs
+- **THEN** it SHALL be output as a JSON object with timestamp, level, and message fields
+
+#### Scenario: Sensitive fields are redacted
+
+- **GIVEN** a log message contains a field matching a sensitive key pattern (password, token, secret, apiKey, authorization)
+- **WHEN** the log is written
+- **THEN** the sensitive field value SHALL be replaced with "[REDACTED]"
+
+#### Scenario: Log level is configurable
+
+- **GIVEN** the environment variable `LOG_LEVEL` is set to a valid level (debug, info, warn, error)
+- **WHEN** the server starts
+- **THEN** only log messages at or above that level SHALL be output
+
+### Requirement: Project Build Configuration
+
+The system SHALL be buildable to JavaScript for production deployment using TypeScript compiler.
+
+#### Scenario: Project builds successfully
+
+- **GIVEN** the source code is valid TypeScript
+- **WHEN** `npm run build` is executed
+- **THEN** compiled JavaScript SHALL be output to `dist/` directory
+- **AND** the build SHALL complete without errors
+
+#### Scenario: Development mode runs with hot-reload
+
+- **GIVEN** the development dependencies are installed
+- **WHEN** `npm run dev` is executed
+- **THEN** the server SHALL start with file watching enabled
+- **AND** changes to source files SHALL trigger automatic restart
+
+#### Scenario: Package is executable as CLI
+
+- **GIVEN** the project is built
+- **WHEN** `npx testing-mcp` is executed (or the bin entry is invoked)
+- **THEN** the server SHALL start with default configuration
+
+### Requirement: Unit Test Infrastructure
+
+The system SHALL include unit test configuration for validating tool handlers in isolation.
+
+#### Scenario: Unit tests execute successfully
+
+- **GIVEN** unit test files exist in the project
+- **WHEN** `npm test` is executed
+- **THEN** the test runner SHALL discover and execute all test files
+- **AND** results SHALL be reported to stdout
+
+#### Scenario: Tool handlers are testable in isolation
+
+- **GIVEN** a tool handler function
+- **WHEN** called directly with valid input
+- **THEN** it SHALL return the expected result without requiring server initialization
+
+### Requirement: Integration Test Infrastructure
+
+The system SHALL include integration tests that spawn the server and communicate using the MCP protocol to verify end-to-end behavior.
+
+#### Scenario: Integration test spawns server
+
+- **GIVEN** integration test configuration exists
+- **WHEN** an integration test runs
+- **THEN** it SHALL spawn the server as a child process
+- **AND** connect to it using StdioServerTransport
+
+#### Scenario: Integration test executes tool end-to-end
+
+- **GIVEN** an integration test has connected to the server
+- **WHEN** it calls a tool with valid input
+- **THEN** it SHALL receive the expected response payload
+- **AND** verify the response matches expected format
+
+#### Scenario: Integration test verifies error handling
+
+- **GIVEN** an integration test has connected to the server
+- **WHEN** it calls a tool with invalid input
+- **THEN** it SHALL receive an appropriate error response
+- **AND** verify the error format matches MCP protocol specification

package/openspec/changes/archive/2025-12-18-add-mcp-server-foundation/tasks.md

@@ -0,0 +1,112 @@
+## 1. Project Configuration
+
+- [x] 1.1 Initialize `package.json` with:
+  - name: "testing-mcp"
+  - type: "module"
+  - exports map: `{ ".": "./dist/index.js" }`
+  - bin entry: `{ "testing-mcp": "./dist/index.js" }`
+  - scripts: dev, build, test, test:integration, start
+  - engines: `{ "node": ">=22.18.0" }`
+- [x] 1.2 Create `tsconfig.json` targeting ES2022, NodeNext module resolution, strict mode enabled
+- [x] 1.3 Install dependencies: `@modelcontextprotocol/sdk`, `zod`
+- [x] 1.4 Install dev dependencies: `typescript`, `tsx`, `vitest`, `@types/node`
+- [x] 1.5 Add `.gitignore` entries for `node_modules/`, `dist/`, and coverage reports
+- [x] 1.6 Create `vitest.config.ts` with TypeScript and ESM support
+
+## 2. Project Structure
+
+- [x] 2.1 Create `src/` directory structure:
+  ```
+  src/
+  ├── index.ts
+  ├── server.ts
+  ├── config.ts
+  ├── logger.ts
+  ├── transports/
+  │   ├── index.ts
+  │   ├── stdio.ts
+  │   └── http.ts
+  ├── tools/
+  │   ├── index.ts
+  │   └── hello.ts
+  ├── schemas/
+  │   └── config.ts
+  └── types/
+      └── tool.ts
+  ```
+
+## 3. Configuration & Logging
+
+- [x] 3.1 Create `src/schemas/config.ts` with Zod schema for environment config:
+  - `TRANSPORT`: enum `stdio` | `http` (default: `stdio`)
+  - `PORT`: number (default: `3000`, required when TRANSPORT=http)
+  - `LOG_LEVEL`: enum `debug` | `info` | `warn` | `error` (default: `info`)
+- [x] 3.2 Create `src/config.ts` that parses and validates env vars at startup
+- [x] 3.3 Create `src/logger.ts` with:
+  - Structured JSON output
+  - Configurable log level
+  - Secret redaction for sensitive keys (password, token, secret, apiKey, authorization)
+
+## 4. Transport Layer
+
+- [x] 4.1 Create `src/types/tool.ts` with `McpTool` interface
+- [x] 4.2 Create `src/transports/stdio.ts` wrapping StdioServerTransport
+- [x] 4.3 Create `src/transports/http.ts` wrapping StreamableHTTPServerTransport
+- [x] 4.4 Create `src/transports/index.ts` transport factory based on config
+
+## 5. Tool Registry
+
+- [x] 5.1 Create `src/tools/hello.ts` with:
+  - Zod input schema for `name` parameter
+  - Handler returning greeting message
+  - Export following `McpTool` interface
+- [x] 5.2 Create `src/tools/index.ts` registry exporting all tools
+- [x] 5.3 Verify JSON Schema generation from Zod works correctly
+
+## 6. Server Core
+
+- [x] 6.1 Create `src/server.ts` with:
+  - MCP server factory function
+  - Tool registration from registry
+  - Server identification (name, version from package.json)
+- [x] 6.2 Create `src/index.ts` entry point:
+  - Config validation
+  - Logger initialization
+  - Transport creation
+  - Server bootstrap
+  - Graceful shutdown handlers (SIGINT/SIGTERM)
+
+## 7. Unit Tests
+
+- [x] 7.1 Create `src/tools/hello.test.ts` testing:
+  - Handler returns correct greeting
+  - Input validation rejects invalid input
+- [x] 7.2 Create `src/config.test.ts` testing:
+  - Valid config parses correctly
+  - Invalid config throws descriptive error
+- [x] 7.3 Create `src/logger.test.ts` testing:
+  - Output is valid JSON
+  - Sensitive fields are redacted
+- [x] 7.4 Verify `npm test` runs all unit tests successfully
+
+## 8. Integration Tests
+
+- [x] 8.1 Create `tests/integration/` directory
+- [x] 8.2 Create `tests/integration/server.test.ts`:
+  - Spawn server as child process
+  - Connect using MCP client with StdioClientTransport
+  - Verify tool list includes "hello"
+- [x] 8.3 Create `tests/integration/tools.test.ts`:
+  - Call hello tool with valid input, verify response
+  - Call hello tool with invalid input, verify error response
+- [x] 8.4 Add `test:integration` npm script
+- [x] 8.5 Verify integration tests pass
+
+## 9. Validation & Documentation
+
+- [x] 9.1 Verify `npm run build` produces valid output in `dist/`
+- [x] 9.2 Verify `npm run dev` starts server with watch mode (stdio transport)
+- [x] 9.3 Verify `TRANSPORT=http PORT=3000 npm run dev` starts HTTP server
+- [x] 9.4 Test server with MCP client (e.g., Claude Code) to confirm tool discovery and execution
+- [x] 9.5 Add shebang `#!/usr/bin/env node` to entry point for bin execution
+- [x] 9.6 Verify `npx .` works after build (local bin test)

package/openspec/changes/archive/2025-12-18-add-webtest-orchestrator/design.md

@@ -0,0 +1,333 @@
+# Design: Dynamic Web Testing Orchestrator
+
+## Context
+
+This MCP server orchestrates web application testing by:
+1. Managing browser automation via an external Playwright MCP server
+2. Using MCP Sampling for all LLM-powered decisions (client-controlled)
+3. Exposing artifacts as MCP Resources for client consumption
+4. Supporting interactive workflows via MCP Elicitation
+
+The architecture spans multiple systems (this server, Playwright MCP, client LLM) and introduces patterns for capability negotiation, fallback modes, and secure multi-model orchestration.
+
+## Goals / Non-Goals
+
+### Goals
+- Provide end-to-end web testing workflow: explore → analyze → generate tests → execute
+- Use MCP Sampling exclusively for LLM reasoning (no server-side API keys)
+- Support graceful degradation when client lacks sampling/elicitation
+- Ensure all artifacts are browsable as MCP Resources
+- Support cancellation and progress for long-running operations
+- Enforce security: domain allowlists, no credential elicitation, prompt injection resistance
+
+### Non-Goals
+- Authentication/login automation (explicitly out of scope; stop and inform user)
+- Server-side LLM API keys or model selection
+- Visual regression testing (future enhancement)
+- Multi-browser support (Playwright MCP handles this; we just orchestrate)
+- Parallel test execution (single-threaded for v1)
+
+## Architecture Overview
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                        MCP Client                                │
+│  (Claude Desktop, VS Code, custom client)                       │
+│  - Handles sampling/createMessage requests                      │
+│  - Displays resources, prompts                                   │
+│  - Provides elicitation UI                                       │
+└─────────────────┬───────────────────────────────────────────────┘
+                  │ MCP Protocol (stdio/HTTP)
+┌─────────────────▼───────────────────────────────────────────────┐
+│              testing-mcp (This Server)                          │
+│  ┌──────────────┐ ┌──────────────┐ ┌──────────────────────────┐│
+│  │ Lifecycle    │ │ Tool         │ │ Resource Manager         ││
+│  │ Manager      │ │ Handlers     │ │ (workspace/artifacts)    ││
+│  │ (caps nego)  │ │ (5 tools)    │ │                          ││
+│  └──────────────┘ └──────────────┘ └──────────────────────────┘│
+│  ┌──────────────┐ ┌──────────────┐ ┌──────────────────────────┐│
+│  │ Sampling     │ │ Elicitation  │ │ Progress/Cancellation    ││
+│  │ Client       │ │ Client       │ │ Manager                  ││
+│  └──────────────┘ └──────────────┘ └──────────────────────────┘│
+│  ┌──────────────────────────────────────────────────────────────┐│
+│  │ Playwright MCP Client (orchestrates external server)        ││
+│  └──────────────────────────────────────────────────────────────┘│
+└─────────────────┬───────────────────────────────────────────────┘
+                  │ MCP Protocol (stdio subprocess)
+┌─────────────────▼───────────────────────────────────────────────┐
+│           Playwright MCP Server (Microsoft)                     │
+│  - browser_snapshot, browser_take_screenshot                    │
+│  - browser_click, browser_type, browser_navigate               │
+│  - browser_run_code (for DOM extraction)                        │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+## Decisions
+
+### D1: Playwright MCP as subprocess, not embedded
+**Decision**: Spawn Playwright MCP server as a subprocess and communicate via stdio MCP protocol.
+
+**Rationale**:
+- Microsoft's Playwright MCP is maintained separately with frequent updates
+- Subprocess isolation prevents version conflicts
+- Standard MCP client pattern; reusable code
+- Can be configured via environment (e.g., browser type, headless mode)
+
+**Alternatives considered**:
+- Direct Playwright library integration: Higher coupling, maintenance burden
+- HTTP transport to remote Playwright MCP: Adds network complexity for local use
+
+### D2: Sampling-first with fallback modes
+**Decision**: Primary reasoning via `sampling/createMessage`. When sampling unavailable, emit "human prompt" resources for manual execution.
+
+**Rationale**:
+- MCP Sampling keeps API keys client-side (security, flexibility)
+- Fallback ensures server works with minimal clients
+- "Human prompt" resources let users copy/paste to their LLM
+
+**Fallback behavior**:
+- `webtest_crawl_app` without sampling: Returns `needsManualInput: true` and a resource with the prompt
+- Tool accepts `manualNextActions` input to continue crawl with user-provided actions
+
+### D3: Structured JSON schemas for all sampling requests
+**Decision**: All sampling requests include strict JSON output schemas. Responses are validated before use.
+
+**Rationale**:
+- Predictable parsing of LLM responses
+- Type safety in TypeScript handlers
+- Clear contract between server and client LLM
+
+**Schema examples**:
+- Crawl action: `{ actions: [{ tool: string, args: object }], reasoning: string, goalProgress: string }`
+- Test generation: `{ tests: [{ id, name, steps: [...] }] }`
+
+### D4: File-based workspace with Resource URIs
+**Decision**: Each analysis creates a workspace directory. All artifacts written to disk and exposed as `webtest://analysisId/...` resources.
+
+**Rationale**:
+- Persistence survives server restarts
+- Resources are stable, shareable URIs
+- File system is simple, debuggable
+- Enables future features (workspace resume, export)
+
+**Structure**:
+```
+workspaces/
+  {analysisId}/
+    index.json           # Analysis metadata
+    crawls/
+      {crawlId}/
+        index.json       # Crawl metadata, page list
+        pages/
+          {pageId}/
+            snapshot.json
+            screenshot.png
+            dom.html
+        summary.md
+    analysis/
+      app-analysis.md
+      flows.json
+    tests/
+      tests.md
+      tests.json
+    runs/
+      {runId}/
+        report.md
+        artifacts.json
+        steps/
+          {stepId}/
+            screenshot.png
+            snapshot.json
+```
+
+### D5: Capability-based runtime behavior
+**Decision**: Query client capabilities at initialization; store in server context; branch behavior at runtime.
+
+**Rationale**:
+- MCP clients vary in capability support
+- Graceful degradation over hard failures
+- Single codebase serves all client types
+
+**Capabilities checked**:
+- `sampling`: Use sampling or fallback to manual prompts
+- `elicitation`: Ask user or write questions to output
+- `logging`: Emit logs or stay silent
+- `progress`: Report progress or skip
+- `tasks`: Use task-augmented execution for long operations (optional)
+
+### D6: Security boundaries
+**Decision**: Implement multiple security layers.
+
+**Rationale**: Web testing interacts with untrusted content; must prevent abuse.
+
+**Layers**:
+1. **Domain allowlist**: Default to target domain only. Explicitly opt-in for additional domains.
+2. **Prompt injection resistance**: Model instructions are prefixed with "SYSTEM:" and wrapped; page content is clearly demarcated as "USER CONTENT:". Sampling prompts instruct model to ignore instructions in page content.
+3. **No credential elicitation**: If auth required, inform user and stop. Never ask for passwords/tokens via elicitation.
+4. **Action validation**: Before executing Playwright actions, validate they target allowed domains.
+
+### D7: Progress and cancellation implementation
+**Decision**: Use `progressToken` from request `_meta`; emit `notifications/progress`. Check cancellation registry on each loop iteration.
+
+**Rationale**:
+- Standard MCP progress pattern
+- Cancellation enables user control over long crawls
+- Partial results are still valuable
+
+**Implementation**:
+- Maintain `Set<requestId>` of cancelled requests
+- On `notifications/cancelled`, add to set
+- Each crawl/test loop iteration checks set; if cancelled, finalize partial output
+
+### D8: Elicitation for specific decision points
+**Decision**: Use elicitation only for enumerated, non-sensitive decisions.
+
+**Elicitation triggers** (exhaustive list):
+- Cookie consent: "Accept", "Reject", "Dismiss"
+- Modal blocking: "Close modal", "Interact with modal"
+- Ambiguous navigation: Multiple similar options → list them
+- Auth required: "Stop analysis", "Continue unauthenticated"
+
+**Never elicit**: Passwords, tokens, 2FA codes, personal data
+
+### D9: Protocol version requirements for elicitation
+**Decision**: Require MCP protocol revision 2025-06-18 or later; negotiate gracefully with older clients.
+
+**Rationale**:
+- Elicitation is a newer MCP feature not available in all clients
+- Explicit version requirement prevents runtime surprises
+- Graceful degradation for older clients maintains usability
+
+**Implementation**:
+- Declare `protocolVersion: "2025-06-18"` in server capabilities
+- If client negotiates older version, mark elicitation as unavailable
+- Log warning when running in degraded mode
+
+### D10: Resource change signaling
+**Decision**: Implement `resources/list_changed` notifications and optional `resources/subscribe` for live artifact updates.
+
+**Rationale**:
+- Long-running operations (crawl, test execution) produce artifacts incrementally
+- Clients benefit from knowing when new artifacts are available
+- Standard MCP pattern for resource-heavy servers
+
+**Implementation**:
+- Check `capabilities.resources.listChanged` at init
+- Emit `notifications/resources/list_changed` when new resources created
+- Support `resources/subscribe` for per-resource update notifications
+- Fallback: clients poll `resources/list` if notifications unsupported
+
+### D11: Playwright MCP capability adapter
+**Decision**: Dynamically discover Playwright MCP tools and build an adapter layer mapping canonical operations to actual tool names.
+
+**Rationale**:
+- Different Playwright MCP implementations use different naming (browser_*, playwright_*, unprefixed)
+- Microsoft's implementation may change tool names between versions
+- Adapter pattern isolates our code from external API changes
+
+**Implementation**:
+- On first Playwright MCP use, call `tools/list`
+- Build mapping: `{ snapshot: "browser_snapshot", click: "browser_click", ... }`
+- Check for required capabilities; log warnings if missing
+- Cache mapping for session lifetime
+
+### D12: Crawl checkpointing and loop prevention
+**Decision**: Implement periodic checkpoints and multi-level loop detection during crawl.
+
+**Rationale**:
+- Long crawls may be interrupted (cancellation, errors, timeouts)
+- Infinite loops on complex apps are a real risk
+- Checkpoints enable resumption; loop detection prevents resource waste
+
+**Checkpointing**:
+- Write checkpoint every N steps (default 5)
+- Checkpoint includes: step count, visited pages, action history, goal progress
+- Support `resume: true` to continue from checkpoint
+
+**Loop detection**:
+- DOM signature (hash of structural elements) detects same-state loops
+- URL tracking detects navigation cycles
+- Action deduplication prevents repeated identical actions
+- Include loop state in sampling prompts to help model avoid patterns
+
+### D13: Structured logging with correlation and redaction
+**Decision**: Implement MCP logging notifications with correlation IDs, log level control, and sensitive data redaction.
+
+**Rationale**:
+- Progress tells "where we are"; logs tell "why we did that"
+- Correlation IDs enable tracing across analysis → crawl → test
+- Sensitive data (tokens, passwords, cookies) must not leak to logs
+
+**Implementation**:
+- Support `logging/setLevel` for dynamic control
+- Include `analysisId`, `crawlId`, `testRunId`, `iteration` in all logs
+- Redact: URL query params matching sensitive patterns, cookie values, password inputs
+- Log Playwright tool calls and sampling requests for debugging
+
+### D14: Comprehensive prompt injection hardening
+**Decision**: Implement defense-in-depth against prompt injection attacks via page content.
+
+**Rationale**:
+- MCP Sampling forwards untrusted page content to a model
+- Injection attacks could expand scope, exfiltrate data, or request secrets
+- Multiple layers of defense required
+
+**Layers**:
+1. **Demarcation**: Page content wrapped with explicit security warnings
+2. **Instruction protection**: System instructions use `[WEBTEST-SYSTEM]:` prefix
+3. **Action validation**: All actions checked against allowed domains
+4. **Scope enforcement**: Reject actions outside stated user goal
+5. **Exfiltration blocking**: Block POST to external domains, external network calls
+6. **Audit logging**: Log all sampling inputs/outputs for security review
+7. **Test suite**: Include injection resistance tests (direct, indirect, goal hijacking)
+
+## Risks / Trade-offs
+
+### Risk: Sampling latency impacts UX
+**Mitigation**:
+- Emit progress notifications frequently
+- Allow cancellation
+- Batch simple decisions where possible
+
+### Risk: Playwright MCP tool names change
+**Mitigation**:
+- Discover tools at connection time via `tools/list`
+- Maintain mapping from canonical names to actual names
+- Log warnings if expected tools missing
+
+### Risk: Large workspaces consume disk
+**Mitigation**:
+- Configurable retention policy (env var)
+- Screenshots compressed (JPEG quality setting)
+- Future: workspace cleanup command
+
+### Risk: Prompt injection via page content
+**Mitigation**:
+- Clear demarcation in sampling prompts
+- Output schema validation (reject malformed responses)
+- Domain allowlist prevents navigation to attacker-controlled sites
+- Monitoring: log all sampling inputs/outputs for audit
+
+## Migration Plan
+
+This is greenfield functionality; no migration needed. The `hello` tool removal is the only breaking change.
+
+**Rollout**:
+1. Implement core infrastructure (lifecycle, sampling client, Playwright client)
+2. Implement `start_analysis` + resource system
+3. Implement `crawl` with sampling/elicitation
+4. Implement `analyze_app` and `generate_tests`
+5. Implement `run_test_case`
+6. Add prompts
+7. Remove `hello` tool
+8. Documentation and examples
+
+## Open Questions
+
+1. **Playwright MCP package name**: Is it `@anthropic-ai/mcp-playwright`, `@playwright/mcp`, or community package? Need to verify at implementation time.
+
+2. **Tasks support**: The MCP tasks extension is optional. Should we implement it in v1 or defer? **Recommendation**: Defer to v2; progress + cancellation covers most use cases.
+
+3. **Workspace location**: Default to `./workspaces` relative to CWD, or use temp directory? **Recommendation**: Configurable via `WEBTEST_WORKSPACE_DIR` env var, default to `./webtest-workspaces`.
+
+4. **Screenshot format**: PNG (lossless, larger) vs JPEG (lossy, smaller)? **Recommendation**: PNG for accuracy; make configurable.