Far-future, not scheduled.
Today the bridge pushes live state as replace-snapshots (state.stats every ~10s, state.built, research, TURD). A Prometheus-style evolution would retain history instead of overwriting, so trends can be graphed and alerted on.
Sketch:
- Treat the ~10s stats push as a scrape interval and persist samples (good, produced/s, consumed/s, tick, timestamp) into a time-series store rather than the single
production_stats row-per-good snapshot. Down-sample and retain windows so it does not grow unbounded.
- Same for built-machine counts and power, anything currently snapshot-only.
- Web: time-series charts (throughput over time, per item and machine) and threshold alerts ("iron plate output < X/s", "block starved for N minutes").
- Alternatives to weigh: a real Prometheus exporter endpoint the user scrapes with their own stack, versus an embedded lightweight TSDB (for example SQLite rollups) owned end-to-end. The mod side barely changes, since it already emits the right counters.
This builds on the live production stats and the state.* bridge messages.
Far-future, not scheduled.
Today the bridge pushes live state as replace-snapshots (
state.statsevery ~10s,state.built, research, TURD). A Prometheus-style evolution would retain history instead of overwriting, so trends can be graphed and alerted on.Sketch:
production_statsrow-per-good snapshot. Down-sample and retain windows so it does not grow unbounded.This builds on the live production stats and the
state.*bridge messages.