`scripts/cta-crcp-health.sh`

73 lines
#!/usr/bin/env bash
# TK-10753 — self-provisioning health runner for the CRCP filter-control CTA.
#
# The whole cookie-rot risk (Cody's TK-10643 dissent) is that a STORED crcp_sid expires.
# This runner sidesteps it: it mints a FRESH session every run (login the throwaway test
# account, or register it if it doesn't exist yet), then runs the cross-browser harness,
# then surfaces its PASS/WARN/FAIL verdict + exit code. Safe to schedule later because it
# never depends on a persisted cookie.
#
# Fail-loud: any failure — server down, auth failure, harness crash — writes a FAIL
# verdict to cta/health-10643.json (via the harness) or prints a FAIL here, and exits
# non-zero. It can never silently no-op.
#
# Usage: bash scripts/cta-crcp-health.sh
#
# DEFERRED (TK-10643 verdict C — do NOT schedule yet; the CRCP filter UI is low-churn).
# When always-on monitoring IS wanted, this runner is already schedule-safe (self-provisions
# its session). Two steps to promote it to a watched fleet canary:
#   1. Have this runner ALSO mirror cta/health-10643.json to a skills path the fleet reads,
#      e.g.  ~/.claude/skills/cta-crcp-filters/data/latest.json  (fleet-health-rollup +
#      dw-canary-meta-watchdog both only glob ~/.claude/skills/*/data/latest.json).
#   2. Add ONE REGISTRY row to ~/.claude/skills/dw-canary-meta-watchdog/watchdog.mjs:
#      { label:'com.steve.cta-crcp-filters', skill:'cta-crcp-filters', hb:'data/latest.json', every:'daily', maxAgeMs: 30*H }
#   …and drop a com.steve.cta-crcp-filters.plist that runs this script daily.
# Until then it's an on-demand health check that fails LOUD — never a silent-green corpse.
set -uo pipefail

BASE="${CTA_BASE:-http://127.0.0.1:9911}"
USER="${CTA_USER:-ctahealth10753}"
PASS="${CTA_PASS:-ctahealth10753pw}"
ROOT="$(cd "$(dirname "$0")/.." && pwd)"
HEALTH="$ROOT/cta/health-10643.json"
COOKIES="$(mktemp /tmp/cta-health-cookies.XXXXXX)"
export NODE_PATH="${NODE_PATH:-$(npm root -g 2>/dev/null)}"

fail() {  # write a FAIL heartbeat ourselves when we can't even reach the harness
  mkdir -p "$ROOT/cta"
  printf '{"canary":"cta-crcp-filters","verdict":"FAIL","ts":"%s","detail":"%s"}\n' \
    "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$1" > "$HEALTH"
  echo "HEALTH: FAIL — $1"
  rm -f "$COOKIES"
  exit 1
}

# 0) server reachable?
code=$(curl -s -o /dev/null -w '%{http_code}' -m 8 "$BASE/healthz" 2>/dev/null || echo 000)
[ "$code" = "200" ] || fail "CRCP server not answering on $BASE/healthz (got $code)"

# 1) mint a fresh session — login first, register on failure (self-heals a missing account)
login() { curl -s -m 10 -c "$COOKIES" -X POST "$BASE/auth/$1" -H 'Content-Type: application/json' \
  -d "{\"username\":\"$USER\",\"password\":\"$PASS\",\"name\":\"CTA Health $USER\"}" 2>/dev/null; }
resp=$(login login)
echo "$resp" | grep -q '"ok":true' || resp=$(login register)
echo "$resp" | grep -q '"ok":true' || fail "could not mint a session (login+register both failed): $(echo "$resp" | head -c 160)"

SID=$(awk '/crcp_sid/{print $7}' "$COOKIES" | tail -1)
[ -n "$SID" ] || fail "authenticated but no crcp_sid cookie was set"

# 2) run the cross-browser harness with the fresh cookie; it writes the real verdict
echo "→ session minted for $USER; running cross-browser harness…"
CTA_SID="$SID" CTA_BASE="$BASE" node "$ROOT/scripts/cta-crcp-filters-10643.js"
rc=$?
rm -f "$COOKIES"

# 3) surface the verdict the harness stamped
if [ -f "$HEALTH" ]; then
  verdict=$(grep -oE '"verdict"[[:space:]]*:[[:space:]]*"[A-Z]+"' "$HEALTH" | head -1 | grep -oE '[A-Z]+"$' | tr -d '"')
  echo "── cta-crcp-filters health: ${verdict:-UNKNOWN} (harness exit $rc) → $HEALTH"
else
  fail "harness produced no health file (exit $rc)"
fi
exit $rc