Relaunch atrinik.org from the standalone MIT website repository

[zoeyrose]

Important

Website source now belongs at the root of the fresh MIT atrinik/website repository on main. The root workspace only registers/builds it as a component; it contains no Astro source.

Replacement implementation contract

Preserve the complete visual, information-architecture, content, accessibility, community, discovery, and deployment design below, with these technical corrections:

• Astro project root is this repository root, not atrinik/website/.
• Production branch is main, with preview deployments for pull requests and an exact Website validation required check after bootstrap.
• Cloudflare Pages ownership, environments, domain/DNS, secrets, health checks, and rollback live here.
• Downloads use immutable release manifests/checksums and clearly distinguish classic GPL packages from fresh MIT replacements throughout coexistence.
• Every visual has source, author, exact license, hash, transformation, attribution, and alt text. An approved MIT provenance grant applies only through the merged grantor registry and complete-history evidence policy in docs: register MIT provenance grantors atrinik#275.
• The website does not become a game account/API/backend or source of protocol/content truth.
• Release/deployment supply-chain evidence, accessibility, security headers, dependency policy, and performance budgets are acceptance gates.

Additional acceptance criteria

• Clean clone builds/deploys without any Atrinik sibling checkout.
• The wrapper invokes published commands/artifacts only and remains thin.
• Broken/missing external release/status data cannot publish misleading links or claims.
• Production deployment and previous-version rollback are rehearsed before DNS cutover.
• The implementation issue links website Bootstrap the MIT Astro website repository and validation contract #1–Harden website accessibility, performance, security, deployment, and rollback #3 and the organization replacement roadmap.

Preserved website product/design specification and historical technical notes

Summary

Relaunch atrinik.org as a small, static-first project website whose source lives in this repository and whose production deployment is hosted for $0 on Cloudflare Pages.

The first release should restore the useful public entry points from the old site—what Atrinik is, screenshots, downloads, getting started, server information, and contribution links—without reviving the old PHP/SMF forum stack. GitHub Releases should remain the source of downloadable binaries, repository documentation should remain the source of developer truth, and the Cloudflare metaserver should remain a separate service.

The recurring hosting cost should be $0 under the current Cloudflare Pages free tier. Domain registration is separate and already exists.

Why this is needed

• README.md still sends users to https://www.atrinik.org/, /page/installing_atrinik_client, and /page/development_join, but the site is unavailable.
• As of 2026-08-05, atrinik.org is already delegated to Cloudflare nameservers, but the apex has no A/AAAA target and www.atrinik.org does not exist in DNS. This makes Cloudflare Pages a low-friction restoration path rather than a DNS-provider migration.
• There is no general website source or website deployment workflow in this repository, and no website repository exists in the atrinik GitHub organization.
• Current releases already contain the artifacts the site should direct people to. For example, v5.0.9 publishes Windows client and server ZIPs through GitHub Releases.
• The project now has active release automation, a Cloudflare metaserver implementation, and a modern browser prototype under next/; the public site should describe these accurately instead of presenting the frozen 4.0-era state.

What the old site contained

An archived capture of the old homepage shows that the SMF-based site combined several different concerns:

• project landing page and feature summary;
• news and release announcements;
• client downloads and checksum/verification pages;
• installation, starter, player, and gameplay guides;
• live server list;
• screenshots/gallery;
• development, programming, map-making, and server documentation;
• forum, calendar, search, contact, and team profiles.

The archive also contains archived routes such as page/installing_atrinik_client.html, page/development_join.html, page/player_guide.html, page/servers_list.html, and about 30 more guide/reference pages.

We should preserve the important user journeys and incoming URLs, not copy the obsolete SMF application, stale account data, old download binaries, or outdated team roster.

Proposed architecture

1. Add an independent website/ component

Create website/ at the repository root, alongside next/ and metaserver/worker/.

Recommended implementation: Astro with static output, TypeScript, and Markdown/MDX content.

Why Astro:

• it produces plain static HTML/CSS/JS and needs no production server;
• it gives multi-page content and reusable layouts without turning the site into another application runtime;
• Markdown is a good fit for guides and makes content reviewable in pull requests;
• it is officially supported by Cloudflare Pages;

Suggested initial structure:

website/
├── public/                 # favicon, social card, approved screenshots/art
├── src/
│   ├── components/
│   ├── content/            # short website-owned guides/content
│   ├── layouts/
│   ├── pages/
│   └── styles/
├── ATTRIBUTION.md
├── package.json
├── package-lock.json
└── astro.config.mjs

Add website/AGENTS.md and a short README covering ownership, local commands, generated dist/, content boundaries, and deployment. Update the owning architecture documentation to list the public-web component and keep website and Worker ownership separate.

2. Ship a focused first information architecture

Initial pages:

• / — concise game pitch, current project/revival status, screenshots, primary download and contribution calls to action;
• /download — supported packages and a prominent link to the latest GitHub release; do not copy 80+ MiB release artifacts into Pages;
• /play — installing/running the native client;
• /servers — how server discovery works and, initially, an honest availability state;
• /about — project history, open-source status, licensing, and acknowledgements;
• /develop — links to the repository, issues, build instructions, architecture guide, map/content contribution paths, and the modern experiment;
• /gallery — a small curated set of current screenshots with alt text and attribution;
• /docs — a navigation page into the owning repository documentation rather than a copied second documentation tree;
• /404.html, robots.txt, and sitemap.xml.

Use GitHub Releases as the source of truth. A stable https://github.com/atrinik/atrinik/releases/latest link is sufficient for the MVP and cannot become stale when a new tag is published. The page must describe only packages that are actually produced; the current release workflow publishes Windows client/server ZIPs, not the old Debian packages advertised by the archived site.

