validating-e2e-coveragelisted

# Validating E2E Coverage **Render before asking.** Before any AskUserQuestion, render the decision context as assistant chat text. Content that exists only in a Read result, a subagent/Agent return, or the question/option strings **does not count as rendered** (the UI shows a compact card) — restate it in chat first. Post-hoc validation that reads a written feature spec, detects which operational/architectural surfaces the feature touches, maps them to the E2E taxonomy, gap-analyzes against existing acceptance criteria, and returns recommended additions. The goal is to catch the scenarios that live outside the feature's own logic — timeouts, idempotency, degradation, privilege boundaries — before they become production incidents. ## When to Invoke | Caller | Trigger | |---|---| | `/ship-discuss` Phase 3.7 | After spec write, before quality gate | | `/ship-discuss` REFINE mode | On re-entry to existing feature (backfill) | ## Inputs The calling skill provides: - Feature file path (the written spec at `<SHIPYARD_DATA>/spec/features/FNNN-slug.md`) - Existing AC list (parsed from the feature file's `## Acceptance Criteria` section) - Domain hints (e.g., `["payments", "auth"]`) from the discussion context ## Procedure ### Step 1: Detect Touch Surfaces Read the feature spec: user story, acceptance criteria, interface, data model, technical notes, flows, error handling sections. For each line, match against the touch-surface detection table in `${CLAUDE_PLUGIN_ROOT}/skills