operator-inbox

Operator Inbox

Maintain a durable action queue without turning a connector into the owner of operator state.

The caller fetches bounded, grant-authorized provider pages and passes their normalized observations to this skill. The skill owns work-item identity, status, dispositions, replay suppression, reopen rules, and scan coverage. Every read and write is composed through data-store; the skill does not call Slack, SQLite, Postgres, or another provider directly.

Composes

• data-store#append_event
• data-store#list_stream_heads
• data-store#read_events

What this skill does

Use local://runx/operator-inbox/default unless the operator selects another logical source. Unbound local refs resolve to SQLite under .runx/data/local-sources/. A hosted database is opt-in through the same data_source_ref binding. Runx Connect may still own OAuth, grants, and provider execution; that does not move this queue into the hosted control plane.

Observations and resumable checkpoints live in operator_inbox_scans, partitioned by query digest. Action snapshots live in operator_inbox_actions, with one stream per stable thread digest. Queue reads use bounded list_stream_heads pages; no command folds or transports the complete queue.

Direct invocation defaults to a bounded list_actions read against that local source. To record a disposition or provider observation, select the exact write runner; composed graphs can pass the prior action packet without re-reading or re-fetching provider data.

When to use this skill

• Build or revisit a local action queue from bounded connector observations.
• Preserve an explicit resolved, dismissed, waiting, or followed_up decision across repeated provider scans.
• Reopen a completed item when a newer external occurrence arrives.
• Inspect bounded action or scan state without handing queue ownership to the provider or hosted control plane.