docs: Comprehensive technical audit of the OLManager codebase (post-v0.2.0)

[NicoRuedaA]

Note: This is a comprehensive technical audit of the OLManager codebase. It is intended as a reference for maintainers and contributors, and should not block the v0.2.0 release cycle.

Problem or opportunity

There is no centralized technical overview of the OLManager codebase available to contributors. New developers (and AI assistants) need to spend hours reverse-engineering the architecture, stack, conventions, and testing strategy. This audit consolidates everything into a single reference document, identifying:

• Full technology stack and version matrix
• Architecture patterns (frontend, backend, Tauri bridge, data layer)
• Testing strategy and coverage gaps
• Code quality assessment (TypeScript strictness, Rust patterns, clean architecture)
• Feature inventory (30+ features mapped to files)
• Security posture (CSP, audits, input validation)
• CI/CD pipeline analysis
• Key risks and recommendations for v0.3.0-beta readiness

Proposed solution

Use this audit as the foundation for:

1. CONTRIBUTING.md enhancements — Add an "Architecture Overview" section linking to this analysis.
2. docs/ARCHITECTURE.md updates — Refresh with current stack versions and crate diagrams.
3. Team onboarding — New contributors can read this instead of grepping 536 source files.
4. Roadmap prioritization — The identified risks (CSP disabled, lol_sim_v2.rs monolith, CI non-blocking) feed directly into v0.3 planning.

Architecture Summary

Stack: React 19 + TypeScript 6.0 + Vite 8 + Tailwind CSS 4 (frontend) | Rust edition 2024 workspace with 4 crates + Tauri 2.10 (backend) | SQLite (rusqlite) | Zustand | i18next (8 locales)

Frontend (347 TS files):

• Feature-based component structure (~36 subdirectories)
• Zustand stores (gameStore, settingsStore)
• Typed service layer over Tauri IPC (10 services)
• Lazy-loaded pages with react-router-dom 7
• 117 test files (Vitest + Testing Library + jsdom)

Backend (189 Rust files):

• domain crate — Pure types, serializable, ts-rs feature flag for TS generation
• engine crate — Match simulation (pure, no I/O)
• ofm_core crate — Game logic (43 modules, ~100+ Tauri commands)
• db crate — SQLite persistence (52 migrations, 15 repositories)
• StateManager with Mutex<Session> (single-lock pattern)

Data Layer:

• 52 SQLite migrations (V1–V51)
• Per-save .db files with SHA2 checksums
• Legacy migration path from OpenFootManager
• Deterministic player stat generation from IGN hash

Testing Capabilities

Capability	Status
Test Runner (TS)	Vitest 4.1.2 ✅
Test Runner (Rust)	cargo test ✅
Unit Tests	✅ (117 TS + 22 Rust files)
Integration Tests	✅ (@testing-library/react + Rust integration tests)

| Coverage (TS) | ✅ @vitest/coverage-v8 |
| Coverage (Rust) | ❌ Not configured |
| Linter (Rust) | ✅ cargo clippy |
| Type Checker (TS) | ✅ tsc --noEmit strict mode |

⚠️ CI Issue: cargo test for the main openleaguemanager crate is skipped in CI due to lol_sim_v2.rs blocking compilation.

Code Quality Assessment

Strengths:

• TypeScript strict mode enabled (strict, noUnusedLocals, noUnusedParameters, noFallthroughCasesInSwitch)
• Rust clean architecture separation (domain → engine → ofm_core → db)
• ts-rs for automatic Rust→TypeScript type generation
• 52 well-structured SQLite migrations
• Single-lock StateManager prevents deadlocks
• Auto-updater integrated (Tauri plugin)
• Legacy migration path maintained

Concerns:

• TypeScript 6.0 is bleeding edge and may have stability issues
• Rust edition 2024 is very new; monitor compatibility
• lol_sim_v2.rs is 6,376 lines — monolithic, blocks tests
• transfers.rs is 2,104 lines — should be split
• team.rs domain is 1,266 lines with ~50 fields
• store/types.ts is 843 lines with manual type duplication
• Clippy warnings suppressed in domain and engine crates
• LegacyCompatibilityValue = any breaks type safety

Security Posture

Aspect	Status
CSP	🔴 Disabled ("csp": null)
SQL Injection	✅ Prevented (parameterized queries)
Input Validation	🟡 Partial (validator crate available but inconsistently used)
Error Disclosure	✅ Controlled (AppError with i18n codes)
Secrets Management	✅ Documented in SECURITY.md
Safe File Handling	✅ Correct (path sanitization via app_data_dir())
npm/cargo Audit in CI	🟡 Runs but continue-on-error: true — does not block PRs
Dependabot/CodeQL	❌ Not configured

Key Recommendations

1. Enable CSP in tauri.conf.json — critical security gap
2. Refactor lol_sim_v2.rs — split into modules, unblock cargo test in CI
3. Make CI blocking — remove continue-on-error from clippy, fmt, and security audits
4. Add Rust coverage — configure cargo test with coverage reporting
5. Configure Dependabot for automatic security updates
6. Review Tauri capabilities (capabilities/default.json) for minimum privilege

Acceptance criteria

• This audit is reviewed by at least one core maintainer for accuracy.
• Any factual errors or outdated information is corrected.
• Actionable recommendations are converted into separate issues (CSP, lol_sim_v2 refactor, CI tightening).
• docs/ARCHITECTURE.md is updated to reflect current stack versions.
• New contributors can onboard using this audit + existing docs without reverse-engineering the codebase.

Scope

Documentation

Approval pre-flight

• I searched existing issues and did not find a duplicate.
• I understand maintainers must add status:approved before a PR is opened.
• I will branch from development using type/lowercase-slug if this is approved.
• I identified whether this changes docs, release behavior, licensing, or data provenance.