Files
truf-server/openspec/changes/resolve-ambiguous-key-providers/proposal.md
T
2026-09-30 20:30:56 +03:00

28 lines
1.9 KiB
Markdown

## Why
Generic `sk-...` credentials can match several supported providers, while the current exact-hint routing leaves ambiguous findings unconsumed and can eventually quarantine them without testing a compatible provider. The keycheck pipeline needs ordered provider resolution and ZAI coverage so a credential is attributed to the first provider that positively recognizes it.
## What Changes
- Add durable, sequential resolution for credentials whose format or finding context permits multiple providers.
- Distinguish provider mismatch from authenticated match and retryable probe failure.
- Stop remaining provider attempts after the first positive match while retaining auditable attempt outcomes.
- Add a ZAI provider checker with a minimal generation/billing probe and include ZAI in compatible generic-key routing.
- Keep explicit single-provider findings on their existing direct validation path.
## Capabilities
### New Capabilities
- `ambiguous-provider-resolution`: Ordered, durable validation of one ambiguous credential across compatible providers until one positively matches or all definitive routes are exhausted.
- `zai-key-validation`: Extraction, probing, classification, persistence, and runtime registration for ZAI API credentials.
### Modified Capabilities
None.
## Impact
- Affects scanner provider hints, keycheck candidate extraction, PostgreSQL queue/schema operations, provider checker orchestration, status projection, runtime configuration, and lifecycle authority manifests.
- Adds a ZAI checker module using the existing HTTP and PostgreSQL keycheck infrastructure; model-list authentication alone does not qualify a key as alive.
- Requires regression coverage for route ordering, retry behavior, atomic match resolution, candidate deduplication, and ZAI response classification; the existing free-form service and credential tables require no schema migration.