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:
2026-07-22 03:00:04 +00:00
parent b4a0b1f8be
commit a01e33eb5e
35 changed files with 1093 additions and 9215 deletions
+110 -31
View File
@@ -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