Der Musikclub — Product plan

Der Musikclub is a PvP table game. This file is the product and client plan, not the rules. Implement matches from rules.md and comprehensive-rules.md.

Horizon:

Phase	Session	Proof
Now	Standalone PvP: each DJ has their own client session	Two humans, two browsers, one match
Next	3–4 seats on the same session model	Same engine, more clients
Later	Tournaments	Brackets and seating; not new mix rules

There is no hotseat. One process never plays two human seats. A bot may fill a seat. It is optional. It is not the MVP.

---

MVP

A person opens the HTML client as their session, joins a PvP match with at least one other human session, finishes a night according to the rulebook, and may hear music caused by play.

Browser A (session) ──┐
                      ├── match host / rules engine
Browser B (session) ──┘
                      → match result per client
                      → lobby / next match

Music, if present:

match event → MusicRequested → service or fixture → samples

Out of scope for this MVP

• Tournament brackets, ratings, persistent season stats
• Trading, marketplace, payments
• Public developer API / plugin SDK
• Full account-management product
• Native desktop/mobile as the primary target
• Treating a bot match as the product loop
• Hotseat (two humans on one client)

Deck construction only as far as the rulebook’s crate needs for a playable night.

---

Shell

Scene flow (simple is fine):

Boot → (optional identity) → Lobby → Match → Result → Lobby

Lobby verbs are join / host PvP. Each client is one DJ. Practice vs bot is secondary.

The shell is Der Musikclub: typography, color, table layout (lines, mix, dice, owner borders). It does not implement legality; it renders GameState.

---

Identity and session

Each human DJ is a standalone session (own browser, own connection, own private hand).

• the client requests a session and a seat
• the match host owns the rules engine and the authoritative GameState
• the client does not invent legality or other DJs’ private zones
• the server decides entitlements if a backend exists

CORS and HTTPS are required for a hosted client.

---

Music (optional spike, then attach)

1. Version a small event vocabulary (tempo, time, pitch, velocity, duration).
2. Play it through Web Audio / local samples.
3. Prove one instrument.
4. Then attach MusicRequested to real match events.

Playback failure must not freeze the match (retry / skip music).

---

Match

Each client:

• joins or hosts a match (2–4 seats)
• occupies one seat
• submits only actions the host accepts for that seat
• renders the view the host allows that session (public table + own private zones)
• shows the engine’s end: win, shared win, or stalemate

Do not specify SATB, costs, or hold here.

The bot, if any, calls the same legal-action API as a human.

---

Failure states

Usable UI for: engine exception, disconnected seat, music timeout, autoplay block, missing assets. Never a blank freeze.

---

Acceptance (MVP)

Without developer intervention:

1. Two people open the client (two sessions).
2. They join the same PvP match, one seat each.
3. Play until the rules engine ends the night.
4. Each sees the result. Return to lobby. Start another match.

Stretch: at least one gameplay event produces audible music.

Tournaments are a later proof. Extra seats (3–4) can follow the two-session bar.

---

Dependency order

HTML client
        → session + match host (authoritative rules engine)
        → two standalone PvP sessions, one match
        → (optional) music playback
        → 3–4 seats
        → tournaments

Three proofs:

1. Client — Der Musikclub runs in the browser as one seat per session.
2. Night — two humans, two sessions, finish a match on the real rules.
3. Music — a match event can cause sound (optional for the first night).