ezgha-watchdog

name	ezgha-watchdog
description	Read-only fleet-size consumer for the 6 mac + 16 linux ezgha runner invariant. Restart-only remediation is UNAVAILABLE (fail-closed) pending jleechanorg/ez-gh-actions PR 67 (dual-Lima convergence) and PR 70/issue 60 (recovery controller) merging AND being proven live-deployed — a 2026-07-09..11 audit found restarts can kill active jobs, create offline-busy 422 registrations, and cannot repair a dead/wrong-namespace backend. Use when the user says "make sure we have N mac and M linux runners", "ezgha fleet short", "supervisor stuck", or after any /runner-health AMBER/RED verdict — but diagnose with ez-gh-actions' doctor-runner first, never treat a shortfall as expected churn.
type	skill
scope	repo
owner	$USER
version	2.0.0
triggers	["enforce ezgha fleet size","ezgha serve stuck","fill missing runner slots","auto-replenish ezgha","is the ezgha fleet recovered"]
allowed-tools	["Bash","Read"]
context	["ezgha serve is a long-running supervisor that respawns runner containers as jobs complete (one job per container, then exit). It replaces churned slots but does NOT aggressively top-up to N when below configured count — if a slot stays deregistered for any reason (rate limit, crash, race), serve won't refill it on its own loop. That part of the diagnosis is still true.","What is NO LONGER true: treating a restart as the normal/expected fix, or treating 5/6 mac or 14/16 linux as unremarkable churn. A 2026-07-09..11 audit (bead rev-ft3i8, GH issue #8329) proved restarts can kill ACTIVE jobs mid-run, can create offline-busy 422 runner registrations that neither `ezgha status` nor the GitHub API auto-cleans, and CANNOT repair a dead or wrong-namespace backend (e.g. a Lima VM pointing at the wrong Docker context) — a restart just respawns containers against the same broken backend, looking 'recovered' while masking the real defect.","Runtime recovery logic (graceful drain, backend health verification, safe respawn ordering) belongs in jleechanorg/ez-gh-actions, not your-project.com. This repo's skills/scripts are READ-ONLY CONSUMERS of that repo's health contract (doctor-runner, ezgha status, GitHub runner API) — do not add backend-recovery mutation logic here.","Expected fleet: 6 mac (`ez-mac-runner-b-1..6` on MacBook via `~/.config/ezgha/config.toml` `count=6`) + 16 linux (`ez-runner-b-1..16` on jeff-ubuntu via SSH `~/.config/ezgha/config.toml` `count=16`) = 22 total.","A shortfall (N/M below configured count) is a DIAGNOSTIC PROMPT, not a threshold to dismiss. Run `doctor-runner` (see below) before deciding anything is 'expected'. Never lower `count` or the alert threshold to make a shortfall look normal — that hides the same defect the audit found."]

/ezgha-watchdog — read-only consumer of the 6 mac + 16 linux runner invariant

STATUS (2026-07-13): restart-only remediation is UNAVAILABLE — diagnose-first, fail-closed

Do not treat launchctl kickstart / systemctl --user restart ezgha as a routine self-heal. The previous version of this skill said restarting the supervisor was the normal/expected fix and that 5/6 mac or 14/16 linux was "expected churn — don't alarm." Both statements are now known to be unsafe defaults per the 2026-07-09 through 2026-07-11 audit (bead rev-ft3i8, GH issue #8329):

• Restarts can kill active jobs mid-run, not just idle slots.
• Restarts can create offline-busy 422 runner registrations that neither ezgha status nor GitHub's runner API cleans up automatically.
• A restart cannot repair a dead or wrong-namespace backend (e.g. a Lima VM pointing at the wrong Docker context) — it just respawns containers against the same broken backend, which looks recovered while the real defect stays live.

Gating condition for restart-only mutation to become available again — BOTH must be independently confirmed merged in git AND proven live-deployed on the Mac/Linux hosts (a git merge alone is not activation — see "MANDATORY: post-merge activation check" below):

1. jleechanorg/ez-gh-actions PR #67 — dual-Lima convergence to a single canonical Docker backend (bead ez-gh-actions-apye). Verify current status with:

   gh api repos/jleechanorg/ez-gh-actions/pulls/67 --jq '{state,merged,merged_at}'
   

   Status as of 2026-07-13: {"state":"open","merged":false,"merged_at":null} — NOT merged.
2. jleechanorg/ez-gh-actions PR #70 — singleton backend-aware recovery controller for Mac+Linux (bead ez-gh-actions-ghd2.7, tracking issue ez-gh-actions#60). Verify current status with:

   gh api repos/jleechanorg/ez-gh-actions/pulls/70 --jq '{state,merged,merged_at}'
   

   Status as of 2026-07-13: {"state":"open","merged":false,"merged_at":null} — NOT merged.

Until both are merged AND their live-deployment is independently proven (see "Live-deploy proof required" below), any restart of — via this skill's script, , or — is a , never an automated first response or something to silently normalize.