Monitoring, briefs and watches

Monitoring is read-only. A watch may fetch, compute, save and alert. It may never send to the exchange. If a watch condition implies action ("stop got hit, re-enter"), the alert opens a proposal; the lifecycle does the rest.

Grok Bot routines

Each Bot can own routines (schedules or event triggers). Ask the owning Bot to create one with: schedule and time zone, input source, expected result, approval boundary. Keep routines few and specific; the app keeps only recent run records, so a routine that produces something durable should also write to /workspace/trading-desk.

Recommended starting set (the user picks; none is on by default):

The desk brief

Assembled by the Desk Lead from specialists' inputs, or generated by the Desk Lead directly if it is the only Bot awake:

CONCLUSION: The ETH long remains open with a resting stop; HG-20260816-01 is live.
DESK BRIEF | 2026-08-17 07:00 UTC | mainnet | account 0xabc...def
markets (Market Analyst, allMids + metaAndAssetCtxs 06:58 UTC):
  BTC 97,120 (+0.8% 24h) | funding 0.0010%/h | OI $4.1B
  ETH 3,004 (+0.2%) | funding 0.0012%/h | OI $1.2B
  SOL 151.2 (-1.1%) | funding -0.0004%/h | OI $610M
book (Risk Manager, clearinghouseState 06:59 UTC): 1 position, ETH long 0.4827 @ 3,000, uPnL +$1.9, margin ratio 4.6%, stop resting 2,900; open risk 0.5%; day PnL 0.0%
research (Research Analyst): ETH client release scheduled 2026-08-19 [link]; nothing breaking on held markets
open items: HG-20260816-01 live; pending tickets: none

Lead the brief with a plain conclusion about the current book and any required attention, then present these facts with sources. Keep interpretation on one clearly labelled line. Name existing positions and live or pending tickets; do not describe a book with an open position or ticket as having no open items. No trade suggestions.

When to post

A requested update or scheduled report always receives an answer, even when the state is unchanged. For other background checks, save the source, network, UTC check time, accepted and observed data age, result and relevant position or proposal ids under /workspace/trading-desk. Stay quiet only when the check succeeded with fresh, complete data and found no actionable change.

Post changed conditions, failures, stale reads, missing data and gaps with their consequence and next owner or required action. Successful request completion alone is not an all-clear; apply the freshness and completeness checks below before suppressing a message. A quiet run still leaves timestamped evidence and a heartbeat for inspection.

Watches

A watch is a condition plus an alert. Two ways to run one on the desk computer:

• Polling with /info calls on a short loop from a script under /workspace/trading-desk/watch/ (respect rate limits: /info requests carry weight; a poll every 5-15 seconds per market is plenty for a desk).
• WebSocket subscriptions (allMids, l2Book, trades, candle, userFills, orderUpdates, userEvents) per hyperliquid-websocket. Better for fills and order updates. Keep the process supervised (a routine can restart it) and log to a file.

Common watch conditions:

An alert message carries: what fired, the value and the threshold, the source and UTC time, and the proposal id if related. Alerts do not include instructions to trade.

Silence is not an all-clear. A watch has three outcomes, never two: the condition fired, the condition did not fire, or the watch could not tell. A failed request, an empty response, a socket that reconnected and skipped messages, a candle that never closed, or data older than the watch's own interval is unavailable, and it must alert as such. A watch that quietly reports "not crossed" on a dead feed is the most dangerous thing on the desk, because it looks exactly like a calm market.

Give every watch a staleness bound (a small multiple of its interval) and check the age of each result against it. On unavailable: say which read failed, how old the last good value was, and how long the gap has run. Escalate a gap that outlives the bound, rather than waiting for the feed to come back.

Hygiene

• Every watch script logs to /workspace/trading-desk/watch/<name>.log with UTC timestamps.
• A watch that fails silently is worse than none: routines that own a watch check its heartbeat.
• Do not run more than a few watches at once; each is a process on the shared computer.
• When the desk goes flat and the user is done for the day, stop the watches that only make sense with positions.

Never

• Never let a watch place, modify or cancel an order, or change leverage. Even a "protective" one. It alerts; the desk acts through a ticket.
• Never alert with unsourced numbers.
• Never report a stale or failed read as a condition that did not fire. That is an unavailable alert, not silence.
• Never poll faster than the desk needs; a rate-limited desk is a blind desk.