Mirrors RunicGateway/website's pr-checks.yml, since this module is two npm
packages shaped like that repo's server/ and client/ and is loaded into that
repo's process: same Node 20, same npm ci + test + build, same concurrency
cancel and the same `PR Checks / *` status pattern for branch protection.
The repo has no module code yet — the API contract is settled in Phase 1 and
Phase 3 is what extracts the UO half of website/ into here — so each half's
gates are conditional on its package.json existing. Before the code lands the
jobs report green with a notice explaining why; the moment a package.json
appears they arm themselves with no edit to this file. That is the same guard
the installer repo used through its own planning phase, and it beats both
alternatives: leaving the repo ungated, or red-Xing every governance PR.
Landing it now also gets the status contexts reported once, which is what makes
them selectable when the `main` branch-protection rule is configured.
Deliberately not here yet, because there is nothing for them to act on until
Phase 3: the release workflow that publishes module-uo-<version>.tar.gz and its
sha256, the zero-internal-imports check, and the module's own frozen route
manifest. Each lands with the code it checks.
Co-Authored-By: Claude <noreply@anthropic.com>
First commit for the UO module — the game-specific half of the Runic Gateway
website, extracted from core so that core can become game-agnostic. Phase 0 of
the module system plan (docs/website/MODULE_SYSTEM.md §2.7) calls for this repo
to get its initial commit before any module work starts.
Governance scaffolding only; no module code. The design of record settles the
API surface in Phase 1 and Phase 3 is what fills the repo, so writing module
code now would be writing against a contract that does not exist yet.
- README.md what module-uo is, the phase table, the packaging layout,
and why an operator never builds anything
- CONTRIBUTING.md planning status, the dev loop (a module is not runnable on
its own), the zero-internal-imports and one-path-segment
rules, schema fragments instead of migrations
- SECURITY.md private reporting, plus the module-specific notes: the
module boundary is not a security boundary, access control
lives in core, and the uo-link token stays write-only
- CODE_OF_CONDUCT.md, CONTRIBUTORS.md, LICENSE.md (GPL-3.0-or-later),
PR + issue templates — the same set every repo in the org carries
- .gitignore Node-shaped; client/dist/ is ignored deliberately, since it
is a release artifact built by CI, not a source artifact
CI lands next, in a PR, mirroring how the installer repo was bootstrapped: an
empty repo cannot take a pull request, but everything after it can.
Co-Authored-By: Claude <noreply@anthropic.com>
