fix(ci): remove validate from testing branch protection to unblock sync (#1014)

* fix(ci): remove validate from testing branch protection to unblock sync

The validate job in build.yml only fires on pull_request events. A direct
push from sync-main-to-testing never triggers it, so the required status
check could never be satisfied — GITHUB_TOKEN is always rejected by the
protected branch rule.

PRs to testing still run validate before entering the merge queue. Removing
the branch-level requirement adds no risk and unblocks the automated
post-promotion sync needed for Tuesday releases.

Assisted-by: Claude Sonnet 4.6 via GitHub Copilot

* docs(skills): fix sync lesson — testing is loose integration branch, no PR CI gate

The initial entry incorrectly claimed PRs to testing are gated by validate
before merge queue entry. In reality, without a required status check on
testing, gh pr merge --auto fails and pr-triage falls back to direct squash
immediately. PRs merge to testing without waiting for CI.

Update ci-reference.md lesson to describe the actual tradeoff accurately.
Update pr-review.md to clarify validate+e2e are required on main only.

Assisted-by: Claude Sonnet 4.6 via GitHub Copilot

Author: castrojo

.github/workflows/sync-main-to-testing.yml

@@ -5,8 +5,10 @@ name: Sync main → testing
 # main back into testing automatically so the next promotion PR is not blocked.
 #
 # Reusable logic lives in projectbluefin/actions. This is a thin caller.
-# No GitHub App token needed — GITHUB_TOKEN can push to testing (same as the
-# promote job in publish.yml which already fast-forwards testing directly).
+# No GitHub App token needed: testing branch protection has no required status
+# checks for direct pushes. The `validate` job only runs on pull_request events
+# and must NOT be a required status check on testing — it would block every
+# direct push including this sync (no PATs or bypasses allowed).
 
 on:
   push:

docs/skills/ci-reference.md

@@ -1833,3 +1833,25 @@ a synchronous kernel scan — nodes are ready immediately.
 **Note:** The boot-check gate never passed from PR #849 (2026-06-13) through
 PR #895 (2026-06-16) due to iterating on the wrong approach. The fix was
 always to use `--via-loopback` as documented. The image works on real hardware.
+
+### sync-main-to-testing fails: `validate` required status check blocks direct push (2026-06-21)
+
+**Symptom:** `Sync main → testing` workflow fails with:
+```
+remote: error: GH006: Protected branch update failed for refs/heads/testing.
+remote: - Required status check "validate" is expected.
+```
+
+**Root cause:** The `validate` job in `build.yml` only runs on `pull_request` events. A direct push from the sync workflow never triggers it, so the required status check can never be satisfied — GITHUB_TOKEN is always rejected.
+
+**Fix:** Remove `validate` from `testing` branch required status checks:
+```bash
+gh api /repos/projectbluefin/dakota/branches/testing/protection/required_status_checks \
+  -X PATCH --input - <<'PAYLOAD'
+{"strict": false, "contexts": []}
+PAYLOAD
+```
+
+**Why this is safe:** `testing` is a loose integration branch — not a stability gate. PRs to testing still trigger the `validate` job (visible as an informational PR check), but without a required status check, `gh pr merge --auto` fails and pr-triage falls back to a direct squash merge immediately. PRs merge to testing without waiting for CI. The real quality gates are (a) at `main` where `validate` IS required, and (b) at the `production` Environment requiring 2 distinct human approvals. Removing `validate` from `testing` branch protection trades PR-time CI enforcement on the integration branch for a working automated sync.
+
+**Do NOT add PATs or tokens to the sync workflow — banned.** Fix is always at the branch protection level.

docs/skills/pr-review.md

@@ -37,7 +37,7 @@ Use when asked to review any Dakota PR, including feature PRs, dep-update PRs, o
 
 1. **Branch hygiene** — PR must branch from `upstream/main`, not a fork's local `main`. Verify with `git diff upstream/main...HEAD --stat` — it should be minimal and contain only the PR's changes.
 2. **Checklist compliance** — verify the relevant items from `pr-checklist.md` for the type of change (junction bump, patch, OCI, element, etc.).
-3. **CI gate status** — `validate` and `e2e` are required status checks. If CI hasn't run, note it. If `e2e` was skipped (non-image paths), that counts as passing.
+3. **CI gate status** — `validate` and `e2e` are required status checks on `main`. PRs targeting `testing` have no required status checks (testing is a loose integration branch; the quality gate is at `main` + `production` Environment). If CI hasn't run on a main-targeting PR, note it. If `e2e` was skipped (non-image paths), that counts as passing.
 4. **Scope discipline** — one logical change per PR. Junction bumps must not include patch modifications in the same commit.
 5. **Correctness** — element syntax, layer kind (`compose` not `stack`), cargo sources generated not hand-written, systemd units enabled via BST install commands.