Skip to main content

Fleet / cross-build live status reporting

Use when asked where builds/fleet are at. Report live state. When the owner asks "where is <build> at", "where are we with builds", or "give me the work in progress", answer from each build's OWN authoritative sources read at that moment. Injected MemPalace / memory recall is STALE — it describes past passes, not the live head. Never build a status answer from recalled context; read live, then report.

"Work status" for this owner specifically means live subagents + background jobs, OS coding-agent processes, cron jobs, and containers — not a prose narrative.

Sources to read (batch the independent reads in one turn)​

  • Subagents: delegate_task action=list.
  • Cron inventory: cronjob_manage action=list (enabled/paused/completed + last_status).
  • Background OS work: ps for opencode/codex/claude/node/python/hermes.
  • Containers: docker ps -a — live prod vs. the pile of exited review/build ones.
  • Per cron-driven build: read the NEWEST cron OUTPUT file, not the job metadata: /root/.hermes/cron/output/<job_id>_<ts>.txt (ls -t | head -1). Each build's report is self-describing — what it delivered, what it's blocked on, which owner decisions it needs.
  • Product builds with a controller: run the controller's compact status CLI (NEVER dump private per-file state.json), plus live GitHub open PRs/issues and main's HEAD via API-verified SHA — the repo CWD may be an old branch.

The four buckets the owner actually wants (state each explicitly, per build)​

  1. MERGED / integrated on main — real progress.
  2. Gate-green or dual-approved candidates STUCK IN REVIEW — code is done, waiting on a governance/route deploy, not on more implementation.
  3. Blocked on an OWNER DECISION — name the exact decision and who owns it.
  4. Blocked on a HUMAN GATE (e.g. install validation on real hardware) or a CAPACITY/429 event (a wall-clock session-limit reset, not a code fault). Most "stuck" fleet state is buckets 2–4, not unfinished code. Say so plainly.

Reading a wedged controller retry loop correctly​

Retry entries with active:false, next_at:0, stuck:true and a stable stuck_reason are SELF-QUIESCED by the controller — not live failures, and NOT something to hand-edit out of state. High failures counts (50+) repeating one reason (delivery lacks exact validation handoff evidence, candidate changed, owner generation changed) mean the loop is retrying a step only an owner action or a code deploy can satisfy. A planner with last_result:"no_result" and rising failures is the same: backing off, waiting on an unmet prerequisite. Report as "blocked on owner decision X", never "the build is failing." (planner.failures also counts benign ok_no_improvement vacancy outcomes.)

Fold shared root causes; lead with the highest-leverage unblock​

Multiple builds are often wedged on the SAME knot. Name the shared root cause once and lead with the single action that unblocks the most, instead of listing each build's symptoms independently. Then end by offering to dig into that one blocker.

Style (this owner)​

Role-based language; models are interchangeable config, never role identities. Lead with the answer, group by build, mark each item's bucket, and finish with the one decision only they can make. See references/cross-build-status-reporting.md for the job_id→build map and a worked example.

Supporting files: this skill's supporting files are held in the docsite at docs/15-skills/_support/automation/fleet-build-status-reporting/ — fetch them fresh from jknash/docsite main alongside this page. Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/automation/fleet-build-status-reporting/ · view source · Imported 2026-10-04. Supporting files (references, scripts) remain in the source repository.

Published by Muse · 2026-10-04.