Clean up backend folder - remove obsolete scripts and test files
Removed obsolete scripts that were not imported or used: - card_interaction_rule_engine.py - card_profile_extractor.py - create_card_interaction_graph.py - interaction_determinator.py - interaction_pipeline.py - interaction_recommender.py - interaction_schema.py - recommendation_engine.py - migrate_complete.py - migrate_schema.py - test_interaction_determinator.py - check_mtgjson_full.py - check_mtgjson_status.py - verify_integration.py - verify_mtgjson_data.py - sanity_check_mtgjson.py - investigate_sets.py - inspect_db.py - code_review.md - monitor/mtg_monitor.py Removed test artifacts: - test.db - test_download.py - test_system.py - setup_db.py - BACKEND_TESTING_SUMMARY.md - CHAT_PROMPT_TEST.md - CONTINUATION_PROMPT.md - PORTED_STATE.md - SPEC_synergy-mapping-engine.md - STATE.md - SUPPORTED_FILE_TYPES.md Removed sensitive/environment files: - .env.local - state.json (backend) Cleaned up: - __pycache__ directories - venv directory Backend scripts/ directory now contains only essential data loading and maintenance scripts.
This commit is contained in:
+110
-31
@@ -255,44 +255,123 @@ docker exec <mtgdata_container_id> psql -U mtgonline_user mtgdata -c "SELECT * F
|
||||
- Check CORS_ORIGINS setting in app/core/settings.py
|
||||
- Ensure frontend URL matches allowed origins
|
||||
|
||||
## Next Phase: Backend Expansion for Frontend Support
|
||||
## Next Phase: V1 Backend — Deck Building & Card Management (NEW SCOPE)
|
||||
|
||||
**Primary Focus**: Expand the PostgreSQL database schema and API endpoints to support frontend deckbuilding and gameplay features on a per-user basis.
|
||||
The v1 app function focuses on three core capabilities:
|
||||
1. **Per-user deck building** with card search, deck precedents, and card suggestions
|
||||
2. **Card list import** from spreadsheet/text files with fuzzy matching
|
||||
3. **Multiplayer gameplay** (handled by a separate backend)
|
||||
|
||||
### Database Schema Expansion
|
||||
- Per-user deck storage (decks, folders, custom card sets)
|
||||
- Game state persistence (saved games, match history, game logs)
|
||||
- User card collection tracking (owned cards, favorites)
|
||||
- Game room state management (active games, waiting lists)
|
||||
- Tournament and custom rule support
|
||||
### 1. Per-User Deck Building
|
||||
|
||||
### API Endpoints to Implement
|
||||
- Deck CRUD with user ownership and sharing
|
||||
- Game room creation, joining, and state management
|
||||
- Real-time WebSocket endpoints for multiplayer gameplay
|
||||
- Card collection APIs (search, filter, organize)
|
||||
- Game history and replay APIs
|
||||
- Admin tools for game monitoring and moderation
|
||||
#### Database Schema
|
||||
- **`user_decks` table** (per-user storage in primary `mtgonline` database):
|
||||
- `deck_id` (PK, auto-increment)
|
||||
- `user_id` (FK → users)
|
||||
- `name` (text)
|
||||
- `status` (ENUM: `DRAFT`, `FINAL`)
|
||||
- `DRAFT` = works in progress, can be edited freely
|
||||
- `FINAL` = user considers it complete, no further changes expected
|
||||
- `cards` (JSONB or separate junction table with `card_id`, `quantity`)
|
||||
- `created_at`, `updated_at` (timestamps)
|
||||
- `folder_id` (FK → user folders, optional)
|
||||
|
||||
### Frontend Features to Support (from ROADMAP.md Phase 2)
|
||||
- **Deck Builder**: Card search with filters (name, color, type, set), drag-and-drop editor, import/export formats
|
||||
- **Game Interface**: Game board visualization, player zones (hand, library, graveyard, exile, command), real-time updates
|
||||
- **Chat System**: Room chat, game chat, player list, moderator tools
|
||||
- **Admin Dashboard**: User management, ban/unban controls, game logs, system statistics
|
||||
#### API Endpoints to Implement
|
||||
- `POST /decks/` — Create new draft deck (auto status: DRAFT)
|
||||
- `GET /decks/` — List user's decks, filtered by status
|
||||
- `GET /decks/{deck_id}` — Get full deck details
|
||||
- `PATCH /decks/{deck_id}` — Update deck (name, status, card list)
|
||||
- `POST /decks/{deck_id}/finalize` — Transition DRAFT → FINAL
|
||||
- `DELETE /decks/{deck_id}` — Delete deck (only if FINAL, or admin override)
|
||||
- `GET /decks/{deck_id}/cards` — Get cards in deck with quantity counts
|
||||
|
||||
### Integration Requirements (from ROADMAP.md Phase 3)
|
||||
- WebSocket client with reconnection logic
|
||||
- Card database caching and search functionality
|
||||
- Game logic implementation (turn-based state, mana tracking, stack resolution)
|
||||
- Performance optimization (virtual scrolling, memoization, code splitting)
|
||||
#### Deck Building Features
|
||||
- **Card Search**: Search the MTG card database by name, type, set, color, etc. Returns matching cards with full details.
|
||||
- **Deck Precedents**: Preset/starting deck templates that users can use as a basis. Could be built-in (e.g., "Starter Deck") or user-saved as FINAL decks to be reused.
|
||||
- **Card Suggestion**: Given a card already in the deck, suggest similar cards (same type, same color, same set, same mana cost, or cards often paired with the input card in existing decks).
|
||||
|
||||
### Deployment & Production (from ROADMAP.md Phase 4)
|
||||
- Docker Compose for development and production
|
||||
- CI/CD pipeline with GitHub Actions
|
||||
- Security hardening (rate limiting, input validation, HTTPS)
|
||||
- Monitoring and alerting (structured logging, error tracking)
|
||||
### 2. Card Import from Files
|
||||
|
||||
See **ROADMAP.md** for complete feature specifications and timeline.
|
||||
#### Supported Formats
|
||||
- XLSX (Excel)
|
||||
- CSV
|
||||
- JSON
|
||||
- ODS (OpenDocument Spreadsheet)
|
||||
|
||||
#### Import Flow
|
||||
1. User uploads a file (XLSX, CSV, JSON, or ODS)
|
||||
2. Backend parses the file — each row is treated as one card entry
|
||||
3. Duplicates within the file are allowed (each row → one card instance)
|
||||
4. For each card name in the file, backend performs **fuzzy matching** against the `Cards` PSQL table
|
||||
5. Matched cards are stored in a **user-owned card table** with metadata:
|
||||
- `user_id` (FK → users)
|
||||
- `card_id` (FK → mtg_cards from mtgdata, matched via fuzzy search)
|
||||
- `raw_name` (original name from file, for traceability)
|
||||
- `confidence` (match score from fuzzy search)
|
||||
- `imported_at` (timestamp)
|
||||
|
||||
#### Fuzzy Search Requirements
|
||||
- Must handle **spelling errors** (e.g., "Wondrrland" → "Wonderland")
|
||||
- Must handle **American vs British English** differences (e.g., "color" vs "colour", "armor" vs "armour")
|
||||
- Use a fuzzy string matching library (e.g., `python-Levenshtein`, `thefuzz`/`fuzzymatch`)
|
||||
- Confidence threshold to auto-accept vs flag for manual review
|
||||
- Bulk matching: process all cards in the file in a single batch operation
|
||||
|
||||
#### API Endpoints to Implement
|
||||
- `POST /cards/import` — Upload file for import
|
||||
- `GET /cards/import/{import_id}/status` — Check import progress/status
|
||||
- `GET /cards/import/{import_id}/results` — Get match results with confidence scores
|
||||
- `POST /cards/import/{import_id}/confirm` — Confirm import (save to user card table)
|
||||
- `GET /user/cards` — List user's imported/owned cards
|
||||
- `DELETE /user/cards/{card_import_id}` — Remove from user card table
|
||||
|
||||
### 3. Multiplayer Play Feature (Separate Backend)
|
||||
|
||||
#### Architecture Decision
|
||||
The multiplayer gameplay feature will live in a **separate backend codebase** to ensure smooth, independent development. This backend will communicate with the card backend via:
|
||||
|
||||
- **API Calls**: For authentication, user data, deck retrieval, card lookups
|
||||
- **Direct PSQL Queries**: For card data and user deck data
|
||||
|
||||
#### Integration Points
|
||||
- **Card Backend API** (`http://backend:8000`):
|
||||
- `GET /api/cards/{card_id}` — Get card details for in-game display
|
||||
- `GET /api/cards/search?q=...` — Search cards during gameplay
|
||||
- `GET /api/sets/` — List available sets for game formatting
|
||||
|
||||
- **PSQL Direct Access** (via shared connection string):
|
||||
- `mtgdata` database — Read card data (cards, sets, etc.)
|
||||
- `mtgonline` database — Read user decks (for deck validation, game setup)
|
||||
|
||||
#### API Endpoints for Play Backend
|
||||
- `POST /play/decks/{deck_id}/validate` — Validate deck against card database
|
||||
- `GET /play/users/{user_id}/decks` — Get user's FINAL decks for selection
|
||||
- `GET /play/cards/{card_id}` — Get card details for game board display
|
||||
|
||||
**Note**: The play backend is out of scope for this document. See separate codebase/repository when ready.
|
||||
|
||||
### Summary of Work Required in This Backend
|
||||
|
||||
| Feature | Database | API | Notes |
|
||||
|---------|----------|-----|-------|
|
||||
| User deck CRUD | `mtgonline` (new tables) | Full CRUD + finalize | DRAFT/FINAL status |
|
||||
| Card search | `mtgdata` (existing) | Search endpoint | Leverages existing card DB |
|
||||
| Card suggestions | `mtgonline` + `mtgdata` | Suggestion endpoint | Based on similar cards |
|
||||
| File import (XLSX/CSV/JSON/ODS) | `mtgonline` (new user cards table) | Upload + confirm | Fuzzy match required |
|
||||
| Fuzzy matching service | N/A | Internal service | Handles spelling + EN variants |
|
||||
| Play backend integration | Read-only access | API consumer | Separate codebase |
|
||||
|
||||
### Files to Create/Modify
|
||||
- New models: `models/user_deck.py`, `models/user_card.py`
|
||||
- New migrations: Alembic migrations for new tables
|
||||
- New router: `routers/decks.py`, `routers/card_import.py`
|
||||
- New service: `services/fuzzy_card_matcher.py`
|
||||
- New service: `services/deck_suggestion.py`
|
||||
- New schema: `schemas/deck.py`, `schemas/card_import.py`
|
||||
- Update `core/database.py` if new engine needed
|
||||
- Update `requirements.txt` with fuzzy matching libraries
|
||||
|
||||
See **ROADMAP.md Phase 2** for detailed task breakdown.
|
||||
|
||||
## State File
|
||||
|
||||
|
||||
Reference in New Issue
Block a user