For Quality

What's actually testable from this repository

The change under test is 12 lines in .github/workflows/sandbox.yml:198-208. Everything downstream of /opt/homelab/sandbox/bin/sandbox-shots (the gate, the agent, the publish step, the comment logic) lives outside this repo and is out of reach for a normal PR review or test run against /work/repo — it can only be exercised by actually running a PR through the real CI pipeline on the host. Keep that boundary in mind when scoping test effort: don't try to unit-test behavior that isn't in this checkout.

What to verify in the workflow YAML itself

• Syntax/lint: the added block is valid YAML nested correctly under

steps: in the deploy job — a GitHub Actions workflow lint or a dry run of the workflow file will catch structural mistakes (bad indentation, wrong run: block) that no code review would.

• No if: regression: confirm this step intentionally lacks the

if: github.event.action == 'opened' guard that the docs-generation step right above it has (.github/workflows/sandbox.yml:189). That's not a copy-paste omission — the PR description explicitly wants this to run on every push, not just PR open — but it's exactly the kind of one-line diff a future edit could silently "fix" by copying the sibling step's guard. Worth a regression check if this file changes again.

• Non-blocking guarantee: confirm || true stays on the invocation. If

it's ever dropped, a transient failure in host-side tooling this repo doesn't control would start failing the Sandbox deploy job for unrelated reasons.

• Token scope: the step declares GITHUB_TOKEN: ${{ github.token }} in

its own env: block, matching the pattern used by the deploy step above it (.github/workflows/sandbox.yml:157) rather than relying on any ambient token — worth confirming this token is used only for posting the comment and not persisted or logged anywhere the step's output is visible.

Edges worth probing once the host-side tool is testable

These can't be checked from /work/repo, but are worth a QA pass against the real pipeline once accessible, since the PR description's claims about them are currently unverified:

• The gate's exact match logic. Does a diff that touches

packages/clinic-web/src/index.html but nothing else in the package still count as "UI changed"? What about a diff that only touches packages/clinic-web/package.json (a dependency bump, no UI code)? The PR description only says "touches packages/clinic-web/" — the granularity of that check determines the false-positive rate for AI spend.

• Comment update-in-place behavior across force-pushes, rebases, and

PRs with a long commit history — does the marker-comment pattern (implied to be the same approach as the existing sandbox-URL comment, .github/workflows/sandbox.yml:460-475) correctly find and update the prior comment every time, or can it ever duplicate?

• Screen-selection quality. Since "which screens are worth a shot" is

an AI judgment call per PR description, not a deterministic mapping — false negatives (a changed screen that doesn't get photographed) are the failure mode most worth sampling for once this runs on real PRs.

• Detached-run failure visibility. Since the step is || true and

detached, a silently-failing agent run currently has no failure signal visible from the GitHub Actions UI at all — worth confirming there's some alerting path on the host side, even if it's outside this repo.

• Mobile flag correctness. Once SHOTS_MOBILE is ever flipped on,

confirm it fails closed (skips mobile screenshots) rather than silently screenshotting production data through the hardcoded API host described in Feature breakdown, rather than the PR's own sandbox.