Initial Commit

.agent/rules/development-folders.md

@@ -0,0 +1,25 @@
+---
+trigger: always_on
+---
+
+## Documentation and Work Logging
+You are required to use the `./docs/development/devlog` directory to track all work plans and their current status individually; within this directory, create logs using the strict filename format `yyyy-mm-dd-hh24miss_very_brief_description`. Additionally, use the `./docs/development` directory to maintain a summary `CENTRAL.md` file containing links to specific files within `./docs/development/devlog` alongside a brief synthesis of the development status.
+
+## Source Code Organization
+Use `./src` as the root for the monolithic **Node.js (TypeScript)** solution.
+The project follows a **Modular Monolith** pattern. All backend logic is structured by modules, while frontend code (React) resides within a client directory or is served as static assets from the node application.
+
+## Backend and Frontend Integration (The Monolith)
+The core server project (e.g., `./src/server` or `./src/app`) contains the entry point (`index.ts` or `main.ts`). Functionality is divided into **Modules**:
+
+* **Controllers:** `./src/modules/[ModuleName]/controllers/` (Handle HTTP requests).
+* **Routes:** `./src/modules/[ModuleName]/routes/` (Define express/fastify routes).
+* **DTOs:** `./src/modules/[ModuleName]/dtos/` (Data Transfer Objects for validation).
+* **Static Assets:** `./src/public/` (for module-specific assets if necessary).
+
+## Domain Layer
+Shared business logic and database entities reside in shared directories or within the modules themselves, designed to be importable:
+
+* **Entities:** `./src/modules/[ModuleName]/entities/` (ORM definitions, e.g., TypeORM/Prisma models).
+* **Services:** `./src/modules/[ModuleName]/services/` (Business logic implementation).
+* **Interfaces:** `./src/shared/interfaces/` or within the module (Type definitions).

.agent/rules/development-guide.md

@@ -0,0 +1,21 @@
+---
+trigger: always_on
+---
+
+## Planning and Workflow
+You must always start by producing an implementation plan in the dedicated folders and proposing to the user that they view it by default. If the user chooses to proceed, you are to continue with the implementation of the plan without stopping. It is essential that you update the plan continuously as the development progresses to reflect the current state of the project.
+
+## Code Philosophy and Integration
+You are required to work with the existing code, specifically utilizing the logic found in the provided gemini-generated.js file—including its regex parsing, Scryfall data fetching, caching strategies, and pack generation algorithms—as the core of the "Draft Preparation Phase". You must refactor this monolithic component into modular services, such as a `CardParserService` and `PackGeneratorService`, to effectively separate the user interface from the business logic, making the system suitable for a multiplayer backend state. The software must be extremely optimized and easy to use; while the preparation phase happens on the client side, the live draft state must be synchronized via the backend. The average user, acting as the Draft Host, must be guided through every operation, from uploading a list and fetching data to configuring packs and opening a lobby for multiplayer.
+
+## UI/UX Design and Tech Stack
+The graphics must be professional, immersive, and reassuring, utilizing a dark mode or gaming theme that replicates the visual style of the provided file (using Tailwind and Lucide icons) while elevating it to a production standard. The interface must include shortcuts for quick usage, and data saving must be immediate without requiring the user to click "Save" buttons. You must implement the specific views found in the provided code, including List View, Grid View, and the 3D perspective Stack View, ensuring they work seamlessly in a multiplayer context. The development will utilize **React** for the frontend, reusing component logic like `StackView` and `PackCard`, and **Node.js with TypeScript** for the backend. You must use **Socket.IO** to handle the real-time multiplayer draft state for synchronizing pack passing between clients, and the frontend generator must produce a JSON object of packs to be sent to the backend to initialize the session.
+
+## Documentation and Architecture
+For every implementation, update, or modification request, you must create a detailed work plan to be followed strictly. If a request implies complex development, such as synchronizing drag-and-drop actions across multiple clients, you must warn the user beforehand. Before starting, always write a file dedicated to the request and the created plan within the `./docs/development` folder, and keep this file updated throughout the execution of the work plan. The platform must be organized into applications managed via a sidebar, such as the Cube Manager (using the adapted logic), Lobby Manager, and Live Draft interface. Each application must be toggleable and purchasable via an internal administration section.
+
+## Design System, Navigation, and Viewport
+Interfaces must always be created using Material Design principles adapted for a dark gaming UI, with icons that clearly identify the purpose of the application or function. The interface must be fully responsive, with specific handling for mobile devices, such as converting the "Stack View" to a "Swipe View" where necessary. The menu must be a lateral sidebar with two levels: the first for active applications and the second for functions within those applications. A top search bar must be implemented as an accelerator to search for cards, players, or lobbies hierarchically. The main viewport must be configurable with tabs; every application opens as a new tab, and upon restarting, the tabs open last time must remain active. Specifically, starting a draft should open a new tab for the "Live Lobby," and the system must handle persistence to reconnect users to their active session upon reloading.
+
+## Localization, Database, and Error Handling
+The management system is currently supporting English only.

