Repository navigation
Fix the single-dash -force flag the README documents - #12
Merged
Merged
Conversation
The README's agent prompt says "I may run `autor3search-javascript stop -force` myself". That failed with "Unknown option '-f'". parseArgs takes a single dash only for a single-character name, so the harness rewrites the documented spellings first — but the rewrite was driven by a list of names written out by hand next to the declaration, and that list had drifted: `stop` passed ['tag'] and never mentioned force. `baseline -force` was broken the same way, and nothing had noticed either. Passing the parseArgs options themselves removes the gap a hand-kept list leaves open. A flag can no longer be documented, declared, and still unparseable, because the thing that expands it and the thing that parses it are now one object. Consuming the following token is decided by the declared type rather than assumed. Booleans take no value, so the token after one is another flag and must still be expanded: adding 'force' to the old list would have made `stop -force -tag t` fail on "Unknown option '-t'" instead, trading the bug for a quieter one. Single-character names are left alone, since parseArgs already accepts `-C`. Worth knowing: -force was inert in an agent's hands before this, because it simply errored. It works now, so program.md's standing rule against passing it is load-bearing where it previously guarded nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FV5Usy3xLiz4ngEp6zPC5L
`stop -force`, which the README's agent prompt tells you to run, failed with "Unknown option '-f'" in 0.2.2 and every release before it. So did `baseline -force`. Both parse now, and the single-dash spellings are derived from the option declarations rather than a list kept by hand beside them, so a documented flag cannot go unparseable again without a test noticing. No behaviour changes anywhere else. Windows support and the marker-based stop path shipped in 0.2.2 are untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FV5Usy3xLiz4ngEp6zPC5L
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.
README.md's agent prompt says "I may runautor3search-javascript stop -forcemyself". It failed withUnknown option '-f'— in 0.2.2 and every release before it.baseline -forcewas broken the same way, and nothing had noticed either.Root cause
Node's
parseArgsaccepts a single dash only for a single-character name, so this harness rewrites the documented spellings before parsing. That rewrite was driven by a list of names written out by hand beside the declaration, and the list had drifted:cmd-stop.jspassed['tag']and never mentionedforce.Why the obvious fix is wrong
Adding
'force'to the list trades the bug for a quieter one.expandSingleDashFlagssetexpectingValue = trueafter every match, because it was built for value-taking flags:So
stop -force -tag twould have died onUnknown option '-t'.The fix
Derive the expandable set from the
parseArgsoptions the command already declares, and consume a following token only whentype !== 'boolean'. The four call sites hoistoptionsto a const and pass it to both the expander and the parser, so the two can no longer disagree — a flag cannot be documented, declared, and still unparseable.Every single-dash spelling in
README.mdandtemplates/program.mdwas enumerated and checked to parse:stop -force,stop -tag,eval -desc,baseline -tag,status -tag, andbaseline -force -tag.Worth knowing
-forcewas inert in an agent's hands before this, because it simply errored. It works now, soprogram.md's standing rule against passing it is load-bearing where it previously guarded nothing.485/485 passing locally (480 + 5 new: two unit tests covering the boolean-ordering trap, two CLI tests covering the spelling a human types, one for
-tag/-forcein either order).🤖 Generated with Claude Code
https://claude.ai/code/session_01FV5Usy3xLiz4ngEp6zPC5L