Two people can change a Profile
A shared DSH Profile contains plugins and configuration that someone else can install. After installation, it becomes personal: the user may add dependencies, disable a bundle, reorder plugins, or change configuration. Meanwhile, the Profile author can publish a new release.
Replacing the local Profile with that release would discard the user’s edits. Keeping every local file untouched would miss the author’s updates. Jiahang’s Profile lifecycle contribution for 0.5.0 addresses this by keeping the author baseline separate from personal patches and explicit enable/remove choices.
An author updates a plugin. A user has disabled it locally. The upgrade needs to account for both changes.
Review against a specific state
The change adds staged edits and upgrades, conflict resolution tied to the current context, revision history, and recovery. A saved plan describes the proposed operation and records the local state it was based on. If that state changes before application, the plan needs to be refreshed.
There is a useful distinction in the CLI: direct mutation commands execute immediately unless the user requests --plan or --dry-run. Agent tools use the plan/apply flow. The interface should make that distinction visible rather than imply that every command is only a preview.
- Author baseline
- The starting point for comparing the installed release with an upstream update.
- Local intent
- Personal patches, extra dependencies, and explicit plugin choices that need to survive daily edits.
- Recovery
- A previous revision and its dependency receipts remain available if the new state needs to be rolled back.
Configuration is also a process boundary
Saved input values are kept separate from package preparation and nested host-tool processes. The selected Profile’s inputs are loaded again for validation and launch. This prevents a package-preparation step from receiving saved credentials simply because it belongs to the same workflow.
The merged change records tests for failed staging, rollback, dependency-lock reuse, and input boundaries. It also explicitly leaves native Windows and clean third-party acceptance to later validation. Those limits matter when reading the release: repository checks describe what was tested, not how the tool has performed for every user.
This is one contribution to the shared DSH Hub project. The merged change and its follow-up document provide the detailed scope.