feat(growth): run scheduled playtests as a privacy-preserving acquisition loop

[zoeyrose]

Outcome

Turn scheduled Atrinik Classic playtests into a repeatable growth loop:

1. publish one useful, indexable event page;
2. guide a visitor through download and connection;
3. capture authentic gameplay material with appropriate consent;
4. publish a durable player-facing recap or guide improvement; and
5. compare aggregate visits, downloads, successful connections, and return participation without tracking individual visitors.

Deliver the first authorized pilot through this process and retain a reusable template for later events.

Why

A scheduled populated session gives prospective players a concrete reason to visit now and solves the empty-world problem better than undirected promotion. Each session can also produce original screenshots, video, beginner guidance, release feedback, and update pages that compound search and referral value.

The current website intentionally contains no repository-authored analytics, cookies, tracking, or browser JavaScript. Growth measurement must preserve that boundary. “Visitor-to-activation” therefore means an approximate comparison of separately owned aggregate counts over a defined period—not user-level attribution.

Scope

• Add a static playtest/event content model and template covering:
  • title, stable URL, status, date, time, timezone, and expected duration;
  • supported release and platform;
  • download, install, connection, and first-objective guidance;
  • server capacity and honest availability expectations;
  • organizer/support destination;
  • cancellation, postponement, completion, and recap states.
• Make current events discoverable through the player journey, internal links, metadata, and sitemap. Preserve completed event URLs as useful recaps instead of deleting them.
• Where search-engine structured data is used, emit accurate Event data and update its status when an event moves, cancels, or completes.
• Establish a per-event production checklist:
  • announce only through individually approved channels;
  • rehearse the exact release and public connection path;
  • capture authentic gameplay footage and screenshots;
  • obtain consent before publishing identifiable player names, chat, voice, or other personal material;
  • publish a concise recap, player outcome, and material guide improvements;
  • record bugs and operational problems in their owning repositories.
• Define privacy-preserving aggregate measures and their owners:
  • event/play-page request or referrer aggregates already available at the hosting-provider boundary, if suitable;
  • GitHub release-asset download counts;
  • server-owned counts of successful connections and active players during the event window;
  • an aggregate later-session participation measure only if the server owner can produce it without exporting account/player data to the website.
• Keep metrics separate by system and time window. Do not introduce a shared visitor/player identifier or pretend that separately counted cohorts are an exact funnel.
• Record baseline, target, collection time, limitations, and post-event results in a compact retrospective.
• If an aggregate cannot be obtained under the privacy contract, mark it unavailable rather than adding tracking.
• Do not add repository-authored analytics, cookies, fingerprinting, campaign beacons, cross-service identifiers, client telemetry, third-party embeds, or personal-level attribution.
• Do not schedule an external event, publish announcements, invite press/communities, or record participants without the exact action and consent model being explicitly authorized.

Important

Repository implementation may prepare event pages, templates, copy, and checklists. A maintainer must separately approve the pilot date, production topology, organizers, external announcement targets, recording plan, and each external publication before those actions occur.

Acceptance criteria

• A reusable static event template supports scheduled, postponed, cancelled, completed, and recap states without client-side JavaScript.
• Dates, timezones, availability, release/platform requirements, and canonical play links are unambiguous and accessible.
• Current events are internally discoverable and completed events retain original player value rather than becoming thin archive pages.
• Structured event metadata, when present, matches visible content and changes with the event state.
• The measurement contract names the source, owner, time window, retention, limitations, and privacy boundary for every aggregate.
• No cookie, browser identifier, query-based campaign tracker, fingerprint, account export, or cross-service identity join is introduced.
• The published report clearly labels aggregate ratios as estimates rather than individual conversion attribution.
• Gameplay media has participant consent where needed and satisfies content(media): replace temporary generated concept art with human-created visuals #22's provenance, notice, accessibility, and truthful-presentation requirements.
• No external scheduling, announcement, invitation, recording, or publication occurs without the exact authorization recorded here.
• The first authorized pilot is rehearsed, run, recapped, and reviewed against the defined aggregate measures.
• npm run check, npm run build, npm run deploy:dry-run, and git diff --check pass for website changes.

Dependencies

• Relaunch atrinik.org from the standalone MIT website repository #4 owns the player journey and static-site architecture used by event pages.
• content(media): replace temporary generated concept art with human-created visuals #22 owns provenance-cleared human-created imagery and truthful gameplay presentation.
• feat(metadata): add structured identity, favicons, and page-specific previews #27 owns structured page and event metadata.
• content(play): publish a player-first Classic getting-started path #28 and content(guide): publish a verified first-hour Classic walkthrough #30 own the download/connection and first-session journeys.
• content(distribution): prepare an accurate cross-channel player launch kit #32 owns the approved launch kit and target-channel drafts.
• atrinik/metaserver-worker#18 and its consumer-release dependencies must provide a tested production discovery/connect path before an event is announced.