## ADDED Requirements

### Requirement: Reviewed rank-one breadth authority
The system SHALL support a code-pinned rank-one breadth profile of 61 ordered
queries, at most 39 owned repositories per query, one image per repository, and
exactly 2,000 unique physical repository selections and target slots. It SHALL
reject arbitrary limit combinations and SHALL preserve the existing depth
profile unchanged.

#### Scenario: Breadth profile is valid
- **WHEN** configuration supplies the exact reviewed breadth selector and limits
- **THEN** validation SHALL produce a distinct immutable authority hash with a physical target ceiling of 2,000

#### Scenario: Profile limits are mixed
- **WHEN** configuration combines a selector or limit from different reviewed profiles
- **THEN** startup SHALL fail before secrets, database mutation, network work, or workers initialize

#### Scenario: Prior authority is not released
- **WHEN** another Docker experiment is nonterminal, unreleased, or fenced
- **THEN** breadth cohort application and activation SHALL fail without changing either experiment

### Requirement: Exact balanced physical cohort
The system SHALL deterministically select exactly 2,000 previously unscanned
physical repository anchors from the existing complete frozen discovery pass,
excluding every repository in the depth cohort. Selection SHALL be independent
of prior finding or credential yield.

#### Scenario: Reviewed frozen pool is selected
- **WHEN** 52 keywords have sufficient eligible repositories and nine have none
- **THEN** each nonempty keyword SHALL own 38 unique repositories, the first 24 still-eligible keywords in pinned order SHALL own one additional repository, and empty keywords SHALL remain explicit zero rows

#### Scenario: Repository appears under several keywords
- **WHEN** the next candidate is already physically owned by an earlier round-robin selection
- **THEN** it SHALL consume neither another physical slot nor the selecting keyword's quota, and selection SHALL continue to that keyword's next eligible candidate

#### Scenario: Exact cohort cannot be formed
- **WHEN** deterministic eligible selection cannot reach exactly 2,000 unique repositories with the reviewed distribution
- **THEN** manifest generation or application SHALL fail closed and no partial experiment cohort SHALL activate

### Requirement: Released policy history eligibility
The system SHALL admit a previously held repository only when its complete
policy-event history consists exclusively of authority-valid cold/reactivate
pairs owned by completed and released Docker experiments.

#### Scenario: Prior hold was exactly released
- **WHEN** every prior cold event has one matching reverse event that restores its recorded state and matches experiment, config, policy, manifest, and audit evidence
- **THEN** the unfenced unscanned repository MAY participate in the new reviewed cohort or hold manifest

#### Scenario: Prior history is incomplete or unrelated
- **WHEN** any policy event is unreversed, malformed, belongs to an unreleased experiment, or represents an unrelated policy
- **THEN** the repository SHALL remain ineligible and its queue and event history SHALL remain unchanged

### Requirement: Rank-one-only execution
The system SHALL resolve at most the newest eligible immutable image for each
selected repository and SHALL create no image selection above rank one.

#### Scenario: Repository has an eligible newest image
- **WHEN** its dedicated resolver completes under a valid owner, generation, token, and experiment authority
- **THEN** exactly one rank-one selection MAY consume one physical experiment target slot

#### Scenario: Candidate image is unsafe
- **WHEN** the newest candidate is previously scanned, failed, quarantined, independently cold, fenced, or otherwise ineligible
- **THEN** existing deterministic safe replacement rules SHALL apply without reactivating historical work or selecting an older image rank for depth

#### Scenario: Breadth work is dispatched
- **WHEN** rank-one targets become available
- **THEN** they SHALL use one round-robin dispatch wave with existing reservation, capacity, retry, and terminal-binding guarantees

### Requirement: Reviewed handoff and reversible holds
The system SHALL activate the breadth experiment only through a stopped-runtime
reviewed handoff after the depth experiment completes and releases its owned
cold rows. Breadth-owned non-cohort holds SHALL remain exactly reversible.

#### Scenario: Canonical handoff succeeds
- **WHEN** runtime is stopped, the depth experiment is completed and fence-free, its exact release SHA is approved, and the breadth cohort and hold SHAs are approved
- **THEN** release and breadth activation SHALL commit through their existing experiment-row-first fenced protocols before runtime restarts

#### Scenario: Breadth release is reviewed
- **WHEN** the breadth experiment later completes and its exact reactivation manifest is approved
- **THEN** only unreversed breadth-owned cold events SHALL restore their recorded prior states

### Requirement: Secret-safe breadth reporting
The system SHALL report physical coverage, globally deduplicated credential and
currently-alive yield, per-keyword attribution, scan cost, and both yield
measures per scanner-hour without exposing secret or target material.

#### Scenario: Credential repeats across keywords
- **WHEN** one credential is found in a repository attributed to multiple frozen keyword observations
- **THEN** global totals SHALL count it once while each eligible keyword attribution MAY receive an explicit non-additive credit

#### Scenario: Report measures novelty
- **WHEN** findings repeat across target-scoped locations
- **THEN** the decision report SHALL distinguish finding locations from detector-secret identities and credential identities and SHALL use credentials and currently-alive credentials as primary outcomes

#### Scenario: Report reads sensitive evidence
- **WHEN** aggregate reporting accesses findings or keycheck rows
- **THEN** output SHALL omit raw credentials, repositories, image targets, URLs, hashes, excerpts, DSNs, and configuration identities