Release notes/news can initially link to GitHub Releases. A custom CMS, accounts, comments, and forum are unnecessary for launch. If the project wants a forum replacement later, enable GitHub Discussions as a separate decision (it is currently disabled) and link to it from the site.

3. Preserve important established URLs

Add Cloudflare Pages _redirects entries for the routes still referenced by the repository and the most valuable archived routes, including both extensionless and .html forms where necessary. At minimum:

/page/installing_atrinik_client*  /download  301
/page/development_join*           /develop   301
/page/development*                /develop   301
/page/player_guide*               /play      301
/page/starter_guide*              /play      301
/page/how_to_play*                /play      301
/page/servers_list*               /servers   301
/page/team*                       /about     301

Map the remaining archived guide URLs deliberately to /docs, a specific current document, or 410 Gone; do not silently send every unknown path to the homepage. Remove or update the dead website links in the root and component READMEs only when the replacement routes are live.

4. Reuse current assets safely

Prefer new screenshots captured from the current client/build over blindly copying the archived gallery. The current repository already contains usable visual material such as client/textures/intro.png, but all reused game art must retain the attribution recorded in nearby LICENSE files.

For every image copied into website/public/:

• record its source path, author, and license in website/ATTRIBUTION.md;
• preserve any required nearby license text;
• optimize a derivative for the web while retaining the authored source elsewhere;
• provide useful alt text (or mark decorative imagery as decorative).

Do not restore archived avatars, team biographies, forum posts, or other personal data as site content without a separate review.

5. Validate in GitHub Actions, deploy through Cloudflare Pages

Add a website CI job that runs from website/ and performs the equivalent of:

npm ci
npm run check
npm run build

It should also run a broken-link check against the built output and git diff --check. Treat website/dist/ as generated and do not commit it.

For deployment, connect the public repository to a Cloudflare Pages project using:

• root directory: website;
• build command: npm ci && npm run build;
• output directory: dist;
• production branch: master;
• preview deployments for pull requests/branches.

Then associate atrinik.org with the Pages project and redirect www.atrinik.org to the apex (or choose www as canonical and redirect the apex, but document one canonical URL). Keep meta.atrinik.org as a separate hostname/Worker route.

Cloudflare currently documents free static asset requests, 500 Pages builds per month and a 25 MiB per-file limit, and custom apex-domain support. Keeping downloadable builds on GitHub Releases avoids the Pages file-size limit and keeps release ownership where it already belongs.

GitHub Pages is a viable fallback for a static project site, but Cloudflare Pages is the recommended target because the domain already uses Cloudflare DNS, the planned metaserver is already a Cloudflare Worker, and Pages leaves room for a narrowly scoped same-origin server-list bridge later.

6. Treat dynamic integrations as follow-up work

Do not block the website launch on the metaserver cutover or the next/ prototype.

A later server-directory slice can consume GET https://meta.atrinik.org/v2/servers, but the current Worker returns XML without browser CORS headers. That follow-up must choose and test one explicit boundary:

1. add a strict allowlist CORS response for read-only server listings; or
2. add a small same-origin Pages Function that proxies/caches the public listing.

The page must retain a graceful unavailable/empty state, and the game client remains the authoritative way to connect.

Delivery plan

Phase 0 — ownership and content inventory

• Confirm who has Cloudflare account access for the existing atrinik.org zone.
• Agree on the canonical hostname (atrinik.org recommended).
• Inventory every current repository link to the old site.
• Map archived routes to new pages, current repository docs, or deliberate retirement.
• Select current screenshots/assets and audit their attribution.

Phase 1 — website MVP

• Scaffold website/ with the component README/AGENTS guidance.
• Implement the initial pages, shared navigation, footer, metadata, 404, sitemap, and redirects.
• Add responsive and keyboard-accessible presentation.
• Link downloads to GitHub Releases and developer content to its repository-owned source.
• Add CI build/check/link validation.

Phase 2 — preview and cutover

• Create the Cloudflare Pages project and enable preview deployments.
• Review a preview on desktop and mobile, including slow/no-JavaScript behavior.
• Associate the custom domain and enable HTTPS.
• Configure the canonical-host redirect.
• Verify meta.atrinik.org remains independently routable.
• Update repository website/download links after production is healthy.
• Submit the new site to the Internet Archive after launch.

Phase 3 — optional integrations

• Add a live server list only after the metaserver production cutover and browser access contract are ready.
• Decide whether to enable GitHub Discussions as the community replacement.
• Add a play.atrinik.org link only after the browser prototype has an intentionally operated public backend.

Acceptance criteria

• atrinik.org and www.atrinik.org resolve over HTTPS to one canonical website.
• Hosting incurs no recurring charge under the documented current free-tier limits.
• Pull requests validate the website and receive a reviewable preview deployment.
• The production site is generated entirely from version-controlled source; generated output is not committed.
• Home, download, play, servers, about, develop, gallery, and docs pages work on desktop and mobile with keyboard navigation.
• The download path reaches the actual latest GitHub release and does not advertise nonexistent packages.
• The established URLs currently used by README.md redirect to relevant new destinations.
• There are no broken internal links in the built output.
• Reused visuals have complete attribution and useful accessibility text.
• The website does not depend on the metaserver, the next/ Go backend, a database, accounts, or a CMS to render its core content.
• DNS/deployment documentation makes the Pages site, meta.atrinik.org, and any future play.atrinik.org ownership boundaries explicit.

Out of scope for this issue

• restoring SMF accounts, forum posts, calendar, private messages, or the old gallery application;
• serving release ZIPs from the website host;
• duplicating all repository technical documentation into the site;
• deploying the metaserver or a persistent public game server;
• presenting the next/ vertical slice as a finished or hosted game;
• analytics, tracking, advertising, donations, payments, or a newsletter.