hive-stateful-monitoring

hive-stateful-monitoring — Stateful Monitoring

Turn durable intent — watch, alert, schedule, remember — into Hive monitors, alerts, reports, and memory facts. Monitor execution happens on Hive workers between sessions, not in the current chat, so the contract is: capture intent precisely, confirm what was saved, and never pretend something was saved when the call failed.

Task toolset and identifiers

Toolset: stateful_monitoring. Read hive://toolsets/stateful_monitoring before execution; it is authoritative for the current output schema, material-call budget, phases, fallback condition, stop conditions, and the read/write routing policy.

Required identifiers: monitor kind and target object. Worker-supported monitor kinds are wallet, token, protocol, market, watchlist_digest, token_discovery_risk, and risk_watch.

Before choosing endpoints, select exactly one matching entry from the exact workflow's routes[]. Follow its ordered steps, use a fallback only under that step's published condition, stop at four material calls, and preserve the selected route_id in the typed result. The broad coverageCatalog is discovery coverage, not an execution plan.

Procedure

1. Convert the user's durable intent into a monitor kind, target, rules, and cadence.
2. Inspect each exact endpoint schema. On the compact root, state reads route through invoke_api_endpoint. Every create, update, archive, remember, forget, acknowledge, or resolve action routes through invoke_stateful_endpoint, which must never be auto-approved.
3. Call hive_list_monitors before creating — update instead of duplicating.
4. Describe the proposed state change to the user and obtain explicit approval.
5. Call hive_create_monitor for new watch requests, hive_update_monitor to change cadence, rules, target, metadata, or status, and hive_archive_monitor when the user asks Hive to stop watching.
6. For "what changed / what is alerting / what does Hive remember": use hive_get_monitor_runs, hive_list_observations, hive_list_alerts, hive_get_latest_snapshot, or hive_generate_monitor_report.
7. Use hive_update_alert_status when the user acknowledges, reopens, or resolves an alert.
8. Use hive_remember_fact, hive_list_memory_facts, and hive_forget_memory_fact for durable user-scoped facts that should appear in future monitor reports.
9. After any write, verify the persisted result, then confirm back to the user exactly what is being watched, the rules, and the cadence — that confirmation is their only window to catch a mis-captured intent before workers start running it.