Decide whether spotlight-validator should be public — its output already is

[kinlane]

api-commons/spotlight-validator holds the 740-rule catalog behind apicommons.org/rules and /rulesets/. It is currently private.

How it got here

The original remote 404'd with no rename redirect — the repo had been removed from the org at some point, and the local working copy was the only copy in existence. It was restored to api-commons/spotlight-validator as private on 2026-08-17, because republishing something that had been deliberately removed is a decision to take on purpose, not a side effect of restoring a backup.

The tension

scripts/generate-spotlight.py in the hub reads ../spotlight-validator/rules/all-rules.yaml to generate _data/spotlight_rules.json, assets/rulesets/*, and the /rules/ and /rulesets/ pages.

So the output is public and the source is private. Anyone can read all 740 rules on the site; nobody outside can see where they come from, propose a fix, or check provenance — in an organization whose entire premise is open, provenanced governance.

The generator now fails loudly with clone instructions if the checkout is missing, so the silent-stale-regeneration failure is closed. But the openness question is not.

The decision

• Make it public — the rules are already public via the site; this just makes their source inspectable and contributable.
• Keep it private — there is a reason it was removed that I do not have.

Related: spotlight-rules (the site), spotlight-spec (the format), spotlight-tools (the linter build) are all public.

[kinlane]

This now has a concrete consequence: the deploy workflow cannot succeed

CI is green on main again after spotlight-validator#11. The deploy workflow is a separate failure, and it has failed on every run since the repo was restored — three for three:

Commit	deploy
294a2eff (the CI fix merge)	failure
ae883875	failure
704398b9 (the RFC 9457 pass)	failure

The build succeeds and uploads its artifact. Deployment is what fails:

Creating Pages deployment with payload: { "artifact_id": ..., "pages_build_version": "294a2eff..." }
##[error]Creating Pages deployment failed
##[error]HttpError: Not Found
##[error]Error: Failed to create deployment (status: 404)

Why

Three facts, each verified:

• GET /repos/api-commons/spotlight-validator/pages → 404. Pages is not enabled.
• The repo is private.
• The api-commons org is on the free plan.

GitHub Pages on a private repo requires Pro/Team/Enterprise. On a free plan, Pages is public-repos-only. So deploy cannot be made to pass while this repo stays private — the workflow is not misconfigured, it is asking for something the current combination does not allow.

This is a consequence of the restore choice. The repo was recreated as private on purpose, because republishing something that had been removed from the org is a decision to take deliberately. That was the right call to leave open — but it has a cost that is now visible in CI.

Which turns this issue into a fork in the road

1. Make it public. Pages works, deploy goes green, and the 740 rules become inspectable at their source — which the site already publishes anyway.
2. Keep it private and remove the deploy workflow, since it can never succeed. The site is generated in the hub from all-rules.yaml, so this repo does not need to publish anything itself.

What should not happen is leaving a workflow that fails on every commit — it trains everyone to ignore red, which is exactly how spotlight-validator#11 sat unnoticed on main for hours.

[kinlane]

Resolved: made public.

Both consequences the issue described are now settled.

What changed

• api-commons/spotlight-validator is public.
• GitHub Pages enabled with build_type: workflow, matching the actions/deploy-pages step the workflow already used. Pages had never been enabled on the restored repo — that 404 was the deployment failure.
• The deploy run that had failed three times for three was re-run: build success, deploy success.
• The validator is live at https://api-commons.github.io/spotlight-validator/ — Spotlight Validator — API Governance Playground, HTTP 200.

main is now green on both workflows for the first time since the repo was restored.

Scanned before publishing

Full history — 64 commits — plus the working tree, for API keys, tokens, private keys and Slack/AWS/Google credential patterns. Clean. The only embedded identifier is a Google Analytics measurement ID (G-YJEJYCXZH3), which is public by design and already visible in the page source of the deployed site.

What this settles

The 740 rules published at apicommons.org/rules now have an inspectable source. Anyone can read rules/all-rules.yaml, see where a rule came from, propose a fix, or check its provenance — which is what an organization premised on open, provenanced governance should allow.

It also removes the split where the output was public and the source was not.