74 lines
4.0 KiB
Markdown
74 lines
4.0 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: Source-specific OpenAI ecosystem queries
|
|
The system SHALL include the approved first-wave OpenAI ecosystem queries only in the source rotations whose search semantics match those queries.
|
|
|
|
#### Scenario: GitHub searches integration signatures
|
|
- **WHEN** GitHub reaches the first-wave positions in its normal rotation
|
|
- **THEN** it SHALL search `OPENAI_API_KEY`, `api.openai.com`, and `openai-agents`
|
|
|
|
#### Scenario: GitLab searches branded project metadata
|
|
- **WHEN** GitLab reaches the first-wave positions in its normal rotation
|
|
- **THEN** it SHALL search `openai-api`, `openai-agents`, and `librechat`
|
|
|
|
#### Scenario: DockerHub searches deployable ecosystems
|
|
- **WHEN** DockerHub reaches the first-wave positions in its normal rotation
|
|
- **THEN** it SHALL search `librechat`, `lobechat`, and `openai-proxy`
|
|
|
|
#### Scenario: Broad generic expansion is excluded
|
|
- **WHEN** the first-wave configuration is evaluated
|
|
- **THEN** it SHALL NOT add new broad variants of `gpt`, `llm`, `chatgpt`, `ai`, or `model`
|
|
|
|
### Requirement: Independent bounded query policies
|
|
Each first-wave query SHALL have an exact allowlisted override that bounds both discovery volume and scan claims without changing source defaults or other query policies.
|
|
|
|
#### Scenario: GitHub signature queries are bounded
|
|
- **WHEN** GitHub builds arguments for `OPENAI_API_KEY` or `api.openai.com`
|
|
- **THEN** it SHALL use one page of 25 results and claim at most five targets
|
|
|
|
#### Scenario: GitHub agent query is bounded
|
|
- **WHEN** GitHub builds arguments for `openai-agents`
|
|
- **THEN** it SHALL use one page of 50 results and claim at most five targets
|
|
|
|
#### Scenario: GitLab queries are bounded
|
|
- **WHEN** GitLab builds arguments for a first-wave query
|
|
- **THEN** it SHALL use one page, the configured 25- or 50-result page size, and claim at most five targets
|
|
|
|
#### Scenario: DockerHub queries are bounded
|
|
- **WHEN** DockerHub builds arguments for a first-wave query
|
|
- **THEN** it SHALL use at most two pages of ten repositories and claim at most ten targets
|
|
|
|
#### Scenario: Existing authority limits remain unchanged
|
|
- **WHEN** any first-wave query runs
|
|
- **THEN** global scan concurrency, revision-aware promotion limits, cooldowns, and Docker digest requirements SHALL remain authoritative
|
|
|
|
### Requirement: Natural rotation and failure behavior
|
|
The first-wave queries SHALL use the existing persisted source rotation without direct query-state modification.
|
|
|
|
#### Scenario: Successful query advances
|
|
- **WHEN** a first-wave discovery cycle completes successfully
|
|
- **THEN** the source SHALL advance through the existing persisted rotation semantics
|
|
|
|
#### Scenario: Failed query is retained
|
|
- **WHEN** first-wave discovery fails before successful completion
|
|
- **THEN** the source SHALL retain that query according to existing failure semantics
|
|
|
|
#### Scenario: Backlog work does not masquerade as discovery
|
|
- **WHEN** a source drains existing backlog while a first-wave query is current
|
|
- **THEN** canary attribution SHALL distinguish backlog-only cycles from the actual discovery cycle
|
|
|
|
### Requirement: Per-query end-to-end canary evidence
|
|
Operators SHALL evaluate each first-wave query through durable source, scan, candidate, provider-result, and projection evidence without exposing targets or credential values.
|
|
|
|
#### Scenario: Query cohort reaches terminal accounting
|
|
- **WHEN** a first-wave query admits new or updated targets
|
|
- **THEN** operators SHALL verify queue dispositions, scan completion, candidate completion, and projection drain for that exact query cohort
|
|
|
|
#### Scenario: Useful yield is measured separately
|
|
- **WHEN** a first-wave cohort creates OpenAI candidates
|
|
- **THEN** genuinely new credentials and their explicit API outcomes SHALL be reported separately from cached-known occurrences
|
|
|
|
#### Scenario: Retention decision uses measured value
|
|
- **WHEN** the bounded canary is complete
|
|
- **THEN** each query SHALL be retained, revised, or removed using its distinct credential yield, usable outcomes, and operational error cost rather than fetched count alone
|