Low-fidelity wireframes for Phase 1/2 screens. Purpose: confirm the data each
screen needs before the API in spec.md §6.1 and the WS messages in §6.2 are
locked in. Grayscale on purpose — visual design is deferred to Phase 5
(and a focused hi-fi pass on the restore wizard in Phase 3).
[GET /api/...] tags mark REST data sources.
[WS: ...] tags mark WebSocket message dependencies.
Open the “Findings” section at the bottom for spec gaps.
Screen 1 · Dashboard (/)
restic-manager
user: alice (admin) · logout
Fleet status
10 online · 1 offline · 1 degraded
Last sync 12s ago
Storage (sum across repos)
2.4 TB across 12 repos
+18 GB last 24h
Open alerts
3 · 1 critical
2 unacked
[ search hosts · filter by tag · status ]
+ Add host
Hosts
prod-db-01 linux/amd64
online
Last backup
2h ago · success
Repo
412 GB · 1,284 snapshots
Alerts
—
ViewBackup now
staging-app linux/arm64
degraded
Last backup
9h ago · failed
Repo
88 GB · 412 snapshots
Alerts
2 · 1 critical
ViewRetry
laptop-bob windows/amd64
offline
Last seen
3d ago
Repo
142 GB · 88 snapshots
Alerts
1
ViewBackup now
… more host cards (12 total in target deployment)
Recent activity (fleet-wide)
When
Host
Kind
Status
Duration
2h ago
prod-db-01
backup
succeeded
00:14:22
view
3h ago
web-02
backup
succeeded
00:08:11
view
9h ago
staging-app
backup
failed
00:01:03
view
1d ago
prod-db-01
check
succeeded
00:42:17
view
1d ago
web-01
prune
succeeded
00:04:55
view
Screen 2 · Host detail (/hosts/:id)
restic-manager
user: alice (admin)
« Dashboard / Hosts
prod-db-01
linux/amd64 · agent 0.4.2 · restic 0.17.1 · last seen 12s ago
[ ] auto-scroll [ ] show stderr only download full log
Findings — gaps in spec.md §6 surfaced by Phase 0 wireframing
Aggregate fleet endpoint missing. Dashboard summary strip and Prometheus metrics (§14.4) both need fleet rollups. Add GET /api/fleet/summary returning host counts by status, total repo bytes, open alert counts. Cheaper than client fanout and reused by /metrics.
Host list response is too thin. Domain model Host (§5) has status + last_seen_at; cards need last_backup_at, last_backup_status, repo_size_bytes, snapshot_count, open_alert_count, current_job_id. Either add columns or compute server-side and include in GET /api/hosts.
Job actor not modelled. Job table tracks scheduled_id but not who (user vs schedule vs system) triggered a run-now. Dashboard "Recent activity" and Jobs tab both want this. Add Job.actor_kind + Job.actor_id — cheaper than joining AuditLog every time.
WS job.progress JSON shape is undefined. §6.2 lists the message name only. Lock the shape now: {percent_done: float, files_done: int, total_files: int, bytes_done: int, total_bytes: int, eta_seconds: int, throughput_bps: int}. Keeps client + agent in lockstep before Phase 1 codes against it.
Repo response needs more fields. §6.1 says size/last-check/lock state. Wireframe also wants: dedup ratio, snapshot count, credential rotation timestamp, append-only flag. Most derive from restic stats + Credential row — expose them through GET /api/hosts/:id/repo.
Snapshot filtering needs server support. Tag/path/date filters belong on the server (12-host fleets are small but a single host can hold thousands of snapshots). Add query params to GET /api/hosts/:id/snapshots: ?tag=, ?path=, ?since=, ?limit=. Distinct-tag list endpoint optional — could be derived client-side at first.
Job listing needs query params. Recent activity, host-scoped jobs, and the Jobs page all use GET /api/jobs. Lock down: ?host_id=, ?kind=, ?status=, ?since=, ?limit=, ?order=. Pagination too.
Agent self-update endpoint not in §6.1. §4.2 describes the mechanism but no REST endpoint exists. Settings tab wants a "Force update now" button — add POST /api/hosts/:id/agent/update.
Schedule retention/options JSON shape. §14.2 (bandwidth) and §14.3 (hooks) both extend Schedule. Document the canonical shape now (retention_policy, options.limit_upload, options.limit_download, pre_hook, post_hook) so the schedule editor and the agent can both target it.
HTMX-vs-WS responsibility split. Decision: only the Job detail screen needs WS. Dashboard, Hosts, Snapshots use HTMX polling (10s). This avoids fan-out complexity for v1; revisit if dashboard feels stale.