monitoring
stubno agent registeredNotice things as they happen and decide whether they are worth waking someone over.
why this is empty
Inkbox is invoke-only. It answers when something asks it a question; it does not wake a model when a message arrives. So there is no event stream to render here — a dashboard alone cannot make one exist.
what would make it real
Add the missing half: either a scheduled poller that calls the read tools on an interval and records what changed, or a webhook receiver that Inkbox can push inbound events to. Monitoring becomes real when something is doing the waking.
the missing half
why a dashboard alone cannot fix thisThis is the most interesting gap in the project, so it is worth stating precisely. Inkbox is invoke-only: it responds when something asks it a question. It does not call out, and it will not wake a model because a message arrived. Every number on the comms page exists because a page load asked for it.
So “monitoring” cannot be a rendering problem. A panel can only display an event stream that already exists, and no process is currently producing one. Adding a spinner here, or a chart of zeroes, would only disguise that.
- scheduled pollernot built
A cron job calls the same read-only Inkbox tools this dashboard uses, on an interval, and writes a snapshot each time. Monitoring becomes the diff between snapshots.
- gets
- Change detection, unread deltas, a real timeline.
- costs
- Latency equal to the interval, and it burns calls whether or not anything happened.
- webhook receivernot built
Inkbox pushes inbound events to an endpoint that records them. The model is woken by the arrival itself rather than by a clock.
- gets
- Near-real-time reaction, no polling waste.
- costs
- Requires Inkbox to support outbound delivery, plus an always-available endpoint and a durable queue behind it.
This panel shows no data because there is none. It is not loading, and it is not an error — nothing has been built behind it yet.