tabletop-infra in-progress

Current state

Languages

• Shell: 57,080 bytes
• TypeScript: 53,590 bytes
• JavaScript: 9,325 bytes
• Dockerfile: 3,203 bytes

CI

skipped — e2e

Last commit

e728c8ed7096816f51de673fc2ee0e66f774e9ab (2026-08-15T21:22:21Z)

Module/package dependency graph (dependency-cruiser, folder-collapsed)

22 node(s), 20 edge(s) — scroll to zoom, drag to pan, click a node for details.

Circular dependencies (madge): 0

Class diagram (UML, via ts-morph)

12 node(s), 0 edge(s) — scroll to zoom, drag to pan, click a node for details.

GraphQL API

CI/CD pipeline (all workflows)

16 node(s), 0 edge(s) — scroll to zoom, drag to pan, click a node for details.

Outgoing relationships

None detected.

Incoming relationships

None detected.

Target state (spec-kit)

• specs/001-foundations-skeleton/spec.md — Feature Specification: Foundations and Repo/Infra Skeleton
  A new engineer joins the project, clones the repository, and needs to get a runnable local environment (database, cache, event bus placeholder, and one running service) without hunting through chat history or asking a teammate to walk them through undocumented setup steps.
• specs/002-observability-security-hardening/spec.md — Feature Specification: Observability and Security Hardening
  An on-call engineer gets a report that something went wrong for a specific player action (e.g. a token move that didn't sync). They need to follow that one request as it passed through the gateway and every service it touched, reading a single connected trail of log entries instead of grepping through each service's logs separately and guessing which entries belong together.
• specs/003-deployment-devops/spec.md — Feature Specification: Deployment and DevOps
  An engineer needs to run a service in a real (non-laptop) environment. The service must start from a single, versioned deployment definition that declares how much CPU and memory it needs and is allowed to use — figures based on what the service actually consumed under the realistic load test from the observability epic, not a guess.
• specs/004-qa-testing-strategy/spec.md — Feature Specification: QA and Testing Strategy
  An engineer finishing a story writes the unit tests for the logic they just added or changed, as part of that same story — not as a follow-up ticket and not as someone else's job. Before anyone else looks at the change, the engineer already knows the new logic behaves as intended and that a regression in it will be caught automatically in the future.

ADR files: 3