Machine-local wait / event bus — register a wait, get completion. Stop inventing poll loops.
Table of contents
wait-hub is a thin general wait / event bus for the local machine (and later any harness). Clients register a wait with a service id and subject; the daemon owns waiting, fan-in, and completion notify.
Waiting is a general problem. Forges / CI are the main target for now, but the product is not “another GitHub Actions tray app.” The same contract covers registry publish, Pages/DNS, deploy probes, and any long job with a completion signal — so agents and tools stop reinventing AwaitShell / poll scripts.
Core API (service-agnostic): register_wait · complete_wait · wait_until · list
serviceis an open string- Catalogued adapters handle known services (v1 ships GitHub Actions as adapter #1, not the product identity)
- Unknown services: propose-automation cold path (draft for review → first-party adapter later)
- Equivalence-engine is out of the hot path — no scavenging local poll scripts (ADR 0001, ADR 0002)
Sibling to hive-watch (hive git remotes). Different job: remotes status vs wait-for-completion.
Agents / harnesses: register a wait and block or subscribe on the daemon. Do not invent monitors for catalogued services when wait-hub is available. Future ideal: gh and peers hand off “wait for X” here.
| Example | service (illustrative) |
v1 |
|---|---|---|
| GitHub Actions run | github.actions |
Adapter #1 (API poll; webhook ingest stub) |
| Registry publish / package index | e.g. npm.publish, dub.upload |
Later adapter |
| Pages / DNS / deploy probe | open string + subject | Later / propose |
| Local hive remotes ahead/behind | — | Use hive-watch, not wait-hub |
| Cursor cloud wake on CI | — | Cursor Automations / Subscriptions (complementary) |
Webhooks alone do not reach the laptop; v1 polls where needed. Optional ingest endpoints land as adapters grow (open questions).
Prerequisites: Node 20+. For the GitHub Actions adapter: gh authenticated or GITHUB_TOKEN.
git clone https://github.com/dev-centr/wait-hub.git "$env:code\github.com\dev-centr\wait-hub"
cd "$env:code\github.com\dev-centr\wait-hub"
node bin/waitd.js --write-config --code-root $env:code
node bin/waitd.js --serveIPC default: http://127.0.0.1:17357 (hive-watch uses 17356).
Artifacts (machine-local, not committed):
| Path | Role |
|---|---|
$CODE_ROOT/wait-hub.config.json |
Port, poll interval, paths |
$CODE_ROOT/wait-hub.status.json |
Pending summary |
$CODE_ROOT/wait-hub.events.jsonl |
Append-only events |
$CODE_ROOT/wait-hub/waits/*.json |
Per-wait records |
First client surface for DevCentr harness — any harness can use the same CLI/HTTP:
node bin/wait-hub.js wait github.actions --repo OWNER/REPO --run-id 123456789 --client devcentr-harnessAlso: health, list, get <wait_id>, --no-block to register only. See docs/harness-client.md.
| Role | Stack |
|---|---|
| Runtime | Node.js 20+ (ESM), localhost HTTP IPC |
| Adapter #1 auth | GitHub CLI (gh) or GITHUB_TOKEN |
| Sibling pattern | hive-watch daemon + $CODE_ROOT status files |
- hive-watch — hive remotes fetch + status (not waits)
- plan-stack — speculative multi-phase wait queue (consumes wait-hub; ETA-sized stacks)
- harness — first intended client
- docs/open-questions.md — webhook relay, Cursor mid-turn wake, more adapters
- docs/forge-watch-push.md — why forge watches should prefer push over poll (cli/cli#14410)
- HCI-Nerdz plan-stack demo — teaching surface for speculative queues
MIT — see LICENSE.
Dev-Centr — github.com/dev-centr