Update Versions

[github-actions]

Changepacks

devup-mcp@0.8.0 → 0.9.0 - crates/devup-mcp/Cargo.toml

Minor

• devup-mcp now carries the changepacks skill and reports the obligation a .changepacks directory creates. Agents routinely opened pull requests without a changepack log, and the cause was documentation rather than the agent: the invocation the project documents is the bare interactive command, which hangs or is cancelled in a non-TTY shell, so the step was skipped and the change reached the base branch with no version bump. The non-interactive form already existed and was undocumented, so docs: add SKILL.md so agents can create a changepack non-interactively changepacks/changepacks#131 added a consumer-facing SKILL.md leading with it, and this vendors that document as an embedded skill installable with no network. Detection is the other half: devup_skills now reports a repoObligations.changepacks block whenever the workspace has a .changepacks directory, carrying the exact non-interactive command, why the bare one hangs, the tracked-path patterns read out of config.json rather than assumed, the base branch and any pending logs. That reaches a caller who never asked about changepacks, which is precisely the caller who produces the pull request that lacks one. Two tests had hardcoded dev-five-git into the provenance assertion and failed on the first skill vendored from another organisation; they now derive the repository from the record.

Patch

• 0.8.0 shipped wrong build advice in two of the skills it installs, and this corrects both. The devup-ui and devfive-frontend documents told readers that @devup-ui/reset-css has to be declared to the build plugin or its classes are never emitted, with three settings to add: an include entry, an optimizeDeps.exclude entry and an ssr.noExternal entry. None of them are needed. The reset is a globalCss() call at the top level of that package's own module and resetCss() is an empty function that only keeps the import from being tree-shaken, so the single requirement is that the plugin transforms the package inside node_modules - and createNodeModulesExcludeRegex already allows @devup-ui and @devup-editor through that exclusion unconditionally, with include only appending to the list. ssr.noExternal is set from a /@devup-ui/ pattern for the same reason. devup-ui's own apps/landing imports resetCss in its root layout and passes DevupUI({ singleCss }) and nothing else, which is the empirical proof. The advice came from reading one downstream project that had added include and inferring it was required; a single observation of a redundant setting is not evidence that the setting is needed, and the plugin source was three files away. Because devup-mcp vendors these documents into the binary, the wrong recipe was what devup_skills install wrote on every machine with no network - the machines least able to check it against the plugin source. Both documents now say the package needs no configuration and say plainly not to add those entries, since writing them teaches the next reader that a devup-ui package needs wiring when none does.