Initial server source import
This commit is contained in:
sashatrask
@@ -0,0 +1,87 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Discovery preserves remote content recency
|
||||
The system SHALL preserve a normalized remote content-update timestamp for GitHub, GitLab, and HuggingFace discovery records and SHALL keep DockerHub digest-based identity behavior unchanged.
|
||||
|
||||
#### Scenario: Source-specific remote timestamp is retained
|
||||
- **WHEN** GitHub supplies `pushed_at`, GitLab supplies `last_activity_at`, or HuggingFace supplies `lastModified`
|
||||
- **THEN** the queue observation stores the valid UTC timestamp with the target identity
|
||||
|
||||
#### Scenario: Missing or malformed remote timestamp
|
||||
- **WHEN** a discovery result has no valid remote content-update timestamp
|
||||
- **THEN** the target remains eligible for normal new-target admission but MUST NOT trigger an updated-target rescan
|
||||
|
||||
#### Scenario: DockerHub discovery
|
||||
- **WHEN** DockerHub resolves an image tag
|
||||
- **THEN** the existing digest identity and refresh behavior remain authoritative without updated-target promotion
|
||||
|
||||
### Requirement: Only changed completed targets are promoted
|
||||
The system SHALL promote a known target only when it is completed, its observed remote timestamp is strictly newer than the remote timestamp covered by its latest scan, and its configured cooldown has elapsed.
|
||||
|
||||
#### Scenario: Completed target changed after its covered revision
|
||||
- **WHEN** discovery observes a newer valid remote timestamp for a completed target after cooldown
|
||||
- **THEN** the target becomes pending for one normal fenced scan
|
||||
|
||||
#### Scenario: Unchanged target is rediscovered
|
||||
- **WHEN** discovery observes the same or an older remote timestamp
|
||||
- **THEN** the completed target remains unchanged and unclaimable
|
||||
|
||||
#### Scenario: Legacy completed target is first observed
|
||||
- **WHEN** a completed target has no claimed remote timestamp
|
||||
- **THEN** it is promoted only if the observed remote timestamp is strictly newer than its last completion time
|
||||
|
||||
#### Scenario: Non-completed target is rediscovered
|
||||
- **WHEN** the target is failed, pending, deferred, in progress, unresolved, leased, claimed, or reserved
|
||||
- **THEN** updated-target discovery MUST NOT alter its lifecycle or authority fields
|
||||
|
||||
#### Scenario: Update arrives during a scan
|
||||
- **WHEN** discovery records a newer remote timestamp after the active claim captured its scan timestamp
|
||||
- **THEN** completion preserves the newer observation and permits one bounded follow-up scan after cooldown
|
||||
|
||||
### Requirement: Updated-target admission is bounded
|
||||
The system SHALL enforce a source-configured hard maximum of updated-target promotions per discovery cycle and a per-target cooldown.
|
||||
|
||||
#### Scenario: Eligible changes exceed the cycle budget
|
||||
- **WHEN** more completed changed targets are eligible than the configured maximum
|
||||
- **THEN** at most the configured maximum are promoted and the remainder stay eligible for later cycles
|
||||
|
||||
#### Scenario: Cooldown has not elapsed
|
||||
- **WHEN** a changed completed target was scanned within the configured cooldown
|
||||
- **THEN** it remains completed until a later eligible cycle
|
||||
|
||||
#### Scenario: Concurrent discovery cycles
|
||||
- **WHEN** multiple workers observe the same changed target concurrently
|
||||
- **THEN** transactional row fencing permits at most one promotion for the covered revision
|
||||
|
||||
### Requirement: Updated discovery remains capable of seeing changed known targets
|
||||
The system SHALL NOT use identity-only known-page stopping for a source while updated-target rescans are enabled and SHALL keep discovery bounded by explicit page and result limits.
|
||||
|
||||
#### Scenario: Known identities appear on an early page
|
||||
- **WHEN** an early discovery page contains only known target identities
|
||||
- **THEN** discovery continues within its configured hard page limit so later changed targets can be observed
|
||||
|
||||
#### Scenario: HuggingFace Space was created long ago and recently updated
|
||||
- **WHEN** a known Space has a recent `lastModified` value
|
||||
- **THEN** update-sorted HuggingFace discovery can observe it independently of creation time
|
||||
|
||||
### Requirement: Claims record the covered remote revision
|
||||
The system SHALL atomically snapshot the newest observed remote timestamp when a target is claimed.
|
||||
|
||||
#### Scenario: Revision-aware target is claimed
|
||||
- **WHEN** a pending target receives a valid lease and reservation
|
||||
- **THEN** its scan-covered timestamp equals the newest remote timestamp observed before that claim
|
||||
|
||||
#### Scenario: Claim fails before authority is committed
|
||||
- **WHEN** capacity or fencing prevents the claim
|
||||
- **THEN** the scan-covered timestamp MUST NOT advance
|
||||
|
||||
### Requirement: Updated-target activity is separately observable
|
||||
The system SHALL report updated-target promotions separately from newly discovered target admissions in durable cycle metrics, source logs, and dashboard summaries.
|
||||
|
||||
#### Scenario: Cycle admits new and updated targets
|
||||
- **WHEN** a discovery cycle inserts new identities and promotes changed completed identities
|
||||
- **THEN** `queued_new_count` and `queued_updated_count` record the respective counts without overlap
|
||||
|
||||
#### Scenario: No changed targets are promoted
|
||||
- **WHEN** a cycle observes only unchanged or ineligible known targets
|
||||
- **THEN** `queued_updated_count` is zero
|
||||
Reference in New Issue
Block a user