Context
The harness enforces gates locally — settings.json hooks + gate.sh, plus the orchestrator running them before it opens a PR. But nothing enforces gates at the GitHub PR level: the template ships no .github/workflows/. Downstream (reDeploy), a PR merged with an empty status-check rollup — the only thing between a red gate and main was the orchestrator remembering to run gate.sh.
A feature comparison with emdash sharpened why this matters: emdash treats GitHub Actions as the source of truth for pre-merge checks — it only monitors check runs (docs), it doesn't run them. Any visual front-end that sits on top of this harness will expect server-side checks to exist.
Suggestion
Ship a generated .github/workflows/gates.yml (plus a PROMPTS.md entry to draft it from gates.json) that runs each gate (build / lint / typecheck / test / coverage) on pull_request, mirroring the local gate commands, so:
- merges are gated server-side, not only by an agent's diligence;
coverage_threshold is enforced in CI;- visual front-ends (emdash et al.) can surface pass/fail.
Keep it adapter-driven: generate the job matrix from gates.json modules so it stays a ~config edit, not hand-maintained YAML. Document branch protection (required checks) as the enforcement teeth.
Surfaced by a feature comparison with emdash while driving the template downstream (reDeploy).
Context
The harness enforces gates locally —
settings.jsonhooks +gate.sh, plus the orchestrator running them before it opens a PR. But nothing enforces gates at the GitHub PR level: the template ships no.github/workflows/. Downstream (reDeploy), a PR merged with an empty status-check rollup — the only thing between a red gate andmainwas the orchestrator remembering to rungate.sh.A feature comparison with emdash sharpened why this matters: emdash treats GitHub Actions as the source of truth for pre-merge checks — it only monitors check runs (docs), it doesn't run them. Any visual front-end that sits on top of this harness will expect server-side checks to exist.
Suggestion
Ship a generated
.github/workflows/gates.yml(plus aPROMPTS.mdentry to draft it fromgates.json) that runs each gate (build/lint/typecheck/test/coverage) onpull_request, mirroring the local gate commands, so:coverage_thresholdis enforced in CI;Keep it adapter-driven: generate the job matrix from
gates.jsonmodulesso it stays a ~config edit, not hand-maintained YAML. Document branch protection (required checks) as the enforcement teeth.Surfaced by a feature comparison with emdash while driving the template downstream (reDeploy).