| name | goobers-workflow-upgrade |
| description | Compare a Goobers workflow with a target release and plan or apply an explicit, reviewable DSL upgrade using release-matched schemas and validation. |
Goobers workflow upgrade
Upgrade configuration deliberately; never reinterpret it against the newest
default branch or silently bump its DSL version. Resolve the current toolkit,
binary, and source set with goobers-environment-resolver first.
Upgrade procedure
- Read each workflow's explicit
dslVersion and run goobers versions --json
for the target binary. Select a target version whose lifecycle level permits
loading. Treat preview versions as opt-in and unsupported versions as load
errors.
- Compare the current and target contracts using this toolkit's
release-matched
docs/, api/schemas/, config-examples/, and
release.json. Use goobers features --dsl-version <version> when that
optional command is available.
- Produce a reviewable migration plan before editing. Identify field changes,
state-graph changes, stage input/output vocabulary, capabilities, and
behavior changes separately.
- If the target binary exposes a
goobers fix --to <version> command, use it
only as an author-requested starting point and review its diff. Otherwise
make the smallest manual change supported by the bundled target schemas.
Never assume a migration command exists.
- Update one workflow version boundary at a time. Preserve user-owned
instructions and unrelated definitions.
- Run
goobers validate against the target release and repair schema,
reference, reachability, gate-outcome, and capability-admission errors.
Report any remaining semantic review that validation cannot prove.
Do not start workflows or mutate runtime state as part of an upgrade. Links to
the default branch may explain later changes but are not authoritative for the
target release.
