Scope control: separate new features from release blockers

Locked Feature Scope protects the game Clowdr approved. It does not excuse a broken critical path, missing credits, or assets that fail the Quality Baseline. Those problems may become Release Blockers even when every planned ticket is complete.

The useful distinction is what the change accomplishes: a new player-facing capability expands the game; a Release Blocker makes the already approved game publishable. This guide applies that distinction from Clowdr's production process and ADR 0005.

Test a request before creating a task

For each proposed change, answer five questions:

1. Which approved capability or Player Promise does it serve?
2. What fails without it, and where is that failure visible?
3. Does it repair the approved experience or add a new capability?
4. What integration and verification work will it require?
5. Who decides, owns the work, and records the result?

A hypothetical controller-navigation defect that prevents starting the approved game is a blocker. A request to add a second combat mode is a new feature. Calling that mode “polish” does not change its scope.

Craft problems need the same care. Fixing unreadable feedback can be required to meet the approved baseline. Adding a new visual customization system cannot enter through that repair.

Keep cut features outside the active commitment

Record declined additions in a separate future-pitch list. Give each a short reason and the date of the decision. The list keeps the idea available without making it a hidden promise to contributors.

During the Slice Phase, claimable work stays limited to the Vertical Slice. After Quality Baseline approval, the remaining approved Feature Scope opens for Production. Neither gate allows a contributor to quietly enlarge the game because a task looked easy in isolation.

If the approved scope no longer fits the project's capacity, bring that conflict to the Lead and Clowdr. Record any approved change and its effect on the Player Promise; do not silently drop part of the promised experience.

A deadline does not waive the standard

At a planned release date, review the integrated build and the unresolved blockers. Cut unapproved additions first. Resolve the work required for the approved scope, then submit a Release Candidate when the Project is Done.

The Lead cannot declare publication to meet a calendar target. Clowdr's Publication Review checks the Five Proofs of Release and may require revision or decline publication.

Use the Vertical Slice guide to establish the baseline and How We Ship to follow the release path. This decision test helps classify work; it does not guarantee that any project will finish.