States the four admissible reasons for a change to state-hub during
retirement -- preserve compatibility, enable extraction, reduce scope, fix
operational risk -- and the inadmissible case: establishing new permanent
ownership in the component being retired.
The operative test is 'where does this live after cutover?', not 'is this a
good change?' Most inadmissible changes are good changes; STATE-WP-0080's
retarget to RMGR-WP-0004 is the worked example.
Enforced by review rather than new automation: a freeze-checker built inside
State Hub would itself be new permanent automation here, so the policy would
violate itself. New tables/routes/MCP tools are the one hard stop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add Intake Definition of Comprehension and work-item Definition of Ready as
hub policies with dashboard edit surfaces, document the Definition family and
DoX-Ok/Failed badge convention, and mark STATE-WP-0076 finished.
