Files
felhom.eu/REPORT.md
T

6.6 KiB
Raw Blame History

felhom.eu — task reports

Overwrite this file with a summary of the most recent task only (uniform with the other repos; not cumulative). The cumulative hub history lives in hub/CHANGELOG.md; the scripts history lives in scripts/CHANGELOG.md.


REPORT — TASK-D4: Felhom Hub re-skin (design system v2, final surface) → hub v0.30.0

Date: 2026-07-02 · Deployed: k3s felhom-system deploy/hub @ felhom-hub:0.30.1 (0.30.0 + the badge no-wrap follow-up; rolled out)

1. Baselines

  • felhom.eu main @ 43189e8 (D3 final) — matched; main had not moved.
  • felhom-controller @ d0c70a7 — read-only woff2 source (byte-copied).

2. The enumerated OverallStatus set and its mapping

From source (server.go handleDashboard, configs.go overallStatus, hosts.go hostStatusClass): ok, warn, down, pending, disabled, blocked (+ fail accepted as a statusColor input, stale in the hosts domain). Complete mapping (exception-color principle):

Status Token Reasoning
ok nominal operating normally — blue, not green
warn warn degraded / stale report — amber
stale (hosts) warn consistent with hostStatusClass's existing warn reuse
down crit outage — red
fail crit health=fail — red
pending neutral a not-yet-provisioned customer is a NORMAL fleet state (Peti Debian stays quiet)
disabled neutral deliberately paused — not a deviation
blocked warn operator cut a customer off: intentional but attention-worthy — amber, not red (not an outage)
unknown/"" neutral unknown values stay quiet

A healthy fleet dashboard is blue/neutral only. Event severity counts remain filled amber/red badges (exceptions stay loud, per the design-system .badge addendum).

3. Commits

Commit Content
bc8d54d Part 1: fonts embedded + /static/fonts/ route, 12-symbol sprite partial on all 9 pages, statusColor semantic remap, statusIcon retired, truth-table + parse tests
c136308 Part 2: style.css v2 (tokens, tag-style status badges + CSS dots, hairline rows, row tints warn/down only), two-tone H1 ×8, charts retinted, inline hexes swept, login retinted
fc79a3a manifests: hub image 0.30.0 (GitOps truth kept in sync with the set-image deploy — repo convention; auto-sync is off)
(docs) Part 3: hub/CHANGELOG v0.30.0 + this REPORT

4. Tests + red-proof

go build ./... && go vet ./... && go test ./... green after each commit (hub/). New tests (the hub web package previously had none for funcmap/templates):

  • TestStatusColorTruthTable — full enumerated set. Red-proof: against the stashed pre-change implementation it failed exactly as required (statusColor("ok") = "#4ade80", want "nominal", warn→#facc15, stale→#94a3b8, down→#f87171). Restored → pass.
  • TestTemplatesParseWithFuncmap — all 9 templates parse with the production funcmap.

5. Grep gates (before → after, hub/internal/web non-test files)

#0f172a 2→0 · #1e293b 2→0 · #334155 3→0 · #60a5fa 3→0 · #4ade80 5→0 · #facc15 1→0 · #f87171 7→0 · #94a3b8 10→0 · #64748b 3→0 · #475569 3→0 · #e2e8f0 2→0 · #0088cc (login) →0 · statusIcon template usage 2→0 · inline style="color: {{statusColor}}" 2→0 · box-shadow 0→0 (never had any).

6. API freeze proof

git diff 43189e8..HEAD --stat touches ONLY hub/internal/web/** (+ hub/CHANGELOG.md, manifests/hub.yaml one-line tag, REPORT.md). Nothing under hub/internal/api/, hub/internal/store/, or any ingestion/notify/monitor package.

7. Deployment + Scenario E (live E2E)

deployment "hub" successfully rolled out
hub-757d8dcb46-pq84j   1/1   Running   0   13s
[INFO] Listening on :8080   (felhom-hub 0.30.0)

Scenario E passed: hub deployed 22:40 CEST; the demo controller's next 15-minute cycle at 2026/07/02 20:45:19 UTC (22:45 CEST) logged Hub report pushed successfully (5423 bytes) — an HTTP 200 from the freshly deployed hub's /api/v1/report, proving ingestion end-to-end after the re-skin (the controller only logs success on a 2xx). The dashboard LAST SEEN visual confirmation joins the authenticated Chrome pass (§8).

8. Chrome checks (authenticated pass — operator logged in)

  • Dashboard (Scenario A/B): two-tone "Felhom Hub", navy tokens, hairline rows. DOM-asserted: 0 green and 0 red elements on the healthy fleet; OK = blue outline tag + dot (rgb(46,168,245)); PENDING (Peti Debian) = quiet neutral tag with hollow dot; 0 radii beyond 0/2px/50%. (First load showed the OLD skin from the browser's 1-hour /style.css cache — a hard reload fixed it; noted in Observations.)
  • Fonts (Scenario C): document.fonts.check true for both faces; woff2 served from /static/fonts/; 0 external requests; "Demo Ügyfél" renders in Plus Jakarta Sans (screenshots — dashboard + customer page H1).
  • Charts (Scenario D): app_detail (nextcloud) memory trend — avg #2EA8F5 filled, peak #8E7CE8 dashed, catalog-limit #E0A93E dashed; clearly distinguishable (screenshot). Severity warn chips filled amber in Known Issues (exceptions loud).
  • Scenario E visual: dashboard LAST SEEN "4 min ago" + Controller 0.98.3 in the version column — the post-deploy report cycle rendered.
  • Customers/customer_unified, Apps, Hosts (blue ONLINE tag, neutral NO REPORT), Configuration (rendered read-only, nothing submitted; the artifact manifest shows agent 0.60.0 / golden 0.85.1 selected — unchanged) all render v2.
  • v0.30.1 follow-up: the pass caught multi-word badges (PENDING / NO REPORT) wrapping between the CSS dot and label in narrow columns — fixed with white-space: nowrap on .status-badge, built + deployed (manifest bumped).

9. NOT live-validated

  • warn/crit fleet states (no customer is currently degraded) — truth-table-tested only.
  • The Configuration page was NOT submitted/altered (per spec §12).

10. Observations (not acted on)

  1. The hub login page is inline HTML in server.go (two copies, error + plain) — a template would be cleaner; retinted only.
  2. customer_unified.html carries a small per-page <style> block (toggle styles) — tokens updated in place; consolidation into style.css is a candidate for a later pass.
  3. memoryColor/accuracyClass (mem-ok/warn/danger) already returned classes; their CSS is now v2 but the class names keep their legacy spelling (grep-safe rename candidate).
  4. Session store is in-memory — every deploy logs the operator out; fine for a single-operator tool, noted for the future.