story-readiness

Story readiness validation checks embedded GDD requirement traces, testable acceptance criteria, and dependency status to return READY, NEEDS WORK, or BLOCKED verdicts. This process requires reading supporting design, architecture, and manifest context to identify specific gaps before implementation begins.

GDD traceability links story requirements directly to Game Design Document entries. You need it during pre-sprint vetting and sprint planning escalation to ensure no unresolved design uncertainty exists, preventing wasted implementation time on incomplete or blocked stories.

Dependency and governance checks verify referenced ADR status, such as Accepted versus Proposed, alongside manifest version currency and TR-ID validity. These checks ensure technical decisions are formally approved and engine control rules are documented before development starts.

Yes, story readiness validation applies to workflow scenarios including single story vetting, full sprint scope checking, and all production epic stories. It evaluates operational confidence items like estimates and definition of done evidence across multiple files simultaneously.

A BLOCKED verdict occurs when dependency checks fail, such as referencing a Proposed rather than Accepted ADR, invalid TR-IDs, or outdated manifest versions. The validation returns specific blockers indicating unresolved design uncertainty or missing governance approvals.