Conversation
An unknown `reasoning_effort` in settings.json was replaced by the default with nothing logged, while `readMuseSettings` already reports its other two failure modes and the session config setter rejects the same value loudly. The muse CLI documents efforts this adapter has no wire type for (`max`), so a value copied from `muse exec --help` silently ran at `high`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Author
|
One correction to the premise in this PR's commit message, now filed as #13: That does not change this patch. Whatever |
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.
Closes #11.
What
readMuseSettingsnow logs whenreasoning_effortholds a value outsideEFFORT_LEVELS, naming the supported values. The fallback itself is unchanged:the session still runs at the default.
Why here rather than in
defaultSessionConfigreadMuseSettingsalready owns this job. It reports its two other failure modes,a missing file and a non-object document, and it is the only one of the two that
already receives a logger. Every call site is
defaultSessionConfig(readMuseSettings(env, this.logger)), so nothing has to berethreaded.
One thing to call out
muse-settings.tsnow imports fromconfig-options.ts, which importsMuseSettingsback. That reverse edge is type-only and TypeScript elides it, sothe emitted
dist/config-options.jskeeps a single import and there is no runtimecycle. If you would rather not carry the compile-time edge at all, say so and I
will move
EFFORT_LEVELSandisReasoningEffortinto a leaf module that bothfiles import.
Verified
npx vitest run src/tests/muse-settings.test.ts src/tests/config-options.test.ts: 14 passednpm run build: cleannpm run check: cleanOne caveat, stated plainly:
npm run test:unitis unstable on my machine. Failuresare timing based (
Matcher did not succeed in time,write EPIPE) and differ fromrun to run, between 1 and 10 files, never touching the two files this change
concerns. I could not get a stable full-suite baseline to compare against.