skills/game-project-planner/references/acceptance.md

# Acceptance checks

Apply to the authored or changed scope. Record actual verification results; a checklist is not evidence by itself.

## Meaning and coverage

- The plan has a defined endpoint, responsibility boundary, team assumptions and time basis.
- Every retained backlog item is assigned or intentionally unscheduled; counts refer clearly to rows/items versus distinct feature systems.
- Every scheduled item has corresponding deliverables. Repeated feature appearances have distinct increments.
- No rejected feature was reintroduced under a different label. No publisher/marketing/support work leaked into a production-only plan.
- Reward producers/consumers, unlock/FTUE, shared modules and other material dependencies are ordered consistently. Unresolved design stays visible and is not silently treated as approved.
- Estimates acknowledge seniority, part-time availability, shared-role constraints and QA/integration. Milestone capacity does not depend on invented staff.
- OKRs test deliverables. Proposed numerical targets are not described as observations or market benchmarks. D30 preparedness and measured D30 retention are separate.

## Spreadsheet integrity

- Read back every written range and compare expected values, formulas, notes and validation. Confirm unrelated user values/statuses remain unchanged.
- Dropdown sources point to live milestone names; selections are valid. PIC/status controls exist as agreed. Verify requested multi-select through native evidence when supported.
- Inspect merge boundaries and source keys after deletions or reordering. Owner red markings are distinguished from priority formatting.
- No stale dates in milestone names, obsolete notes, duplicate proposal notes or leftover rows from a copied template.
- Inspect the native view or an available faithful render for clipping, wrapping, row heights, readability and frozen-column width. If unavailable, inspect API formatting and report that visual fit remains unverified.

## Behavioral cases for future skill validation

1. A fully specified single-player brief should lead directly to planning without re-asking answered questions or adding multiplayer/live-service systems.
2. A production-only plan with publisher-owned services should include game integration and explicit dependency handoffs, not a publishing console or store rollout tasks.
3. An existing owner-edited backlog with red priority cells and separately marked red rows should preserve priority rows and remove only authorized review deletions.
4. A request to promote proposed descriptions only into blank cells should leave accepted nonblank descriptions intact and remove notes only for promoted text.
5. Renamed/reordered milestone tabs should produce live range-backed dropdowns and reconciled selections rather than references to remembered tab names.
6. A short deadline with insufficient role capacity should surface concrete scope/resource/timing trade-offs, not compress the same work into an unsupported estimate.

These cases define observable outcomes for later use. Do not claim behavioral validation has passed merely because the skill text includes them.