Fix the roadmap Liquid error, and make CI build the way Pages does

[kinlane]

What broke

pages-build-deployment has failed on every run since dd997d5 ("Make the roadmap issue-driven", 2026-07-31) — 20+ consecutive failures. spec.spotlight-rules.com has been serving the last good build since then; the Pages API reports "status": "errored".

Rendering: roadmap.md
github-pages 232 | Error: Liquid syntax error (line 155): Expected end_of_string but found id

Why

Pages pins github-pages 232 → Jekyll 3.10. Its where_exp parses exactly one comparison and then demands end-of-string; and/or inside the expression is a Jekyll 4 feature. So roadmap.md:165 —

{% raw %}{% assign live = site.data.roadmap.items | where_exp: "i", "i.deferred == false and i.state == 'open'" %}{% endraw %}

— parses fine locally and blows up in production. Confirmed by running Jekyll 3.10's own parse_condition against each expression:

FAIL : i.deferred == false and i.state == 'open'  ->  Liquid::SyntaxError: Expected end_of_string but found id
OK   : i.state == 'closed'
FAIL : i.deferred and i.state == 'open'           ->  Liquid::SyntaxError: Expected end_of_string but found id

Commit 1 — fix the outage

One comparison per where_exp, chained — exactly what spotlight-rules/roadmap.md already does. Its comment explaining the trap is carried over so the next person doesn't reintroduce it.

Rendering is unchanged. A Jekyll 4 build of the branch puts all 12 open issues in the same buckets as the data: ready [12], consensus [2, 9, 11], discussing [1, 3, 7, 8, 10, 13, 14, 15].

Commit 2 — stop it happening silently again

The reason this ran for a week unnoticed: Gemfile pins jekyll ~> 4.4 and ci.yml ran bundle exec jekyll build, so CI was green through all 20+ Pages failures. The only symptom was a site that stopped updating.

Added a second CI job that builds against .github/Gemfile.pages — the github-pages gem, deliberately unpinned, since tracking whatever Pages currently resolves to is the point. The Jekyll 4 job stays; it's what a local jekyll serve does.

The parity job is self-proving: it resolves github-pages (232), the exact version in the failing production log, and passes only because of commit 1.

GitHub Pages (what actually deploys)   pass   51s
Jekyll 4 (what we develop on)          pass   11s

spotlight-rules had the identical CI blind spot — closed in api-commons/spotlight-rules#8.

🤖 Generated with Claude Code