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

• aut0
• aut0/sdk/rust-sdk
• infra/agent-native-platforms/garden/celery
• infra/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.