cc-ci/machine-docs/JOURNAL-kuma.md

JOURNAL — phase kuma (uptime-kuma create-a-monitor functional test)

Design rationale, investigations, and dead-ends. Adversary does NOT read this before forming its verdict (anti-anchoring per plan §6.1). See STATUS-kuma.md for claim context.

---

2026-06-11 — Approach selection: Playwright over python-socketio

Context: The phase plan offers two choices:

• (a) python-socketio client speaking Socket.IO events directly
• (b) Playwright driving the real browser UI

Investigation: Checked the cc-ci Nix Python environment:

/nix/store/x188l04r3gfkh18gy1dpf05fv3kkrgs7-python3-3.12.8-env/lib/python3.12/site-packages/
→ greenlet, playwright 1.50.0, pytest 8.3.3, pyee, packaging, pluggy, iniconfig
→ NO socketio, NO websocket-client, NO aiohttp, NO requests

python-socketio would need a nix/cc-ci.nix addition + nixos-rebuild switch on cc-ci. Playwright is already present. Chose option (b): no Nix changes, faster to ship.

Selector research: Inspected uptime-kuma 2.2.1 source files in the Docker image:

• src/pages/Setup.vue: confirms data-cy attributes on all setup form fields
• src/pages/EditMonitor.vue: confirms data-testid on friendly-name, url, save-button
• src/pages/Details.vue: confirms data-testid="monitor-status" on status badge
• Compiled bundle dist/assets/index-D_mnxLA0.js: grep confirms all target attributes

Heartbeat "important" logic: Checked server/model/monitor.js line 1420:

// * ? -> ANY STATUS = important [isFirstBeat]

The server marks the first heartbeat as important=true, so it WILL appear in the important-heartbeat table immediately after the first probe. This means the table row check is a reliable proof of real probe execution.

Status text: From src/mixins/socket.js line 755 (statusList computed):

text: this.$t("Up"),   // UP=1
text: this.$t("Down"), // DOWN=0

English locale: "Up" (capital U, lowercase p) and "Down". Used these exact strings in the _wait_for_status assertions.

URL routing: src/router.js uses createWebHistory() (history mode, not hash mode). Routes: / → Entry.vue → redirects to /dashboard; /add → EditMonitor.vue; /dashboard/:id → Details.vue. So page.goto(f"{base}/add") reliably opens the monitor form directly.

Negative test choice: http://127.0.0.1:19999/dead:

• Inside the container, port 19999 is unused → OS returns ECONNREFUSED instantly
• Connection-refused causes uptime-kuma to mark the monitor DOWN immediately (no timeout wait)
• This proves the probe engine makes real outbound calls (not a stub)
• Included — fits runtime budget easily (~5 s for DOWN detection)

Runtime budget analysis:

• Setup wizard + login: ~10 s
• Create monitor 1 + wait UP: ~15-30 s (first probe immediate, but socket roundtrip)
• Create monitor 2 + wait DOWN: ~10 s (ECONNREFUSED is fast)
• Overhead: ~5 s
• Total estimate: ~40-55 s — well within ≤90 s target

---

2026-06-11 — Build #460 result + M1 claim

!testme triggered on uptime-kuma PR #3 (comment #14349). Bridge log:

[poll] triggered build 460 for uptime-kuma@eb4521cc (PR #3, comment 14349) by autonomic-bot
reflected outcome build 460 (uptime-kuma PR #3): success

Build 460 results.json:

• level: 5, all stages PASS (install/upgrade/backup/restore/custom/lint)
• customization: {custom_tests: {cc-ci: {functional: 3, playwright: 1}}}
• stage custom tests: health_check [pass], socketio_handshake [pass], spa_branding [pass], test_monitor_wizard [pass]
• flags: {clean_teardown: true, no_secret_leak: true}

PR comment #14350 posted: ✅ passed.

M1 claimed (commit fe8922c). Second !testme posted (comment #14352) for flake check while Adversary reviews M1.