aiw-validationlisted

# Validation Read this file before presenting work for the human's done decision, alongside aiw-verification and aiw-housekeeping. ## Why This Skill Exists Verification asks whether the change is correct. Validation asks whether the result is the thing that was wanted. The two fail independently, and work can pass every check in a repository while delivering nothing the human asked for. A request arrives in the human's words. It becomes an issue, then a plan, then a diff, and every gate downstream checks the work against the nearest translation. The human's own words are read once, at the start, and never again. The translations lose in one direction: toward what is convenient to check. ## The Deliverable The deliverable is what the human will open, read, run, or look at when this is done. Not the code that produces it, not the tests that cover it, not the pull request that carries it. Name it in the plan, as a noun, in the human's terms. "The threads page shows applications per week as a chart" is a deliverable. "Add charting to the threads view" is the work, and naming the work instead is how the thing goes missing: the work can be complete while the artifact is absent. If the task produces nothing a human meets, say so in the plan. That sentence discharges the questions below, and it is an argument about what the change is, never a bare assertion. The end impact is still stated, in the plan and in the line this skill leaves behind, because a task with nothing to op