Repository navigation
Resolve and report the key of the configured judgment backend - #10
Merged
Merged
Conversation
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
This was referenced Sep 22, 2026
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 #9. Consumer side is DevMortimer/pi-warden#57.
What was wrong
createTypeSafe({ backend })knew which environment variable to read, butkeySituation,resolveApiKey,authState,describeAuth, andensureApiKeydid not. WithOPENROUTER_API_KEYset and no TypeSafe key, judgments ran while the status line said "TypeSafe key: missing", andensureApiKeyopened the TypeSafe login prompt and verified the pasted key against api.typesafe.ai.createTypeSafe({ backend: "openrouter" })also fell back toTYPESAFE_API_KEYand the login store whenOPENROUTER_API_KEYwas unset, so a TypeSafe key could be sent to OpenRouter.Change
src/backends.tsholds the registry,DEFAULT_BACKEND, and the rule that only the TypeSafe backend has a login store.client.tsre-exports the same names, so the public API is unchanged apart from the additions below.keySituation(backend),resolveApiKey(backend),authState({ backend }), andensureApiKey(ctx, { backend })take the backend; it defaults totypesafe, so existing callers are unchanged. Other backends read only their own environment variable.describeAuthlabels the key by backend ("OpenRouter key: …") and names the variable to set.AuthStategainsbackend; an environmentKeySituationgainskeyEnv.ensureApiKeyfor a backend without a login store returns the environment source or throwsconfigurationnaming the variable. It never opens the prompt.createTypeSafeuses the samekeySituation(backend)as the reporting functions, so the request and the status line agree.DEFAULT_BACKENDis exported; everyDECISIONS_BACKENDSentry carries alabel.docs/api.mddocument thebackendoption 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 checkpasses: 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.