Walkthrough

This PR's surface is entirely on GitHub — PR comments and a pinned issue — plus one host-side CLI action. There's no Dentolize app screen to click through. What is real and screenshot-able is the sandbox that /sandbox ultimately produces: a live, isolated deployment of the clinic app. The screenshot below was captured from this PR's own sandbox (ci-sandbox-command-and-registry.sandbox.anastawfik.com) to show what a reviewer lands on once /sandbox finishes.

For the GitHub-side surfaces (the comment thread and the pinned issue), the mockups below are reconstructed verbatim from the workflow source — the exact strings the github-script steps build — not simulated screenshots, since this sandbox environment doesn't have a real GitHub repo to comment on.

1. Commenting /sandbox on a PR

A reviewer (or the PR author) comments on the pull request:

/sandbox

sandbox-command.yml wakes up on the issue_comment event, confirms the comment is on a PR and starts with /sandbox (.github/workflows/sandbox-command.yml:33-36), then reacts with 👀 while it works (sandbox-command.yml:62):

🧑‍💻 reviewer commented: /sandbox — 👀 (reaction added by the workflow)

If the commenter isn't a repo member (OWNER/MEMBER/COLLABORATOR), the workflow reacts 👎 instead and stops silently — no reply, no dispatch (sandbox-command.yml:56-61).

2. The command resolves and dispatches

The bare word /sandbox maps to the redeploy action (sandbox-command.yml:66-68), same as /sandbox create, /sandbox deploy, or /sandbox up. The workflow looks up the PR's head branch (sandbox-command.yml:85-86) and fires a workflow_dispatch REST call at Sandbox Ops for that branch with inputs.action = "redeploy" (sandbox-command.yml:92-104). On success it reacts 🚀 and leaves an actions-log notice — it does not post a new PR comment itself:

🧑‍💻 reviewer commented: /sandbox — 🚀 (reaction added once dispatch succeeds)

A minute or two later, Sandbox Ops finishes and posts/updates the usual sandbox-info comment on the same PR (this part is unchanged from #428 — sandbox-ops.yml:188-356), with the web URL, seeded logins, and access credentials. That's the comment that ultimately points a reviewer at a deployed app like the one below.

This is the actual Dentolize dashboard, logged in as the owner seed user on ci-sandbox-command-and-registry.sandbox.anastawfik.com — the same kind of environment a /sandbox comment on a real PR would produce.

3. An unrecognized sub-command

Typing something the command map doesn't know, e.g. /sandbox nuke, gets a 😕 reaction and a help reply instead of a silent failure (sandbox-command.yml:74-82):

🧑‍💻 reviewer commented: /sandbox nuke — 😕 (reaction) 🤖 github-actions replied: 🤖 Unknown /sandbox command. Try: /sandbox (create/redeploy) · /sandbox destroy · /sandbox reseed · /sandbox reset-data · /sandbox docs.

4. The other sub-commands

(Mapping: sandbox-command.yml:66-72; action semantics: sandbox-ops.yml:5-11.)

5. The pinned "🗂 Open sandboxes" issue

Independently of any single command, sandbox-registry.yml keeps one pinned issue current. Reconstructed from the exact body-builder in the workflow (sandbox-registry.yml:69-91):

📌 🗂 Open sandboxes _Every live preview sandbox, auto-updated after each deploy/teardown and every 30 min. 3 total · 2 running._ Sandboxes are created on demand — comment /sandbox on a PR, or run Sandbox Ops → redeploy. They redeploy on new commits and are torn down when the PR closes. | Status | Branch | PR | Web | Commit | Deployed | |---|---|---|---|---|---| | 🟢 running | ci/sandbox-command-and-registry | #429 | open | ecb6da2 | 7h ago | | 🟢 running | feat/x | #431 | open | 57dc633 | 2h ago | | ⏸️ parked | main | _demo_ | open | 1a2b3c4 | 3d ago | ➡️ Teardown candidates (closed PRs) are tracked in the 🧹 Sandbox teardown tracker issue. _Updated: run 123456789_

This issue is created once and then updated in place by matching an HTML comment marker (<!-- sandbox-registry -->) in existing open issues, and pinned via the GraphQL pinIssue mutation (sandbox-registry.yml:93-116).