add tasks

Author: stringhandler

meta/tasks/backlog/background-parse-unparsed-matches.md

@@ -0,0 +1,37 @@
+# Background Parse Unparsed Matches
+
+## Summary
+
+When the app is running, automatically parse any stored matches that are still unparsed — at a slow, throttled rate — so that over time the local database is fully parsed without triggering OpenDota's rate limits.
+
+## Motivation
+
+Users may have hundreds of matches in the database that were fetched but never parsed (e.g. backfilled history, or matches where parsing was skipped). Today, parsing is manual. This task makes parsing happen automatically in the background so goal evaluation and analysis are accurate without user intervention.
+
+## Acceptance Criteria
+
+- On app start (or shortly after), the backend checks for matches with `parsed = 0` (or `parsed IS NULL`) in the database.
+- It processes one unparsed match at a time, with a configurable delay between requests (default: **10 seconds** between parse attempts).
+- If OpenDota returns a rate-limit error (HTTP 429), the background parser backs off and retries after a longer delay (e.g. 60 seconds).
+- The parser stops when all matches are parsed, and restarts the next time the app launches.
+- Parsing runs on a background Tokio task; it does **not** block the UI.
+- The user sees no mandatory notification, but a subtle indicator (e.g. status text in Settings or footer) can optionally show "Parsing X matches in background…".
+- The feature can be paused/disabled in Settings if the user doesn't want background network activity.
+
+## Implementation Notes
+
+- Tauri command to query `SELECT id FROM matches WHERE parsed = 0 ORDER BY match_id DESC` (newest first, so recent matches are parsed sooner).
+- Spawn a `tokio::spawn` background loop at app startup (in `lib.rs` setup or via a dedicated `start_background_parser` command called from the frontend on mount).
+- Use `tokio::time::sleep(Duration::from_secs(10))` between parse calls.
+- On 429, sleep 60 s before retrying the same match.
+- Reuse the existing `parse_match` / `request_parse` OpenDota logic.
+- Consider adding a `parsing_in_progress` boolean to settings/state so the frontend can show a subtle indicator.
+
+## Rate Limit Guidance
+
+OpenDota free tier allows roughly 60 requests/minute. Parsing a match typically requires 1–2 calls. At 10 s between matches this is well within limits. At 5 s it is still safe but leaves less headroom.
+
+## Out of Scope
+
+- Prioritising specific matches for immediate parse (manual parse button still handles that).
+- Showing a detailed parse queue UI.

meta/tasks/bugs/database-locked-concurrent-connections.md

@@ -0,0 +1,57 @@
+# Bug: "Failed to delete data, the database is locked"
+
+## Symptom
+
+Users (and the dev) see warnings/errors like:
+
+> Failed to delete data, the database is locked
+
+This occurs intermittently, typically when multiple Tauri commands run concurrently (e.g. on app startup when the frontend calls several commands at once).
+
+## Root Cause
+
+Every Tauri command calls `init_db()` to open a **new** `rusqlite::Connection`. SQLite uses file-level write locking — only one writer can hold the lock at a time. When multiple async Tauri commands are in flight simultaneously, each with its own connection, any that try to write while another holds the lock will fail immediately with `SQLITE_BUSY` ("database is locked").
+
+This is a structural issue: the pattern of opening a new connection per command call is inherently unsafe under concurrency.
+
+## Fix
+
+Replace the per-command `init_db()` call pattern with a **single shared connection** protected by a `Mutex`, stored in Tauri's managed state.
+
+```rust
+// In lib.rs
+use std::sync::Mutex;
+use rusqlite::Connection;
+
+pub struct DbState(pub Mutex<Connection>);
+```
+
+Register it at app startup:
+
+```rust
+tauri::Builder::default()
+    .manage(DbState(Mutex::new(database::init_db().expect("DB init failed"))))
+    // ...
+```
+
+Each command receives it via `State`:
+
+```rust
+#[tauri::command]
+async fn my_command(state: tauri::State<'_, DbState>) -> Result<..., String> {
+    let conn = state.0.lock().map_err(|e| e.to_string())?;
+    // use &*conn
+}
+```
+
+This serializes all DB access through one connection, eliminating concurrent-write races entirely. The `Mutex` ensures only one command touches the DB at a time.
+
+## Additional Hardening (optional, do after the fix)
+
+- Set `PRAGMA journal_mode=WAL` after opening the connection. WAL allows concurrent readers with a single writer and dramatically reduces lock contention if we ever move to a connection pool.
+- Set `PRAGMA busy_timeout=5000` as a belt-and-suspenders measure so SQLite waits up to 5 s before returning SQLITE_BUSY instead of failing immediately.
+
+## Affected Area
+
+`src-tauri/src/lib.rs` — all ~35 `let conn = init_db()?;` call sites.
+`src-tauri/src/database.rs` — `init_db()` function.

