Scope the registry to the target host's shell - #110
Merged
Conversation
A Windows host accepted `ls -la`: it resolved to the POSIX manifest, then failed at the OS. A Unix host accepted `Get-Service` the same way. Both burn exactly the turns this guard rail exists to save, and the fuzzy suggester compounded it by proposing commands from the wrong dialect. The shell field becomes three-way: shell: bash Unix only - ls, df, uname, systemctl shell: powershell Windows only - Get-Service, netstat, DSCheckLS.exe absent universal - docker, curl, python, aws, psql Absent means universal rather than POSIX. That is the load-bearing choice: a strict two-way filter would have broken docker, kubectl, aws, svn, curl, wget, python, node, and psql on Windows hosts, all of which run fine under PowerShell. Only a manifest naming a *different* shell is filtered, so marking is additive - an unmarked Unix-only manifest stays reachable everywhere until someone marks it, and nothing breaks meanwhile. Implemented as a registry filter at the entry point rather than by threading a shell parameter through validateSegment, validateSudo, validateXargs, validateSubcommand, lookupManifest, and closestCmdlet. lookupManifest and the suggester then only ever see in-dialect manifests, with no signature churn: ValidatePipeline is unchanged, and Core.Validate keeps its type so the eight test injection sites still compile. Marks 47 manifests, including the systemctl_* subcommand manifests - found by testing, since `systemctl status` resolves to systemctl_status and marking only the parent left it reachable on Windows. An unknown shell filters nothing, so the standalone validate tool, which has no connection and therefore no dialect, is unaffected.
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.
Why
A Windows host accepted
ls -la— it resolved to the POSIX manifest, then failed at theOS. A Unix host accepted
Get-Servicethe same way. Both burn exactly the turns thisguard rail exists to save, and the fuzzy suggester compounded it by proposing commands
from the wrong dialect.
The load-bearing decision
The obvious fix — filter POSIX manifests on Windows and vice versa — is wrong. It
would break
docker,kubectl,aws,svn,curl,wget,python,node, andpsqlon Windows hosts, all of which run fine under PowerShell. The registry is 181 POSIXto 104 PowerShell, and the POSIX set is a mix of Unix-only and cross-platform.
So the
shellfield becomes three-way:shell: bashls,df,uname,systemctlshell: powershellGet-Service,netstat,DSCheckLS.exedocker,curl,python,aws,psqlAbsent means universal, not POSIX. Only a manifest naming a different shell is filtered,
so marking is additive: an unmarked Unix-only manifest stays reachable everywhere until
someone marks it, and nothing breaks in the meantime.
Implementation
A registry filter at the entry point (
ScopeRegistry), not a shell parameter threadedthrough
validateSegment,validateSudo,validateXargs,validateSubcommand,lookupManifest, andclosestCmdlet. Lookup and the suggester then only ever seein-dialect manifests.
No signature churn:
ValidatePipelineis unchanged, andCore.Validatekeeps its type sothe eight test injection sites still compile.
Executealready computed the shell threelines above the validate call to pick the parser — it simply wasn't passing it.
Marks 47 manifests, including the
systemctl_*subcommand manifests. That one wasfound by testing, not reasoning:
systemctl statusresolves tosystemctl_status, somarking only the parent left it reachable on Windows.
An unknown shell filters nothing, so the standalone
validatetool — which has noconnection and therefore no dialect — is unaffected.
Testing
TestScopeRegistryByShellasserts all three categories in both directions (12 commands ×2 shells).
TestScopeRegistryUnknownShellIsPermissivepins the no-connection case.3DX session replay still runs 16/17 under PowerShell scoping — no regression.
Full suite passes including
-race;go vetclean.Known limit
Marking is incomplete by design. 47 of ~181 POSIX manifests are marked — the ones that
cause false-accepts today. The rest stay universal and therefore still reachable on
Windows. That is safe (nothing breaks) but not finished; the remainder can be marked as
they surface.
No real Windows host available, so this is verified against the recorded transcript and
unit tests only.
🤖 Generated with Claude Code