# 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):
```javascript
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.
