Skip to content

Operator inbox

Since 2026-10-03, everything that waits on the operator goes to the private repo dashecorp/operator-inbox: credentials, decisions, approvals and setup steps. The operator's words: "If you have things waiting for me I want a notification and descriptions in rig cockpit". The operator often works from the phone, and chat text gets lost.

How it reaches the operator

  1. An agent files one issue per action in dashecorp/operator-inbox.
  2. The repo's signed issues webhook goes to Rig Cockpit's /v1/github/inbox (dashecorp/infra#585; see Networking).
  3. Rig Cockpit sends a push and lists the issue under "Waiting for you":
  4. on the web (rig-cockpit-worker #282/#283; API GET /v1/operator/requests, operator-only);
  5. on the native iOS app's Rig tab (rig-cockpit-ios #131/#132), from build 15 on TestFlight Internal Testers. The operator confirmed on 2026-10-03 that the list shows.

Rig Cockpit can't push yet. It needs the APNs key, requested in operator-inbox #5 (see Credentials). Until then, the push code posts to Discord #admin instead. Never write "wait for the Cockpit push": send the link in chat and as an issue comment. That includes the approval link for a credential-ops run, such as C2.

The intake doesn't backfill. It reads webhooks only, so an issue filed before the intake shipped never appears.

A run waiting on an environment such as credential-ops comes in another way, through the approvals banner and push (/v1/github/waiting). Phase 2 adds Face ID approvals (rig-cockpit-worker#268).

Writing an issue: phone-first

The operator reads items on the phone, often away from the desk. On 2026-10-04 they said: "And i think the instructions are hard to follow". Operator-inbox #1 is the model. Never show something that looks interactive but isn't.

  • Title: a machine tag, then what is needed. The tag is one of [MacBook Air], [Mac Mini], [Both Macs], [Phone] or [Any device]. The operator asked for it on 2026-10-06: "Can you update inbox so it say if it is for mac mini or for mac air". Example: [MacBook Air] Upgrade sops to 3.13.3 and pin it (Terminal, 1 min).
  • Mac Mini: it sits in Ålesund, so any hands-on step there means Screen Sharing. Prefer the MacBook Air when either Mac would do.
  • [Mac Mini] on a yes/no: a question about the Mac Mini that can be answered anywhere still gets [Mac Mini], plus "answer anywhere".
  • First line: **Priority N** · <why, in a few words>. Re-rank the others when an item is added or closed. Rig Cockpit sorts on that prefix only at the very start of the body (PRIORITY_SQL in rig-cockpit-worker src/handlers/operator-inbox.js), so nothing may go before it.
  • Second line: **Where:** <machine, and in what: Terminal, a browser, Safari>. Also say what isn't needed, for example "Nothing on the Mac Mini". An item with no priority puts the Where line first.
  • A one-line intro: how long it takes and what it unlocks.
  • Three to five steps, as a GitHub task list, each with a verb-first title. Under each step, indent numbered sub-steps by 2 spaces, one action per line: 
    - [ ] **Step 1 · Make a token**
  1. https://github.com/… (the exact page, as a bare URL)
  2. Expiration: `No expiration`
- [ ] **Step 2 · …**
  • The link comes first. Exact values go in code, so they can be copied.
  • Decide every choice in advance, and keep jargon out of the steps.
  • One line on what happens next: if the agent is watching for the result, say there's no need to report back. Otherwise, say how to report it.
  • A --- line, then the background: Why, How I verify, Safety. The app collapses this part under Details.
  • Never ask for a secret anywhere but the GitHub secret page.
  • Chat stays short: the link, the action, the value.
  • Close the issue only after verifying the result, for example that the secret name now exists. Then mention it in chat.

The planner triages inbox issues, because rig-conductor doesn't honor rig-ignore yet (rig-conductor#2628). If it adds agent-ready, remove the label and comment.

Tappable steps and the Done button

Steps are tappable. The Worker's tracked steps are live: rig-cockpit-worker#285, deployed 2026-10-04, stores ticks in D1 (POST /v1/operator/requests/{n}/steps/{i}) and posts to Discord when every step is ticked. The app shows them with rig-cockpit-ios#134 and #137 (TestFlight build of 2026-10-04), and rig-cockpit-ios#139 adds the phone-first layout: step cards, tap-to-copy code, and everything after --- under Details. The operator ticks steps in the app. An agent ticks a box on GitHub after verifying that step itself, and the webhook shows it as done.

The Done button (rig-cockpit-worker#287, rig-cockpit-ios#137) lets the operator say an item is done, with an optional note and Undo. Done is a signal, never an approval: the agent verifies the result, then closes the issue. - The note rejects anything that looks like a secret. - A Done is stored in the Worker's database. The Worker comments on the GitHub issue only when INBOX_COMMENT_TOKEN is set, and no Rig Cockpit post has reached Discord #admin yet (2026-10-05). - The comment token is set (2026-10-06), and the Worker was redeployed with it (Credentials). The end-to-end test is pending: the operator's Done on operator-inbox #9. Until it passes, results go in GitHub comments, as each item says.

The priority sort is live (rig-cockpit-worker#293, merged at 16:05Z on 2026-10-04). The Worker orders items by their **Priority N** line, and the web list adds a "Next" tag. The iOS app keeps the Worker's order. Editing an item no longer moves it to the top.

Face ID approvals (phase 2)

The code is merged, and nothing is deployed. All 13 PRs are on dashecorp/rig-approve: the page track (#8, #9, #10, #17, #18) and the updater track (#19–#26). Five rounds of independent review approved them, and 121 of 121 tests pass locally. The deferred low findings are rig-approve#27. Approve stays hidden while the registry's pins are zero, until docs/pin-filling.md is satisfied.

Go-live waits on three things: 1. operator-inbox #6: iCloud Keychain off on the agent Macs. Both reviewers found that turning it off is the only fix that covers the page, the updater and the Cloudflare login. The answer then sets KEY_MODE in a one-line commit: 'synced-passkey' if it's off, or 'security-key' plus a hardware key if it stays on. That makes a new reviewed blob with a new SHA-256. 2. rig-gitops#909: C2 hardening for the pin-filling checklist. It pins the trusted checkout to github.sha with a guard, validates target_branch early in a job with no environment, and adds run-name, sops --config and a live display_title test. 3. The operator's phone install, filed as an inbox task list after #6. The steps: create the isolated Cloudflare account and its login, make the CF_API_TOKEN, paste updater.js, enroll the updater, mint the page code, deploy, enroll the page with the PAT and passphrase, and fill the pins per the checklist.

Check updater.js before pasting it. On the phone, use a Shortcut to check the file against the reviewed values:

Value
File updater/updater.js on rig-approve main, 1,085 lines
Git blob 28adb89e5038c95a10f6ab3150b736a811b69280
SHA-256 bc749de8f5a41a0f5955ed4973cfb8ec46ffe7e5e7d6ae4f8a14014f2cdefbd1

Open items (2026-10-07)

Closed: - 2026-10-07: #22, the C2 run for tgc-play, approved. #23, the node:24.21.0-trixie-slim review, approved. #20 (TGC hosting), #19 (round rules) and #18 (how PR #34 gets reviewed) were answered. - #7, the C6 Dell pre-checks. All seven passed. The orchestrator ran them from the Mac Mini after dashecorp/infra#604 gave it Dell access, and rig-gitops#913 (PR-11) then merged. - Earlier: #8, decision 4 on the tripwires, answered YES (Rig autonomy level); #1, the GHCR token; and #10, package access for the parity proof (CI/CD).

Every open item's title now starts with its machine tag.

# Tag Item Done when
24 [MacBook Air] Priority 1. C0 for GHCR PR-6: one read-only gcloud compute ssh command, run on the MacBook Air The orchestrator marks rig-gitops#939 ready
25 [Any device] Yes/no: read-only access to the GCP rig cluster for claude-3, a new credential needing a standing OK The operator answers
26 [Mac Mini] Yes/no: is OrbStack, running as claude on the Mac Mini, intentional? It isn't an approved tool; colima is The operator answers
27 [Any device] How Mermaid on the public docs site gets reviewed and registered: review then register (recommended), bundle via npm, or leave it pinned The operator picks one
9 [Phone] The Done test: the comment token is set, so tap Done The operator's Done on #9 arrives as a GitHub comment
5 [MacBook Air] The APNs secrets, for pushes A test push arrives
6 [Both Macs] iCloud Keychain sync off: the MacBook Air, and the Mac Mini if its post user is signed in (or keep it on) The MacBook's KEYCHAIN_SYNC flag reads off, plus the operator's comment for the Mac Mini
4 [Mac Mini] Yes/no: is the age key in the Mac Mini's claude home intentional? The operator answers
2 [Any device] O1, the Cloudflare permission for the R2 tokens P1b's plan passes
3 [MacBook Air] sops 3.13.3, pinned sops --version and brew list --pinned
11–16, 21 [Any device], except #15 [MacBook Air] and #21 [Mac Mini] TAGS GONE CRAZY owner items, filed by the claude-4 session: trademarks, the Unity org, the developer-account entity, the playtest panel, Unity Hub, the LiteNetLib review plan, and how game PR #34 gets reviewed See each item