meta/tasks/upnext/beta-release-channel.md

@@ -0,0 +1,85 @@
+# Beta Release Channel
+
+## Summary
+
+Introduce a separate **beta build** of Dota Keeper alongside the stable build, so new features can be tested with opt-in users without risking breakage for everyone on the stable track.
+
+## Decision: Separate Build (not a channel toggle)
+
+A **fully separate beta build** is the right approach rather than a runtime setting that switches the update URL. Reasons:
+
+- A bad beta update can't accidentally land on a stable installation.
+- The beta can (and should) use a separate database so beta data doesn't pollute stable saves.
+- It installs side-by-side — you can run both at the same time.
+- CI can publish beta releases independently without touching the stable update manifest.
+
+A "switch update channel in settings" approach is tempting but dangerous: if the beta update itself is broken you can't roll back via the updater.
+
+## What Needs to Change
+
+### 1. Tauri Config (`tauri.conf.json` → new `tauri.beta.conf.json`)
+
+```json
+{
+  "productName": "Dota Keeper Beta",
+  "identifier": "com.volthawk.dota-keeper-beta",
+  "plugins": {
+    "updater": {
+      "endpoints": [
+        "https://raw.githubusercontent.com/stringhandler/dota-keeper/main/meta/autoupdate/latest-beta.json"
+      ]
+    }
+  }
+}
+```
+
+Key differences vs stable:
+- `productName`: `"Dota Keeper Beta"` — shows "Beta" in title bar and taskbar
+- `identifier`: `com.volthawk.dota-keeper-beta` — separate OS install, separate registry entry
+- `endpoints`: points to `latest-beta.json` instead of `latest.json`
+
+### 2. Database Separation (`database.rs`)
+
+The database name is already `dota_keeper.db` for release and `dota_keeper_dev.db` for dev. Add a third variant for beta: `dota_keeper_beta.db`.
+
+Detect via a compile-time feature flag or a `DOTA_KEEPER_BETA` env var set in the beta build script.
+
+### 3. New Autoupdate Manifest (`meta/autoupdate/latest-beta.json`)
+
+Same structure as `latest.json`. CI populates this on every beta release.
+
+### 4. CI / GitHub Actions
+
+Add a `release-beta.yml` workflow (or a conditional path in the existing `release.yml`) that mirrors the existing `release` branch workflow:
+- Triggers on pushes to the `beta` branch (same pattern as `release` → stable)
+- Builds using `tauri.beta.conf.json`
+- Publishes artifacts as a GitHub **pre-release**
+- Updates `meta/autoupdate/latest-beta.json` and commits/pushes it to `main`
+
+Stable releases continue to trigger on pushes to `release` and update `latest.json`.
+
+### 5. Window Title / Visual Indicator
+
+Add a subtle "BETA" badge in the custom title bar (or window title string) when running the beta build, so it's obvious which version is open.
+
+## Release Flow
+
+```
+main (dev work)
+  │
+  ├─► merge to beta branch
+  │     → CI builds beta → GitHub pre-release + latest-beta.json updated
+  │     → beta users auto-update
+  │
+  └─► (after testing) merge beta → release branch
+        → CI builds stable → GitHub release + latest.json updated
+        → stable users auto-update
+```
+
+This mirrors the existing `release` branch pattern — no tags needed, the branch push is the release trigger.
+
+## Out of Scope
+
+- In-app channel switching (too risky, decided against above)
+- Android / iOS beta tracks (separate concern)
+- Crash reporting / telemetry differences between tracks