first commit

.cursor/rules/frontend-ui.mdc

@@ -0,0 +1,18 @@
+---
+description: Frontend and UI rules for Mixmaker
+globs: frontend/**/*.{ts,tsx,css}
+alwaysApply: false
+---
+
+# Frontend And UI
+
+- Build mobile-first screens first, then scale up to desktop.
+- Use React, TypeScript, Vite, TanStack Router, TanStack Query, Tailwind CSS, shadcn/ui, and accessible primitives.
+- Organize code by product capabilities; keep reusable primitives in `shared`.
+- Keep the live match screen focused: show the current step, active team, allowed actions, score, and concise validation feedback.
+- Use orange and blue team accents on a dark graphite base, with accessible contrast and non-color status indicators.
+- Make touch targets large and keep the primary action reachable on phones.
+- Treat server state as authoritative; use optimistic updates only when rollback is clear and safe.
+- Keep API access behind typed client functions generated from or aligned with OpenAPI.
+- Prefer subtle motion that communicates state changes; respect reduced-motion preferences.
+- Do not encode map pools, hero catalogs, or draft rules directly in UI components.

.cursor/rules/go-clean-architecture.mdc

@@ -0,0 +1,18 @@
+---
+description: Go Clean Architecture rules for Mixmaker backend
+globs: backend/**/*.go
+alwaysApply: false
+---
+
+# Go Backend Architecture
+
+- Keep dependency direction strict: `domain` has no outward dependencies; `application` depends on domain and ports; adapters depend on application contracts; `cmd/api` performs wiring.
+- `backend/internal/domain` must not import HTTP routers, SQL drivers, configuration, loggers, or framework code.
+- `backend/internal/application` must depend on domain types and consumer-owned ports, never concrete adapters.
+- Put request and response DTOs in HTTP adapters, not in domain entities.
+- Prefer explicit domain errors and small interfaces owned by their consumers.
+- Keep SQL, migrations, and PostgreSQL-specific types inside output adapters.
+- Make transactions explicit at the application boundary for multi-step state changes.
+- Keep balancing and draft validation deterministic and free of infrastructure dependencies.
+- Pass clocks, random sources, and ID generators through ports when behavior must be testable.
+- Add focused unit tests whenever domain behavior or a use case changes.

.cursor/rules/project-context.mdc

@@ -0,0 +1,21 @@
+---
+description: Core Mixmaker product context
+alwaysApply: true
+---
+
+# Mixmaker Context
+
+- Mixmaker is a web app for organizing Overwatch scrims for communities of 20+ players.
+- Read the relevant files in `memory_bank/` before meaningful product or architecture changes.
+- The core flows are Discord auth, player profiles, event calendar and RSVP, role-based team balancing, coin toss, map and hero bans, Bo3 results, and tournament brackets.
+- Players sign in through Discord and may edit only their own Tank, Damage, and Support ratings.
+- Scheduled events support Going, Maybe, and NotGoing participation statuses.
+- Admins may manage events and change RSVP for another player; store the acting account for every administrative override.
+- The balancer creates full 5v5 teams with 1 Tank, 2 Damage, and 2 Support; unmatched players remain in reserve.
+- An Admin assigns one captain from each team's current roster; captain permission is scoped to that team.
+- Keep the UI polished, responsive, mobile-first, and styled as a dark esports control panel.
+- Business rules and draft state are enforced by the backend; the frontend must not be the source of truth.
+- Preserve draft, result corrections, and match history as auditable actions instead of silently rewriting completed steps.
+- Production deploys to Coolify as one Docker Compose stack with PostgreSQL; do not declare custom Compose networks unless explicitly required.
+- Do not commit production secrets, publish PostgreSQL ports, or omit persistent storage, healthchecks, and backup documentation.
+- After meaningful product, architecture, API, data-model, deployment, or workflow changes, update the relevant files in `memory_bank/` in the same task.

.cursor/rules/testing-and-quality.mdc

@@ -0,0 +1,16 @@
+---
+description: Testing and quality expectations for Mixmaker
+alwaysApply: true
+---
+
+# Testing And Quality
+
+- Keep changes scoped and aligned with `memory_bank/`.
+- After substantive edits, run the narrowest useful checks available.
+- Backend domain rules and use cases must be unit-testable without PostgreSQL.
+- Add focused tests for balancing constraints, draft transitions, role limits, and repeated-ban rules.
+- Repository and migration behavior should use integration tests once the database layer exists.
+- Critical frontend flows should receive component or end-to-end coverage as the UI stabilizes.
+- Test concurrent or repeated draft commands for idempotency and version conflicts.
+- Do not add broad abstractions until repeated behavior proves they are needed.
+- Prefer explicit domain invariants over compatibility with unfinished code.