For Quality

Both workflows are GitHub Actions YAML with inline github-script — there's no unit test suite in this repo for them. Verification is necessarily a mix of static review and live behavior on real PRs/issues. The PR description claims "Both YAMLs valid; /sandbox command-parsing + permission gate reviewed; registry JSON live-tested; registry table rendering unit-tested against real data" — the table-rendering unit test isn't part of this repo's diff (it exercises the host-side sandbox registry CLI), so its claim can't be independently verified from /work/repo.

/sandbox — things worth testing on a real PR

• Permission gate correctness: comment as a non-member (e.g. a

first-time external contributor) and confirm a silent 👎, not a dispatch — sandbox-command.yml:56-61. Also confirm a member-association comment does dispatch.

• Command aliasing: every alias in the map (create, deploy,

redeploy, up → redeploy; down → destroy; reset → reset-data; update-docs → same as docs) resolves to the action it's supposed to — sandbox-command.yml:66-72. Easy to typo one of these during a future edit without a test catching it.

• Unknown command handling: /sandbox banana should react 😕 and reply

with the usage hint, not silently no-op or error — sandbox-command.yml:74-82.

• Extra whitespace / arguments: the parser only reads

body.trim().split(/\s+/)[1] — confirm leading/trailing whitespace and trailing extra words (e.g. /sandbox destroy now please) behave as expected (extra words after the first argument are currently ignored, not rejected).

• No open PR on the branch: pulls.get assumes the comment is on an

actual pull request (guarded by the job's if:), so this should always resolve — but worth confirming behavior if a PR is converted from a draft or the branch was force-pushed/deleted mid-dispatch.

• Dispatch failure path: simulate a bad token or wrong workflow filename

and confirm the 👎 reaction, the truncated error reply, and core.setFailed all fire (sandbox-command.yml:105-111) — this path is easy to leave broken since it only triggers on infrastructure failure, not normal use.

Registry — things worth testing

• Upsert correctness: run the registry workflow twice in a row and

confirm it updates the same issue (matched by the <!-- sandbox-registry --> marker in the body) rather than creating a duplicate — sandbox-registry.yml:93-106.

• Empty state: when zero sandboxes are live, confirm the issue renders

"_No sandboxes are currently live._" instead of an empty/broken table (sandbox-registry.yml:80-86).

• PR-branch mismatch: a sandbox whose branch has no matching open PR

(closed, merged, or the main demo branch) should render — or _demo_ respectively, not a broken link (sandbox-registry.yml:63).

• Pin-limit edge case: with 3 issues already pinned elsewhere in the

repo, confirm the workflow logs and continues rather than failing the run (sandbox-registry.yml:108-116) — and separately confirm the content update still happens even when the pin attempt fails.

• Status mapping default: confirm any CLI status value other than the

literal string "running" renders as ⏸️ parked rather than throwing (sandbox-registry.yml:59) — this is a silent default, worth knowing if the CLI ever adds a third status.

• Time formatting boundaries: spot-check ago() around the 1-hour and

24-hour boundaries (sandbox-registry.yml:52-58) for off-by-one issues.

Out of scope for this repo's test surface

The sandbox registry CLI subcommand that produces the JSON this workflow consumes lives on the homelab runner host, not in /work/repo. Any test of its actual output shape, docker ps integration, or state-file parsing has to happen against that host — it's not reachable from this repository's CI or code review.