Register certified Harnesses through adapter declarations - #286
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
1 participant
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.
The daemon registered three adapters that Core cannot schedule, while certified Harness discovery, capabilities and factory wiring were spread across named CLI branches. Delete the unused adapters, retain their shared skill-installation helpers in a neutral package, and have each certified Harness publish one Runtime–Harness declaration. CLI discovery and registration now iterate one static list; onboarding documents that boundary.
Certified capability descriptors, version gates, workspace rules, factory wrappers and native usage identifiers remain unchanged. Shared archive validation, extraction locking and pruning tests move with the retained helpers. Two independent reviews completed; the first identified a native usage identifier change, which was restored and regression-tested, and the fresh second review found no blocking issues.
Validation: daemon/shared Go suites, full Go build, focused daemon/gateway/API vet, name guard and 14 guard tests, Core API database suite and both changed store tests with the pinned official SDK. Actual pinned Codex/mcode discovery passed. The existing registered Claude SDK test passed against a real MiniMax model, including tool receipts, cancellation and cold continuation. Relevant tests were rerun after integration with current main. Store-wide vet still reports two unchanged mutex-copy warnings in existing environment fixture tests; the broad store run has no captured completion result, so only the explicit focused store PASS results are claimed. No full
make checkwas run under the requested focused workflow.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.