For Support

Who actually uses this

This feature's "users" are Dentolize engineers and reviewers, not clinic customers. If a question about /sandbox or "Open sandboxes" ever reaches Support, it's almost certainly from someone internal (a teammate, a contractor doing a review) — not a clinic end user, who has no way to trigger or see any of this.

Questions you might get, and the answers

"I commented /sandbox on my PR and nothing happened." Check comment.author_association — only OWNER, MEMBER, or COLLABORATOR can trigger it (sandbox-command.yml:56-61). Anyone without write access gets a silent 👎 reaction and no reply — that's by design, not a bug. If the commenter does have access and still sees nothing, check whether the comment actually started with /sandbox (leading whitespace or a different first word won't match startsWith, sandbox-command.yml:35).

"It reacted with 😕 instead of doing anything." The sub-command after /sandbox wasn't recognized. The accepted words are: (blank), create, deploy, redeploy, up → redeploy; destroy, down → destroy; reseed; reset-data, reset; docs, update-docs (sandbox-command.yml:66-72). The bot's own reply lists these — point people at that reply first.

"It reacted with 🚀 but no sandbox showed up." 🚀 only means the workflow_dispatch call to Sandbox Ops succeeded (sandbox-command.yml:112-115) — it does not mean the deploy itself finished or succeeded. Check the Sandbox Ops run in the Actions tab for that branch. If it failed there, the sandbox-info PR comment won't appear/update.

"The 'Open sandboxes' issue looks stale / wrong." It refreshes after Sandbox, Sandbox Ops, or the main demo workflow complete, plus every 30 minutes (sandbox-registry.yml:11-17). A brief lag (up to ~30 min) after a park/reap event is expected — that's what the cron schedule is for. If it's been stale much longer than that, check whether the registry workflow itself is failing (Actions tab → "Sandbox Registry").

"I don't see the 🗂 Open sandboxes issue pinned anymore." GitHub allows at most 3 pinned issues per repo. If something else got pinned, this issue could get bumped — the workflow only best-effort attempts to pin and logs (not fails) on error (sandbox-registry.yml:108-116). The issue content itself still updates even if unpinned; check open issues for the 🗂 Open sandboxes title.

What Support cannot fix

The sandbox registry CLI and the persisted GitHub token (/opt/homelab/sandbox/qa-agent/gh-token) both live on the self-hosted runner host, outside this repo. Anything that looks like a problem with the CLI's data (wrong status, missing sandbox) or with authentication (dispatch calls failing with 401/403) needs someone with access to the homelab runner, not a repo-level fix.