TOOLCHAIN_MANIFEST_BASENAMES deliberately excludes package.json and pyproject.toml, with the comment "whether one exists lives in file contents this scan does not read". That premise is no longer true: manifest texts are already fetched and parsed (embedded_linter_configs reads package.json and pyproject.toml contents).
Observed on express-rate-limit/express-rate-limit: one_command_bootstrap scores 0/18 although package.json declares a "test" script (run-s lint test:lib) — npm install && npm test is the canonical one-command loop for the ecosystem, exactly the situation the comment's serde/regex example describes for cargo.
Suggested: credit the weaker toolchain-manifest tier (12.6/18) when the already-fetched package.json declares a scripts.test (npm ignores its default placeholder "echo \"Error: no test specified\" && exit 1"), and analogously when pyproject.toml carries a recognized task/test runner section. No new API calls needed.
TOOLCHAIN_MANIFEST_BASENAMESdeliberately excludes package.json and pyproject.toml, with the comment "whether one exists lives in file contents this scan does not read". That premise is no longer true: manifest texts are already fetched and parsed (embedded_linter_configsreads package.json and pyproject.toml contents).Observed on express-rate-limit/express-rate-limit:
one_command_bootstrapscores 0/18 although package.json declares a"test"script (run-s lint test:lib) —npm install && npm testis the canonical one-command loop for the ecosystem, exactly the situation the comment's serde/regex example describes for cargo.Suggested: credit the weaker toolchain-manifest tier (12.6/18) when the already-fetched package.json declares a
scripts.test(npm ignores its default placeholder"echo \"Error: no test specified\" && exit 1"), and analogously when pyproject.toml carries a recognized task/test runner section. No new API calls needed.