fix(managed-skills): unsupported rows on every path; failed discovery is degraded - #1037
Merged
Merged
Conversation
…led discovery #1017 review minors, fail-first on the real service: - the first snapshot after startup must already name the unsupported provider, not only after a save; - a target conflict on enable must keep that row beside the conflict; - an installed skill whose provider target discovery fails must read degraded with the resolution error, not unsupported with stale rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… discovery is degraded From the #1017 internal review (ledger T10): - The informational unsupported:* rows were appended by two of the roughly fifteen paths that set target statuses. The startup audit, a target conflict, a disable and the custom/installed reconciles dropped them. They are now added when a snapshot is built, from this.targets, by one builder that replaces three near-identical ones. Health reads the stored statuses, which never contain these rows. - resolveTargetsSafely invalidated conventions and custom skills on a discovery failure, but not installed skills. Those kept stale rows, and installedHealth then read unsupported, because it checked the zero-targets case before the error. Installed skills now get the error row, and installedHealth orders error first, as the other two do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…bled skill From the #1037 review (CHANGES REQUESTED): - MEDIUM: the new provider-target-resolution error row counted as a delete blocker. It has no fingerprint and so could never be approved, and deleting a disabled installed skill then dead-ended with "External changes must be reviewed" until discovery recovered. It is no longer a blocker. The stillOwnedKeys journal check still refuses to forget a skill whose files are on disk. Fail-first test. - LOW: the custom-skills list shows the provider on an unsupported row, where it used to show a generic path. - LOW: three comments still described the removed append mechanism. - NIT: an installed skill's error row shows its message. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Owner
Author
|
Review (CHANGES REQUESTED) addressed in
Managed-skills and settings: 147/147, and tsc is clean. |
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.
Follow-up to #1017's internal review (ledger T10).
Why
unsupported:<provider>rows show in Settings instead of blocking. Those rows were appended by only two of the roughly fifteen code paths that set target statuses. The startup audit, a target conflict on enable, a disable, and the custom and installed reconciles all replaced the list without them. So Settings stopped naming the unsupported provider as soon as anything else happened.resolveTargetsSafelymarked conventions and custom skills with the resolution error, but not installed skills. They kept stale rows, andinstalledHealthchecked "zero targets → unsupported" before any error. The skill therefore said "no provider can take this" when the truth was "we could not look".Change
withUnsupportedRowsadds the rows when a snapshot is built, derived fromthis.targets, so every path agrees.installedHealthchecks error before "unsupported", ashealth()andcustomHealth()already do.Tests (the real service, fail-first)
AgentCodeConventionsService.system.test.ts:unsupported:grok;conflictrow.AgentCodeInstalledSkillsService.system.test.ts: after an install, a discovery failure, thenaudit(), the skill isdegradedwith theprovider-target-resolutionerror row.All three fail on main. The managed-skills system and unit suites pass (128), the settings renderer suites pass (18), and
npx tsc -bis clean.🤖 Generated with Claude Code