Dentolize · Sandbox Command & Registry Walkthrough
On this pageWhy this mattersRisk profileWhat to watch after merge

For Stakeholders

Why this matters

This PR is a developer-velocity investment, not a product feature. It removes two pieces of review friction that #428 (auto-created PR sandboxes) didn't fully solve:

  • Discoverability of control: managing a sandbox (redeploy, destroy,

reseed, reset data) used to require knowing an internal convention (a PR description block) or navigating to the Actions tab and picking the right branch by hand. Now it's a one-line PR comment, visible in the same place the review conversation already happens.

  • Visibility of state: there was no single answer to "what sandboxes are

currently running." A pinned, self-updating issue now answers that continuously, refreshed after every relevant deploy/teardown and every 30 minutes as a backstop.

Faster, lower-friction review cycles compound — every PR that gets reviewed sooner is a feature or fix that ships sooner. This is a small mechanism, but it removes a repeated tax on every single pull request.

Risk profile

This is entirely internal tooling — it does not touch the Dentolize application, its data model, or anything customer-facing. The main risks are operational, scoped to the CI/review process itself:

  • Access control: /sandbox is gated on GitHub's own

author_association (OWNER/MEMBER/COLLABORATOR) — non-members can't trigger it. This can't be spoofed via comment content since GitHub computes the association server-side.

  • Credential handling: dispatching Sandbox Ops requires a persisted

personal access token on the runner host (the default Actions token can't start a workflow_dispatch). That token lives outside this repo (/opt/homelab/sandbox/qa-agent/gh-token) and isn't covered by this PR's diff — its scope and rotation policy should be confirmed with whoever manages the homelab runner, not assumed from this change.

  • Blast radius of a mistake: the worst case for either workflow is a

wrong/stale sandbox or a stuck registry issue — inconvenient for reviewers, not a production incident. Neither workflow has write access to production infrastructure.

What to watch after merge

  • Whether /sandbox actually gets used vs. the old PR-body/Actions-tab

flow — this is worth a quick informal check-in with the team a few weeks out.

  • Whether the pinned issue slot conflicts with other pinned issues (GitHub

caps pins at 3 per repo); if the registry issue keeps getting bumped, that needs a manual decision about what stays pinned.