'test ${PIPESTATUS[0]} -eq 0' sends a literal backslash to bash, which
escapes the dollar sign and prevents variable expansion — test receives the
string '${PIPESTATUS[0]}' instead of an integer, causing exit code 2.
Fix: remove the backslash so bash expands PIPESTATUS correctly.
Two safety nets to prevent rsync --delete wiping the wrong directory:
1. Pre-deploy: verify destination/style.css exists (proves it's a theme dir)
2. Post-deploy: compare active plugin count before and after — fail if any dropped
Addresses root cause of 2026-04-23 theme deploy incident.
The peptide-starter-theme v1.5.2 release added
peptide_starter_is_cloudflare_peer() — a CF-peer IP validator that
correctly rejects direct-to-origin requests as non-Cloudflare traffic
with HTTP 403. The deploy workflow's post-deploy health check makes
exactly such a request from a GHA runner IP, so it now reliably
receives 403 even on successful deploys.
Two deploys today (peptide-starter-theme v1.5.2, prautoblogger Commit 1a)
both succeeded but reported workflow failure due to this. The actual
deploys (rsync + cache purge) ran clean; site verified HTTP 200 from
real traffic both times.
Fix: accept either 200 (normal healthy response) or 403 (validator
actively rejecting non-CF origin — itself a positive liveness signal)
in the health check. Reject only on 5xx, 4xx-other, or connection
failure.
Reverting this fix is correct only if we either (a) bypass the
validator for our own health-check user-agent, or (b) route the
health check through Cloudflare. Both are larger changes for a
later release.
Agent-Session: cowork-deploy-healthcheck-fix-20260415
Co-authored-by: peptiderepo <peptiderepo@users.noreply.github.com>
* ci: post CTO review as COMMENT instead of APPROVE
GITHUB_TOKEN cannot formally approve PRs without a repo setting toggle.
Verdict is still prominent in the first line of the review body, and
the human merges based on reading it — no behavior loss.
Agent-Session: cowork-reviewer-fix-20260414
* fix(ci): ssh-keyscan failure no longer fails the deploy
ssh-keyscan was being called with set -e in effect and stderr suppressed,
so a single keyscan failure killed the entire deploy with no diagnostic
output. Since rsync/ssh use StrictHostKeyChecking=no, the known_hosts
entry is not load-bearing — making the keyscan best-effort is safe.
stderr is now captured to /tmp/keyscan.err and emitted as a warning so
future failures are debuggable.
Agent-Session: cowork-deploy-fix-20260414
The CI was overriding the project PHPCS config by passing
--standard=WordPress-Core directly. Now uses the project
.phpcs.xml.dist which includes exclusions for standard WP
patterns (class in functions.php).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
