Dentolize · PR Template Sandbox Block Walkthrough
On this pageScopeWhat to testWhat's explicitly not this PR's concern to test

For Quality

Scope

This PR changes exactly one file: .github/PULL_REQUEST_TEMPLATE.md (+20/-0). There is no application code to test — no resolver, no UI, no database migration. Quality work here means verifying the template renders and parses correctly, and that the pre-existing (unmodified) gate/parse/deploy logic in .github/workflows/sandbox.yml still behaves as documented against this new default content. See gate-and-deploy-flow.md and sandbox-settings-block.md for the mechanics being tested below.

What to test

Template content itself

  • Open a new PR against this repo (or preview the raw file) and confirm the

## 🧪 Sandbox section appears after the existing "Other information" line, with a fenced ``` `yaml `` block containing exactly five keys: two_regions, whatsapp, cron, seed, env.IS_SANDBOX`.

  • Confirm the YAML is syntactically valid — paste the block through `yq -p

yaml -o json (the exact converter the workflow uses, sandbox.yml:104-105`) and check it parses without error.

  • Confirm IS_SANDBOX parses to the JSON string "true", not the

boolean true — this is the specific thing the PR description says was verified, since an unquoted true would coerce differently and could break a shell consumer expecting text.

The gate (redeploy trigger) logic — pre-existing, worth a regression pass

  • New PR, template untouched → should deploy (action = opened,

sandbox.yml:70).

  • New commit pushed → should deploy (synchronize).
  • Edit PR title only → should not redeploy (BODY_CHANGED false,

sandbox.yml:72).

  • Edit a paragraph outside the Sandbox block → should not redeploy

(block text unchanged, sandbox.yml:76).

  • Edit a value inside the Sandbox block (e.g. flip whatsapp to

true) → should redeploy (sandbox.yml:74).

  • Delete the entire Sandbox block → should redeploy once (block went

from present to absent, which is a text change), and the resulting deploy should fall back to {} / all defaults (sandbox.yml:106-107).

Edge cases worth deliberately trying

  • Malformed YAML in the block (bad indentation, unclosed quote) — per

sandbox.yml:104-105, this should silently fall back to {} (all defaults) rather than fail the job. Confirm the job doesn't error, and confirm the "🧪 parsed sandbox settings" log group shows {}. Silent-fallback-to-defaults is easy to miss in review; make sure it's actually silent and not a hard failure that would block unrelated PRs. Because this fallback is invisible to the PR author (no comment, no warning, just quietly-ignored settings), consider this the single highest-value regression to actually re-run and confirm.

  • A second, unrelated fenced code block later in the description (e.g.

a bug repro snippet under a different heading) — the awk extractor should not pick it up; it stops at the first ` after the Sandbox heading (sandbox.yml:100-101).

  • A heading containing "sandbox" that isn't the intended one (e.g. "##

Sandbox testing notes" used for something unrelated) — the matcher is a loose case-insensitive substring match on sandbox (sandbox.yml:63/99), so a differently-intentioned heading could be misparsed as the settings block. Worth a deliberate test if this comes up in review.

  • Two ## Sandbox-ish headings in one PR body — extractor takes the

first one found; confirm that matches expectation if this combination is ever produced.

  • two_regions: true on a branch without packages/auth-server — per

the inline comment, this should be a no-op; confirm the deploy doesn't error and doesn't produce regional-only outputs (AUTH_URL, API_ME_URL) on such a branch.

What's explicitly not this PR's concern to test

  • The sandbox CLI's internal handling of each setting

(/opt/homelab/sandbox/bin/sandbox) — it lives outside this repository and isn't part of this diff.

  • Any Dentolize application behavior — nothing here touches

packages/server, packages/prisma, packages/clinic-web, or packages/clinic-mobile.