Skip to content

Resolve and report the key of the configured judgment backend - #10

Merged
DevMortimer merged 2 commits into
mainfrom
fix/backend-aware-key-resolution
Sep 22, 2026
Merged

DevMortimer merged 2 commits into
mainfrom
fix/backend-aware-key-resolution

Conversation

@DevMortimer

Copy link
Copy Markdown
Owner

Closes #9. Consumer side is DevMortimer/pi-warden#57.

What was wrong

createTypeSafe({ backend }) knew which environment variable to read, but keySituation, resolveApiKey, authState, describeAuth, and ensureApiKey did not. With OPENROUTER_API_KEY set and no TypeSafe key, judgments ran while the status line said "TypeSafe key: missing", and ensureApiKey opened the TypeSafe login prompt and verified the pasted key against api.typesafe.ai.

createTypeSafe({ backend: "openrouter" }) also fell back to TYPESAFE_API_KEY and the login store when OPENROUTER_API_KEY was unset, so a TypeSafe key could be sent to OpenRouter.

Change

  • New src/backends.ts holds the registry, DEFAULT_BACKEND, and the rule that only the TypeSafe backend has a login store. client.ts re-exports the same names, so the public API is unchanged apart from the additions below.
  • keySituation(backend), resolveApiKey(backend), authState({ backend }), and ensureApiKey(ctx, { backend }) take the backend; it defaults to typesafe, so existing callers are unchanged. Other backends read only their own environment variable.
  • describeAuth labels the key by backend ("OpenRouter key: …") and names the variable to set. AuthState gains backend; an environment KeySituation gains keyEnv.
  • ensureApiKey for a backend without a login store returns the environment source or throws configuration naming the variable. It never opens the prompt.
  • createTypeSafe uses the same keySituation(backend) as the reporting functions, so the request and the status line agree.
  • DEFAULT_BACKEND is exported; every DECISIONS_BACKENDS entry carries a label.
  • README and docs/api.md document the backend option and which key each backend reads.

Accepted limitation

The verification and failure record (auth-state.json) is one file shared by every backend. After switching backends the last outcome stands until the next request. Documented in the API reference.

Verification

npm run check passes: build, typecheck, 96 offline tests (four new). Not run: npm run test:live; the transport and response validation are untouched.

Last commit is the version bump to 0.7.0, as requested by the maintainer.

keySituation, resolveApiKey, authState, and ensureApiKey take the backend
that createTypeSafe uses, read that backend's own environment variable,
and describeAuth labels the key by backend. A backend without a login
store never opens the TypeSafe prompt, which verified the pasted key
against api.typesafe.ai. createTypeSafe no longer sends a TypeSafe key to
another backend when that backend's variable is unset. The registry moves
to src/backends.ts so the key functions and the client share it.

Closes #9
@DevMortimer
DevMortimer merged commit 6fa2f2a into main Sep 22, 2026
8 checks passed
@DevMortimer
DevMortimer deleted the fix/backend-aware-key-resolution branch September 24, 2026 14:59
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.

Key resolution cannot express the configured judgment backend

1 participant