Initial server source import

2026-09-30 20:30:56 +03:00
commit 170dd941b9
498 changed files with 261563 additions and 0 deletions
@@ -0,0 +1,52 @@
+## ADDED Requirements
+
+### Requirement: Ambiguous credentials use one sequential resolver
+The system SHALL represent one ambiguous credential occurrence as one leased resolver candidate and SHALL probe only the compatible provider set in deterministic order.
+
+#### Scenario: Weak generic-key context
+- **WHEN** a detector-qualified generic `sk-...` finding has no single strong provider attribution
+- **THEN** the system SHALL enqueue one resolver candidate rather than independently active candidates for every compatible provider
+
+#### Scenario: Strong provider attribution
+- **WHEN** a finding has one strong provider-specific format or context signal
+- **THEN** the system SHALL retain the direct provider route without invoking unrelated provider adapters
+
+### Requirement: Resolver outcomes control progression
+The resolver SHALL distinguish positive match, definitive provider mismatch, and retryable uncertainty.
+
+#### Scenario: Provider rejects credential
+- **WHEN** a provider definitively reports invalid authentication for an ambiguous credential
+- **THEN** the resolver SHALL record that attempt and continue to the next compatible provider
+
+#### Scenario: Provider response is inconclusive
+- **WHEN** a provider attempt fails because of a network error, server error, or otherwise inconclusive response
+- **THEN** the resolver SHALL NOT classify that attempt as a definitive provider mismatch
+
+#### Scenario: All providers reject credential
+- **WHEN** every compatible provider definitively rejects the credential
+- **THEN** the resolver SHALL record an exhausted unresolved result after the final attempt
+
+### Requirement: First positive match terminates resolution
+The resolver SHALL stop after the first response that proves the credential belongs to a provider.
+
+#### Scenario: Later provider recognizes credential
+- **WHEN** earlier providers reject a credential and a later provider positively recognizes it
+- **THEN** the resolver SHALL stop without calling subsequent providers and SHALL retain the ordered attempt evidence
+
+### Requirement: Matched result uses actual provider authority
+A positively resolved candidate SHALL be completed transactionally under the provider that recognized it.
+
+#### Scenario: Resolver candidate matches another service
+- **WHEN** a leased resolver candidate receives a positive ZAI result
+- **THEN** the same fenced transaction SHALL associate the candidate and current state with the canonical ZAI credential and project the result as service `zai`
+
+#### Scenario: Completion loses its lease fence
+- **WHEN** the candidate lease no longer matches during provider reassignment
+- **THEN** no result, current-state update, or partial service reassignment SHALL be committed
+
+### Requirement: Legacy ambiguous candidates remain recoverable
+Existing generic-provider candidates with persisted ambiguous routing evidence SHALL use the resolver when explicitly retried.
+
+#### Scenario: Retried legacy Qwen candidate
+- **WHEN** an old Qwen candidate carries an ambiguous generic-provider hint and is retried
+- **THEN** the Qwen worker SHALL delegate it to the shared resolver instead of leaving it unconsumed again
@@ -0,0 +1,49 @@
+## ADDED Requirements
+
+### Requirement: ZAI findings produce keycheck candidates
+The scanner SHALL create ZAI keycheck candidates for detector-qualified `zai-...`, compatible `sk-...`, and bounded dotted ZAI/Zhipu key forms.
+
+#### Scenario: Existing ZaiGLM detector finding
+- **WHEN** the `ZaiGLM` custom detector emits a bounded API credential
+- **THEN** candidate extraction SHALL preserve its finding attribution and route it to ZAI or the ambiguous resolver according to persisted provider evidence
+
+### Requirement: ZAI validation proves generation availability
+The ZAI checker SHALL authenticate with a model-list request and SHALL require a bounded one-token `glm-5.2` generation probe before classifying a credential as valid and alive.
+
+#### Scenario: Global ZAI credential
+- **WHEN** the global ZAI `/models` endpoint accepts the credential and the bounded generation probe succeeds
+- **THEN** the checker SHALL record a valid authenticated ZAI result with bounded model and probe metadata
+
+#### Scenario: China Zhipu credential
+- **WHEN** the global endpoint rejects a credential but the configured China endpoint accepts it and its bounded generation probe succeeds
+- **THEN** the checker SHALL record the credential as ZAI with the successful endpoint region
+
+#### Scenario: Model listing succeeds but generation is unavailable
+- **WHEN** `/models` authenticates the credential but the generation probe reports quota, balance, permission, transient, or inconclusive failure
+- **THEN** the checker SHALL preserve the authenticated ZAI match but SHALL NOT classify the credential as valid or write it to the alive set
+
+#### Scenario: Model listing omits GLM 5.2
+- **WHEN** `/models` authenticates the credential but does not advertise `glm-5.2`
+- **THEN** the checker SHALL still probe the fixed `glm-5.2` target and SHALL NOT substitute another model
+
+### Requirement: ZAI responses are classified by protocol evidence
+The checker SHALL classify HTTP status and documented ZAI business error codes without treating inconclusive failures as invalid credentials.
+
+#### Scenario: Authentication rejected
+- **WHEN** ZAI returns HTTP 401 or an authentication-failure business code
+- **THEN** the attempt SHALL be classified as a definitive provider mismatch or dead direct credential
+
+#### Scenario: Authenticated balance or plan restriction
+- **WHEN** ZAI returns a provider-specific balance, usage-plan, or permission response during model listing or the generation probe
+- **THEN** the attempt SHALL be marked as belonging to ZAI with the corresponding limited, no-balance, or restricted status
+
+#### Scenario: Network or server failure
+- **WHEN** the request fails in transit or ZAI returns a server error
+- **THEN** the checker SHALL classify the attempt as retryable rather than dead
+
+### Requirement: ZAI participates in normal runtime accounting
+The ZAI checker SHALL use the existing PostgreSQL lease, result, current-state, projection, and summary infrastructure.
+
+#### Scenario: Scheduled ZAI work exists
+- **WHEN** the unified keycheck scheduler detects claimable ZAI candidates
+- **THEN** it SHALL launch the ZAI checker with the same authority and bounded-slice controls used for other providers