cc-ci-orchestrator/cc-ci-plan/plan-phase-kuma-monitor.md

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.