## ADDED Requirements

### Requirement: Single-page operator view
The dashboard SHALL present finding lookup, reporting metrics, source results, alive credential results, and current runtime health on one page without legacy page navigation.

#### Scenario: Operator opens the dashboard
- **WHEN** the supervisor-launched dashboard session connects
- **THEN** one page presents the primary lookup and observability sections in operational priority order

#### Scenario: Retired diagnostics remain hidden
- **WHEN** the page renders successfully
- **THEN** it does not present compatibility queue files, global runner state, TSV-gated summaries, raw logs, or advanced/debug navigation

### Requirement: Accurate reporting window
The dashboard SHALL apply the selected start and end timestamps in PostgreSQL before aggregating or limiting historical rows.

#### Scenario: Preset period is selected
- **WHEN** the operator selects 1 hour, 24 hours, 7 days, or 30 days
- **THEN** all historical KPI and breakdown queries use that exact UTC interval

#### Scenario: Custom period is selected
- **WHEN** the operator supplies a valid custom start and end
- **THEN** the page reports data only from the normalized custom interval

#### Scenario: Invalid custom period is supplied
- **WHEN** the end is not later than the start
- **THEN** the dashboard explains the error and does not run historical aggregation queries

### Requirement: PostgreSQL-authoritative summary
The dashboard SHALL derive scanner, finding, queue, candidate, and validation statistics from PostgreSQL and SHALL label current runtime values separately from period values.

#### Scenario: Period contains activity
- **WHEN** scans and keychecks exist in the selected interval
- **THEN** the page shows scanned targets, findings, errors, newly alive credentials, current alive credentials, and grouped source/provider results

#### Scenario: No period activity exists
- **WHEN** no matching historical rows exist
- **THEN** the page renders zero-valued KPIs and clear empty states without falling back to compatibility files

### Requirement: Safe unified finding lookup
The dashboard SHALL locate current validation state and finding origins using a pasted credential, SHA-256 identity, finding ID/UID, masked value, target, path, commit, or other redacted metadata without selecting raw database payload columns.

#### Scenario: Raw credential-like value is pasted
- **WHEN** the operator submits a credential-like value
- **THEN** the dashboard hashes it in memory and sends only its SHA-256 identity to PostgreSQL

#### Scenario: Exact identity is pasted
- **WHEN** the operator submits a finding ID, finding UID, fingerprint, or SHA-256 identity
- **THEN** indexed exact predicates locate matching current status and bounded origins independently of reporting filters

#### Scenario: Non-secret metadata is pasted
- **WHEN** the operator submits a sufficiently specific target, path, commit, detector, source, or query fragment
- **THEN** escaped metadata predicates return bounded redacted matches

#### Scenario: Match has validation state
- **WHEN** a finding or credential is linked to current keycheck state
- **THEN** the result includes service, provider status, status group, checked time, source, query, target, and available location metadata

### Requirement: Read-only safety boundaries
The simplified dashboard SHALL remain supervisor-authorized, loopback-only, read-only, redacted, and bounded.

#### Scenario: Dashboard issues database queries
- **WHEN** any page section loads or a lookup is submitted
- **THEN** no mutation statement or forbidden raw payload column is requested

#### Scenario: PostgreSQL query fails
- **WHEN** a query times out or the connection enters an error transaction
- **THEN** the dashboard rolls back and renders a bounded degraded message instead of failing the process

#### Scenario: Dashboard is launched without authority
- **WHEN** the process lacks canonical supervisor and loopback launch markers
- **THEN** startup is refused before argument parsing or database access