sashatrask
49 lines
2.8 KiB
Markdown
49 lines
2.8 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: PostgreSQL Candidate And Current-State Authority
|
|
Normal provider workers SHALL claim one fenced PostgreSQL candidate at a time and SHALL transactionally insert the result, update `keycheck_current_state`, complete that candidate, and create a projection job.
|
|
|
|
#### Scenario: Compatibility files lag or fail
|
|
- **WHEN** keycheck JSONL or status projection is delayed or quarantined
|
|
- **THEN** the committed PostgreSQL result and current state SHALL remain authoritative and unrelated candidates SHALL continue
|
|
|
|
#### Scenario: Explicit compatibility input
|
|
- **WHEN** an operator selects `--input-mode jsonl`
|
|
- **THEN** the bounded legacy JSONL reader MAY be used, but `--input` SHALL be rejected in normal PostgreSQL mode
|
|
|
|
### Requirement: Provider Support Uses Detector And Keychecker Pair
|
|
New provider API key support SHALL include both detection and validation when a safe validation endpoint is available.
|
|
|
|
#### Scenario: Provider has safe validation endpoint
|
|
- **WHEN** support is added for a provider with a non-generating authentication or model-list endpoint
|
|
- **THEN** the change SHALL include a detector or detector routing rule and a keychecker for that provider
|
|
|
|
#### Scenario: Provider has no safe validation endpoint
|
|
- **WHEN** a provider does not have a safe validation endpoint
|
|
- **THEN** the detector MAY be added only with explicit documentation that validation is unavailable
|
|
|
|
### Requirement: Ambiguous Key Formats Use Context Routing
|
|
The scanner SHALL use nearby provider-specific context to route ambiguous key formats to the correct keychecker when possible.
|
|
|
|
#### Scenario: Qwen context around generic key
|
|
- **WHEN** an `sk-...` key is found near Qwen or DashScope context
|
|
- **THEN** the key SHALL be routed away from unrelated generic `sk-...` checkers such as DeepSeek when the context does not also identify that provider
|
|
|
|
#### Scenario: Weak context around generic key
|
|
- **WHEN** an ambiguous key has no strong provider-specific context
|
|
- **THEN** the scanner SHALL avoid speculative rerouting that would suppress the existing detector result
|
|
|
|
### Requirement: Keycheckers Avoid Token-Generating Probes By Default
|
|
Provider keycheckers SHALL prefer safe non-generating validation endpoints where available.
|
|
|
|
#### Scenario: Provider exposes model-list endpoint
|
|
- **WHEN** a provider exposes an authenticated model-list or account-status endpoint
|
|
- **THEN** the keychecker SHALL use that endpoint before considering any generation-style probe
|
|
|
|
### Requirement: Keycheck Results Remain Linkable To Findings
|
|
Provider keycheckers SHALL emit detector names and result metadata that can be linked back to scanner findings.
|
|
|
|
#### Scenario: Custom detector result is validated
|
|
- **WHEN** a keychecker validates a key from a custom detector finding
|
|
- **THEN** the result SHALL include a stable detector name and source metadata sufficient for DB link repair
|