Question
What release strategy should govern Ultra once its behavior and verification contract are settled?
Choose and document:
- whether the feature launches directly, behind an opt-in flag, or in a staged/canary form;
- minimum supported OpenCode and Codex client/catalog baselines;
- behavior when upstream removes, renames, or changes Ultra metadata or semantics;
- release-note language and the boundary of the parity claim;
- upgrade guidance for existing custom
ultra configurations;
- runtime signals that justify rollback or disabling the feature;
- the smallest safe rollback path without corrupting user configuration or catalog caches;
- additions to
UPSTREAM_SYNC.md, upstream-watch.json, automated parity watches, or maintenance issues;
- required smoke evidence and sign-off before package publication.
The resolution should produce a release gate, rollback decision tree, and named upstream surfaces that remain owned after launch. It must not publish or release anything.
Question
What release strategy should govern Ultra once its behavior and verification contract are settled?
Choose and document:
ultraconfigurations;UPSTREAM_SYNC.md,upstream-watch.json, automated parity watches, or maintenance issues;The resolution should produce a release gate, rollback decision tree, and named upstream surfaces that remain owned after launch. It must not publish or release anything.