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> |
||
|---|---|---|
| .. | ||
| intake-doc.md | ||
| repo-doi.md | ||
| retirement-freeze.md | ||
| service-dom.md | ||
| work-item-dor.md | ||
| workstream-dod.md | ||