Skip to content

fix: report a reasoning_effort the adapter cannot carry - #12

Open
yoke-yoke wants to merge 1 commit into
bex-co:mainfrom
yoke-yoke:fix/report-unknown-reasoning-effort
Open

yoke-yoke wants to merge 1 commit into
bex-co:mainfrom
yoke-yoke:fix/report-unknown-reasoning-effort

Conversation

@yoke-yoke

Copy link
Copy Markdown

Closes #11.

What

readMuseSettings now logs when reasoning_effort holds a value outside
EFFORT_LEVELS, naming the supported values. The fallback itself is unchanged:
the session still runs at the default.

Why here rather than in defaultSessionConfig

readMuseSettings already 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 be
rethreaded.

One thing to call out

muse-settings.ts now imports from config-options.ts, which imports
MuseSettings back. That reverse edge is type-only and TypeScript elides it, so
the emitted dist/config-options.js keeps a single import and there is no runtime
cycle. If you would rather not carry the compile-time edge at all, say so and I
will move EFFORT_LEVELS and isReasoningEffort into a leaf module that both
files import.

Verified

  • the new test fails without the change, on the missing log line
  • npx vitest run src/tests/muse-settings.test.ts src/tests/config-options.test.ts: 14 passed
  • npm run build: clean
  • npm run check: clean

One caveat, stated plainly: npm run test:unit is unstable on my machine. Failures
are timing based (Matcher did not succeed in time, write EPIPE) and differ from
run 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.

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>
@yoke-yoke

Copy link
Copy Markdown
Author

One correction to the premise in this PR's commit message, now filed as #13: max is not a CLI-only level that the adapter has no wire type for. It is in the protocol as of @muse-code/sdk 1.3.0, published one day after 0.6.1; the adapter simply pins 0.1.1.

That does not change this patch. Whatever EFFORT_LEVELS ends up containing, a value outside it is still replaced by the default with nothing logged, and that is what this fixes. I will reword the commit message if you prefer it to match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

reasoning_effort from settings.json is silently replaced by high when the value is outside EFFORT_LEVELS

1 participant