Repository navigation
refactor(host): converge DSH integration through adapter - #433
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was wrong
DSH product-facing types and lazy scope/profile-host lookups were imported from many OPS modules directly. The plugin avoided load-time value imports, but it did not have one auditable project-owned adapter boundary. Its compatibility declaration also stopped at
0.2.1-rc.2, despite the published0.2.1-rc.3and0.2.1-rc.4host lines.The change
src/adapter/dshboundary for DSH type surfaces and runtime host loading.dsh-scopelazy and resolve it once at each existing asynchronous adapter seam; no DSH value package is evaluated during plugin module loading.dsh-ops/adapter/dshfor the package's host integration boundary.>=0.2.0-rc.2 <0.2.2-0, covering0.2.0-rc.2,0.2.1-rc.2,0.2.1-rc.3,0.2.1-rc.4and0.2.1, while rejecting0.2.0-rc.1,0.2.2-rc.1and0.3.0.No
@dsh-stdprotocol support is claimed: the current standard documents provide generic adapter/lifecycle concepts but no normative DSH tool, sandbox, subprocess, PTC or permission protocol for OPS to implement. The product adapter remains project-owned as required bydsh-std.Validation
The 4 skips are the existing TUI host/native environment skips. The local full run used the staged Windows worker and Bash IPC payload. An isolated DSH
0.2.1-rc.4host installation was created through the Clash proxy; the real host metadata/composition suite passed 4/4 against itsdsh-app-bootcompatibility evaluator. rc4 was published less than seven days ago, so no new rc4 dependency was added to this repository; the fixture is outside the repository and is only validation evidence.Environment
Windows x64, Node 24, Rust 1.97.1, exact source branch from
origin/maincommita6e215a; no Desktop profile changes, npm publication, merge or release performed.