ci-monitoringlisted

# On-Demand CI Monitoring A single push can trigger multiple GitHub Actions workflows (PR Checks, Fuzz, CodeQL, etc.). Do not auto-start this monitor after routine pushes. Start it only when the user explicitly asks to monitor CI, or when you are about to deploy/merge and need a fresh CI result. You MUST wait for ALL workflows for the monitored HEAD to finish before claiming green or deploying. ## Continuous background monitor pattern When monitoring is requested, use **one detached bounded monitor** per pushed HEAD. Do not manually issue repeated GitHub Actions polling calls in the conversation. Launch the temp script, print its `CI_MONITOR_STARTED ... log=<path>` handle, and leave the long-running polling inside that script so the main session stays free. The monitor appends progress and the terminal `CI_RESULT` line to its durable temp log. The printed log path is the completion source; the short launcher output is not proof of CI success or failure. ### Toolset selection - runs under Bash *or* `ctx_*` The launcher is plain shell and runs under either toolset. `gh` and `node` work fine **inside** a `ctx_execute` shell subprocess (a context-mode routing gate only intercepts the Bash *tool*, not the binaries), so a session that cannot run `gh` through the Bash tool can still run the exact same launcher through `ctx_*`. Pick whichever the session supports; never fall back to manual chat polling. - **Native Bash tool** (default when the Bash tool can run `gh`/`node`): r