sashatrask
4.0 KiB
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