sitreplisted

# Sitrep Turn a user's monitoring request into one or more of exactly three product objects: | Need | Emit | Primary surface | |---|---|---| | A bounded process with a beginning and end | `task.*` | Dynamic Island, lock screen, 现在 | | A continuously changing value | `metric.update` | widgets, 指标, menu bar | | A point-in-time event that already happened | `message.send` | notification, 消息 | Treat an ongoing condition as an automation that produces a metric and/or a message. Do not invent a fourth product object. ## Resolve Sitrep safely 1. Resolve the CLI with `command -v sitrep`. 2. On macOS, if it is not on `PATH`, use `/Applications/Sitrep Menu Bar.app/Contents/Resources/sitrep` when executable. 3. Run `sitrep automation list` to verify that the computer is paired and the service is reachable. 4. If neither CLI exists or pairing fails, stop and tell the user to install or connect Sitrep. Do not fabricate a local-only monitor. Let the CLI load credentials. Never print, return, copy, or ask an Agent to read `~/.config/sitrep/config.json`, `SITREP_TOKEN`, or Keychain values. ## Classify before implementing Map the request by user intent, not by its data source: - Use a **task** for a run the user waits to finish: build, training, deploy, download, or an interactive Agent session. - Use a **metric** for a value the user wants to glance at repeatedly: CPU, price, odds, stars, queue depth, or latest version. - Use a **message** only when something happened.