e2e-capability-verificationlisted

# E2E機能検証 UI automationやstagingでWeb appを検証する。機能が見当たらない、dataを変更し得る、または認証済みbrowser stateが必要な場合に特に適用する。 **振り分け**: repositoryのE2E wrapper、staging検証、破壊的flow gateには本Skillを使う。アドホック操作、tool選択、協調ログイン、repositoryをまたぐ個人sessionには `browser-operations` を使う。 ## 必須ガードレール - Do not conclude "not possible" from visible UI alone. Check at least one code/API source too: routes, shared schemas, generated OpenAPI, tests, DB schema, or network calls. - Separate "no visible affordance" from "no capability". Say which one you have evidence for. - Before destructive E2E, identify cleanup path first: UI delete, API delete, DB-safe fixture cleanup, or explicit user approval to leave data. - Treat staging as real data unless the user explicitly says test data can be modified. - Prefer dedicated staging/test users with minimum privileges; never use production or personal daily-use browser sessions for agent-driven E2E. - Treat Playwright `storageState` files as credentials. Do not print, paste, summarize, commit, or inspect their cookie/localStorage/token contents. - If authenticated browser state exists, reuse it only through an isolated context, and verify identity/tenant before actions. - Do not ask the user to paste passwords, tokens, cookies, or storageState contents into the prompt. Ask them to run a local wrapper or auth setup if secrets are missing. - If the repo provides an E2E wrapper, metadata precheck, auth-state validator, or runbook, treat that as canonical. Do not bypass it with raw Playwr