validatelisted

Via `pd-validator`, against a running application. Evidence or nothing. Reading the source and concluding it works is explicitly not validation, and there is no way to record PASS on that basis — the outcome of a step comes from what is attached to it, and `pdkit validate attach` has no `--status`. ## Preconditions `pdkit state <issue>` says `implemented`. Validating a change that is still being written means validating something nobody will ship. ## 1. What is waiting ``` pdkit validate steps --issue <n> ``` The requirements, the tasks with the command each said it would be done by, the plan's `e2e coverage` decision, and whatever is already attached. Turn that into scenarios. This is the part the tests do not reach: a task's `Done when` proves the unit works, and what is left is whether a person using the application gets what the issue asked for. ## 2. The application ``` pdkit validate launch --issue <n> [--build] ``` Prints a CDP endpoint. Playwright MCP attaches to it — configure the server with `--cdp-endpoint`; pdkit starts the application and does not connect to it. `--build` first when the tree is stale. `/pd:doctor` says whether there is anything to drive at all, which is a different problem from Playwright being absent and has a different fix. Stop it when you are done: `pdkit validate stop --issue <n>`. ## 3. Drive it, and attach what you see ``` pdkit validate attach --issue <n> --requirement R2 --requirement R5 \ --title "the dialog does not rea