feat: adapter-driven CI workflow that runs gates.json gates on PRs (#8)

[robercano]

Sub-task

Ship a CI workflow that runs the gates.json gates on PRs — server-side gate enforcement (issue #8).

What changed

• .github/workflows/gates.yml — runs on pull_request (+ workflow_dispatch). One matrix job per gate (build/lint/typecheck/test/coverage/security) so each surfaces as its own PR check (what visual front-ends like emdash monitor). Each job just runs bash .claude/scripts/gate.sh <name>, which reads the command from gates.json and skips empties — so it's fully adapter-driven, no hand-maintained YAML per downstream repo. fail-fast: false + per-ref concurrency cancel.
• .github/actions/setup/action.yml — composite action driven by gates.json (project.packageManager / language / coverage_threshold). Sets up the JS/TS toolchain (the common case), runs the install gate, exports COVERAGE_THRESHOLD to env, and leaves a clearly-marked extension point for other stacks (Foundry/Python examples inline) — the seam to Per-worktree setup/teardown lifecycle hooks so isolated workers can run all gates #9 (per-worktree lifecycle).
• docs/GETTING_STARTED.md — new "Step 7 — Enforce gates in CI": branch-protection (required status checks) as the actual enforcement teeth, with a gh api recipe + a checklist item.
• docs/PROMPTS.md — prompt Evaluate an optional visual cockpit (e.g. emdash) as a front-end over the headless pipeline #10 to wire up / adapt CI enforcement.

Why

The harness enforces gates locally (hooks + gate.sh) and the orchestrator runs them before opening a PR — but nothing enforced gates at the GitHub PR level (no .github/workflows/). Downstream (reDeploy), a PR could merge with an empty status-check rollup. Any visual front-end (emdash et al.) also expects server-side checks to exist.

Design notes

• Reuses gate.sh rather than reimplementing gate parsing — same skip-empty semantics as the local hooks, single source of truth.
• Per-gate matrix (not per-module): gate commands in gates.json are repo-global, and one check per gate is what gives front-ends granular pass/fail to surface.
• Required checks (Step 7) are what actually block merge; the workflow alone only reports.

Gates

This is the template repo (no self-gates yet — see #11). Both YAML files validated as well-formed; the workflow path-resolves gate.sh from repo root and node is preinstalled on runners (same dependency gate.sh already has).

Open risks / follow-ups

• Non-JS toolchain setup is an extension point, not shipped wiring (intentional; ties into Per-worktree setup/teardown lifecycle hooks so isolated workers can run all gates #9).
• install runs once per matrix job (separate runners — inherent to matrix parallelism); cache tuning left to downstream.

Closes #8.

🤖 Generated via the multi-agent orchestrator template.

[robercano]

Closing to re-open as the bot machine account so the repo owner can formally review/approve (GitHub blocks PR authors from approving their own PRs). Same branch feat/ci-gates-workflow, identical diff.

[robercano]

Superseded by #13 — reopened from the same branch (feat/ci-gates-workflow, identical diff) authored by the bot machine account so the repo owner can formally review/approve. Please review #13.