Capability Retirement with Migration Paths
Retire a distributed capability with replacement and migration information.
These examples and illustrative results are independently authored teaching materials, not measured model results.
Use case
Retire review-old in favor of review-new. Immediate disappearance loses installed users’ path and can prompt later agents to recreate deliberate removals.
Mechanism
Use actual registry lifecycle states, recording identity, reason, replacement, support deadline and migration steps. Preserve discoverable aliases/explanations and removal intent. Check links, consumers and new contracts; retired means unavailable, not silent switching to broader behavior. Record revisit conditions and keep deletion authorized.
Bad example
Mark deprecated and erase every explanation/ID, leaving users to guess and agents to restore it.
Good example
Retain teaching review-old deprecation/deadline/review-new steps. Old links expose reasons/replacements; retired retains identity/revisit conditions without invocation. Verify new contracts/configuration and actual support for fields instead of inventing APIs.
Why the change matters
Lifecycle separates migration from retirement. Identity/history preserves discovery and intent; replacement paths enable continued tasks.
Observable expectation
Teaching old entries display state/replacement links and changed parameters have steps. Unsupported state fields need existing mechanisms. Future missing-capability checks recognize intentional removal records.
Limits
Registries/hosts differ, and planned dates are not completion facts. Replacement is not necessarily equivalent; verify permissions/artifacts. History cannot preserve secrets/inaccuracy; correct with dated notes.