npx metaharness <first-arg> uses the same positional slot for two unrelated things: a reserved subcommand (score, analyze, genome, learn, --wizard, --list, --from-existing, …) and the name of a new harness to scaffold. When <first-arg> doesn't match a known subcommand, it is silently treated as a harness name and scaffolded — there is no "unrecognized command" error path.
Repro:
$ npx metaharness analyze-repo .
# intent: run the analyzer (`metaharness analyze <repo>`)
# actual: scaffolds a new harness project named "analyze-repo" in ./analyze-repo,
# with "." silently ignored/unused, no warning that "analyze-repo" isn't a command
Confirmed live against the published package.
Why this is bad CLI design: a typo in a subcommand name (analyze-repo vs. the real analyze) produces no error — it produces a different, silent, side-effecting action (writing files to disk) with zero feedback that the intended command was never invoked. A user has to notice an unexpected directory appeared to realize their command didn't run.
Suggested fix: stop overloading the position. Add an explicit init <name> (or new <name>) subcommand for scaffolding, so "scaffold a harness" always requires an explicit verb — never a bare name in argv[0]. Then, if argv[0] doesn't match any recognized subcommand (init/new, score, analyze, genome, learn, mint, etc.), exit with a nonzero code and an "unknown command '', did you mean...?" error instead of falling through to the scaffold path.
npx metaharness <first-arg>uses the same positional slot for two unrelated things: a reserved subcommand (score,analyze,genome,learn,--wizard,--list,--from-existing, …) and the name of a new harness to scaffold. When<first-arg>doesn't match a known subcommand, it is silently treated as a harness name and scaffolded — there is no "unrecognized command" error path.Repro:
Confirmed live against the published package.
Why this is bad CLI design: a typo in a subcommand name (
analyze-repovs. the realanalyze) produces no error — it produces a different, silent, side-effecting action (writing files to disk) with zero feedback that the intended command was never invoked. A user has to notice an unexpected directory appeared to realize their command didn't run.Suggested fix: stop overloading the position. Add an explicit
init <name>(ornew <name>) subcommand for scaffolding, so "scaffold a harness" always requires an explicit verb — never a bare name in argv[0]. Then, ifargv[0]doesn't match any recognized subcommand (init/new,score,analyze,genome,learn,mint, etc.), exit with a nonzero code and an "unknown command '', did you mean...?" error instead of falling through to the scaffold path.