Set bundled OpenRouter smoke-test defaults

This commit is contained in:
2026-11-03 14:40:58 +00:00
parent 75204d6134
commit e0cd63923d

View File

@@ -2,7 +2,7 @@
## Status And Purpose
Proposed; no implementation changes yet.
Design decisions settled; implementation has not started.
Ship a small OpenRouter configuration bundle with PromptKit so consumers
can begin using named profiles without installing a separate catalog. Include
@@ -78,9 +78,36 @@ Include the root `openrouter` backend with OpenRouter's API base endpoint,
bundle. Reuse the existing OpenAI-compatible client and credential resolution.
Keep the backend minimal. Leave concurrency limits, queue policy, and provider
request parameters to existing defaults or application configuration. Smoke-test
metadata is a separate decision below; bundling does not automatically run
diagnostics or select an inference smoke-test profile.
request parameters to existing defaults or application configuration.
### Smoke-Test Defaults
Include the following metadata on the root `openrouter` backend:
```yaml
smoke_tests:
default_profile: gpt-luna-latest
authentication:
kind: openrouter_key
```
Omit the reachability endpoint to use the existing backend-endpoint fallback.
Omit the authentication endpoint to use the adapter's backend-relative `/key`
destination. OpenRouter documents the authenticated
[current-key endpoint](https://openrouter.ai/docs/api/api-reference/api-keys/get-current-api-key).
Use `gpt-luna-latest` as the inference diagnostic default when the caller supplies
neither a prompt nor a profile. Explicit prompt/profile selection continues to
follow existing smoke-test selection rules. The default names the effective
root profile, so an application replacement of that profile also affects this
fallback. Applications can change the backend metadata through ordinary
configuration composition.
These defaults make explicit diagnostics usable without additional setup; they
do not run tests automatically or establish a default for ordinary prompt
execution. Results describe the selected diagnostic path, not backend-wide
readiness. The inference smoke test makes a small request with potentially
non-zero cost; no fixed cost or model-availability guarantee is introduced.
### Small Profile Set
@@ -146,8 +173,8 @@ does not identify or pin the concrete model selected upstream.
## Implementation Work
1. Resolve the diagnostic-metadata decision below. Verify the provider endpoint
and exact model values for the twelve selected root profiles.
1. Verify the provider endpoint and exact model values for the twelve selected
root profiles.
2. Add the embedded YAML backend and profiles, and integrate their dedicated
underlay with engine construction. Add the disable option using the existing
facade option pattern. Apply the ordinary load/normalize/validate lifecycle.
@@ -159,42 +186,15 @@ does not identify or pin the concrete model selected upstream.
source evidence. Exercise request preparation with a fake client or local
server as appropriate; construction must not depend on provider reachability
or a live API key. Reuse existing credential tests and add coverage only for
new integration behavior.
new integration behavior. Cover default reachability, the authentication
adapter, inference fallback to `gpt-luna-latest`, explicit prompt/profile
selection, and application replacement of the fallback profile or metadata.
5. Update the format reference, consumer guide, relevant GoDoc, and maintained
examples when implementation lands. Explain how to disable, replace, or derive
from bundled profiles, and distinguish routers/latest aliases from fixed
models. Include the inventory/inspection change in release notes.
Keep current-state documentation unchanged until implementation lands. Retire
this roadmap after the behavior and remaining decisions reach their durable
owners. No new configuration syntax or collection specification version is
needed solely to distribute this data.
## Open Decisions
### Smoke-Test Metadata In The Bundled Backend
**Recommendation:** Include `smoke_tests.authentication.kind: openrouter_key`
using the existing adapter's backend-relative `/key` endpoint. Leave a separate
reachability endpoint and inference `default_profile` unspecified. The adapter
already exists, so this is a small configuration addition that makes explicit
API-key diagnostics useful out of the box without choosing an inference model.
OpenRouter documents the authenticated
[current-key endpoint](https://openrouter.ai/docs/api/api-reference/api-keys/get-current-api-key).
Its acceptance of a key is evidence about that endpoint, not a guarantee that
an arbitrary inference request will succeed.
This revises the initial recommendation to omit diagnostic metadata: given the
existing adapter and the bundle's convenience purpose, the added utility seems
worth maintaining the small declaration. The decision remains open pending
maintainer agreement.
**Alternative:** Include only the backend endpoint and credential-variable name.
This keeps the shipped configuration smaller and leaves diagnostic declarations
entirely with the consumer, but applications wanting authentication diagnostics
must configure the existing adapter themselves. Ordinary inference is unaffected.
Either approach uses existing diagnostic APIs and execution rules. Neither
implies automatic diagnostics during construction or execution. Selecting a
built-in inference smoke-test default would be a separate choice; this proposal
leaves callers able to select a profile explicitly without prescribing one.
this roadmap after the implemented behavior reaches its durable owners. No new
configuration syntax or collection specification version is needed solely to
distribute this data.