Migrations
Forge is being productionized as one coordinated release train. That means downstream migrations are part of the core delivery, not follow-up work.
Current release-blocking downstreams
aut0aut0/sdk/rust-sdkinfra/agent-native-platforms/garden/celeryinfra/agent-native-platforms/garden/basil
Migration rules
- breaking changes must be approved before implementation
- downstreams migrate with Forge, not after it
- security and contract changes are not optional per-consumer
- release readiness is blocked by the weakest required downstream
What migration work includes
Each downstream migration should cover:
- code changes
- test changes
- documentation changes
- runtime contract validation
- release-gate compatibility where applicable
What not to rely on
Downstreams should not rely on:
- private vendor wrappers that bypass the Forge core contract
- compatibility shims that weaken security or truthfulness
- docs that describe planned behavior as already shipped
Docs rule
Public migration docs must distinguish between approved contract changes, shipped runtime behavior, and future roadmap items.