Initial server source import

2026-09-30 20:30:56 +03:00
commit 170dd941b9
498 changed files with 261563 additions and 0 deletions
@@ -0,0 +1,71 @@
+## ADDED Requirements
+
+### Requirement: Separate assignment and scan outcomes
+The worker administration list SHALL display assignment transport outcome, scan outcome, and diagnostic count as separate fields and SHALL not label `last_error_code` as the complete scan error category.
+
+#### Scenario: Accepted scan has an error outcome
+- **WHEN** a reservation has a durable accepted bundle whose target scan status is `error`
+- **THEN** the list SHALL show assignment `accepted`, scan `error`, and the diagnostic count/categories
+
+#### Scenario: Assignment expires before scan ingestion
+- **WHEN** a reservation expires without an accepted bundle
+- **THEN** the list SHALL show assignment `expired`, scan outcome unavailable, and the expiry diagnostic
+
+### Requirement: Assignment detail timeline
+Each worker assignment row SHALL link to a detail page that reconstructs issued, phase-progress, bundle/terminal report, receipt, ingestion, queue settlement, and projection timestamps that exist for that assignment.
+
+#### Scenario: Administrator opens an active assignment
+- **WHEN** progress events exist for an unresolved assignment
+- **THEN** the page SHALL show current phase, phase age, last progress age, scan deadline, assignment deadline, and ordered prior phases
+
+#### Scenario: Administrator opens a settled assignment
+- **WHEN** the assignment has been accepted and projected
+- **THEN** the timeline SHALL distinguish acceptance, ingestion, queue settlement, and projection completion rather than collapsing them into one completion time
+
+### Requirement: Clickable diagnostic detail
+The assignment detail page SHALL list diagnostics and SHALL provide human summary, canonical envelope JSON, raw body view, process log view, transformation metadata, and copy/download actions for each diagnostic.
+
+#### Scenario: Diagnostic body is complete
+- **WHEN** an HTTP diagnostic contains an untruncated body
+- **THEN** the raw-body view SHALL identify it as complete and display the captured content and metadata
+
+#### Scenario: Diagnostic material is truncated
+- **WHEN** body or log material was size-truncated
+- **THEN** the view SHALL prominently display original/stored sizes, hash, and truncation state
+
+#### Scenario: Legacy scan error has no diagnostic envelope
+- **WHEN** an older scan has only existing `errors.raw_error` or result metadata
+- **THEN** the detail page SHALL display those fields as legacy evidence and SHALL not invent a new envelope
+
+### Requirement: Diagnostic filtering and grouping
+The admin UI SHALL filter independently by source, time, worker/device, assignment outcome, scan outcome, phase, category, stable code, and retryability and SHALL group repeated diagnostic fingerprints without hiding individual occurrences.
+
+#### Scenario: Administrator filters rate-limit errors
+- **WHEN** category `rate_limit` and a time window are selected
+- **THEN** results SHALL include matching diagnostics regardless of whether their assignments were accepted or prebundle-failed
+
+#### Scenario: Repeated diagnostics are grouped
+- **WHEN** multiple diagnostics share a fingerprint
+- **THEN** the UI SHALL show aggregate count and affected assignments while retaining links to each occurrence
+
+### Requirement: Worker fleet status
+The admin UI SHALL display each worker's configured cap, active slots, current phases, package identity, latest contact/progress ages, pending local-recovery indication when reported, and known idle/backoff reason.
+
+#### Scenario: Worker is scanning without recent API contact
+- **WHEN** a worker has an active assignment and recent progress events but its authentication contact timestamp is old
+- **THEN** fleet status SHALL show active progress rather than classifying the worker as idle solely from contact age
+
+#### Scenario: Worker cannot claim due to capacity
+- **WHEN** the server rejects claims because a pipeline capacity axis is closed
+- **THEN** fleet status SHALL show the capacity reason instead of a generic offline/idle state
+
+### Requirement: Deadline and duration administration
+The runtime editor and worker observability pages SHALL explain effective scan, upload, and assignment deadlines and SHALL show p50/p95/p99 duration metrics with sample counts by source and phase.
+
+#### Scenario: Administrator edits a source assignment deadline
+- **WHEN** a per-source TTL candidate is previewed
+- **THEN** the editor SHALL show the effective policy, validation relationship to scan/upload bounds, and that only future assignments are affected
+
+#### Scenario: Administrator compares policy to observations
+- **WHEN** sufficient phase-duration samples exist
+- **THEN** the page SHALL show the configured deadline alongside source-specific percentile values without automatically changing configuration