Complete update of tournament scraping pipeline and updated GH Action (#108)

## Summary

This PR adds a **SQLite wrapper** for offline scraper testing, improves
the Longshanks and Rollbetter scrapers, fixes the missing `winner_id` in
match records, and updates the GitHub Action to support a SQLite-only
run mode.

## Changes

### New file
- **`backend/scripts/scrape_tournaments_sqlite.py`** — wrapper that sets
`DATABASE_URL` to a local SQLite file before importing the main scraper.
Enables offline testing without Postgres. Usage:
  ```bash
  python -m backend.scripts.scrape_tournaments_sqlite \
    --sqlite-path scraped.db \
    --platform longshanks+rollbetter \
    --time-range 7
  ```

### Improved scrapers
- **`scrape_tournaments.py`** — added `--tournament-url` flag for
scraping individual URLs directly (supports Rollbetter, Longshanks, and
ListFortress). Added `--tournament-url` support for benchmark
validation.
- **`rollbetter_scraper.py`** — scoped match table selection to the
active tab panel and added a `wait_for_selector` before reading round
data. This fixes several rounds that previously reported "No match table
found".
- **`longshanks_scraper.py`** — replaced jQuery `trigger(change)` with
the sites own `load_games()` helper (which is how the page actually
loads match data). Scoped `.results` lookups to the `#games` container.
Fixed date parsing to use the start date from Longshanks date ranges.

### Bug fix
- **`save_tournament_data`** — `winner_id` was never set when converting
match dicts to `Match` objects. Now resolves `winner_name_temp` against
the player name map to populate the foreign key. **All 20 matches in the
validation scrape now have a non-null `winner_id`** (previously 0).

### GitHub Action
- **`scrape_tournaments.yml`** — added `none` as an environment option
(SQLite-only, no Postgres). Exposed `upload_sqlite_artifact` as an input
toggle. Postgres writes only occur for `prod`/`dev`. When `environment:
none`, uses the SQLite wrapper.

## Validation
- ✅ Local SQLite scrape of 10 benchmark tournaments matches expected
counts (Rollbetter events match exactly; Longshanks now captures
**more** matches thanks to the `load_games()` fix — previously missed
rounds)
- ✅ GH Action ran successfully against **dev** Postgres (8 new
tournaments from Apr 15–30, grew DB from 604 → 612)
- ✅ GH Action correctly uses `DEV_DATABASE_URL` secret when
environment=dev
- ✅ SQLite artifact uploaded as expected
- ✅ `winner_id` now correctly populated in all match records
- ✅ Local scrape of Apr 1–7 produced 5 tournaments, 26 players, 36
matches across both platforms

Closes # (no issue linked)

---------

Author: Francespo

.devcontainer/devcontainer-lock.json

@@ -0,0 +1,29 @@
+{
+  "features": {
+    "ghcr.io/devcontainers/features/copilot-cli:1": {
+      "version": "1.1.2",
+      "resolved": "ghcr.io/devcontainers/features/copilot-cli@sha256:757c6c2899dc902c44a9f6164c1f7392832ced13c6bb632d8d60a880f2e92456",
+      "integrity": "sha256:757c6c2899dc902c44a9f6164c1f7392832ced13c6bb632d8d60a880f2e92456"
+    },
+    "ghcr.io/devcontainers/features/git-lfs:1": {
+      "version": "1.2.5",
+      "resolved": "ghcr.io/devcontainers/features/git-lfs@sha256:71c2b371cf12ab7fcec47cf17369c6f59156100dad9abf9e4c593049d789de72",
+      "integrity": "sha256:71c2b371cf12ab7fcec47cf17369c6f59156100dad9abf9e4c593049d789de72"
+    },
+    "ghcr.io/devcontainers/features/github-cli:1": {
+      "version": "1.1.0",
+      "resolved": "ghcr.io/devcontainers/features/github-cli@sha256:d22f50b70ed75339b4eed1ba9ecde3a1791f90e88d37936517e3bace0bbad671",
+      "integrity": "sha256:d22f50b70ed75339b4eed1ba9ecde3a1791f90e88d37936517e3bace0bbad671"
+    },
+    "ghcr.io/devcontainers/features/node:2.0.0": {
+      "version": "2.0.0",
+      "resolved": "ghcr.io/devcontainers/features/node@sha256:fedd4c11f7adfb64283b578dddc7da906728daa25fa293351c9d913231acf12f",
+      "integrity": "sha256:fedd4c11f7adfb64283b578dddc7da906728daa25fa293351c9d913231acf12f"
+    },
+    "ghcr.io/siri404/devcontainer-ai-features/gemini-cli:1": {
+      "version": "1.0.1",
+      "resolved": "ghcr.io/siri404/devcontainer-ai-features/gemini-cli@sha256:99754255ee3d9596430bf730c0e55475bd9d7d741845d96e6ec3c81a89fec51b",
+      "integrity": "sha256:99754255ee3d9596430bf730c0e55475bd9d7d741845d96e6ec3c81a89fec51b"
+    }
+  }
+}

.devcontainer/devcontainer.json

@@ -0,0 +1,48 @@
+{
+  "name": "m3tacron-dev",
+  "image": "mcr.microsoft.com/devcontainers/python:3-3.13-trixie",
+  "features": {
+    "ghcr.io/devcontainers/features/node:2.0.0": {},
+    "ghcr.io/devcontainers/features/github-cli:1": {},
+    "ghcr.io/devcontainers/features/copilot-cli:1": {},
+    "ghcr.io/siri404/devcontainer-ai-features/gemini-cli:1": {},
+    "ghcr.io/devcontainers/features/git-lfs:1": {}
+  },
+  "forwardPorts": [8000, 3000, 8100, 5173],
+  "portsAttributes": {
+    "8000": {
+      "label": "FastAPI"
+    },
+    "8100": {
+      "label": "FastAPI (README)"
+    },
+    "3000": {
+      "label": "Svelte"
+    },
+    "5173": {
+      "label": "Vite"
+    }
+  },
+  "customizations": {
+    "vscode": {
+      "extensions": [
+        "ms-python.python",
+        "ms-python.vscode-pylance",
+        "ms-playwright.playwright",
+        "svelte.svelte-vscode",
+        "esbenp.prettier-vscode",
+        "ms-python.vscode-python-envs",
+        "ms-python.debugpy",
+        "ms-ossdata.vscode-pgsql",
+        "GitHub.vscode-pull-request-github",
+        "bretwardjames.gh-projects",
+        "GitHub.copilot-chat",
+        "github.vscode-github-actions"
+      ],
+      "settings": {
+        "python.analysis.typeCheckingMode": "basic",
+        "editor.formatOnSave": true
+      }
+    }
+  }
+}

.github/agents/discovery-web-auditor.agent.md

@@ -0,0 +1,56 @@
+---
+name: Discovery Web Auditor
+description: "Use when discovering UX/UI/responsiveness improvements, performance/refactor opportunities, and project-aligned feature ideas by combining browser auditing with codebase analysis."
+argument-hint: "Base URL, routes/flows to inspect, project goals/audience, and focus areas (UX/UI, performance/refactor, feature ideas)"
+tools:
+  [
+    read,
+    search,
+    execute,
+    web,
+    open_browser_page,
+    navigate_page,
+    read_page,
+    click_element,
+    type_in_page,
+    hover_element,
+    screenshot_page,
+    run_playwright_code,
+  ]
+user-invocable: true
+---
+
+You are a discovery specialist for product, UX/UI, responsiveness, and engineering improvement opportunities.
+
+## Scope
+
+- Analyze the running website for UX, UI consistency, accessibility-adjacent usability, and responsiveness improvements.
+- Analyze the codebase for performance and refactor opportunities with clear user or maintainability impact.
+- Propose project-aligned feature ideas grounded in current capabilities, architecture, target audience, and repository scope.
+- Produce issue-ready findings without writing implementation code.
+
+## Constraints
+
+- Do not edit files or propose code patches.
+- Do not invent findings that are not reproducible.
+- Do not prescribe detailed implementation unless explicitly requested.
+- Do not spend effort validating basic site uptime; assume the site is running and focus on quality and opportunity discovery.
+
+## Procedure
+
+1. Build project context from README, key frontend/backend modules, and existing features.
+2. Audit critical website journeys with integrated browser tools, emphasizing UX/UI quality and responsiveness behavior.
+3. Inspect code hotspots for performance and refactor candidates using read/search and focused command-line analysis.
+4. Derive feature opportunities that are realistic for this codebase and consistent with product goals.
+5. Capture evidence for each finding: route/module, reproduction steps, observed impact, and expected outcome.
+6. Group findings into cohesive issue candidates sized for independent delivery.
+
+## Output Format
+
+Return a concise report with:
+
+1. `UX/UI/Responsiveness Findings` with severity and evidence.
+2. `Performance/Refactor Findings` with code-level context and impact.
+3. `Feature Opportunities` with rationale and user value.
+4. `Grouped Issue Candidates` with objective and expected outcome.
+5. `Clarification Questions` to resolve before issue creation.

.github/instructions/github-issues.instructions.md

@@ -0,0 +1,117 @@
+---
+name: github-issues
+applyTo: "**/*"
+description: "Use when creating or managing GitHub issues for this repository. Enforces the repo's issue creation workflow and required metadata."
+---
+
+## GitHub Issue Creation Guidelines
+
+Follow the repository's issue workflow exactly when opening new GitHub issues.
+
+- Check for existing relevant issues first using `gh issue list` to avoid duplicates.
+- Clarify scope with the user before creating the issue.
+- Use `gh issue create` to open the issue before starting implementation.
+
+### Required issue body format
+
+Each issue body must include:
+
+- `Objective`: A short statement of what the issue is intended to accomplish.
+- `Context & Symptoms`: A developer-focused description of the current problem or goal, including relevant files or behavior. Avoid prescribing a rigid technical solution.
+- `Expected Outcome`: A concise description of the wanted end state and acceptance outcome, without technical implementation details unless explicitly discussed.
+
+Do not store Priority and Size in the issue body. Manage them through GitHub Project fields.
+
+### Markdown formatting and template
+
+- Write issue bodies in GitHub Flavored Markdown.
+- Keep section order fixed: `Objective`, `Context & Symptoms`, `Expected Outcome`.
+- Use one blank line between sections and avoid trailing whitespace.
+- Use concise bullet points when listing symptoms or acceptance outcomes.
+- Keep tone human-written, specific, and repository-aware.
+
+Use this template:
+
+```markdown
+## Objective
+
+<1-3 lines describing the goal>
+
+## Context & Symptoms
+
+- <current behavior or problem>
+- <where it appears: route/module/component>
+- <impact on users/developers>
+
+## Expected Outcome
+
+- <observable end state>
+- <acceptance-oriented result>
+```
+
+### Newlines and special formatting in CLI
+
+- Prefer `gh issue create --body-file <file>` for multi-line content.
+- If creating from shell inline, prefer a heredoc with a quoted delimiter to preserve formatting exactly:
+
+```bash
+cat > /tmp/issue-body.md <<'EOF'
+## Objective
+
+...
+EOF
+
+gh issue create --title "..." --body-file /tmp/issue-body.md
+```
+
+- Avoid packing multi-line Markdown into a single `--body` string when possible.
+- When issue text includes special characters (for example `` ` ``, `$`, `*`, `_`, or `#`), use `--body-file` to avoid shell escaping errors.
+
+### Project field updates (Priority and Size)
+
+- After issue creation, set Priority and Size in the linked GitHub Project item.
+- Allowed `Size` values: `S`, `M`, `L`.
+- Assign `Size` using these measurable criteria:
+  - `S`: small scoped change, usually one flow/module, up to about 3 files touched, with localized edits or small additions.
+  - `M`: medium scoped change, usually up to 2 related flows/modules, about 4-8 files touched, with moderate additions/refactors.
+  - `L`: largest allowed single-issue scope, usually up to 3 related flows/modules, about 9-15 files touched, with substantial but cohesive changes.
+- If scope exceeds `L` (for example more than 15 files touched, more than 3 flows/modules, or would require more than one PR), split it into cohesive sub-issues before creation.
+- Allowed `Priority` values:
+  - `Urgent & Important`
+  - `Not Urgent & Important`
+  - `Urgent & Not Important`
+  - `Not Urgent & Not Important`
+- Use these exact option names when mapping to project single-select options.
+- Use CLI commands in this sequence:
+  - `gh project field-list <project-number> --owner <owner> --format json`
+  - `gh project item-list <project-number> --owner <owner> --format json`
+  - `gh project item-edit --id <item-id> --project-id <project-id> --field-id <field-id> --single-select-option-id <option-id>`
+- Use one `gh project item-edit` invocation per field update.
+
+### Multi-Issue Discussion and Creation
+
+- When multiple problems or improvement ideas are discussed in one conversation, group them into cohesive issues first.
+- Grouping and drafting are a single workflow pass: create grouped issues in the same phase once scope is clear.
+- Keep issue scope balanced: avoid very small issues and avoid giant umbrella issues.
+- Ask clarifying questions before creating issues, not after.
+- Before creating, request explicit confirmation of both:
+  - the proposed grouping
+  - the proposed issue titles and bodies
+  - the proposed Priority and Size for each issue (to be set in the project fields)
+
+### Labels and milestone
+
+- Assign type and domain labels on the Issue only.
+- Use one type label: `bug`, `enhancement`, `refactor`, or `documentation`.
+- Use one or more domain labels: `frontend`, `backend`, `performance`.
+- Assign the appropriate milestone when creating the issue.
+
+### Other workflow rules
+
+- Keep issue text objective, professional, and developer-to-developer.
+- Keep issue text concise and human-written; avoid generic AI-style phrasing.
+- Issue title and issue body must always be written in English.
+- Technical plan comments posted on GitHub must always be written in English.
+- After creating issues, do not automatically transition to technical planning unless the user explicitly asks to start planning/implementation.
+- Before coding begins for an issue, prepare a technical plan but post it as a comment only after explicit user approval.
+- If the approved plan changes later, update the existing plan comment instead of adding a new one.

.github/instructions/workflow-discovery.instructions.md

@@ -0,0 +1,14 @@
+---
+name: workflow-discovery
+description: "Use during discovery/investigation conversations: clarify current vs expected state, group issues cohesively, and create issues only after explicit user confirmation."
+---
+
+## Discovery Phase Rules
+
+- Focus on investigation, improvement discovery, and scope clarification.
+- Ask clarifying questions early and complete clarification before drafting final issue text.
+- Keep issue drafts implementation-agnostic unless the user explicitly requests technical details.
+- When multiple findings exist, group them into cohesive issue bundles in the same pass.
+- Always present grouped issue proposals and draft issue bodies for explicit user confirmation before creating issues.
+- Do not defer open clarifications to post-creation; resolve them before creating the issue set.
+- After issue creation, remain in discovery mode unless the user explicitly asks to enter planning or implementation.

.github/instructions/workflow-implementation.instructions.md

@@ -0,0 +1,25 @@
+---
+name: workflow-implementation
+description: "Use when executing approved work: implement changes, handle issue-linking edge cases, and keep GitHub plan-comment sync aligned with approved scope."
+---
+
+## Implementation Phase Rules
+
+- Enter implementation phase only when the user explicitly asks to execute changes.
+- If issue(s) are selected, proceed directly with implementation-oriented work.
+- Do not force discovery or planning again unless the user explicitly requests it.
+- Treat the root workspace repository as the repository of reference for implementation and GitHub CLI operations; do not use nested submodules as the primary repo unless the user explicitly requests it.
+- If implementation is requested with no issue provided, search open issues for likely matches and ask the user to confirm the correct issue.
+- If no matching issue is found, ask explicit confirmation before proceeding without an issue and state clearly that no issue is linked.
+- Primary plan source is the approved plan in current chat/context.
+- If no approved plan is available in current chat/context and issue(s) are selected, use approved plan comments from the linked GitHub issue(s).
+- If no approved plan exists, ask whether to return to planning phase or continue with an explicitly approved quick-fix scope.
+- At the end of implementation phase, open a pull request for the implemented changes.
+- Pull request must target branch `dev` as base branch.
+- Pull request body must include `Closes #<issue-id>` for each linked issue.
+- If browser access is available, visually verify changes on the PR preview URL `https://<pr-id>.dev.m3tacron.com`.
+- PR preview usually becomes available about 45-60 seconds after PR creation.
+- Treat the preview as ready when a PR bot comment states that preview deployment is ready; from that moment, preview URL should be accessible.
+- If preview is not yet ready, re-check PR comments and retry access before final handoff.
+- Technical plan comments posted to GitHub must always be written in English.
+- If the plan changes later, update the existing plan comment rather than adding a new one.

.github/instructions/workflow-phases.instructions.md

@@ -0,0 +1,14 @@
+---
+name: workflow-phases
+description: "Use when routing a request to discovery, planning, or implementation phase in the issue-first workflow."
+---
+
+## Phase Routing
+
+- First classify the user request as discovery phase, planning phase, or implementation phase.
+- If the user is in discovery phase, follow the discovery instruction set and do not start coding.
+- If the user asks to define or refine a technical plan, follow the planning instruction set and keep the phase implementation-free.
+- If the user asks to execute changes, follow the implementation instruction set and do not force a new discovery/planning loop unless requested.
+- If the request is ambiguous between planning and implementation, ask explicitly whether the user wants plan-only or code execution.
+- Do not move from discovery/issue-creation into technical planning unless the user explicitly asks to start planning or implementation.
+- For discovery requests that involve UX/UI/responsiveness, feature ideation, or performance/refactor scouting, proactively use or suggest `Discovery Web Auditor`.

.github/instructions/workflow-planning.instructions.md

@@ -0,0 +1,17 @@
+---
+name: workflow-planning
+description: "Use when drafting/refining technical plans: keep planning clean, avoid code implementation actions, and require explicit approval before handoff to implementation."
+---
+
+## Planning Phase Rules
+
+- Enter planning phase only when the user explicitly asks to start planning.
+- Keep this phase focused on plan definition and refinement.
+- Do not perform implementation actions in planning phase.
+- Treat the root workspace repository as the repository of reference for planning context and GitHub CLI operations; do not anchor planning to nested submodules unless the user explicitly requests it.
+- Draft plans with scope/non-goals, approach, validation strategy, and risks.
+- Ask explicit user approval on the final plan text before any implementation phase starts.
+- At the end of planning phase, post or update the approved plan as a GitHub issue comment when issue(s) are linked.
+- Follow all GitHub comment rules already defined in [GitHub Issue Instructions](./github-issues.instructions.md), including English-only and update-instead-of-duplicate behavior.
+- If no issue is linked, keep the approved plan in chat context and state clearly that no GitHub comment was posted.
+- Keep planning output ready for handoff to implementation phase.

.github/prompts/discovery-phase.prompt.md

@@ -0,0 +1,33 @@
+---
+name: Discovery Phase Audit
+description: "Use during discovery to investigate UX/UI/responsiveness improvements, performance/refactor opportunities, and project-aligned feature ideas before issue creation."
+argument-hint: "Base URL, routes/flows, project goals/audience, and focus areas"
+agent: "Discovery Web Auditor"
+---
+
+Run a discovery-phase investigation before issue creation.
+
+## Startup Behavior
+
+If prior chat context is missing or insufficient, ask the user to confirm discovery scope first:
+
+1. Which areas to focus on: UX/UI/responsiveness, performance/refactor, feature opportunities.
+2. Which routes, workflows, or modules to inspect first.
+3. Any business constraints, audience context, or priority order.
+4. Confirmation to start discovery with this scope.
+
+## Discovery Execution
+
+1. Build project understanding from repository context and existing capabilities.
+2. Investigate browser UX/UI/responsiveness quality and evidence-based improvement opportunities.
+3. Inspect code-level performance/refactor opportunities with practical impact.
+4. Propose realistic, project-aligned feature opportunities.
+5. Group findings into cohesive issue candidates.
+
+## Output
+
+Return:
+
+1. Discovery findings with evidence.
+2. Grouped issue candidates with objective and expected outcome.
+3. Clarification questions required before issue drafting/creation.