product-acceptancelisted

# Product acceptance (chartered session testing) **Goal:** find what the product promises and does not keep, and what a person actually experiences using it — the two things code review structurally cannot see, because it reads what exists rather than what was expected. **Relation to the existing skills.** This skill is the _planner and the debriefer_, not a replacement for the walkers. The promises-versus-reality session **is** `tabletop`, run per scenario. Verifying a serious finding before acting on it **is** `verification`, and trying to kill it **is** `refutation`. Rendered-UI checks **are** `visual-verification`. What this skill adds: which sessions to run, in what order, at which moment in the product's life, and how their outputs become one reviewable body of evidence. **Execution shape:** session-based test management (Bach & Bach, 2000) — _charter_, _session_, _session sheet_, _debrief_. In an agent setting a session is one subagent lane, the charter is its brief, the session sheet is a result matrix plus a findings file, and the debrief is the orchestrator judging what lands. --- ## 1. Decide _when_ before deciding _what_ A session run at the wrong moment wastes the finding, not just the time. Four tests, in order. ### Shelf-life against the biggest pending change Ask: _will a change already on the roadmap invalidate this finding?_ Durability differs sharply, and a planned rework is the usual invalidator: | Session