## ADDED Requirements

### Requirement: Cold queue rows are not claimable
The system SHALL represent policy-held target work with `target_queue.status='cold'`, and no scanner, legacy queue consumer, or Docker resolver SHALL claim a cold row.

#### Scenario: Scanner checks active backlog
- **WHEN** a queue row has status `cold`
- **THEN** the row SHALL be excluded from pending, due-deferred, retry, and periodic resolver admission

#### Scenario: Worker completes ordinary work
- **WHEN** a scan result is ingested
- **THEN** its queue disposition SHALL remain limited to ordinary lifecycle outcomes and SHALL NOT create a cold status

### Requirement: Policy holds are exact and audited
The system SHALL transition queue rows into or out of cold state only through a reviewed, hash-fenced, append-only policy event under stopped-source lifecycle authority.

#### Scenario: Eligible stale row is held
- **WHEN** an exact manifest entry still matches an unfenced `pending` or `deferred` row whose source query is absent from canonical policy
- **THEN** the system SHALL atomically record the audit event and change only the row status and update timestamp to `cold`

#### Scenario: Selected row has an active fence
- **WHEN** a selected row has a queue lease, resolver lease, current claim, active result reservation, or submitted content lease
- **THEN** the policy apply SHALL fail closed without partially applying the manifest

#### Scenario: Exact apply is repeated
- **WHEN** the same reviewed manifest is applied again after a successful transition
- **THEN** the system SHALL report an idempotent duplicate without creating a second state transition

### Requirement: Cold state is explicitly reversible
The system SHALL retain the exact prior queue status in policy audit history and SHALL require a reviewed reactivation manifest to restore a cold row.

#### Scenario: Cold row is rediscovered normally
- **WHEN** enqueue, synchronization, rediscovery, retry, or completion logic encounters an existing cold row
- **THEN** the row SHALL remain cold and its historical attribution SHALL remain unchanged

#### Scenario: Reviewed cold event is reactivated
- **WHEN** an exact reactivation manifest references an unreversed cold event and all row fences still match
- **THEN** the system SHALL restore the audited prior `pending` or `deferred` status and append a linked reactivation event

### Requirement: Stale-query selection follows canonical policy
The system SHALL evaluate query staleness using case-sensitive exact source, platform, and query policy derived from canonical configuration.

#### Scenario: Configured query remains active
- **WHEN** a queue row's exact source/platform/query triple remains configured
- **THEN** automatic stale-policy planning SHALL NOT select the row

#### Scenario: Attribution cannot be classified safely
- **WHEN** query attribution is null, blank, operational, non-rotation, or belongs to an unknown source/platform pair
- **THEN** automatic planning SHALL skip and report the row rather than inferring retirement

#### Scenario: Initial Docker stale cohort is planned
- **WHEN** DockerHub policy planning is scoped to platform `docker`
- **THEN** it SHALL include eligible pending/deferred resolver anchors and digest rows attributed to removed exact queries and SHALL expose only aggregate counts plus non-sensitive manifest fields

### Requirement: Docker resolvers honor current query policy
The system SHALL prevent completed or retryable Docker resolver anchors attributed to retired non-null queries from generating new digest queue rows.

#### Scenario: Periodic stale anchor becomes due
- **WHEN** a completed Docker resolver anchor is due but its exact query is not in the configured DockerHub allowlist
- **THEN** resolver admission SHALL leave the anchor unclaimed

#### Scenario: Configured anchor becomes due
- **WHEN** a Docker resolver anchor's exact query remains configured and all ordinary claim fences pass
- **THEN** resolver admission SHALL preserve the existing retry and periodic behavior

### Requirement: Source pause preserves backlog authority
Pausing a source SHALL remove its worker from the active core without deleting or rewriting that source's queue or historical records.

#### Scenario: GitHub Actions is paused
- **WHEN** canonical runtime configuration is loaded after this change
- **THEN** GitHub Actions SHALL be absent from the supervisor core and disabled at both supervisor-source and source configuration layers while its configured query and persisted backlog remain intact

### Requirement: Cold work is separately observable
Operational queue summaries SHALL report cold rows separately and SHALL NOT include them in active pending or deferred backlog counts.

#### Scenario: Queue state is summarized
- **WHEN** an operator inspects canonical target queue status
- **THEN** the summary SHALL expose a distinct cold count without representing those rows as retryable or claimable work