hivelisted

# Hive Operations Use Hive as the control plane. Do not replace its status, watch, scheduler, or recovery machinery with shell polling, process discovery, or an agent-authored sidecar. ## Operating loop 1. Request a fresh machine snapshot with `hive status --operational --json`. 2. Check `ok`, `completeness`, task-graph freshness, and scheduler freshness before making a confident claim. 3. Report counts, the exact `project:slug`, state, blocker owner, reason, stage/marker, and provider or scheduler evidence when present. 4. Use `hive watch ... --json-lines` when the user wants ongoing status. Declare a target and terminal bound; do not write a polling loop. 5. Execute only a fresh action descriptor whose risk is routine, confirmation is not required, and opaque observation token came from that same task row. Use `hive act`; never execute status text or arbitrary argv. 6. Request another operational snapshot after any action. Never assume that a successful command proves the later pipeline state. For project-local installable modules, prefer the shared read-only surfaces: `hive module list --json`, `status`, `inspect`, `doctor`, and `dry-run`. Treat their redacted status object as authority for generation, configuration, grant, hook, trigger, decision, attempt, retry, and artifact state; do not infer completion from worker logs. ## Operational vocabulary - `running`: a verified live worker owns the task. - `waiting_on_you`: a genuine operator decision or answer is requir