Oko
Oko/Docs

Command reference

oko asks update

The hourly update the operator asked for, read from the registers and never written by a session: the questions waiting on him with their choices and the command that answers each, then the defects opened, repaired and closed since the last update sent (with how many are open and how many have no repair), then the open blockers with what each blocks and when it resumes. Oko's service sends it once per period of the schedule `update.json` declares (`@hourly`, the operator's ruling) on the `imessage` channel, so it reaches him without any session writing to him.

Invocation#

Command
oko asks update [--send | --status]

Inputs and options#

  • Nothing to see the update as it would go out now, since the last one sent; nothing is sent or kept.
  • `--send` sends it now on the `imessage` channel and keeps the attempt; `--status` reads the last attempt. The record is `OKO_OPERATOR_UPDATE`, else `operator-update.json` in Oko's folder.

Output and state effect#

  • Without flags, prints `{text}`. With `--send` or `--status`, prints `{schedule, channel, lastAttemptAt, lastSentAt, lastDelivery, lastRefusal, attemptedBy}`: when it was last tried, whom it reached through which relay, or why not.
  • Oko's service logs `serve: operator update sent: <delivery>` or `serve: the operator update refused: <cause>` and does not try again before the next period, so a refusal stands in `--status` until it is fixed. Only the service launchd starts as the declared unit (serve.json service, read from XPC_SERVICE_NAME) sends it; any other `oko serve`, such as one a test starts on the operator's home, logs `serve: this service is not the declared unit, so the operator's hourly update is left to the unit` once at its start and never writes to the operator.
  • Oko Desktop's Requests screen shows the same record under Hourly update, with the update as it would go out and Send it now; the iMessage handle and relay are set beside it under iMessage from Oko itself.

Refusals and safe exits#

  • `<email> did not choose imessage with `oko contact set`, so the update reaches nobody; `oko contact set imessage …` chooses it`, kept as the last refusal.
  • The `imessage` channel's own refusals: the missing handle, Ultrareach address or sender, each naming the Oko Desktop setting that supplies it; the Ultrareach token not readable from Skarbiec; Ultrareach's own status and body.
  • `oko asks update takes only flags; …` (exit 2).

CLI reference#