# Phase `kuma` — uptime-kuma create-a-monitor functional test

**Mission (operator-approved 2026-06-11, DEFERRED re-entry):** add the §4.3-prescribed
functional test that completes uptime-kuma's first-run setup wizard and exercises its
core function — create a monitor, see it actually probe a target — then check off the
DEFERRED entry. This is a cc-ci-repo-only phase (tests/uptime-kuma/), no recipe PR.

State files: `STATUS-kuma.md`, `BACKLOG-kuma.md`, `REVIEW-kuma.md`, `JOURNAL-kuma.md`.
DECISIONS.md shared.

## 1. Starting facts

- DEFERRED entry (2026-05-28): uptime-kuma's first-run setup wizard + monitor CRUD run
  over **Socket.IO** (not plain REST) — that's why it was deferred as fiddly. The
  existing coverage is install/upgrade/health (+ screenshot, fixed in the shot phase);
  the recipe currently earns its level without proving its actual function.
- uptime-kuma has no stable public REST API for this in the pinned version; the web UI
  drives everything via socket.io events (`setup`, `login`, `add monitor`,
  `uptimeList`). Two viable approaches — pick ONE and justify in DECISIONS.md:
  (a) **python-socketio client** speaking the events directly (fast, headless, but
  couples to the event names of the pinned version); or
  (b) **Playwright through the real UI** (slower, but version-robust and reuses the
  harness browser stack like other recipes' playwright tests).
- Wizard creates the admin credential: generated per-run, never logged (secret-safety
  rules apply; the manifest redaction conventions cover meta, your test must not print
  it either).

## 2. Work requirements

1. **Test design:** complete the first-run wizard (admin create) → create an HTTP
   monitor pointing at a target the harness controls (e.g. the app's own /; or a
   second known-up service in the deploy) → wait bounded time for ≥1 check result →
   assert the monitor reports UP with a real probe timestamp. Negative teeth: a monitor
   pointed at a dead target must go DOWN (proves the probe isn't a stub) — include it
   if it fits the runtime budget, else justify.
2. **Placement per rcust conventions:** `tests/uptime-kuma/functional/` (or
   `playwright/` if option b), uniform fixtures (`live_app`, `meta`, ctx hooks), no new
   meta keys without registry+docs.
3. **Runtime budget:** the whole addition stays within the recipe's normal functional
   tier budget (target ≤ ~90s added; bounded waits, no flaky sleeps — poll with
   deadline).
4. **Prove in real CI:** full uptime-kuma lifecycle green with the new test active
   (level should hold or rise under the de-capped ladder); ≥1 drone `!testme` run.
5. **Close records:** tick the DEFERRED entry with commit + run pointers.

## 3. Gates

**M1 — Test implemented + green.** Approach chosen and justified; test lands with
bounded waits and real assertions; full local-path lifecycle green. Adversary
cold-verifies: the monitor result is REAL (not asserted from config echo — there must
be evidence a probe executed), credentials never leak into logs/artifacts, runtime
budget held, nothing weakened.

**M2 — Proven in real CI.** Drone-path run green with the new test; flake check (2
consecutive green runs); levels reconciled; DEFERRED closed. Fresh Adversary PASS →
`## DONE`.

## 4. Guardrails (binding)

- No gate weakening; the new test only ADDS coverage. Secret-safety: generated admin
  credentials never printed/committed. Real-CI etiquette: ≤2-3 concurrent deploys,
  teardown on every exit path, never touch `~/.abra/recipes/uptime-kuma` mid-build.
- Commit author `autonomic-bot <autonomic-bot@noreply.git.autonomic.zone>`; push every
  commit. CI host: no python3 on default PATH (use `cc-ci-run`).

## 5. Definition of Done

uptime-kuma proves its actual function in CI (wizard + created monitor genuinely
probing), flake-checked through the drone path, budget held, DEFERRED checked off,
M1+M2 fresh Adversary PASSes.