functional-validation-planlisted

# Functional validation plan — author protocol A code change is not "done" when the unit tests pass. Someone who did **not** write the code must be able to exercise the feature end-to-end and confirm it behaves as claimed. This skill produces the brief that lets them do that. ## When to apply - Whenever you produce an **implementation plan** that changes MCP-runtime- observable behaviour: the plan must include a functional validation plan as a first-class section, not an afterthought. - Whenever you land a feature or bugfix whose behaviour is observable at **MCP-server runtime** (auth flows, transports, tool surface, resources, prompts, persistence, timing). Skip for changes with no MCP-runtime-observable behaviour: pure docs, comments, formatting, **and pure tooling / dev-tooling** (build scripts, the typecheck/lint/format setup, dev-only scripts, CI, release automation) — those are covered by the standard gates (`pnpm typecheck` / `pnpm check` / `pnpm test` + CI), not a third-party functional pass. Say so explicitly rather than silently omitting the plan. ## Hard rules - **Independent validator.** Write the plan FOR someone other than the implementer — another agent (e.g. the local executor) or a human. Don't assume it shares your conversation context: spell out the state to manipulate and how to observe results. - **Assume a fully ready environment — don't make the validator build it.** The validator's session is already **on the PR branch, in a live