.agent/rules/functional-goal.md

@@ -0,0 +1,15 @@
+---
+trigger: always_on
+---
+
+## Core Objective and User Experience
+The primary objective is to engineer a high-performance, browser-based Magic: The Gathering Multiplayer Draft Simulator that bridges the gap between utilitarian management tools and immersive, game-like user experiences. The platform must be specifically designed to cater to the "Average User" acting as a Host, who requires a friction-free setup process without technical hurdles, and the "Player," who demands a snappy, visually engaging drafting environment accessible on any device. The goal is to provide a seamless transition from deck preparation to active gameplay, ensuring that the software feels responsive and robust, much like a native application rather than a static webpage.
+
+## The Cube Manager and Preparation Phase
+A central functional domain is the "Cube Manager," which handles the preparation phase. The system must provide automated ingestion capabilities that accept raw text lists—such as Arena exports or bulk text—and intelligently parse them using specific regex logic to identify card quantities and names. Following parsing, the system is required to seamlessly fetch and enrich card metadata, including images, rarity, and set information, from the Scryfall API while implementing robust caching to ensure speed. This data drives a sophisticated Pack Generation engine that creates "Booster Packs" based on customizable rules, such as "Peasant" distribution or "Chaos" modes, while automatically filtering out unplayable tokens or basic lands. Users must be empowered to verify their generated pools through distinct visualizations, including List, Grid, and a 3D perspective "Stack" view, before committing to a game.
+
+## The Live Draft and Multiplayer Synchronization
+The core gameplay revolves around the "Live Draft" phase, which necessitates a real-time multiplayer environment where eight or more players pass packs simultaneously. You must implement a synchronization engine (via **Socket.IO**) to ensure that state changes, such as picking a card or passing a pack, are instantly propagated across all connected clients with millisecond precision. The interface must support intuitive interactions, allowing players to draft via drag-and-drop or click-to-pick mechanisms, with built-in logic to auto-sort picked cards by color or mana cost. Crucially, the system must handle network latency and interruptions gracefully; if a player disconnects or refreshes the page, they must be immediately reconnected to the exact state of their active pick without any data loss.
+
+## Ecosystem, Responsiveness, and Session Management
+The user experience must mimic a comprehensive operating system through a tabbed multitasking interface, allowing users to keep the Live Draft open in one tab while managing the Cube in another within the same viewport. The platform operates on a modular "App Store" model, where functional areas like Tournaments, Brackets, or Collection management can be toggled or activated via an admin panel. The interface must be rigorously responsive, employing a mobile-first adaptation strategy that transforms wide desktop column views into touch-friendly carousels or swipe interfaces on smaller screens. Furthermore, all user actions, from deck building to cube editing, must trigger zero-friction auto-saving to backend databases via AJAX/Fetch calls, eliminating the need for manual save buttons and ensuring total data integrity throughout the session.

.agent/rules/running-guide.md

@@ -0,0 +1,5 @@
+---
+trigger: always_on
+---
+
+Everytime there is a new feature or something was changed, run the application and test every new feature in (also in browser) to avoid future bugs.