[Sulstice]

@nadernik — this is how changes now reach the sandbox.

Problem

sandbox-qa.yml was manual-only, so a change (e.g. the SFN 2026 posters/talks feature) landed in dev without ever being built into sandbox.brain-bbqs.org.

What changes

A push to dev (i.e. merging a PR into dev) now automatically runs:

1. Build + publish — builds the new code against the sandbox Supabase project and publishes it to brain-bbqs/bbqs-app-sandbox (served at sandbox.brain-bbqs.org).
2. Smoke QA — deploys edge functions to the sandbox project (this includes sfn-2026-presentations), waits for Pages to serve the new build, then runs the Playwright smoke suite.

Stages 1–3 (prod schema drift check, approval gate, schema + data clone from production) stay manual (workflow_dispatch): they copy real data and stop on drift, so they should not run on every push.

How it works

• verify-prod, approve, sandbox are gated on workflow_dispatch.
• build-deploy runs when sandbox succeeded or was skipped (a failed/cancelled clone still blocks it).
• deploy_pages / run_smoke default to on for push events, which carry no inputs.

Caveats

• Migrations only reach the sandbox schema when someone dispatches the workflow manually after applying them.
• This triggers on merge into dev, not on the PR itself. Building PRs into the sandbox would need a decision on whether PR builds may overwrite the single sandbox site.
• Untested: the workflow can only run once it is on dev. YAML parses and npm run test:guards passes (52/0).

---

Generated by Claude Code

[github-actions]

🤖 Triage: Class C → spec:C

Touches a danger layer. Requires Spec Kit artifacts (spec/plan/tasks/qa-itinerary), a Constitution Check, and human sign-off. Never auto-merges.

Blast radius: HIGH

• ci-workflow: CI/CD workflow — this is the pipeline that ships everything else, including this gate.

Complexity: LOW

• 1 files, 25 lines — within Class-A limits.

Files that set the class:

• .github/workflows/sandbox-qa.yml → ci-workflow (hard)

_{Deterministic classifier — computed from the diff, not from the issue text. Change the rules in scripts/triage/classify.mjs (itself a Class-C path).}

[github-actions]

🛑 Class C — this touches a danger layer

Per the constitution (Development Workflow) danger-layer changes are spec-driven. Before this can merge, a maintainer must:

1. Create the Spec Kit artifacts in bbqs-agent/specs/<NNN-feature>/ — spec.md, plan.md (with a Constitution Check), tasks.md, qa-itinerary.md.
2. Point bbqs-agent/.specify/feature.json at that directory.
3. Run the Find → Fix → Test → Verify-Live loop, incl. the sandbox QA workflow.
4. Add the spec-signoff label to this PR to release the triage/spec-gate check.

This gate is here because a small-looking diff to .github/workflows/sandbox-qa.yml reaches far beyond the file it edits.

[nadernik]

@Sulstice I reviewed the push path. On a push it stays off production: the build resolves the sandbox key or stops, it publishes only to bbqs-app-sandbox with the sandbox CNAME, the stages that read production stay manual, and the smoke run invokes only the read-only functions.

Before merging:

1. Manual runs lose their gate. build-deploy now runs when sandbox is skipped. On a manual run, sandbox is also reported as skipped when verify-prod stops on drift or the approval is rejected, because a job whose needs failed is skipped. So a run that should stop still builds and publishes. Accept skipped only on a push:

   if: ${{ !cancelled() && (needs.sandbox.result == 'success' || (github.event_name == 'push' && needs.sandbox.result == 'skipped')) }}

2. continue-on-error: ${{ inputs.smoke_soft_fail }} has no inputs on a push. ${{ inputs.smoke_soft_fail == true }} is a boolean either way.
3. A guard against the production ref. The build and the function deploy both take vars.SANDBOX_PROJECT_REF. A check at the top of resolve-sandbox-api-key.sh that fails when it equals vpexxhfpvghlejljwpvt makes a mis-set variable stop the run instead of deploying functions to production.
4. One green manual run on dev first. The last manual runs on dev failed (2026-08-13), and the last success was 2026-08-19 on another branch, so the sandbox schema and data are about two months behind. The file's own note was to add the push trigger once the manual loop is green.

Smaller:

• Each push force-pushes the dev tree to the sandbox repo's main, since SANDBOX_SOURCE_BRANCH defaults to main. ${{ github.ref_name }} would keep the branch names accurate.
• The description says the smoke run includes sfn-2026-presentations. It is deployed but isn't in SAFE_FUNCTIONS, so it's never invoked.

One thing to confirm before this runs on every push: the sandbox project's edge-function secrets (email, Google) must not be production's. Every dev push would deploy the newest functions there, against a copy of member data.