As an OpenCode user on any recent 1.18.x, I want SkillSpector to accept my CLI version so a patch release does not break my scans.
The gap
The provider exact-pins one version, so every upstream patch release locks out users until a new pin PR lands. The runtime debug config resolved-subset check is the load-bearing safety net and already re-verifies the deny-all policy per invocation; the version gate is belt-and-suspenders and can be a range without weakening fail-closed.
What I am asking for
Please consider accepting any 1.18.31 <= ver <= 1.18.34: keep rejecting prereleases and unparsable output, keep both gates (preflight + auth check) plus the debug config subset check. Done when users on any of the four versions get scans and anything outside the range still fails closed.
This could be achieved by
- Replacing the exact-pin string with inclusive MIN/MAX triplets and one shared range predicate used by both gates, with error messages printing the range
- Adding boundary tests (accept .31-.34; reject .30, .35, prerelease, garbage, empty) and proving the matrix live per version
- Widening MIN/MAX with appended matrix rows on future bumps, rather than overwriting the pin
As an OpenCode user on any recent 1.18.x, I want SkillSpector to accept my CLI version so a patch release does not break my scans.
The gap
The provider exact-pins one version, so every upstream patch release locks out users until a new pin PR lands. The runtime
debug configresolved-subset check is the load-bearing safety net and already re-verifies the deny-all policy per invocation; the version gate is belt-and-suspenders and can be a range without weakening fail-closed.What I am asking for
Please consider accepting any
1.18.31 <= ver <= 1.18.34: keep rejecting prereleases and unparsable output, keep both gates (preflight + auth check) plus thedebug configsubset check. Done when users on any of the four versions get scans and anything outside the range still fails closed.This could be achieved by