---

description: Project goals, roles, architecture guidelines, and privacy for DojoSphere alwaysApply: true

DojoSphere — Project Overview

Open-source Electron application for organizing small judo tournaments in clubs and local competition settings. Target audience: volunteer organizers without commercial tournament software.

Vision and user roles

| Role | Device | Responsibility | | ----------------------- | ------------------------- | ----------------------------------------------------------------------------------- | | Tournament director | Host computer (Electron) | Starts the app, registers competitors and mat count, manages the tournament | | Scorekeeper | Separate computer/browser | Connects via URL to the host; access only after approval | | Audience | Browser on intranet | Views overview via URL or QR code — without approval by the tournament director |

Planned flow (prospective)

1. Tournament director starts the Electron application on the host computer.
2. Competitors and mat count are recorded locally.
3. Scorekeepers open a URL on the intranet and send a request to the host.
4. Tournament director approves the request and assigns a mat.
5. The audience opens the overview via URL/QR code on the intranet — read-only, no approval.

When building new features, consider these roles and the approval flow: scorekeeper = protected access, audience = public overview on the LAN.

Technical guidelines

• Frontend: Vue 3 (open source, suitable for club projects), Vuetify, Vue Router, vue-i18n
• Desktop: Electron — primary application for the tournament director
• Local-first data: SQLite in the Electron main process; renderer accesses only via IPC/preload
• Cloud optional: Supabase for authentication and cloud storage/sync — configuration and sync in Settings
• Monitoring: Local error log (app.log) + SQLite audit; optional cloud diagnostic toggle (no upload yet)

Data storage and sync

• Primary: local SQLite database on the host (<userData>/database.db)
• Error log (local): <userData>/logs/app.log
• Optional: cloud sync via Supabase after sign-in — manual/automatic control in Settings
• Offline/local-first behavior takes precedence: the app must work without cloud
• Sync logic and conflict handling belong in Settings or dedicated feature slices — not scattered in UI components

Security and GDPR

Tournament competitors are natural persons — protect personal data:

• No sensitive data in plaintext when storing or transmitting (hashed passwords, secure tokens, no PII in logs/monitoring)
• Minimal data collection: only what is needed for tournament operations
• Cloud sync only with authentication; secure access rights server-side (RLS with Supabase)
• Intranet access (scorekeepers/audience) on the LAN — still avoid unnecessary exposure of personal data in URLs or client storage
• For new fields/endpoints, check: storage location (local vs. cloud), consent, deletability, encryption where appropriate

Scope notes for implementation

• Small tournaments: simple operation for volunteers matters more than enterprise features
• Tournament director workflow (Electron) and browser clients (scorekeepers/audience) are separate access paths — shared domain logic, different UI/permissions
• i18n for all UI text; no hardcoded strings
• Open Source (MIT): consider club compatibility for code and dependencies