Cambridge TCG

Building open-source TCG data infrastructure from Cambridge, UK: shared tools and standards for card identity, images, prices and market observations. The website gives people and API clients ways to inspect those records and their sources.

The data-platform roadmap is the current integration plan. The repository is public; reference packages remain workspace-only, and package distribution is a separate release gate. A source adapter, registered game or published plan does not establish available data or permission to redistribute it.

Current boundary: new paid commerce is retired. Existing agreements retain settlement, cancellation, refunds and support. Start with the storefront commerce boundary, wholesale scope, and RewardsPro scope; older shop and launch plans are historical context.

Start here

I want to…	Entry point
Explore cards, collections and community	Website
Understand the data-platform direction	Purpose and integration roadmap — SKU, images, pricing and market foundations
Understand or change this repository	Module map — purpose, source paths, connections and progress
Review the complete website rebuild	Draft room and content plan — purpose, pages, modules, wiring and design
Understand current contracts and gaps	Card-data foundations — identity, images, prices, market observations and source boundaries
Run the site locally	Local development, then the storefront guide
Find a guide or recorded decision	Documentation
Work as a coding agent or use the API	Agent guide — repository rules and public interfaces

This README is the human contributor entrance. Module records describe the checked-in source and recorded work; they do not establish deployment or service health. Coding-agent instructions live in AGENTS.md.

Layout

Path	Role and status
apps/storefront	Human data tools, collector pages, /api/v1 interfaces and /admin/* console; Next.js App Router
apps/admin	Retired standalone app; redirect shell and retained review documentation, with no dev/build/test scripts
apps/wholesale	Price research and existing order operations; new orders and quote requests retired
apps/rewardspro	Existing loyalty and rewards platform; new paid subscriptions and plan changes retired
apps/rewardspro-api	Separate v2 ingestion foundation; does not claim legacy feature, data or business-rule parity
packages/	Shared database, pricing, stock, data, lifecycle and other domain libraries
docs/	Architecture, decisions, runbooks, principles and dated verification records

The module map expands this layout into individual module records. Its JSON catalog gives tools the same inventory.

Local development

Use the pnpm workspace from this repository root. package.json pins pnpm 9.15.0. Use Node 24 LTS for workspace development: the root accepts Node >=20, while RewardsPro API requires Node >=24 <25.

pnpm install --frozen-lockfile
pnpm dev:storefront --hostname 127.0.0.1

The storefront and its admin console run at http://127.0.0.1:3001. Configure only the services needed for your task with local fixtures or scoped development credentials; installation alone does not configure a database or provider. Other apps have their own linked setup guides. Keep credential values out of tracked files, command output and documentation.

Verification

Choose checks for the files changed. These commands are defined in the root or storefront package scripts:

pnpm audit:tracked-secrets
pnpm audit:modules
pnpm --filter cambridgetcg-storefront typecheck
pnpm --filter cambridgetcg-storefront exec vitest run path/to/changed-area.test.ts

Replace the last path with the relevant test, relative to apps/storefront. After changing a module's purpose, connections or progress, update its record with dated evidence in the catalog, regenerate with pnpm docs:modules, then check with pnpm audit:modules. The module guide explains the fields and generated files. The credential audit reports filenames and categories without values; it covers tracked working files, not Git history, ignored files or provider revocation.

pnpm run audit runs the project audit chain; pnpm audit is pnpm's dependency vulnerability check. pnpm verify combines workspace typechecks, the project audits and selected package/storefront tests. Some audits can access a database: inspect their requirements and use safe fixtures before running the full chain.

For an already-running local storefront, STOREFRONT_BASE_URL=http://127.0.0.1:3001 pnpm --filter cambridgetcg-storefront test:e2e:smoke checks the auth surface. Playwright starts no server and otherwise defaults to production. The old pnpm smoke runner is stale and is not a verification gate. The storefront scripts define the available checks.

Find the next detail

• Module map — source inventory, connections and progress; docs index — guides by audience and purpose.
• Historical development plan — earlier architecture and proposals; read current module records before using its paths or status claims.
• Current commerce boundary — current storefront policy and preserved obligations.
• Operations and verification — infrastructure, deployment and credential-scoped checks.
• Agent guide — repository instructions, machine interfaces and optional project culture.

Data rights

Code follows the root Apache-2.0 license and applicable more-specific notices. The CC0 dedication covers specification prose. Provider data, publisher text and artwork retain their own terms; check each source, field and permitted use before reuse. These are separate from repository access, API authentication and package publication.