Canonical implementation: alleycat-rs — Rust HTTP API and data layer for Alleycat. · DeepWiki

Platform role: Backend that persists and serves player records and ingests device telemetry (e.g. PDN crash logs). PDNs and venue systems call HTTP endpoints; PostgreSQL holds durable state. This is not Mission Control — MCS on the MC stack is the Central HTTP adapter; alleycat-rs is the canonical data layer. See Mission Control for live ops.

Notion vs DeepWiki vs GitHub: This page is the Alleycat-facing summary (how the API fits PDN / MC / future game services). For implementation depth (endpoints, domain types, sqlx, Docker/xtask, CI), use DeepWiki first. When behavior or contracts change, update the repo (docs/, README, migrations) first.

Related index: Open Source Software

DeepWiki (API implementation)

<aside> 📚

Context lives here in Notion. For codebase-level docs (HTTP API, player & device-log endpoints, schema/migrations, xtask stack commands, test harness, Docker/CI), use DeepWiki:

alleycatassetacquisitions/alleycat-rs on DeepWiki

</aside>

What this service covers

• Players — registration and lookup HTTP API.
• Device logs — ingest/retrieve crash and diagnostic payloads (protobuf on the wire).
• Data — PostgreSQL schema, migrations, seeding; local dev via Docker Compose (xtask stack).
• Ops — telemetry/logging, hosted deploy spec, CI (see DeepWiki § Build & CI).

Device firmware: Portable Data Node (PDN) and Fixed Data Node in Devices.

Legacy repos

• score-server — prior Go score stack (private).
• alleycat-server-bun — older TypeScript server; superseded directionally by alleycat-rs.

Open questions

• Production boundary: which clients (PDN firmware, MCS, future Campaign services) call alleycat-rs vs legacy paths at the next event.
• Auth model evolution (confirm before exposing beyond lab/VPN).