wip
This commit is contained in:
20
ROADMAP.md
20
ROADMAP.md
@@ -1,20 +0,0 @@
|
|||||||
# Roadmap
|
|
||||||
|
|
||||||
## IRacing Selectors Update (2025-11-27)
|
|
||||||
|
|
||||||
**Summary:** Fixed 15 selectors against [`html-dumps-optimized/iracing-hosted-sessions/`](html-dumps-optimized/iracing-hosted-sessions/) dumps per [`IRacingSelectors-update-plan.md`](packages/infrastructure/adapters/automation/IRacingSelectors-update-plan.md).
|
|
||||||
|
|
||||||
**Key changes:**
|
|
||||||
- Critical (adminList → step-specific tables; sliders → label-proximity)
|
|
||||||
- Recommended (chakra- prefixes, label~inputs)
|
|
||||||
- BLOCKED_SELECTORS unchanged/safe.
|
|
||||||
|
|
||||||
**Verification:**
|
|
||||||
- 4 unit tests green in [`IRacingSelectors.test.ts`](packages/infrastructure/adapters/automation/IRacingSelectors.test.ts)
|
|
||||||
- Debug verified 70+ matches across 18 dumps.
|
|
||||||
|
|
||||||
**Artifacts:**
|
|
||||||
- [`IRacingSelectors-update-plan.md`](packages/infrastructure/adapters/automation/IRacingSelectors-update-plan.md)
|
|
||||||
- updated comments in [`IRacingSelectors.ts`](packages/infrastructure/adapters/automation/IRacingSelectors.ts) "VERIFIED against html-dumps-optimized 2025-11-27"
|
|
||||||
|
|
||||||
**Next:** E2E automation integration.
|
|
||||||
1624
docs/ARCHITECTURE.md
1624
docs/ARCHITECTURE.md
File diff suppressed because it is too large
Load Diff
402
docs/CONCEPT.md
402
docs/CONCEPT.md
@@ -1,402 +0,0 @@
|
|||||||
# GridPilot Concept
|
|
||||||
|
|
||||||
## Problem Statement
|
|
||||||
|
|
||||||
iRacing league management today is fragmented and manual:
|
|
||||||
|
|
||||||
- **Communication Chaos**: League organizers juggle Discord channels, Google Sheets, and manual messaging to coordinate everything
|
|
||||||
- **No Visibility**: Leagues operate in isolation without a central platform for discovery or branding
|
|
||||||
- **Manual Burden**: Admins spend hours manually entering race results, managing registrations, and creating sessions in iRacing
|
|
||||||
- **Team Racing Limitations**: No native support for team-based racing with parallel scoring (one driver per car slot, but team accumulates points)
|
|
||||||
- **Session Creation Pain**: Creating race sessions in iRacing requires tedious browser navigation and form filling
|
|
||||||
- **Migration Challenges**: Existing leagues can't easily migrate historical data or preserve their identity
|
|
||||||
|
|
||||||
Based on feedback from Reddit and Discord communities, league organizers are overwhelmed by administrative tasks when they'd rather focus on building community and running great racing events.
|
|
||||||
|
|
||||||
## Target Users
|
|
||||||
|
|
||||||
### League Organizers & Admins
|
|
||||||
**What they need:**
|
|
||||||
- Automated race result processing
|
|
||||||
- Easy session creation without manual browser work
|
|
||||||
- Tools to manage seasons, sign-ups, and standings
|
|
||||||
- Professional branding and identity for their league
|
|
||||||
- Custom domains to strengthen league identity
|
|
||||||
- Migration support to bring existing league history
|
|
||||||
|
|
||||||
### Team Captains
|
|
||||||
**What they need:**
|
|
||||||
- Create and manage racing teams
|
|
||||||
- Register teams for league seasons
|
|
||||||
- Track team standings alongside driver standings
|
|
||||||
- Coordinate with team drivers
|
|
||||||
- View team performance history
|
|
||||||
|
|
||||||
### Solo Drivers
|
|
||||||
**What they need:**
|
|
||||||
- Browse and discover active leagues
|
|
||||||
- Easy registration and sign-up flows
|
|
||||||
- Personal statistics and race history
|
|
||||||
- Track standings and points
|
|
||||||
- Connect with the racing community
|
|
||||||
|
|
||||||
## Core Features
|
|
||||||
|
|
||||||
### For Solo Drivers
|
|
||||||
|
|
||||||
**League Discovery**
|
|
||||||
- Browse active leagues across different series and skill levels
|
|
||||||
- Filter by time zones, competitiveness, and racing format
|
|
||||||
- Join leagues with simple registration flows
|
|
||||||
|
|
||||||
**Personal Racing Stats**
|
|
||||||
- Automatic race result tracking from iRacing
|
|
||||||
- Historical performance data
|
|
||||||
- Personal standings in each league
|
|
||||||
- Progress tracking across seasons
|
|
||||||
|
|
||||||
### For Teams
|
|
||||||
|
|
||||||
**Team Management**
|
|
||||||
- Create and name racing teams
|
|
||||||
- Invite and manage team drivers
|
|
||||||
- Register teams for league seasons
|
|
||||||
|
|
||||||
**Parallel Racing Format**
|
|
||||||
- One driver per car slot in each race
|
|
||||||
- Team points accumulate from all drivers' results
|
|
||||||
- Both team standings and individual driver standings
|
|
||||||
- Flexibility for different drivers each race
|
|
||||||
|
|
||||||
**Team Identity**
|
|
||||||
- Team branding and profiles
|
|
||||||
- Historical team performance tracking
|
|
||||||
- Team communication tools
|
|
||||||
|
|
||||||
### For League Organizers
|
|
||||||
|
|
||||||
**League Identity & Branding**
|
|
||||||
- Professional league pages with custom branding
|
|
||||||
- Custom domain support (e.g., your-league.racing)
|
|
||||||
- League logos, colors, and identity
|
|
||||||
- Public-facing presence for member recruitment
|
|
||||||
|
|
||||||
**Race Management**
|
|
||||||
- Automated result importing from iRacing
|
|
||||||
- No manual CSV uploads or data entry
|
|
||||||
- Session result processing tied to league structure
|
|
||||||
- Point calculations handled automatically
|
|
||||||
|
|
||||||
**Season Administration**
|
|
||||||
- Create and manage racing seasons
|
|
||||||
- Define scoring rules and formats
|
|
||||||
- Handle sign-ups and registrations
|
|
||||||
- Configure team vs solo racing formats
|
|
||||||
|
|
||||||
**Authentication & Security**
|
|
||||||
- Zero-knowledge login: GridPilot never sees or stores your password
|
|
||||||
- User performs login in visible browser window
|
|
||||||
- Persistent sessions: login once, stay logged in
|
|
||||||
- Secure access control for league admin functions
|
|
||||||
|
|
||||||
### Migration Support
|
|
||||||
|
|
||||||
**For Existing Leagues**
|
|
||||||
- Import historical season data
|
|
||||||
- Preserve league identity and history
|
|
||||||
- Maintain continuity for established communities
|
|
||||||
- Smooth transition without losing context
|
|
||||||
|
|
||||||
## User Journeys
|
|
||||||
|
|
||||||
### Admin Creating a League
|
|
||||||
|
|
||||||
1. Sign in with iRacing credentials
|
|
||||||
2. Create new league with name and branding
|
|
||||||
3. Choose racing series and car/track combinations
|
|
||||||
4. Configure season format (team vs solo, point system)
|
|
||||||
5. Set up custom domain (optional)
|
|
||||||
6. Open registration for drivers/teams
|
|
||||||
7. Publish league page for discovery
|
|
||||||
|
|
||||||
### Team Registering for a Season
|
|
||||||
|
|
||||||
1. Team captain browses available leagues
|
|
||||||
2. Reviews league format and schedule
|
|
||||||
3. Registers team for upcoming season
|
|
||||||
4. Invites or confirms team drivers
|
|
||||||
5. Receives confirmation and season details
|
|
||||||
6. Team appears in league roster
|
|
||||||
|
|
||||||
### Driver Viewing Standings
|
|
||||||
|
|
||||||
1. Driver logs into GridPilot
|
|
||||||
2. Navigates to their league dashboard
|
|
||||||
3. Views current season standings (team and driver)
|
|
||||||
4. Reviews recent race results
|
|
||||||
5. Checks upcoming race schedule
|
|
||||||
6. Accesses historical performance data
|
|
||||||
|
|
||||||
### Organizer Managing Race Day
|
|
||||||
|
|
||||||
1. Admin creates race session through GridPilot
|
|
||||||
2. Session automatically appears in iRacing
|
|
||||||
3. Drivers join and race in iRacing
|
|
||||||
4. Race completes in iRacing
|
|
||||||
5. GridPilot automatically imports results
|
|
||||||
6. Points calculated and standings updated
|
|
||||||
7. Admin reviews and publishes results
|
|
||||||
8. Drivers see updated standings immediately
|
|
||||||
|
|
||||||
## Automation Vision
|
|
||||||
|
|
||||||
### Why Browser Automation?
|
|
||||||
|
|
||||||
iRacing doesn't provide public APIs for session creation or comprehensive result data. League admins currently face:
|
|
||||||
- Repetitive browser navigation to create each race session
|
|
||||||
- Manual form filling for every session detail
|
|
||||||
- Time-consuming workflows that scale poorly with league size
|
|
||||||
- Error-prone manual processes
|
|
||||||
|
|
||||||
### What Automation Solves
|
|
||||||
|
|
||||||
**Session Creation Pain**
|
|
||||||
- Eliminate manual browser work
|
|
||||||
- Create sessions from GridPilot with one click
|
|
||||||
- Batch session creation for full seasons
|
|
||||||
- Consistent configuration without human error
|
|
||||||
|
|
||||||
**Result Processing**
|
|
||||||
- Automatic result imports from iRacing
|
|
||||||
- No manual CSV downloads or uploads
|
|
||||||
- Real-time standings updates
|
|
||||||
- Accurate point calculations
|
|
||||||
|
|
||||||
### Assistant-Style Approach
|
|
||||||
|
|
||||||
GridPilot acts as an admin assistant, not a bot:
|
|
||||||
- Automation runs on admin's behalf with their authorization
|
|
||||||
- Clear opt-in for automation features
|
|
||||||
- Admin maintains full control and visibility
|
|
||||||
- Automation handles tedious tasks, not gameplay
|
|
||||||
|
|
||||||
### Important Boundary
|
|
||||||
|
|
||||||
**We automate admin tasks, not gameplay.**
|
|
||||||
|
|
||||||
GridPilot automates league management workflows - creating sessions, processing results, managing registrations. We never touch actual racing gameplay, driver behavior, or in-race activities. This is administrative automation to free organizers from manual work.
|
|
||||||
|
|
||||||
### iRacing Automation Rules
|
|
||||||
|
|
||||||
Understanding the distinction between iRacing's interfaces is critical:
|
|
||||||
|
|
||||||
**Two iRacing Interfaces:**
|
|
||||||
|
|
||||||
1. **iRacing Website (members.iracing.com)**: This is a standard HTML/DOM web application where hosted session management lives. Being a standard web application, it can be automated with browser automation tools like Playwright. This is 100% legal.
|
|
||||||
|
|
||||||
2. **iRacing Desktop App (Electron)**: The racing simulation itself runs in a sandboxed Electron application. Its DOM is inaccessible, and any modification violates iRacing's Terms of Service. This is why tools like iRefined were shut down.
|
|
||||||
|
|
||||||
**Our Approach:**
|
|
||||||
- ✅ **Browser automation of the website** - Playwright automates members.iracing.com for session creation, form filling, and data extraction
|
|
||||||
- ❌ **Never modify the desktop client** - No DOM injection, no script injection, no client modification
|
|
||||||
|
|
||||||
**Why This Matters:**
|
|
||||||
- iRacing explicitly allows third-party tools that interact with their website
|
|
||||||
- Client modification (like iRefined did) violates TOS and risks account bans
|
|
||||||
- Browser automation is reliable, testable, and fully compliant
|
|
||||||
|
|
||||||
## Security & Authentication
|
|
||||||
|
|
||||||
### Zero-Knowledge Login Design
|
|
||||||
|
|
||||||
GridPilot requires access to your iRacing account to automate session creation, but **we never see, store, or transmit your password**. This section explains how we achieve secure authentication while maintaining complete transparency.
|
|
||||||
|
|
||||||
### The Trust Problem
|
|
||||||
|
|
||||||
When an app asks for your credentials, you're trusting that app with your identity. Many apps:
|
|
||||||
- Store passwords in databases (risk of breach)
|
|
||||||
- Transmit credentials through their servers (man-in-the-middle risk)
|
|
||||||
- Have access to your login data internally (insider risk)
|
|
||||||
|
|
||||||
GridPilot takes a fundamentally different approach: **we never have access to your credentials at all**.
|
|
||||||
|
|
||||||
### How GridPilot Authentication Works
|
|
||||||
|
|
||||||
```
|
|
||||||
┌─────────────────────────────────────────────────────────────────┐
|
|
||||||
│ USER'S COMPUTER │
|
|
||||||
│ ┌───────────────┐ ┌─────────────────────────────────┐ │
|
|
||||||
│ │ GridPilot │ │ Playwright Browser Window │ │
|
|
||||||
│ │ Companion │────────▶│ (Visible to User) │ │
|
|
||||||
│ │ App │ │ │ │
|
|
||||||
│ │ │ │ ┌─────────────────────────┐ │ │
|
|
||||||
│ │ Cannot read │ │ │ iRacing Login Page │ │ │
|
|
||||||
│ │ form inputs │ │ │ members.iracing.com │ │ │
|
|
||||||
│ │ │ │ │ │ │ │
|
|
||||||
│ │ Only detects │ │ │ [Email: *********** ] │ │ │
|
|
||||||
│ │ URL changes │ │ │ [Password: ******** ] │ │ │
|
|
||||||
│ │ │ │ │ [ Sign In ] │ │ │
|
|
||||||
│ └───────────────┘ │ └─────────────────────────┘ │ │
|
|
||||||
│ └─────────────────────────────────┘ │
|
|
||||||
└─────────────────────────────────────────────────────────────────┘
|
|
||||||
│
|
|
||||||
│ HTTPS
|
|
||||||
▼
|
|
||||||
┌─────────────────────┐
|
|
||||||
│ iRacing Servers │
|
|
||||||
│ (Direct connection │
|
|
||||||
│ from browser) │
|
|
||||||
└─────────────────────┘
|
|
||||||
```
|
|
||||||
|
|
||||||
**Step-by-Step Flow:**
|
|
||||||
|
|
||||||
1. **User clicks "Connect to iRacing"** in GridPilot
|
|
||||||
2. **A real browser window opens** showing the iRacing login page
|
|
||||||
3. **User verifies the URL** - it's the real `members.iracing.com`
|
|
||||||
4. **User enters credentials directly** - GridPilot cannot read input fields
|
|
||||||
5. **iRacing authenticates the user** - credentials go directly to iRacing
|
|
||||||
6. **GridPilot detects success** - only by observing the URL change
|
|
||||||
7. **Browser session is saved locally** - for future automation runs
|
|
||||||
|
|
||||||
### What GridPilot CAN and CANNOT Do
|
|
||||||
|
|
||||||
| Capability | GridPilot Access |
|
|
||||||
|------------|------------------|
|
|
||||||
| Read your password | ❌ **Never** |
|
|
||||||
| See what you type | ❌ **Never** |
|
|
||||||
| Intercept credentials | ❌ **Never** |
|
|
||||||
| Know if login succeeded | ✅ By URL change only |
|
|
||||||
| Use authenticated session | ✅ For automation only |
|
|
||||||
| Clear your session | ✅ User-initiated logout |
|
|
||||||
|
|
||||||
### Session Persistence
|
|
||||||
|
|
||||||
After your first login, GridPilot saves the browser session locally on your computer:
|
|
||||||
|
|
||||||
- **Location**: Your user data folder (not transmitted anywhere)
|
|
||||||
- **Contents**: Browser cookies and state (encrypted by OS)
|
|
||||||
- **Benefit**: You don't need to login every time you use GridPilot
|
|
||||||
- **Control**: You can sign out anytime to clear the saved session
|
|
||||||
|
|
||||||
**Session Lifecycle:**
|
|
||||||
|
|
||||||
```
|
|
||||||
First Use Return Visit Session Expired
|
|
||||||
│ │ │
|
|
||||||
▼ ▼ ▼
|
|
||||||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
|
||||||
│ Login │ │ Check │ │ Detect │
|
|
||||||
│ Required│ │ Session │ │ Expiry │
|
|
||||||
└────┬────┘ └────┬────┘ └────┬────┘
|
|
||||||
│ │ │
|
|
||||||
▼ ▼ ▼
|
|
||||||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
|
||||||
│ Browser │ │ Valid? │───Yes────▶ │ Ready │
|
|
||||||
│ Login │ └────┬────┘ │ to Use │
|
|
||||||
└────┬────┘ │ No └─────────┘
|
|
||||||
│ │ │
|
|
||||||
▼ ▼ ▼
|
|
||||||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
|
||||||
│ Save │ │ Re-auth │ │ Pause │
|
|
||||||
│ Session │ │ Prompt │ │ & Prompt│
|
|
||||||
└────┬────┘ └─────────┘ └─────────┘
|
|
||||||
│
|
|
||||||
▼
|
|
||||||
┌─────────┐
|
|
||||||
│ Ready │
|
|
||||||
│ to Use │
|
|
||||||
└─────────┘
|
|
||||||
```
|
|
||||||
|
|
||||||
### User Verification Points
|
|
||||||
|
|
||||||
At every step, you can verify GridPilot's behavior:
|
|
||||||
|
|
||||||
1. **Browser Window**: You see the real browser - not an embedded frame
|
|
||||||
2. **URL Bar**: Verify you're on `members.iracing.com` (look for HTTPS lock)
|
|
||||||
3. **Network Traffic**: Your credentials go directly to iRacing's servers
|
|
||||||
4. **Input Fields**: GridPilot cannot inject JavaScript to read form values
|
|
||||||
5. **Logout Control**: You can sign out from GridPilot at any time
|
|
||||||
|
|
||||||
### Session Expiry During Automation
|
|
||||||
|
|
||||||
If your iRacing session expires while automation is running:
|
|
||||||
|
|
||||||
1. **Automation pauses** - no data loss
|
|
||||||
2. **You're prompted to re-authenticate** - same secure flow
|
|
||||||
3. **Automation resumes** - from where it left off
|
|
||||||
|
|
||||||
GridPilot never stores credentials to "auto-retry" - you always maintain control.
|
|
||||||
|
|
||||||
### Security Guarantees
|
|
||||||
|
|
||||||
| Guarantee | How We Ensure It |
|
|
||||||
|-----------|------------------|
|
|
||||||
| Zero-knowledge | Playwright browser is sandboxed; we cannot inject credential-reading code |
|
|
||||||
| No transmission | Your login happens directly with iRacing; GridPilot servers never see traffic |
|
|
||||||
| Local storage only | Session data stays on your computer, encrypted by your OS |
|
|
||||||
| User control | You can logout, clear sessions, or revoke access anytime |
|
|
||||||
| Transparency | Browser window is visible; you see exactly what's happening |
|
|
||||||
|
|
||||||
### Comparison to Other Approaches
|
|
||||||
|
|
||||||
| Approach | Password Exposure | Risk Level |
|
|
||||||
|----------|-------------------|------------|
|
|
||||||
| **GridPilot (Zero-Knowledge)** | Never exposed | ✅ Minimal |
|
|
||||||
| OAuth (if iRacing offered it) | Never exposed | ✅ Minimal |
|
|
||||||
| Password stored in app | App has access | ⚠️ Moderate |
|
|
||||||
| Password in config file | File has plaintext | ❌ High |
|
|
||||||
|
|
||||||
### Technical Implementation
|
|
||||||
|
|
||||||
For developers interested in the implementation details, see [ARCHITECTURE.md](./ARCHITECTURE.md). Key points:
|
|
||||||
|
|
||||||
- **Playwright BrowserContext**: Manages browser state including cookies
|
|
||||||
- **Persistent Context**: Saved to `app.getPath('userData')` in Electron
|
|
||||||
- **Session Validation**: Navigates to protected page; detects login redirects
|
|
||||||
- **No Credential Ports**: Application layer has no interfaces for password handling
|
|
||||||
|
|
||||||
## Future Vision
|
|
||||||
|
|
||||||
### Monetization Approach
|
|
||||||
|
|
||||||
GridPilot will introduce optional monetization features after the core platform is stable:
|
|
||||||
|
|
||||||
**League Operation Fees**
|
|
||||||
- Organizers can charge season entry fees
|
|
||||||
- Both one-time and per-race payment options
|
|
||||||
- Revenue split between league and GridPilot platform
|
|
||||||
- Support for league sustainability and prizes
|
|
||||||
|
|
||||||
**Platform Position**
|
|
||||||
- GridPilot takes a percentage of collected fees
|
|
||||||
- No fees for free leagues
|
|
||||||
- Transparent pricing structure
|
|
||||||
- Revenue supports platform development and hosting
|
|
||||||
|
|
||||||
### When Monetization Arrives
|
|
||||||
|
|
||||||
Monetization features will be added only after:
|
|
||||||
- Core functionality is proven stable
|
|
||||||
- User base is established and growing
|
|
||||||
- League organizers are successfully using the platform
|
|
||||||
- Feedback confirms value justifies pricing
|
|
||||||
|
|
||||||
The focus now is delivering a great product that solves real problems. Monetization comes later when the platform has earned it.
|
|
||||||
|
|
||||||
### Potential Expansion
|
|
||||||
|
|
||||||
Beyond iRacing, GridPilot's approach could extend to:
|
|
||||||
- Other sim racing platforms
|
|
||||||
- Different racing series and formats
|
|
||||||
- Broader motorsport league management
|
|
||||||
- Cross-platform racing communities
|
|
||||||
|
|
||||||
But first: nail the iRacing league management experience.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
GridPilot exists to make league racing accessible and professional for organizers of all sizes, eliminating manual work so communities can focus on what matters: great racing and strong communities.
|
|
||||||
|
|
||||||
*Last Updated: 2025-11-23*
|
|
||||||
701
docs/ROADMAP.md
701
docs/ROADMAP.md
@@ -1,466 +1,289 @@
|
|||||||
# GridPilot Implementation Roadmap
|
# GridPilot Implementation Roadmap
|
||||||
|
|
||||||
## Overview
|
## 1. Big Picture and Scope
|
||||||
|
|
||||||
This roadmap provides a phased implementation plan for GridPilot, an automated league management platform for iRacing. Each phase builds upon the previous one, with clear success criteria and actionable todos.
|
GridPilot is the **competition layer** for iRacing leagues, as described in:
|
||||||
|
|
||||||
**Purpose:**
|
- [`CONCEPT.md`](docs/concept/CONCEPT.md)
|
||||||
- Guide iterative development from technical validation to public launch and monetization
|
- [`ADMINS.md`](docs/concept/ADMINS.md)
|
||||||
- Track progress through checkable todos
|
- [`DRIVERS.md`](docs/concept/DRIVERS.md)
|
||||||
- Validate assumptions before investing in full implementation
|
- [`COMPETITION.md`](docs/concept/COMPETITION.md)
|
||||||
- Ensure architectural integrity throughout each phase
|
- [`RACING.md`](docs/concept/RACING.md)
|
||||||
|
- [`STATS.md`](docs/concept/STATS.md)
|
||||||
|
- [`RATING.md`](docs/concept/RATING.md)
|
||||||
|
- [`SOCIAL.md`](docs/concept/SOCIAL.md)
|
||||||
|
- [`TEAMS.md`](docs/concept/TEAMS.md)
|
||||||
|
|
||||||
**How to Use:**
|
Those docs describe the full platform: leagues, seasons, standings, stats, rating, complaints, social, teams, discovery, monetization.
|
||||||
- Check off todos as they are completed (replace `[ ]` with `[x]`)
|
|
||||||
- Review success criteria before moving to the next phase
|
This **repository** currently implements a **narrow, ToS-safe slice** of that vision:
|
||||||
- Refer to [ARCHITECTURE.md](./ARCHITECTURE.md) for component boundaries and patterns
|
|
||||||
- Consult [TESTS.md](./TESTS.md) for testing approach and BDD scenario structure
|
- A desktop Electron companion running on the admin’s machine.
|
||||||
- See [CONCEPT.md](./CONCEPT.md) for product vision and user needs
|
- A hosted-session automation engine that drives the iRacing web UI with Playwright.
|
||||||
|
- Domain and application logic for:
|
||||||
|
- hosted wizard steps
|
||||||
|
- authentication and cookie/session reuse
|
||||||
|
- overlays and lifecycle events
|
||||||
|
- checkout safety and confirmation.
|
||||||
|
|
||||||
|
For the technical slice implemented here, see:
|
||||||
|
|
||||||
|
- [`ARCHITECTURE.md`](docs/ARCHITECTURE.md)
|
||||||
|
- [`TECH.md`](docs/TECH.md)
|
||||||
|
- [`TESTS.md`](docs/TESTS.md)
|
||||||
|
|
||||||
|
Everything else from the concept docs (league/season management, stats, social, complaints, team identity, discovery) is **future or external** to this repo and will live in other services.
|
||||||
|
|
||||||
|
This roadmap is therefore split into two levels:
|
||||||
|
|
||||||
|
- **Automation & Companion Roadmap** – implementation-level, this repo.
|
||||||
|
- **Core Platform Roadmap** – high-level, future/external services guided by the concept docs.
|
||||||
|
|
||||||
|
|
||||||
|
## 2. How to Use This Roadmap
|
||||||
|
|
||||||
|
- Treat Automation & Companion items as work **inside this repo**.
|
||||||
|
- Treat Core Platform items as **future/external services** that will integrate with this automation slice later.
|
||||||
|
- Use checklists for near-term Automation & Companion work only.
|
||||||
|
- Use the concept docs plus [`ARCHITECTURE.md`](docs/ARCHITECTURE.md) as the source of truth for scope boundaries.
|
||||||
|
- Keep success criteria **testable**, using patterns in [`TESTS.md`](docs/TESTS.md).
|
||||||
|
|
||||||
**Relationship to MVP:**
|
|
||||||
- **Phase 0-1:** Pre-MVP validation (technical feasibility, market validation)
|
|
||||||
- **Phase 2:** MVP (core league management with automated results)
|
|
||||||
- **Phase 3-4:** Enhanced MVP (automation layer, branding)
|
|
||||||
- **Phase 5-6:** Public launch and monetization
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 0: Foundation (Automation Testing - Internal)
|
## 3. Automation & Companion Roadmap (This Repo)
|
||||||
|
|
||||||
**Goal:** Validate technical feasibility of browser automation and establish testing infrastructure.
|
This track is grounded in the existing code and architecture:
|
||||||
|
|
||||||
### Infrastructure Setup
|
- Hosted wizard flow and step orchestration (see `tests/e2e/steps/*` and `tests/e2e/workflows/*`).
|
||||||
- [ ] Initialize monorepo with npm workspaces (`/src/apps`, `/src/packages`)
|
- Auth and cookie/session management.
|
||||||
- [ ] Set up TypeScript configuration (strict mode, path aliases)
|
- Overlay lifecycle via [`IAutomationLifecycleEmitter`](packages/infrastructure/adapters/IAutomationLifecycleEmitter.ts:1) and [`OverlaySyncService`](packages/application/services/OverlaySyncService.ts:1).
|
||||||
- [ ] Configure ESLint and Prettier (no warnings tolerated)
|
- Checkout safety via [`CheckoutPriceExtractor`](packages/infrastructure/adapters/automation/CheckoutPriceExtractor.ts:1), [`ConfirmCheckoutUseCase`](packages/application/use-cases/ConfirmCheckoutUseCase.ts:1), [`ElectronCheckoutConfirmationAdapter`](packages/infrastructure/adapters/ipc/ElectronCheckoutConfirmationAdapter.ts:1) and the renderer dialog.
|
||||||
- [ ] Create basic domain models (`League`, `Team`, `Event`, `Driver`, `Result`)
|
- Electron companion UI and IPC wiring.
|
||||||
- [ ] Set up test harness (Vitest for unit/integration tests)
|
|
||||||
- [ ] Configure Docker Compose for E2E testing environment
|
|
||||||
- [ ] Document development setup in README.md
|
|
||||||
|
|
||||||
### Automation Validation
|
### Phase A: Solid Hosted-Session Engine & Companion Baseline
|
||||||
- [ ] Install and configure Playwright for browser automation
|
|
||||||
- [ ] Test iRacing website navigation and authentication flow
|
|
||||||
- [ ] Test session creation page detection on members.iracing.com
|
|
||||||
- [ ] Test session ID extraction from URL or page elements
|
|
||||||
- [ ] Validate server-side result polling from iRacing API
|
|
||||||
- [ ] Create proof-of-concept automation script using Playwright
|
|
||||||
- [ ] Document browser automation approach and iRacing automation rules
|
|
||||||
- [ ] Identify automation failure modes and mitigation strategies
|
|
||||||
|
|
||||||
### Testing Foundation
|
**Goal:** Make the existing hosted-session automation and Electron companion reliable, observable, and easy to run on an admin’s machine.
|
||||||
- [ ] Write example BDD scenarios (Given/When/Then format)
|
|
||||||
- [ ] Set up Dockerized E2E test environment
|
|
||||||
- [ ] Create fixture data for test scenarios
|
|
||||||
- [ ] Validate test isolation and repeatability
|
|
||||||
- [ ] Document testing strategy in [TESTS.md](./TESTS.md)
|
|
||||||
|
|
||||||
**Success Criteria:**
|
**Automation (this repo)**
|
||||||
- Technical feasibility confirmed (browser automation reliable)
|
|
||||||
- Test infrastructure operational (unit, integration, E2E)
|
- [ ] Stabilize wizard step orchestration:
|
||||||
- Development environment documented and reproducible
|
- [ ] Review and align wizard-step domain rules with [`StepTransitionValidator`](packages/domain/services/StepTransitionValidator.ts:1).
|
||||||
- No blockers identified for MVP implementation
|
- [ ] Ensure `tests/e2e/steps/*` cover all 18 hosted wizard steps end to end.
|
||||||
|
- [ ] Harden [`WizardStepOrchestrator`](packages/infrastructure/adapters/automation/core/PlaywrightAutomationAdapter.ts:1) behavior for retries and timeouts.
|
||||||
|
- [ ] Strengthen page validation:
|
||||||
|
- [ ] Extend [`PageStateValidator`](packages/domain/services/PageStateValidator.ts:1) to cover edge cases found in real-hosted tests.
|
||||||
|
- [ ] Ensure selector sets in `packages/infrastructure/adapters/automation/dom/*` match current iRacing UI.
|
||||||
|
- [ ] Tighten auth/session flows:
|
||||||
|
- [ ] Verify [`CheckAuthenticationUseCase`](packages/application/use-cases/CheckAuthenticationUseCase.ts:1), [`InitiateLoginUseCase`](packages/application/use-cases/InitiateLoginUseCase.ts:1), and [`VerifyAuthenticatedPageUseCase`](packages/application/use-cases/VerifyAuthenticatedPageUseCase.ts:1) match the constraints in [`CONCEPT.md`](docs/concept/CONCEPT.md) and [`RACING.md`](docs/concept/RACING.md).
|
||||||
|
- [ ] Confirm cookie handling in `automation/auth/*` matches the lifecycle described in [`ARCHITECTURE.md`](docs/ARCHITECTURE.md).
|
||||||
|
- [ ] Companion baseline:
|
||||||
|
- [ ] Ensure the Electron app boots and connects reliably on supported platforms (see smoke tests in `tests/smoke/*`).
|
||||||
|
- [ ] Keep the renderer minimal but clear: session creation, auth state, progress, checkout confirmation.
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- All unit, integration and E2E tests for existing flows are green (see [`TESTS.md`](docs/TESTS.md)).
|
||||||
|
- Full hosted-session workflows (fixture-based and real-hosted where enabled) complete without intermittent failures.
|
||||||
|
- Auth/login flow is ToS-safe, matches the “helper, not cheat” model in [`CONCEPT.md`](docs/concept/CONCEPT.md), and remains visible to the admin.
|
||||||
|
- Companion can run a full hosted-session creation with no manual DOM clicks beyond login.
|
||||||
|
|
||||||
|
|
||||||
|
### Phase B: Overlay & Lifecycle Clarity
|
||||||
|
|
||||||
|
**Goal:** Make the automation lifecycle and overlay behavior predictable and trustworthy for admins.
|
||||||
|
|
||||||
|
**Automation (this repo)**
|
||||||
|
|
||||||
|
- [ ] Lifecycle events:
|
||||||
|
- [ ] Review events emitted by [`IAutomationLifecycleEmitter`](packages/infrastructure/adapters/IAutomationLifecycleEmitter.ts:1) and consumed by [`OverlaySyncService`](packages/application/services/OverlaySyncService.ts:1).
|
||||||
|
- [ ] Ensure all critical state transitions of [`AutomationSession`](packages/domain/entities/AutomationSession.ts:1) are reflected in overlay events.
|
||||||
|
- [ ] Overlay UX:
|
||||||
|
- [ ] Ensure [`SessionProgressMonitor`](apps/companion/renderer/components/SessionProgressMonitor.tsx:1) clearly maps steps 1–18 to admin-understandable labels.
|
||||||
|
- [ ] Align overlay messaging with admin QoL themes in [`ADMINS.md`](docs/concept/ADMINS.md) (less repetitive work, more transparency).
|
||||||
|
- [ ] Error surfacing:
|
||||||
|
- [ ] Standardize how validation and runtime errors are propagated from domain → application → companion UI.
|
||||||
|
- [ ] Ensure failures are actionable (what failed, where, and what the admin can retry).
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- Overlay and progress UI always reflect the underlying session state without lag or missing steps.
|
||||||
|
- Admin can see where automation stopped and why, without reading logs.
|
||||||
|
- Lifecycle behavior is fully covered in tests (overlay integration, companion workflow E2E), as referenced from [`TESTS.md`](docs/TESTS.md).
|
||||||
|
|
||||||
|
|
||||||
|
### Phase C: Checkout Safety Path
|
||||||
|
|
||||||
|
**Goal:** Make every credit/checkout-like action go through an explicit, traceable confirmation path that admins can trust.
|
||||||
|
|
||||||
|
**Automation (this repo)**
|
||||||
|
|
||||||
|
- [ ] Enrich checkout detection:
|
||||||
|
- [ ] Validate selector logic and price parsing in [`CheckoutPriceExtractor`](packages/infrastructure/adapters/automation/CheckoutPriceExtractor.ts:1) against current iRacing UI.
|
||||||
|
- [ ] Ensure [`CheckoutState`](packages/domain/value-objects/CheckoutState.ts:1) covers all relevant button states.
|
||||||
|
- [ ] Harden confirmation logic:
|
||||||
|
- [ ] Confirm [`ConfirmCheckoutUseCase`](packages/application/use-cases/ConfirmCheckoutUseCase.ts:1) is the *only* entry point for automation that proceeds past a non-zero price.
|
||||||
|
- [ ] Ensure [`ElectronCheckoutConfirmationAdapter`](packages/infrastructure/adapters/ipc/ElectronCheckoutConfirmationAdapter.ts:1) and [`CheckoutConfirmationDialog`](apps/companion/renderer/components/CheckoutConfirmationDialog.tsx:1) enforce explicit admin confirmation and timeouts.
|
||||||
|
- [ ] Failure paths:
|
||||||
|
- [ ] Verify that any parsing failure or ambiguous state results in a safe stop, not a blind click.
|
||||||
|
- [ ] Add tests to cover “weird but possible” UI states observed via fixtures.
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- No automation path can perform a checkout-like action without an on-screen confirmation dialog.
|
||||||
|
- All credit-related flows are covered in tests (unit, integration, and companion E2E) with failure-path assertions.
|
||||||
|
- Behavior matches the safety and trust requirements in [`ADMINS.md`](docs/concept/ADMINS.md) and [`RACING.md`](docs/concept/RACING.md).
|
||||||
|
|
||||||
|
|
||||||
|
### Phase D: Additional Hosted Workflows & Admin QoL
|
||||||
|
|
||||||
|
**Goal:** Extend automation beyond the initial hosted-session wizard happy path while staying within the same ToS-safe browser automation model.
|
||||||
|
|
||||||
|
**Automation (this repo)**
|
||||||
|
|
||||||
|
- [ ] Map additional hosted workflows:
|
||||||
|
- [ ] Identify additional iRacing hosted flows that align with admin QoL needs from [`ADMINS.md`](docs/concept/ADMINS.md) (e.g. practice-only, league-specific hosted sessions).
|
||||||
|
- [ ] Encode them as configurations on top of [`HostedSessionConfig`](packages/domain/entities/HostedSessionConfig.ts:1) where feasible.
|
||||||
|
- [ ] Workflow templates:
|
||||||
|
- [ ] Provide a small set of reusable presets (e.g. “standard league race”, “test session”) that can later be populated by external services.
|
||||||
|
- [ ] Resilience work:
|
||||||
|
- [ ] Improve behavior under partial UI changes (selectors, labels) using the validation patterns from [`PageStateValidator`](packages/domain/services/PageStateValidator.ts:1).
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- At least one additional hosted workflow beyond the baseline wizard is supported end to end.
|
||||||
|
- Admins can choose between a small number of well-tested presets that reflect league use-cases from [`COMPETITION.md`](docs/concept/COMPETITION.md).
|
||||||
|
- Automation remains fully ToS-safe (no gameplay-affecting automation, no desktop/sim process interference), as reiterated in [`ARCHITECTURE.md`](docs/ARCHITECTURE.md).
|
||||||
|
|
||||||
|
|
||||||
|
### Phase E: Operationalization & Packaging
|
||||||
|
|
||||||
|
**Goal:** Make it realistic for real league admins to install, configure and operate the companion and automation engine.
|
||||||
|
|
||||||
|
**Automation (this repo)**
|
||||||
|
|
||||||
|
- [ ] Packaging & configuration:
|
||||||
|
- [ ] Ensure Electron packaging, browser mode configuration and logging settings match the expectations in [`TECH.md`](docs/TECH.md).
|
||||||
|
- [ ] Provide a minimal operator-facing configuration story (environment, headless vs headed, fixture vs live).
|
||||||
|
- [ ] Observability:
|
||||||
|
- [ ] Ensure logs and failure artifacts are sufficient for debugging issues without code changes.
|
||||||
|
- [ ] Documentation:
|
||||||
|
- [ ] Keep operator-focused docs short and aligned with admin benefits from [`ADMINS.md`](docs/concept/ADMINS.md).
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- A technically inclined admin can install the companion, configure automation mode, and run a full hosted-session workflow using only the documentation in this repo.
|
||||||
|
- Most operational issues can be diagnosed via logs and failure artifacts without code-level changes.
|
||||||
|
- Existing tests remain the primary safety net for refactors (see [`TESTS.md`](docs/TESTS.md)).
|
||||||
|
|
||||||
**Note:** This phase is internal validation only—no user-facing features.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 1: Landing Page & Market Validation
|
## 4. Core Platform Roadmap (Future / External Services)
|
||||||
|
|
||||||
**Goal:** Validate product-market fit before building the full application.
|
This track covers the broader GridPilot competition platform from the concept docs. It is **not** implemented in this repo and will likely live in separate services/apps that integrate with the automation engine described in [`ARCHITECTURE.md`](docs/ARCHITECTURE.md).
|
||||||
|
|
||||||
### Marketing Website
|
Each phase is intentionally high-level to avoid going stale; details belong in future architecture docs for those services.
|
||||||
- [ ] Build static marketing website (Next.js or similar)
|
|
||||||
- [ ] Create compelling copy addressing league organizer pain points
|
|
||||||
- [ ] Design product mockups and fake screenshots
|
|
||||||
- [ ] Add email collection form (waitlist integration)
|
|
||||||
- [ ] Implement privacy policy and terms of service
|
|
||||||
- [ ] Set up analytics (signups, page views, engagement)
|
|
||||||
|
|
||||||
### Community Engagement
|
### Phase P1: League Identity and Seasons
|
||||||
- [ ] Post to r/iRacing subreddit with mockups
|
|
||||||
- [ ] Share in iRacing Discord communities
|
|
||||||
- [ ] Reach out to league organizers directly
|
|
||||||
- [ ] Collect feedback on pain points and feature requests
|
|
||||||
- [ ] Conduct user interviews with interested organizers
|
|
||||||
- [ ] Document feedback in product backlog
|
|
||||||
|
|
||||||
### Analysis
|
**Core Platform (future/external)**
|
||||||
- [ ] Analyze email signup metrics
|
|
||||||
- [ ] Review qualitative feedback themes
|
|
||||||
- [ ] Validate assumptions about organizer pain points
|
|
||||||
- [ ] Assess willingness to pay (surveys, conversations)
|
|
||||||
- [ ] Document findings and adjust roadmap if needed
|
|
||||||
|
|
||||||
**Success Criteria:**
|
- Provide a clean league home, as described in:
|
||||||
- 100+ email signups from target users
|
- [`CONCEPT.md`](docs/concept/CONCEPT.md)
|
||||||
- Positive feedback from league organizers
|
- [`ADMINS.md`](docs/concept/ADMINS.md)
|
||||||
- Validated demand for automated result import
|
- Implement league identity, schedules and season configuration:
|
||||||
- Confirmed interest in team-based scoring
|
- public league pages, schedules, rules, rosters (see sections 3 and 4 in [`CONCEPT.md`](docs/concept/CONCEPT.md)).
|
||||||
- Product-market fit assumptions validated
|
- admin tools for creating seasons, calendars, formats (mirroring [`RACING.md`](docs/concept/RACING.md)).
|
||||||
|
- Model leagues, seasons and events as first-class entities that can later produce [`HostedSessionConfig`](packages/domain/entities/HostedSessionConfig.ts:1) instances for this repo’s automation engine.
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- Leagues can exist, configure seasons and publish schedules independent of automation.
|
||||||
|
- Competition structure (points presets, drop weeks, team vs solo) matches the expectations in [`COMPETITION.md`](docs/concept/COMPETITION.md).
|
||||||
|
- There is a clear integration point for calling the automation engine with derived hosted-session configurations (described in the future platform’s own architecture docs).
|
||||||
|
|
||||||
|
|
||||||
|
### Phase P2: Results, Stats, Rating v1, and Team Competition
|
||||||
|
|
||||||
|
**Core Platform (future/external)**
|
||||||
|
|
||||||
|
- Result ingestion & standings:
|
||||||
|
- Implement automated result import and standings as described in [`CONCEPT.md`](docs/concept/CONCEPT.md) and [`STATS.md`](docs/concept/STATS.md).
|
||||||
|
- Combine imported results into per-season standings for drivers and teams.
|
||||||
|
- Team system:
|
||||||
|
- Implement team profiles and constructors-style championships as in [`TEAMS.md`](docs/concept/TEAMS.md) and team sections of [`RACING.md`](docs/concept/RACING.md).
|
||||||
|
- Stats and inputs for rating:
|
||||||
|
- Structure league and season stats so that league results, incidents, team points and attendance are reliably captured as described in [`STATS.md`](docs/concept/STATS.md).
|
||||||
|
- GridPilot Rating v1 (platform-side service):
|
||||||
|
- Deliver a first usable GridPilot Rating capability consistent with [`RATING.md`](docs/concept/RATING.md), computed entirely in core platform services.
|
||||||
|
- Treat this repo’s automation slice as a producer of trusted, structured session configs and results; do not move any rating logic into the automation engine.
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- For a league connected to GridPilot, standings and stats update automatically based on iRacing results and provide the inputs required by the rating model in [`RATING.md`](docs/concept/RATING.md).
|
||||||
|
- Teams and drivers have persistent identity and history across seasons, matching the narratives in [`DRIVERS.md`](docs/concept/DRIVERS.md) and [`TEAMS.md`](docs/concept/TEAMS.md).
|
||||||
|
- Automation engine in this repo can be treated as a “session executor” feeding reliable results into the platform’s scoring and rating engines, while rating computation remains in Core Platform services.
|
||||||
|
|
||||||
|
|
||||||
|
### Phase P3: Complaints, Penalties, Transparency, and Rating Fairness
|
||||||
|
|
||||||
|
**Core Platform (future/external)**
|
||||||
|
|
||||||
|
- Complaint intake:
|
||||||
|
- Structured complaint flows as defined in [`CONCEPT.md`](docs/concept/CONCEPT.md) and [`RACING.md`](docs/concept/RACING.md) (race, drivers, timestamps, evidence).
|
||||||
|
- Penalty tools:
|
||||||
|
- Admin-facing review and decision tools described in [`ADMINS.md`](docs/concept/ADMINS.md) and [`RACING.md`](docs/concept/RACING.md).
|
||||||
|
- Classification updates:
|
||||||
|
- Automatic recalculation of results and standings after penalties, aligned with the classification and penalty handling in [`STATS.md`](docs/concept/STATS.md).
|
||||||
|
- Rating dependencies:
|
||||||
|
- Ensure that penalty-aware classification, incident handling and transparency from this phase directly feed into GridPilot Rating as incident and season factors, consistent with [`RATING.md`](docs/concept/RATING.md).
|
||||||
|
- Keep rating computation fully within Core Platform services; this repo continues to provide only the structured competition data that rating consumes.
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- Complaints and penalties are no longer handled via ad-hoc Discord and spreadsheets.
|
||||||
|
- Standings, stats, histories and rating signals remain consistent and penalty-aware.
|
||||||
|
- The platform exposes a transparent, auditable record of decisions, supporting the fairness and rating trust goals from the concept docs.
|
||||||
|
|
||||||
|
|
||||||
|
### Phase P4: Social, Discovery, and Monetization
|
||||||
|
|
||||||
|
**Core Platform (future/external)**
|
||||||
|
|
||||||
|
- Social and discovery:
|
||||||
|
- Implement the lightweight social and discovery features from [`SOCIAL.md`](docs/concept/SOCIAL.md) and league/team profile extensions in [`TEAMS.md`](docs/concept/TEAMS.md).
|
||||||
|
- League and driver discovery:
|
||||||
|
- Make it easy for drivers to find leagues and teams, and for leagues to find drivers, as described in [`DRIVERS.md`](docs/concept/DRIVERS.md) and [`COMPETITION.md`](docs/concept/COMPETITION.md).
|
||||||
|
- Monetization (later phase):
|
||||||
|
- Add monetization and premium features only after the core competition and trust layers are stable, following the MVP philosophy in [`CONCEPT.md`](docs/concept/CONCEPT.md).
|
||||||
|
|
||||||
|
**Success criteria**
|
||||||
|
|
||||||
|
- Drivers, teams and leagues can discover each other through GridPilot, with identity and history driving trust.
|
||||||
|
- Social features remain lightweight and purpose-driven, complementing community tools like Discord instead of replacing them.
|
||||||
|
- Any monetization respects the “clarity, fairness, and admin control” principles in the concept docs.
|
||||||
|
|
||||||
**Note:** No application built in this phase—validation only. Pivot or proceed based on feedback.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Phase 2: MVP (League-Focused)
|
## 5. Dependencies and Evolution
|
||||||
|
|
||||||
**Goal:** Build a functional league management platform with automated result import (no fees, no companion app yet).
|
- Automation & Companion phases (A–E) are largely **independent** of Core Platform phases and can be completed first.
|
||||||
|
- Core Platform phases (P1–P4) depend on:
|
||||||
### Authentication & User Management
|
- A stable automation engine and companion (this repo).
|
||||||
- [ ] Implement iRacing OAuth authentication flow
|
- Clear APIs/IPC or integration contracts that should be documented in future platform services, referencing [`ARCHITECTURE.md`](docs/ARCHITECTURE.md).
|
||||||
- [ ] Create user registration and profile system
|
- The automation slice should remain **small and robust**, so that multiple future services can treat it as a shared “session engine.”
|
||||||
- [ ] Build user role system (organizer, driver, spectator)
|
|
||||||
- [ ] Implement session management and token refresh
|
Use this roadmap as a **living, checkable** guide:
|
||||||
- [ ] Write BDD scenarios for authentication flows
|
|
||||||
- [ ] Achieve test coverage for auth domain
|
- Update checklists under Automation & Companion as work lands.
|
||||||
|
- Keep Core Platform phases at the level of concept alignment, not implementation detail.
|
||||||
### League Management (Core Domain)
|
- When new services are built, they should introduce their own roadmaps and link back to:
|
||||||
- [ ] Implement `CreateLeagueUseCase` (see [ARCHITECTURE.md](./ARCHITECTURE.md#application-layer))
|
- [`CONCEPT.md`](docs/concept/CONCEPT.md) and related concept docs.
|
||||||
- [ ] Create league CRUD operations (update, delete, archive)
|
- [`ARCHITECTURE.md`](docs/ARCHITECTURE.md) for the automation slice.
|
||||||
- [ ] Build season setup (tracks, cars, rules configuration)
|
- [`TESTS.md`](docs/TESTS.md) for testing strategy and coverage expectations.
|
||||||
- [ ] Implement points system configuration (customizable)
|
|
||||||
- [ ] Create race event scheduling system
|
**Last Updated:** 2025-12-01
|
||||||
- [ ] Write BDD scenarios for league lifecycle
|
**Tracks:** Automation & Companion (this repo) / Core Platform (future/external)
|
||||||
- [ ] Achieve >90% test coverage for `League` aggregate
|
**Current Focus:** Phase A (Solid hosted-session engine & companion baseline)
|
||||||
|
|
||||||
### Driver & Team Registration
|
|
||||||
- [ ] Build driver registration system (join league/season)
|
|
||||||
- [ ] Implement team registration system (optional parallel scoring)
|
|
||||||
- [ ] Create team roster management (add/remove drivers)
|
|
||||||
- [ ] Build approval workflow for registrations
|
|
||||||
- [ ] Write BDD scenarios for registration flows
|
|
||||||
- [ ] Test team scoring calculation logic
|
|
||||||
|
|
||||||
### Automated Result Import
|
|
||||||
- [ ] Implement PostgreSQL schema (repositories pattern)
|
|
||||||
- [ ] Create server-side iRacing API integration
|
|
||||||
- [ ] Build automated result polling service
|
|
||||||
- [ ] Implement result parsing and validation
|
|
||||||
- [ ] Create `ImportResultUseCase` (see [ARCHITECTURE.md](./ARCHITECTURE.md#application-layer))
|
|
||||||
- [ ] Handle edge cases (DNS, penalties, disconnects)
|
|
||||||
- [ ] Write BDD scenarios for result import
|
|
||||||
- [ ] Test result import reliability and error handling
|
|
||||||
|
|
||||||
### Standings & Results
|
|
||||||
- [ ] Generate driver standings (individual points calculation)
|
|
||||||
- [ ] Generate team standings (parallel scoring model)
|
|
||||||
- [ ] Build race result pages (lap times, incidents, finishing position)
|
|
||||||
- [ ] Implement historical standings view (by race)
|
|
||||||
- [ ] Create standings export functionality (CSV)
|
|
||||||
- [ ] Write BDD scenarios for standings calculation
|
|
||||||
- [ ] Test edge cases (ties, dropped races, penalties)
|
|
||||||
|
|
||||||
### League Identity & Admin
|
|
||||||
- [ ] Build league identity pages (public view)
|
|
||||||
- [ ] Create basic admin dashboard (organizer tools)
|
|
||||||
- [ ] Implement league settings management
|
|
||||||
- [ ] Build schedule and calendar view
|
|
||||||
- [ ] Create notifications system (race reminders)
|
|
||||||
- [ ] Write BDD scenarios for admin workflows
|
|
||||||
|
|
||||||
### Quality Assurance
|
|
||||||
- [ ] Run full test suite (unit, integration, E2E)
|
|
||||||
- [ ] Achieve >90% test coverage for domain/application layers
|
|
||||||
- [ ] Perform manual testing with real iRacing data
|
|
||||||
- [ ] Fix all critical bugs and edge cases
|
|
||||||
- [ ] Document known limitations
|
|
||||||
|
|
||||||
**Success Criteria:**
|
|
||||||
- Functional platform for league management
|
|
||||||
- Automated result import working reliably
|
|
||||||
- Driver and team standings calculated correctly
|
|
||||||
- No manual result uploads required
|
|
||||||
- Test coverage >90% for core domain
|
|
||||||
- Ready for closed beta testing
|
|
||||||
|
|
||||||
**Note:** No fees, no payouts, no companion app in this phase. Focus on core league management.
|
|
||||||
|
|
||||||
**Cross-References:**
|
|
||||||
- See [ARCHITECTURE.md](./ARCHITECTURE.md) for component boundaries
|
|
||||||
- See [TESTS.md](./TESTS.md) for BDD scenario examples
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase 3: Companion App (Automation Layer)
|
|
||||||
|
|
||||||
**Goal:** Build an Electron companion app to automate session creation and reduce organizer workload.
|
|
||||||
|
|
||||||
### Companion App Foundation
|
|
||||||
- [ ] Set up Electron application structure
|
|
||||||
- [ ] Implement Playwright browser automation framework
|
|
||||||
- [ ] Create IPC bridge for backend communication
|
|
||||||
- [ ] Build auto-updater mechanism
|
|
||||||
- [ ] Set up application signing and packaging
|
|
||||||
- [ ] Document installation and setup process
|
|
||||||
|
|
||||||
### Session Creation Automation
|
|
||||||
- [ ] Build session creation assistance workflow
|
|
||||||
- [ ] Implement iRacing session page detection
|
|
||||||
- [ ] Create session ID extraction mechanism
|
|
||||||
- [ ] Build form auto-fill functionality (track, cars, rules)
|
|
||||||
- [ ] Implement session URL capture and sync
|
|
||||||
- [ ] Handle automation failure cases gracefully
|
|
||||||
- [ ] Write E2E tests for automation flows
|
|
||||||
|
|
||||||
### OAuth & Credential Handoff
|
|
||||||
- [ ] Implement OAuth handoff from companion to web
|
|
||||||
- [ ] Create secure credential storage (encrypted)
|
|
||||||
- [ ] Build IPC bridge for authentication state
|
|
||||||
- [ ] Handle token refresh in companion app
|
|
||||||
- [ ] Write E2E tests for OAuth handoff flow
|
|
||||||
- [ ] Test cross-process credential security
|
|
||||||
|
|
||||||
### Organizer Utilities
|
|
||||||
- [ ] Create session creation guidance (step-by-step)
|
|
||||||
- [ ] Build pre-race checklist functionality
|
|
||||||
- [ ] Implement session status monitoring
|
|
||||||
- [ ] Add quick access to league settings
|
|
||||||
- [ ] Create notifications for upcoming races
|
|
||||||
|
|
||||||
### Testing & Reliability
|
|
||||||
- [ ] Test session creation automation reliability (>95% success rate)
|
|
||||||
- [ ] Validate automation across different iRacing UI versions
|
|
||||||
- [ ] Handle iRacing website changes gracefully
|
|
||||||
- [ ] Create fallback mechanisms for automation failures
|
|
||||||
- [ ] Document troubleshooting guide
|
|
||||||
|
|
||||||
**Success Criteria:**
|
|
||||||
- Companion app reduces session creation time by 80%+
|
|
||||||
- Automation success rate >95%
|
|
||||||
- OAuth handoff secure and seamless
|
|
||||||
- Auto-updater working reliably
|
|
||||||
- Comprehensive E2E test coverage
|
|
||||||
|
|
||||||
**Note:** Companion app is optional but highly valuable for organizers. Focus on reliability over features.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase 4: Branding & Public Pages
|
|
||||||
|
|
||||||
**Goal:** Enable professional league identity and public discoverability.
|
|
||||||
|
|
||||||
### Asset Management
|
|
||||||
- [ ] Implement S3-compatible asset storage (logos, images)
|
|
||||||
- [ ] Add league logo upload functionality
|
|
||||||
- [ ] Create image optimization pipeline
|
|
||||||
- [ ] Implement asset CDN integration
|
|
||||||
- [ ] Build asset management UI (upload, delete, replace)
|
|
||||||
|
|
||||||
### Custom Branding
|
|
||||||
- [ ] Create custom CSS/theming system (colors, fonts)
|
|
||||||
- [ ] Build theme preview functionality
|
|
||||||
- [ ] Implement logo placement customization
|
|
||||||
- [ ] Add custom header/footer options
|
|
||||||
- [ ] Create branding guidelines documentation
|
|
||||||
|
|
||||||
### Public League Directory
|
|
||||||
- [ ] Build public league directory (browse and discover)
|
|
||||||
- [ ] Implement search and filtering (game type, region, skill level)
|
|
||||||
- [ ] Create league detail pages (public view)
|
|
||||||
- [ ] Add league statistics (active seasons, drivers, races)
|
|
||||||
- [ ] Implement privacy settings (public/private leagues)
|
|
||||||
|
|
||||||
### External Integrations
|
|
||||||
- [ ] Implement optional custom domain support (CNAME)
|
|
||||||
- [ ] Create embeddable widgets (standings iframe, schedule)
|
|
||||||
- [ ] Add Discord/TeamSpeak integration links
|
|
||||||
- [ ] Implement YouTube/Twitch VOD linking (external only, no uploads)
|
|
||||||
- [ ] Build social sharing functionality (Twitter, Reddit)
|
|
||||||
|
|
||||||
### Public Result Pages
|
|
||||||
- [ ] Create public race result pages (shareable links)
|
|
||||||
- [ ] Build driver profile pages (career statistics)
|
|
||||||
- [ ] Implement team profile pages (roster, history)
|
|
||||||
- [ ] Add historical standings archive
|
|
||||||
- [ ] Create race replay link integration (if available)
|
|
||||||
|
|
||||||
### Testing & Documentation
|
|
||||||
- [ ] Write BDD scenarios for branding features
|
|
||||||
- [ ] Test public pages with various league configurations
|
|
||||||
- [ ] Validate custom domain setup process
|
|
||||||
- [ ] Create user guide for branding customization
|
|
||||||
- [ ] Test embeddable widgets in external sites
|
|
||||||
|
|
||||||
**Success Criteria:**
|
|
||||||
- Leagues have professional identity and branding
|
|
||||||
- Public directory drives league discovery
|
|
||||||
- Custom domains working reliably
|
|
||||||
- Embeddable widgets functional
|
|
||||||
- External integrations (Discord, Twitch) operational
|
|
||||||
|
|
||||||
**Note:** Branding features are optional but enhance league professionalism and discoverability.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase 5: Public Launch
|
|
||||||
|
|
||||||
**Goal:** Launch GridPilot publicly with production-grade infrastructure and stability.
|
|
||||||
|
|
||||||
### Security & Compliance
|
|
||||||
- [ ] Perform security audit (OAuth, credentials, API security)
|
|
||||||
- [ ] Implement rate limiting and DDoS protection
|
|
||||||
- [ ] Add CSRF and XSS protection
|
|
||||||
- [ ] Conduct penetration testing
|
|
||||||
- [ ] Review GDPR compliance (user data handling)
|
|
||||||
- [ ] Implement data export functionality (user request)
|
|
||||||
- [ ] Create incident response plan
|
|
||||||
|
|
||||||
### Performance & Scalability
|
|
||||||
- [ ] Load testing and performance optimization
|
|
||||||
- [ ] Implement database query optimization
|
|
||||||
- [ ] Add caching layers (Redis for sessions, API responses)
|
|
||||||
- [ ] Configure CDN for static assets
|
|
||||||
- [ ] Optimize Docker images for production
|
|
||||||
- [ ] Set up horizontal scaling strategy
|
|
||||||
|
|
||||||
### Production Infrastructure
|
|
||||||
- [ ] Set up production hosting (AWS/GCP/Azure)
|
|
||||||
- [ ] Configure production database (PostgreSQL with replication)
|
|
||||||
- [ ] Implement database backup strategy (automated, tested)
|
|
||||||
- [ ] Set up monitoring and alerting (logs, errors, uptime)
|
|
||||||
- [ ] Configure error tracking (Sentry or similar)
|
|
||||||
- [ ] Implement log aggregation and analysis
|
|
||||||
- [ ] Create disaster recovery plan
|
|
||||||
|
|
||||||
### Documentation & Support
|
|
||||||
- [ ] Write comprehensive user documentation
|
|
||||||
- [ ] Create organizer onboarding guide
|
|
||||||
- [ ] Build driver user guide
|
|
||||||
- [ ] Document API endpoints (if public)
|
|
||||||
- [ ] Create FAQ and troubleshooting guide
|
|
||||||
- [ ] Set up support system (email, Discord)
|
|
||||||
|
|
||||||
### Launch Preparation
|
|
||||||
- [ ] Prepare launch marketing materials
|
|
||||||
- [ ] Coordinate Reddit/Discord announcements
|
|
||||||
- [ ] Create launch video/demo
|
|
||||||
- [ ] Set up social media presence
|
|
||||||
- [ ] Prepare press kit (if applicable)
|
|
||||||
- [ ] Plan launch timeline and milestones
|
|
||||||
|
|
||||||
### Beta Onboarding
|
|
||||||
- [ ] Onboard first 10 beta leagues (closed beta)
|
|
||||||
- [ ] Collect feedback from beta users
|
|
||||||
- [ ] Fix critical bugs identified in beta
|
|
||||||
- [ ] Validate production stability under real load
|
|
||||||
- [ ] Document lessons learned
|
|
||||||
|
|
||||||
**Success Criteria:**
|
|
||||||
- Platform publicly available and stable
|
|
||||||
- Security audit passed with no critical issues
|
|
||||||
- Production infrastructure operational
|
|
||||||
- Monitoring and alerting functional
|
|
||||||
- User documentation complete
|
|
||||||
- First 10+ leagues successfully onboarded
|
|
||||||
- Platform stable under real-world load
|
|
||||||
|
|
||||||
**Note:** Public launch is a major milestone. Ensure stability and security before opening access.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Phase 6: Monetization & Expansion
|
|
||||||
|
|
||||||
**Goal:** Generate revenue and expand platform capabilities.
|
|
||||||
|
|
||||||
### Monetization Features
|
|
||||||
- [ ] Implement league creation fee system
|
|
||||||
- [ ] Add optional driver entry fee per season
|
|
||||||
- [ ] Build revenue split mechanism (organizer/GridPilot)
|
|
||||||
- [ ] Create billing and invoicing system
|
|
||||||
- [ ] Implement payment processing (Stripe or similar)
|
|
||||||
- [ ] Add subscription management (for premium features)
|
|
||||||
- [ ] Create payout system for organizers
|
|
||||||
- [ ] Implement refund and dispute handling
|
|
||||||
|
|
||||||
### Premium Features
|
|
||||||
- [ ] Create premium league features (advanced analytics)
|
|
||||||
- [ ] Build driver/team performance metrics over time
|
|
||||||
- [ ] Implement historical trend analysis
|
|
||||||
- [ ] Add advanced race strategy tools
|
|
||||||
- [ ] Create custom report generation
|
|
||||||
- [ ] Build league comparison and benchmarking
|
|
||||||
|
|
||||||
### Analytics & Insights
|
|
||||||
- [ ] Add analytics dashboards for leagues
|
|
||||||
- [ ] Implement driver consistency metrics
|
|
||||||
- [ ] Create incident rate analysis
|
|
||||||
- [ ] Build lap time comparison tools
|
|
||||||
- [ ] Add race pace analysis
|
|
||||||
- [ ] Implement predictive performance modeling
|
|
||||||
|
|
||||||
### Platform Expansion
|
|
||||||
- [ ] Explore expansion to other simulators (ACC, rFactor 2)
|
|
||||||
- [ ] Evaluate additional automation features
|
|
||||||
- [ ] Research multi-game league support
|
|
||||||
- [ ] Investigate community-requested features
|
|
||||||
- [ ] Assess partnership opportunities (teams, sponsors)
|
|
||||||
|
|
||||||
### Business Intelligence
|
|
||||||
- [ ] Implement revenue tracking and reporting
|
|
||||||
- [ ] Create user engagement metrics
|
|
||||||
- [ ] Build churn analysis and retention tools
|
|
||||||
- [ ] Add A/B testing framework
|
|
||||||
- [ ] Implement feature adoption tracking
|
|
||||||
|
|
||||||
**Success Criteria:**
|
|
||||||
- Revenue generation active and growing
|
|
||||||
- Premium features adopted by target segment
|
|
||||||
- Payment processing reliable and secure
|
|
||||||
- Organizer payouts working correctly
|
|
||||||
- Platform expansion feasibility validated
|
|
||||||
- Positive unit economics demonstrated
|
|
||||||
|
|
||||||
**Note:** Monetization should not compromise core user experience. Ensure value delivery justifies pricing.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Dependencies & Sequencing
|
|
||||||
|
|
||||||
**Critical Path:**
|
|
||||||
1. Phase 0 must be completed before any development begins
|
|
||||||
2. Phase 1 validation should gate investment in Phase 2
|
|
||||||
3. Phase 2 MVP is required before Phase 3 (companion app depends on API)
|
|
||||||
4. Phase 4 can be developed in parallel with Phase 3 (independent features)
|
|
||||||
5. Phase 5 (public launch) requires Phases 2-4 to be complete and stable
|
|
||||||
6. Phase 6 (monetization) requires Phase 5 (public user base)
|
|
||||||
|
|
||||||
**Optional Paths:**
|
|
||||||
- Phase 3 (companion app) can be delayed if organizers tolerate manual session creation
|
|
||||||
- Phase 4 (branding) can be simplified for MVP launch
|
|
||||||
- Phase 6 features can be prioritized based on user demand
|
|
||||||
|
|
||||||
**Iteration Strategy:**
|
|
||||||
- Complete each phase fully before moving to the next
|
|
||||||
- Validate success criteria before proceeding
|
|
||||||
- Adjust roadmap based on feedback and learnings
|
|
||||||
- Maintain architectural integrity throughout
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Living Document
|
|
||||||
|
|
||||||
This roadmap is a living document and will be updated as the project evolves. Key updates will include:
|
|
||||||
- Completed todos (checked off)
|
|
||||||
- Lessons learned from each phase
|
|
||||||
- Adjusted priorities based on user feedback
|
|
||||||
- New features discovered during development
|
|
||||||
- Changes to success criteria or scope
|
|
||||||
|
|
||||||
**Maintenance:**
|
|
||||||
- Review and update quarterly (or after each phase)
|
|
||||||
- Archive completed phases for reference
|
|
||||||
- Document deviations from original plan
|
|
||||||
- Track velocity and estimate remaining work
|
|
||||||
|
|
||||||
**Cross-References:**
|
|
||||||
- [CONCEPT.md](./CONCEPT.md) - Product vision and user needs
|
|
||||||
- [ARCHITECTURE.md](./ARCHITECTURE.md) - Technical design and component boundaries
|
|
||||||
- [TESTS.md](./TESTS.md) - Testing strategy and BDD scenarios
|
|
||||||
- [TECH.md](./TECH.md) - Technology decisions and rationale
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**Last Updated:** 2025-11-23
|
|
||||||
**Current Phase:** Phase 0 (Foundation)
|
|
||||||
**Overall Progress:** In Progress (browser automation implemented)
|
|
||||||
236
docs/concept/ADMINS.md
Normal file
236
docs/concept/ADMINS.md
Normal file
@@ -0,0 +1,236 @@
|
|||||||
|
# GridPilot for Admins
|
||||||
|
*Professional tools that eliminate the chaos of running an iRacing league — without changing how your community works.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Why Admins Need GridPilot
|
||||||
|
|
||||||
|
Running a league today means juggling:
|
||||||
|
- Discord threads
|
||||||
|
- Google Sheets
|
||||||
|
- CSVs
|
||||||
|
- DMs
|
||||||
|
- PDFs
|
||||||
|
- manual points
|
||||||
|
- manual sign-ups
|
||||||
|
- manual session creation
|
||||||
|
- messy protest handling
|
||||||
|
|
||||||
|
Meanwhile, admins just want to:
|
||||||
|
- run good races
|
||||||
|
- keep drivers happy
|
||||||
|
- keep things fair
|
||||||
|
- and not drown in repetitive work
|
||||||
|
|
||||||
|
GridPilot gives admins the structure and tools iRacing never provided.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. League Identity & Presentation
|
||||||
|
|
||||||
|
Admins get a clean, modern league homepage — instantly.
|
||||||
|
|
||||||
|
### Includes:
|
||||||
|
- league logo + colors
|
||||||
|
- season schedule
|
||||||
|
- standings (driver + team)
|
||||||
|
- team list
|
||||||
|
- driver roster
|
||||||
|
- results archive
|
||||||
|
- links to Discord, YouTube, Twitch
|
||||||
|
|
||||||
|
### Optional:
|
||||||
|
- custom subdomain (e.g. *yourleague.racing*)
|
||||||
|
|
||||||
|
This makes small leagues feel **professional** without any technical effort.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Season Management
|
||||||
|
|
||||||
|
A complete toolkit to organize seasons without spreadsheets.
|
||||||
|
|
||||||
|
### Admins can:
|
||||||
|
- define the league format
|
||||||
|
- create calendars (tracks, car classes)
|
||||||
|
- configure points systems
|
||||||
|
- define drop weeks
|
||||||
|
- choose team vs solo format
|
||||||
|
- set rules & info pages
|
||||||
|
- open/close registration
|
||||||
|
- manage rosters
|
||||||
|
|
||||||
|
Everything stays in one clean UI.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Driver & Team Sign-ups
|
||||||
|
|
||||||
|
Forget Discord forms and DMs.
|
||||||
|
|
||||||
|
### GridPilot handles:
|
||||||
|
- driver sign-ups
|
||||||
|
- team registrations
|
||||||
|
- automatic roster generation
|
||||||
|
- driver availability status
|
||||||
|
- team composition
|
||||||
|
- waitlist management
|
||||||
|
|
||||||
|
Admins no longer need to chase people for info.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Automatic Results Import
|
||||||
|
|
||||||
|
One of the biggest pains in league racing — **gone**.
|
||||||
|
|
||||||
|
GridPilot automatically imports results from iRacing:
|
||||||
|
|
||||||
|
### Extracts:
|
||||||
|
- finishing positions
|
||||||
|
- incident count
|
||||||
|
- best laps
|
||||||
|
- lap-by-lap data
|
||||||
|
- gained/lost positions
|
||||||
|
- SoF (if available)
|
||||||
|
|
||||||
|
### Updates:
|
||||||
|
- driver standings
|
||||||
|
- team standings
|
||||||
|
- season points
|
||||||
|
- drop-week applied points
|
||||||
|
|
||||||
|
Admins don’t upload CSVs or calculate anything manually again.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Complaints & Penalties
|
||||||
|
|
||||||
|
A structured workflow to replace protest chaos.
|
||||||
|
|
||||||
|
### Drivers can submit complaints:
|
||||||
|
- select the race
|
||||||
|
- select involved drivers
|
||||||
|
- add timestamps
|
||||||
|
- add explanations
|
||||||
|
- optionally add short clips
|
||||||
|
|
||||||
|
### Admins get:
|
||||||
|
- a review dashboard
|
||||||
|
- quick decision tools:
|
||||||
|
- no action
|
||||||
|
- warning
|
||||||
|
- time penalty
|
||||||
|
- points deduction
|
||||||
|
- DQ for the race
|
||||||
|
|
||||||
|
### GridPilot updates everything automatically:
|
||||||
|
- recalculates standings
|
||||||
|
- adjusts team points
|
||||||
|
- logs penalties visibly
|
||||||
|
|
||||||
|
Admins stay in full control — GridPilot just removes the manual work.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Optional: Session Creation QoL
|
||||||
|
|
||||||
|
Automation is *optional* — but powerful for admins who want it.
|
||||||
|
|
||||||
|
### One-click creation of:
|
||||||
|
- practice sessions
|
||||||
|
- race sessions
|
||||||
|
- full season batches
|
||||||
|
|
||||||
|
### Benefits:
|
||||||
|
- no repetitive form filling
|
||||||
|
- consistent settings
|
||||||
|
- saves hours every season
|
||||||
|
- always under admin control
|
||||||
|
|
||||||
|
GridPilot acts as an **assistant**, not a bot.
|
||||||
|
Admins keep full responsibility.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Roster & Driver Management
|
||||||
|
|
||||||
|
Admins can:
|
||||||
|
- view complete roster
|
||||||
|
- assign drivers to teams
|
||||||
|
- manage substitutes
|
||||||
|
- approve/reject sign-ups
|
||||||
|
- track attendance
|
||||||
|
- see driver stats for performance evaluation
|
||||||
|
|
||||||
|
Helps maintain a healthy community and balanced competition.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Transparency & Trust
|
||||||
|
|
||||||
|
GridPilot creates structure admins normally have to enforce manually:
|
||||||
|
|
||||||
|
- clear point systems
|
||||||
|
- visible penalties
|
||||||
|
- visible rules
|
||||||
|
- logged decisions
|
||||||
|
- consistent standings
|
||||||
|
- predictable schedules
|
||||||
|
- no lost messages or hidden complaints
|
||||||
|
|
||||||
|
This removes accusations of favoritism or unfairness.
|
||||||
|
|
||||||
|
Admins gain **presence**, not stress.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Zero Technical Overhead
|
||||||
|
|
||||||
|
No coding.
|
||||||
|
No servers.
|
||||||
|
No spreadsheets.
|
||||||
|
No HTML.
|
||||||
|
No spreadsheets.
|
||||||
|
No setup.
|
||||||
|
|
||||||
|
Admins simply:
|
||||||
|
1. create a league
|
||||||
|
2. configure the season
|
||||||
|
3. share the league link
|
||||||
|
4. run the races
|
||||||
|
5. GridPilot handles the rest
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. What GridPilot Is *Not* for Admins
|
||||||
|
|
||||||
|
- not a replacement for your Discord community
|
||||||
|
- not a stewarding system (no live stewarding)
|
||||||
|
- not intrusive automation
|
||||||
|
- not a tool that changes racing behavior
|
||||||
|
- not a way to manipulate results
|
||||||
|
|
||||||
|
We respect the league → we just make it manageable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 12. Summary
|
||||||
|
|
||||||
|
GridPilot gives admins:
|
||||||
|
|
||||||
|
- **professional presentation**
|
||||||
|
- **zero manual points work**
|
||||||
|
- **automatic standings**
|
||||||
|
- **clean sign-ups**
|
||||||
|
- **structured complaints**
|
||||||
|
- **quick penalties**
|
||||||
|
- **optional session automation**
|
||||||
|
- **roster tools**
|
||||||
|
- **driver & team identity**
|
||||||
|
- **season organization**
|
||||||
|
|
||||||
|
It lets admins focus on racing, not paperwork.
|
||||||
|
|
||||||
|
GridPilot =
|
||||||
|
**less chaos, more competition.**
|
||||||
283
docs/concept/COMPETITION.md
Normal file
283
docs/concept/COMPETITION.md
Normal file
@@ -0,0 +1,283 @@
|
|||||||
|
# GridPilot Competition & Unique Selling Points
|
||||||
|
*Why GridPilot matters — and why it fills the biggest gap in iRacing league racing.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 1. What iRacing Leagues Are Missing
|
||||||
|
|
||||||
|
iRacing does many things extremely well:
|
||||||
|
- great cars
|
||||||
|
- great physics
|
||||||
|
- huge official participation
|
||||||
|
- excellent netcode
|
||||||
|
|
||||||
|
But iRacing does **not** provide:
|
||||||
|
- long-term driver identity
|
||||||
|
- league structure
|
||||||
|
- team championships
|
||||||
|
- personalized stats
|
||||||
|
- season history
|
||||||
|
- league discovery
|
||||||
|
- automated standings
|
||||||
|
- protest/penalty workflows
|
||||||
|
- a centralized competition ecosystem
|
||||||
|
|
||||||
|
Everything around league racing is **outsourced to Discord chaos**.
|
||||||
|
|
||||||
|
GridPilot fixes the layer iRacing ignores.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2. The Competition Layer iRacing Never Built
|
||||||
|
|
||||||
|
GridPilot becomes the competition universe for league racing:
|
||||||
|
|
||||||
|
### **Drivers get**
|
||||||
|
- a racing identity
|
||||||
|
- a real profile that spans leagues
|
||||||
|
- season standings that matter
|
||||||
|
- team championships
|
||||||
|
- points that persist
|
||||||
|
- stats that make progress visible
|
||||||
|
|
||||||
|
### **Admins get**
|
||||||
|
- reliable standings
|
||||||
|
- structured schedules
|
||||||
|
- automated results
|
||||||
|
- clean sign-up flows
|
||||||
|
- real competition formats
|
||||||
|
|
||||||
|
### **Leagues get**
|
||||||
|
- a professional home
|
||||||
|
- discoverability
|
||||||
|
- branding
|
||||||
|
- stable structure
|
||||||
|
|
||||||
|
This is something **no existing tool** provides in a unified way.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 3. What Others Do (and Why It’s Not Enough)
|
||||||
|
|
||||||
|
### **SimRacerHub**
|
||||||
|
- ancient UI
|
||||||
|
- manual CSV uploads
|
||||||
|
- no identity
|
||||||
|
- no automation
|
||||||
|
- no team competition
|
||||||
|
- no discovery
|
||||||
|
- no long-term profiles
|
||||||
|
|
||||||
|
### **Discord + Google Sheets**
|
||||||
|
- disorganized
|
||||||
|
- non-scalable
|
||||||
|
- everything is manual
|
||||||
|
- error-prone
|
||||||
|
- no identity
|
||||||
|
- no automation
|
||||||
|
- no trust system
|
||||||
|
- no visibility
|
||||||
|
|
||||||
|
### **iRacing Official Series**
|
||||||
|
- random grids
|
||||||
|
- no personal connection
|
||||||
|
- no ladder
|
||||||
|
- no league-style competition
|
||||||
|
- no teams (beyond 1-car teams)
|
||||||
|
- no season identity
|
||||||
|
|
||||||
|
### **SimGrid (ACC)**
|
||||||
|
- not for iRacing
|
||||||
|
- no automation
|
||||||
|
- not deeply connected to semiprofessional league structures
|
||||||
|
|
||||||
|
### **LFM**
|
||||||
|
- matchmaking, not league management
|
||||||
|
- no season identity
|
||||||
|
- not for iRacing
|
||||||
|
- no team championship
|
||||||
|
- no admin tooling
|
||||||
|
|
||||||
|
**Conclusion:**
|
||||||
|
There is *no* product that unifies the league racing ecosystem for iRacing.
|
||||||
|
|
||||||
|
GridPilot is literally the **first** to do this properly.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 4. What GridPilot Does That Nobody Else Can
|
||||||
|
|
||||||
|
## **1. Clean, automatic league infrastructure**
|
||||||
|
- standings
|
||||||
|
- results
|
||||||
|
- rosters
|
||||||
|
- seasons
|
||||||
|
- scoring
|
||||||
|
- team formats
|
||||||
|
|
||||||
|
Nobody else automates this end-to-end.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## **2. Real Constructors-Style Team Championships**
|
||||||
|
iRacing has:
|
||||||
|
- only one driver per car
|
||||||
|
- no parallel team scoring
|
||||||
|
- no true team competition
|
||||||
|
|
||||||
|
GridPilot:
|
||||||
|
- multiple drivers race for one team
|
||||||
|
- all points count
|
||||||
|
- teams gain prestige across seasons
|
||||||
|
|
||||||
|
This completely changes how league racing feels.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## **3. Unified Driver Identity Across Leagues**
|
||||||
|
Drivers currently:
|
||||||
|
- disappear between seasons
|
||||||
|
- have no home
|
||||||
|
- no stats
|
||||||
|
- no history
|
||||||
|
|
||||||
|
GridPilot gives them:
|
||||||
|
- permanent stats
|
||||||
|
- history
|
||||||
|
- standings
|
||||||
|
- cross-league progression
|
||||||
|
- consistent profile
|
||||||
|
|
||||||
|
This becomes the **center of their virtual racing career**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## **4. Structured Complaints & Penalties**
|
||||||
|
Other platforms:
|
||||||
|
- use DMs
|
||||||
|
- use Discord
|
||||||
|
- lose messages
|
||||||
|
- inconsistent punishment
|
||||||
|
- emotional chaos
|
||||||
|
|
||||||
|
GridPilot:
|
||||||
|
- structured forms
|
||||||
|
- timestamps
|
||||||
|
- clear penalty tools
|
||||||
|
- automatic standings update
|
||||||
|
|
||||||
|
This makes leagues feel *fair* — a huge USP.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## **5. Season creation without busywork**
|
||||||
|
Admins normally spend hours on:
|
||||||
|
- session creation
|
||||||
|
- spreadsheets
|
||||||
|
- messaging
|
||||||
|
|
||||||
|
GridPilot:
|
||||||
|
- automates results
|
||||||
|
- simplifies sessions
|
||||||
|
- cleans up registration
|
||||||
|
- centralizes everything
|
||||||
|
|
||||||
|
It’s the **ultimate league admin QoL platform**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 5. Why Drivers Should Sign Up
|
||||||
|
|
||||||
|
**Because racing finally means something.**
|
||||||
|
|
||||||
|
GridPilot gives drivers:
|
||||||
|
- season standings
|
||||||
|
- long-term stats
|
||||||
|
- team championships
|
||||||
|
- identity
|
||||||
|
- clarity
|
||||||
|
- professionalism
|
||||||
|
- an organized home for their racing
|
||||||
|
|
||||||
|
No more guessing, no more chaos — a place to grow and compete.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 6. Why Admins Should Use GridPilot
|
||||||
|
|
||||||
|
**Because running a league shouldn’t be a full-time job.**
|
||||||
|
|
||||||
|
GridPilot:
|
||||||
|
- removes the boring work
|
||||||
|
- automates the repetitive tasks
|
||||||
|
- enforces structure
|
||||||
|
- keeps standings clean
|
||||||
|
- removes spreadsheet pain
|
||||||
|
- prevents drama
|
||||||
|
- makes their league look professional
|
||||||
|
|
||||||
|
Admins feel supported instead of overwhelmed.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 7. Why GridPilot Will Become THE Platform
|
||||||
|
|
||||||
|
GridPilot combines:
|
||||||
|
|
||||||
|
- **admin tools**
|
||||||
|
- **driver identity**
|
||||||
|
- **team championships**
|
||||||
|
- **competition structure**
|
||||||
|
- **automated results**
|
||||||
|
- **clear season organization**
|
||||||
|
- **discovery & visibility**
|
||||||
|
|
||||||
|
This creates a **complete ecosystem**, not just a tool.
|
||||||
|
|
||||||
|
When multiple leagues use it → drivers collect universal stats.
|
||||||
|
When drivers collect stats → teams form around them.
|
||||||
|
When teams form → prestige and competition grow.
|
||||||
|
When prestige grows → more leagues join.
|
||||||
|
|
||||||
|
This creates a **network effect** no other platform has.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 8. Simple Value Summary (ideal for landing page)
|
||||||
|
|
||||||
|
### For Drivers:
|
||||||
|
- real competition
|
||||||
|
- season identity
|
||||||
|
- long-term stats
|
||||||
|
- team championships
|
||||||
|
- one place for all leagues
|
||||||
|
|
||||||
|
### For Admins:
|
||||||
|
- less work
|
||||||
|
- no spreadsheets
|
||||||
|
- clean sign-ups
|
||||||
|
- automatic standings
|
||||||
|
- proper penalty tools
|
||||||
|
- professional league branding
|
||||||
|
|
||||||
|
### For the Community:
|
||||||
|
- a central home
|
||||||
|
- simple discovery
|
||||||
|
- fair competition
|
||||||
|
- consistent rules
|
||||||
|
- real history
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 9. Why You Should Sign Up Early
|
||||||
|
|
||||||
|
Because:
|
||||||
|
- early leagues define the meta
|
||||||
|
- early drivers get full season history
|
||||||
|
- early admins help shape the platform
|
||||||
|
- you get modern tools for free during beta
|
||||||
|
- you’re part of the first proper iRacing league ecosystem
|
||||||
|
- you want league racing with meaning, structure, and clarity
|
||||||
|
|
||||||
|
GridPilot is the **competition layer iRacing never built —
|
||||||
|
and the league ecosystem drivers always wanted.**
|
||||||
232
docs/concept/CONCEPT.md
Normal file
232
docs/concept/CONCEPT.md
Normal file
@@ -0,0 +1,232 @@
|
|||||||
|
# GridPilot — The Competition Platform for iRacing Leagues
|
||||||
|
*A modern, lightweight platform that gives iRacing league racing structure, identity, and long-term meaning — without taking control away from communities.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 1. What GridPilot Solves
|
||||||
|
|
||||||
|
iRacing’s strength is racing quality, not league infrastructure.
|
||||||
|
Today, league racing suffers from:
|
||||||
|
|
||||||
|
- scattered tools (Discord, Sheets, Forms, DMs)
|
||||||
|
- zero unified identity for leagues
|
||||||
|
- heavy admin workload for every race
|
||||||
|
- no automatic standings or result sync
|
||||||
|
- no long-term driver identity or career stats
|
||||||
|
- no proper team-based competition
|
||||||
|
- unstructured protest handling (DMs, screenshots, chaos)
|
||||||
|
|
||||||
|
GridPilot becomes the **competition layer** above iRacing.
|
||||||
|
We don’t change racing — we fix everything around it.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2. Who GridPilot Is For
|
||||||
|
|
||||||
|
## League Admins
|
||||||
|
Need:
|
||||||
|
- easy season setup
|
||||||
|
- automatic result handling
|
||||||
|
- clean standings
|
||||||
|
- a structured complaints/penalty workflow
|
||||||
|
- predictable points systems
|
||||||
|
- modern league presentation
|
||||||
|
- simple driver/team signups
|
||||||
|
- optional session-creation QoL automation
|
||||||
|
|
||||||
|
## Drivers
|
||||||
|
Need:
|
||||||
|
- easy league discovery
|
||||||
|
- simple registration
|
||||||
|
- clean standings
|
||||||
|
- reliable schedule
|
||||||
|
- personal stats and history
|
||||||
|
- long-term progression
|
||||||
|
- team + individual competition
|
||||||
|
- structured way to file complaints
|
||||||
|
|
||||||
|
Admin + Driver = **GridPilot’s only focus for MVP**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 3. Core Features (MVP)
|
||||||
|
|
||||||
|
## 3.1 League Identity
|
||||||
|
- clean public league page
|
||||||
|
- schedule, standings, roster, rules
|
||||||
|
- league branding (logo, colors)
|
||||||
|
- optional custom domain
|
||||||
|
- links to Discord / YouTube / Twitch
|
||||||
|
|
||||||
|
## 3.2 Season Management
|
||||||
|
- full calendar for each season
|
||||||
|
- point system presets
|
||||||
|
- drop weeks
|
||||||
|
- team or solo mode
|
||||||
|
- automatic standings
|
||||||
|
|
||||||
|
## 3.3 Driver & Team System
|
||||||
|
### Drivers:
|
||||||
|
- league join flow
|
||||||
|
- personal stats (per race + lifetime)
|
||||||
|
- progression + history
|
||||||
|
- cross-league identity (v1 basic)
|
||||||
|
|
||||||
|
### Teams:
|
||||||
|
- create/manage teams
|
||||||
|
- team roster management
|
||||||
|
- real “Constructors Championship” parallel scoring
|
||||||
|
- team standings + history
|
||||||
|
|
||||||
|
(This is a unique selling point: **real team racing in iRacing leagues**.)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 4. Complaints & Penalties (Essential)
|
||||||
|
|
||||||
|
A structured system to replace Discord DMs and random drama.
|
||||||
|
|
||||||
|
## 4.1 Driver Complaints
|
||||||
|
Drivers can file a complaint with:
|
||||||
|
- race
|
||||||
|
- involved drivers
|
||||||
|
- timestamp(s)
|
||||||
|
- description
|
||||||
|
- optional replay clip / link
|
||||||
|
|
||||||
|
Keeps everything organized and searchable.
|
||||||
|
|
||||||
|
## 4.2 Admin Penalty Tools
|
||||||
|
Admins get a review panel:
|
||||||
|
- complaint list
|
||||||
|
- timestamps + notes
|
||||||
|
- direct links to replays
|
||||||
|
- quick actions:
|
||||||
|
- no action
|
||||||
|
- warning
|
||||||
|
- time penalty
|
||||||
|
- points deduction
|
||||||
|
- DQ for race
|
||||||
|
|
||||||
|
## 4.3 Automatic Standings Update
|
||||||
|
When a penalty is assigned:
|
||||||
|
- driver points update
|
||||||
|
- team points update
|
||||||
|
- classification updates with time penalties
|
||||||
|
- everything logged transparently
|
||||||
|
|
||||||
|
Admins stay in control.
|
||||||
|
Drivers understand the decision.
|
||||||
|
Chaos disappears.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 5. Result Automation (Essential QoL)
|
||||||
|
|
||||||
|
- automatically sync race results from iRacing
|
||||||
|
- parse positions, laps, incidents, fastest lap
|
||||||
|
- update standings instantly
|
||||||
|
- eliminate manual CSV uploads or spreadsheets
|
||||||
|
|
||||||
|
This is **core** for both admins and drivers
|
||||||
|
(but not the “main feature” — just feels like magic).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 6. Optional: Session Creation QoL (Not required)
|
||||||
|
|
||||||
|
GridPilot can assist admins:
|
||||||
|
- create sessions via browser automation
|
||||||
|
- batch-create entire season
|
||||||
|
- consistent settings without errors
|
||||||
|
|
||||||
|
Important:
|
||||||
|
**Automation is a helper, not the product.**
|
||||||
|
We never touch gameplay.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 7. Competition Layer
|
||||||
|
|
||||||
|
This is what makes GridPilot more than “tools”.
|
||||||
|
|
||||||
|
## 7.1 Individual Progression
|
||||||
|
Drivers earn:
|
||||||
|
- points
|
||||||
|
- standings
|
||||||
|
- history
|
||||||
|
- personal stats
|
||||||
|
- performance trends
|
||||||
|
|
||||||
|
Racing finally has **long-term meaning**.
|
||||||
|
|
||||||
|
## 7.2 Team Competition
|
||||||
|
Teams accumulate points across races and seasons.
|
||||||
|
Drivers contribute to team success even when racing individually.
|
||||||
|
|
||||||
|
The result:
|
||||||
|
**iRacing Ligen finally feel like real motorsport championships.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 8. Safety, Security & Trust
|
||||||
|
- zero-knowledge login
|
||||||
|
- we never see or store passwords
|
||||||
|
- browser window visible for login
|
||||||
|
- automation always runs *on the admin’s machine*
|
||||||
|
- no client modification (unlike iRefined)
|
||||||
|
|
||||||
|
Trust and legality are fundamental.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 9. MVP Philosophy
|
||||||
|
|
||||||
|
### What we include:
|
||||||
|
- Admin QoL tools
|
||||||
|
- Driver identity
|
||||||
|
- Team competition
|
||||||
|
- Standings + automation
|
||||||
|
- Complaints + penalties
|
||||||
|
- League identity + presentation
|
||||||
|
- Session creation helper (optional)
|
||||||
|
|
||||||
|
### What we leave out for now:
|
||||||
|
- stewards marketplace
|
||||||
|
- streaming tools
|
||||||
|
- monetization
|
||||||
|
- complex global ladder
|
||||||
|
- rating systems
|
||||||
|
- cross-sim functionality
|
||||||
|
- esports organization
|
||||||
|
|
||||||
|
GridPilot starts **simple and solid**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 10. Long-Term Vision (kept small but real)
|
||||||
|
|
||||||
|
GridPilot becomes the central place where:
|
||||||
|
- drivers build a career
|
||||||
|
- teams compete across seasons
|
||||||
|
- leagues run without chaos
|
||||||
|
- complaints/penalties stay structured
|
||||||
|
- standings stay consistent
|
||||||
|
- automation reduces work
|
||||||
|
- identity and progression matter
|
||||||
|
|
||||||
|
This is the part that makes us **THE platform**,
|
||||||
|
but we don’t overpromise it on day one.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Summary
|
||||||
|
|
||||||
|
**GridPilot simplifies league management —
|
||||||
|
and elevates it from scattered spreadsheets
|
||||||
|
to a modern competition platform.**
|
||||||
|
|
||||||
|
Admins get less work.
|
||||||
|
Drivers get more meaning.
|
||||||
|
Teams get real championships.
|
||||||
|
Everyone gets structure instead of chaos.
|
||||||
236
docs/concept/DRIVERS.md
Normal file
236
docs/concept/DRIVERS.md
Normal file
@@ -0,0 +1,236 @@
|
|||||||
|
# GridPilot for Drivers
|
||||||
|
*A clean competition platform that gives iRacing drivers structure, clarity, and long-term identity — without the chaos of Discord, spreadsheets, or scattered tools.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Why GridPilot Matters for Drivers
|
||||||
|
|
||||||
|
iRacing’s official races are fun, but they’re anonymous.
|
||||||
|
Community leagues are exciting, but they’re chaotic and inconsistent.
|
||||||
|
|
||||||
|
Drivers want:
|
||||||
|
- clear schedules
|
||||||
|
- consistent standings
|
||||||
|
- honest competition
|
||||||
|
- long-term stats
|
||||||
|
- team identity
|
||||||
|
- simple sign-ups
|
||||||
|
- structured complaints
|
||||||
|
- a place to follow their own racing journey
|
||||||
|
|
||||||
|
GridPilot gives drivers the **missing competitive layer** on top of iRacing leagues.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Your Driver Profile
|
||||||
|
|
||||||
|
Every GridPilot driver gets a modern profile that shows who they are across leagues.
|
||||||
|
|
||||||
|
### **Profile includes**
|
||||||
|
- name, number, country
|
||||||
|
- leagues you’re currently racing in
|
||||||
|
- season standings (driver + team)
|
||||||
|
- race history
|
||||||
|
- long-term point totals
|
||||||
|
- finishing positions
|
||||||
|
- incident trends
|
||||||
|
- performance stats (e.g., avg finish, win rate)
|
||||||
|
- optional team membership
|
||||||
|
|
||||||
|
### **Why it’s different**
|
||||||
|
For the first time, your results aren’t stuck in individual Discords or spreadsheets.
|
||||||
|
|
||||||
|
Your **racing identity lives in one place**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. League Discovery — Find Where You Belong
|
||||||
|
|
||||||
|
GridPilot makes it easy to find leagues that fit your schedule, skill level, and car preferences.
|
||||||
|
|
||||||
|
### **Search filters**
|
||||||
|
- car class
|
||||||
|
- time of day
|
||||||
|
- weekday/weekend
|
||||||
|
- competition level
|
||||||
|
- league size
|
||||||
|
- region
|
||||||
|
|
||||||
|
### **League pages show**
|
||||||
|
- schedule
|
||||||
|
- standings
|
||||||
|
- rules & format
|
||||||
|
- car/track list
|
||||||
|
- roster
|
||||||
|
- sign-ups
|
||||||
|
|
||||||
|
No more scrolling through dead Discord ads or random forum posts.
|
||||||
|
You actually *see* what you’re joining.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Joining a League — Simple & Fast
|
||||||
|
|
||||||
|
A driver-first flow:
|
||||||
|
|
||||||
|
1. Pick a league
|
||||||
|
2. Review schedule & format
|
||||||
|
3. Join solo or select a team
|
||||||
|
4. See upcoming races instantly
|
||||||
|
5. Start collecting points
|
||||||
|
|
||||||
|
No forms.
|
||||||
|
No spreadsheets.
|
||||||
|
No “talk to the admin.”
|
||||||
|
Just click and race.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Race Day Clarity
|
||||||
|
|
||||||
|
GridPilot gives drivers everything they need to show up ready:
|
||||||
|
|
||||||
|
- upcoming race timer
|
||||||
|
- track, car, session settings
|
||||||
|
- lobby info (password, link, format)
|
||||||
|
- previous race results
|
||||||
|
- standings impact preview
|
||||||
|
- weather / dynamic info (if available)
|
||||||
|
|
||||||
|
Drivers stop asking the admin:
|
||||||
|
> “Hey, what’s the track this week?”
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Automatic Race Results
|
||||||
|
|
||||||
|
After the race, GridPilot automatically pulls iRacing’s results:
|
||||||
|
|
||||||
|
### **You get**
|
||||||
|
- final classification
|
||||||
|
- gained/lost positions
|
||||||
|
- incidents
|
||||||
|
- fastest laps
|
||||||
|
- points earned
|
||||||
|
- drop-week changes
|
||||||
|
|
||||||
|
No more:
|
||||||
|
- waiting for an admin
|
||||||
|
- refreshing Discord
|
||||||
|
- reading screenshots
|
||||||
|
- guessing standings
|
||||||
|
|
||||||
|
Standings update themselves the moment results hit iRacing.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Long-Term Progression
|
||||||
|
|
||||||
|
Drivers always wanted more than “just racing.”
|
||||||
|
GridPilot gives:
|
||||||
|
|
||||||
|
### **Season history**
|
||||||
|
- every race
|
||||||
|
- every point
|
||||||
|
- every position change
|
||||||
|
|
||||||
|
### **Career overview**
|
||||||
|
- races completed
|
||||||
|
- podiums
|
||||||
|
- wins
|
||||||
|
- average finish
|
||||||
|
- trendline performance
|
||||||
|
|
||||||
|
### **Multi-league identity**
|
||||||
|
Your GridPilot profile grows as you race in multiple leagues and seasons.
|
||||||
|
|
||||||
|
This makes league racing finally feel **meaningful**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Team Racing — Real Constructors-Style Competition
|
||||||
|
|
||||||
|
GridPilot supports **real team racing**, not the one-driver-per-team limitation of most leagues.
|
||||||
|
|
||||||
|
### **How it works**
|
||||||
|
- each team registers multiple drivers
|
||||||
|
- drivers race in parallel
|
||||||
|
- all points contribute to the team championship
|
||||||
|
- teams gain prestige over multiple seasons
|
||||||
|
|
||||||
|
### **For drivers**
|
||||||
|
You can:
|
||||||
|
- join a team
|
||||||
|
- help your team climb the standings
|
||||||
|
- show your contribution in your profile
|
||||||
|
- build real rivalries over time
|
||||||
|
|
||||||
|
This creates a feeling of *real motorsport* instead of isolated races.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Complaints & Penalties Made Simple
|
||||||
|
|
||||||
|
Drivers finally get a **structured** way to submit complaints.
|
||||||
|
|
||||||
|
### **Submit complaint**
|
||||||
|
- pick the race
|
||||||
|
- pick involved drivers
|
||||||
|
- add timestamps
|
||||||
|
- add description
|
||||||
|
- optional replay clip / YouTube link
|
||||||
|
|
||||||
|
### **Admin sees a simple review panel.**
|
||||||
|
No lost DMs, no arguments across Discord, no chaos.
|
||||||
|
|
||||||
|
### **Standings update automatically after penalties.**
|
||||||
|
No manual math.
|
||||||
|
No spreadsheet edits.
|
||||||
|
|
||||||
|
Drivers get transparency.
|
||||||
|
Admins get speed.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. The Experience for Drivers
|
||||||
|
|
||||||
|
GridPilot gives drivers:
|
||||||
|
|
||||||
|
- fewer distractions
|
||||||
|
- less confusion
|
||||||
|
- no spreadsheet hell
|
||||||
|
- proper standings
|
||||||
|
- identity that grows
|
||||||
|
- team fantasy + real competition
|
||||||
|
- simple joining
|
||||||
|
- long-term motivation
|
||||||
|
- reliable information
|
||||||
|
- structured dispute resolution
|
||||||
|
|
||||||
|
League racing finally feels like a **proper season**, not a patchwork process.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. What GridPilot *does not* do (important)
|
||||||
|
|
||||||
|
- doesn’t manage your Discord social life
|
||||||
|
- doesn’t auto-join races for you
|
||||||
|
- doesn’t replace iRacing
|
||||||
|
- doesn’t enforce drama rules
|
||||||
|
- doesn’t simulate or interfere with gameplay
|
||||||
|
|
||||||
|
GridPilot strengthens what drivers already enjoy —
|
||||||
|
and eliminates everything that frustrates them.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Summary
|
||||||
|
|
||||||
|
GridPilot for Drivers is about three things:
|
||||||
|
|
||||||
|
1. **Clarity** — know where, when, and what you’re racing.
|
||||||
|
2. **Progression** — see your improvement and career.
|
||||||
|
3. **Competition** — battle in leagues and teams that feel like real motorsport.
|
||||||
|
|
||||||
|
The platform gives drivers exactly what they’re missing today:
|
||||||
|
a central, modern home for their league racing identity.
|
||||||
192
docs/concept/LANDING.md
Normal file
192
docs/concept/LANDING.md
Normal file
@@ -0,0 +1,192 @@
|
|||||||
|
# GridPilot — Where iRacing League Racing Finally Comes Together
|
||||||
|
*A modern platform that makes league racing clearer, cleaner, and actually fun — for drivers, admins, and teams.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## League racing deserves better.
|
||||||
|
|
||||||
|
Right now, running or joining a league means:
|
||||||
|
- Discord chaos
|
||||||
|
- scattered spreadsheets
|
||||||
|
- unclear standings
|
||||||
|
- manual data entry
|
||||||
|
- lost messages
|
||||||
|
- confusing sign-ups
|
||||||
|
- penalties handled in DMs
|
||||||
|
- no global identity
|
||||||
|
- no long-term stats
|
||||||
|
|
||||||
|
The racing in iRacing is amazing.
|
||||||
|
**Everything around it shouldn't be this messy.**
|
||||||
|
|
||||||
|
GridPilot fixes the layer iRacing leaves behind.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# What GridPilot gives you
|
||||||
|
|
||||||
|
## 📅 A real home for your league
|
||||||
|
Every league gets:
|
||||||
|
- a clean schedule
|
||||||
|
- standings
|
||||||
|
- results
|
||||||
|
- driver roster
|
||||||
|
- rules
|
||||||
|
- branding
|
||||||
|
- links (Discord, Twitch, YouTube, etc.)
|
||||||
|
|
||||||
|
No setup.
|
||||||
|
No technical pain.
|
||||||
|
Just a proper league homepage that looks professional.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🏁 Automatic results & standings
|
||||||
|
You race → GridPilot handles the rest.
|
||||||
|
|
||||||
|
We track:
|
||||||
|
- positions
|
||||||
|
- incidents
|
||||||
|
- points
|
||||||
|
- drop weeks
|
||||||
|
- driver stats
|
||||||
|
- team points
|
||||||
|
- performance trends
|
||||||
|
|
||||||
|
Standings update instantly after results hit iRacing.
|
||||||
|
Admins never touch spreadsheets again.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 👥 Real team racing — finally done right
|
||||||
|
Not just “tags next to names.”
|
||||||
|
|
||||||
|
GridPilot supports true constructors-style racing:
|
||||||
|
- multiple drivers contribute points
|
||||||
|
- flexible scoring rules
|
||||||
|
- dynamic lineups (different drivers each race)
|
||||||
|
- team standings
|
||||||
|
- season + all-time history
|
||||||
|
- driver contribution breakdown
|
||||||
|
|
||||||
|
League racing finally feels like **real motorsport**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 👤 Driver identity that actually matters
|
||||||
|
Your racing history follows you across leagues and seasons.
|
||||||
|
|
||||||
|
Your driver profile includes:
|
||||||
|
- race results
|
||||||
|
- season standings
|
||||||
|
- incident trends
|
||||||
|
- consistency metrics
|
||||||
|
- points over time
|
||||||
|
- team membership
|
||||||
|
- personal progress
|
||||||
|
|
||||||
|
iRacing gives you physics.
|
||||||
|
**GridPilot gives you a racing career.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ⚖ Clean protests & quick penalties
|
||||||
|
No more chaotic DM chains or missing evidence.
|
||||||
|
|
||||||
|
Drivers can submit structured complaints with:
|
||||||
|
- timestamps
|
||||||
|
- drivers involved
|
||||||
|
- description
|
||||||
|
- optional replay clips
|
||||||
|
|
||||||
|
Admins get:
|
||||||
|
- a proper review panel
|
||||||
|
- quick penalty tools (warning, time penalty, points deduction, DQ)
|
||||||
|
- auto-updated standings
|
||||||
|
|
||||||
|
Fair. Transparent. Zero drama.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🚀 Race management without headaches
|
||||||
|
Admins get:
|
||||||
|
- season builder
|
||||||
|
- roster tools
|
||||||
|
- sign-up flows
|
||||||
|
- scoring presets
|
||||||
|
- automatic result import
|
||||||
|
- penalty system
|
||||||
|
- league branding
|
||||||
|
|
||||||
|
Everything that normally takes hours per week…
|
||||||
|
now takes minutes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🔧 One-click session creation (Quality-of-Life)
|
||||||
|
Filling out hosted session forms is repetitive as hell.
|
||||||
|
GridPilot can help:
|
||||||
|
|
||||||
|
- generate full season sessions
|
||||||
|
- consistent configuration
|
||||||
|
- no more manual form work
|
||||||
|
- admin stays fully in control
|
||||||
|
|
||||||
|
This is not the product —
|
||||||
|
it's just something that makes life easier.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Why people will use GridPilot
|
||||||
|
|
||||||
|
### For drivers:
|
||||||
|
- clearer racing
|
||||||
|
- real identity
|
||||||
|
- competitive meaning
|
||||||
|
- team pride
|
||||||
|
- structured info
|
||||||
|
- proper stats
|
||||||
|
- no spreadsheet guessing
|
||||||
|
|
||||||
|
### For admins:
|
||||||
|
- less work
|
||||||
|
- fewer mistakes
|
||||||
|
- clean presentation
|
||||||
|
- no nightly result updates
|
||||||
|
- no Discord chaos
|
||||||
|
- clear rules & penalties
|
||||||
|
- smooth seasons
|
||||||
|
|
||||||
|
### For teams:
|
||||||
|
- proper constructors championships
|
||||||
|
- recruitment tools
|
||||||
|
- long-term reputation
|
||||||
|
- contribution metrics
|
||||||
|
- cross-season continuity
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Why this exists (in plain words)
|
||||||
|
|
||||||
|
Because league racing is the best part of iRacing
|
||||||
|
— and the worst-maintained.
|
||||||
|
|
||||||
|
We’re building something practical, modern, and helpful.
|
||||||
|
Not trying to reinvent racing, not trying to replace leagues,
|
||||||
|
just trying to make everything around racing **less painful and more meaningful**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Want early access?
|
||||||
|
|
||||||
|
GridPilot is opening early access to **everyone** who wants smoother, more organized league racing.
|
||||||
|
|
||||||
|
Drop your email if you want:
|
||||||
|
- updates as features go live
|
||||||
|
- a chance to shape the platform
|
||||||
|
- early access once things stabilize
|
||||||
|
- zero spam, zero BS
|
||||||
|
|
||||||
|
[ Email field ] [ Sign Up ]
|
||||||
|
|
||||||
|
Let’s make league racing better — together.
|
||||||
250
docs/concept/RACING.md
Normal file
250
docs/concept/RACING.md
Normal file
@@ -0,0 +1,250 @@
|
|||||||
|
# GridPilot Race Management
|
||||||
|
*A unified system for running modern iRacing leagues with team formats, automated series structures, and clean penalty handling.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 1. Overview
|
||||||
|
|
||||||
|
GridPilot Race Management defines **how racing works on the platform**,
|
||||||
|
independent of league size or community style.
|
||||||
|
|
||||||
|
It consists of three pillars:
|
||||||
|
|
||||||
|
1. **Team Leagues** — real constructors-style multi-driver competitions
|
||||||
|
2. **Automated Leagues** — structured series (e.g., F1-style) that GridPilot can mirror
|
||||||
|
3. **Penalty & Protest System** — clean dispute resolution without Discord chaos
|
||||||
|
|
||||||
|
GridPilot's goal is to make league racing **consistent, fair, and meaningful**,
|
||||||
|
without forcing admins into complexity or drivers into mandatory social interaction.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2. Team Leagues (Constructors Format)
|
||||||
|
|
||||||
|
Most iRacing leagues treat teams as cosmetic.
|
||||||
|
GridPilot treats them as **primary competition units**, like real motorsport.
|
||||||
|
|
||||||
|
## 2.1 Team Structure
|
||||||
|
|
||||||
|
A team has:
|
||||||
|
- Team profile (logo, colors, description)
|
||||||
|
- Captain / co-captains
|
||||||
|
- Roster of drivers
|
||||||
|
- Recruitment status
|
||||||
|
- Participation history
|
||||||
|
- Team stats + points
|
||||||
|
|
||||||
|
Teams exist platform-wide — not only inside one league.
|
||||||
|
|
||||||
|
## 2.2 Team Participation in a League
|
||||||
|
|
||||||
|
Teams can:
|
||||||
|
- register for seasons
|
||||||
|
- assign drivers to race slots
|
||||||
|
- have different drivers each week
|
||||||
|
- score parallel points from every contributing driver
|
||||||
|
|
||||||
|
## 2.3 Constructors-Style Points
|
||||||
|
|
||||||
|
GridPilot supports multiple team scoring methods:
|
||||||
|
|
||||||
|
- **All Drivers Count** (every finisher scores team points)
|
||||||
|
- **Top X Drivers Count** (top 2, top 3, etc.)
|
||||||
|
- **Weighted Points** (e.g., top driver counts 60%, next counts 40%)
|
||||||
|
- **Custom Rules per League**
|
||||||
|
|
||||||
|
Admins choose their model.
|
||||||
|
GridPilot handles the math, standings, history, and transparency.
|
||||||
|
|
||||||
|
## 2.4 Team Rivalries & Identity
|
||||||
|
|
||||||
|
Built-in:
|
||||||
|
- team standings
|
||||||
|
- driver contribution breakdown
|
||||||
|
- cross-season performance
|
||||||
|
- team “form” (last 5 races)
|
||||||
|
- recruitment visibility
|
||||||
|
|
||||||
|
Team racing becomes **a core part of the platform**, not an afterthought.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 3. Automated Leagues (F1-Style Mirror Systems)
|
||||||
|
|
||||||
|
Some admins want complete freedom.
|
||||||
|
Some drivers want structured, official-feeling series.
|
||||||
|
|
||||||
|
GridPilot supports *both* by providing the option for **auto-generated leagues**.
|
||||||
|
|
||||||
|
These are **not forced**; they are templates admins or communities can adopt.
|
||||||
|
|
||||||
|
## 3.1 What Are Automated Leagues?
|
||||||
|
|
||||||
|
An automated league is a **predefined series template** provided by GridPilot that mirrors real motorsport.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
- F1 World Championship (same tracks, same order)
|
||||||
|
- F2 / F3 / F4 analogs
|
||||||
|
- GT3 European Sprint Cup
|
||||||
|
- IMSA-style multiclass
|
||||||
|
- DTM-style format
|
||||||
|
|
||||||
|
Users don’t need to invent formats — they pick from proven structures.
|
||||||
|
|
||||||
|
## 3.2 What an Automated League Includes
|
||||||
|
|
||||||
|
A template defines:
|
||||||
|
- car class
|
||||||
|
- track calendar (pre-set schedule)
|
||||||
|
- race format (practice, quali, race)
|
||||||
|
- scoring system (e.g., FIA F1 points)
|
||||||
|
- bonus points (fastest lap, sprint race, etc.)
|
||||||
|
- team size (e.g., 2 drivers like Constructors)
|
||||||
|
- DNF rules
|
||||||
|
- drop rules (if any)
|
||||||
|
- penalty rules (warnings → time penalties → DSQ)
|
||||||
|
|
||||||
|
Admins can tweak details OR run it 1:1 as provided.
|
||||||
|
|
||||||
|
## 3.3 Session Generation
|
||||||
|
|
||||||
|
GridPilot can automatically:
|
||||||
|
- create the full season
|
||||||
|
- populate all race settings
|
||||||
|
- optionally generate sessions via browser automation
|
||||||
|
- clearly list required content for admins
|
||||||
|
|
||||||
|
This is still *admin-controlled* automation —
|
||||||
|
GridPilot enhances, not replaces, human oversight.
|
||||||
|
|
||||||
|
## 3.4 Why Automated Leagues Matter
|
||||||
|
|
||||||
|
For drivers:
|
||||||
|
- familiar formats
|
||||||
|
- real-world relevance
|
||||||
|
- stability
|
||||||
|
|
||||||
|
For admins:
|
||||||
|
- less planning
|
||||||
|
- less overhead
|
||||||
|
- instantly “professional” structure
|
||||||
|
|
||||||
|
For GridPilot:
|
||||||
|
- predictable competition ecosystem
|
||||||
|
- consistent feature usage
|
||||||
|
- scalable community engagement
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 4. Penalty & Protest System
|
||||||
|
|
||||||
|
A clean, structured way to handle disputes — core to GridPilot fairness.
|
||||||
|
|
||||||
|
## 4.1 Driver-Protest Flow
|
||||||
|
|
||||||
|
Drivers can submit:
|
||||||
|
- race
|
||||||
|
- involved drivers
|
||||||
|
- replay timestamp(s)
|
||||||
|
- explanation text
|
||||||
|
- optional clip/video links
|
||||||
|
|
||||||
|
GridPilot stores everything in a clean UI.
|
||||||
|
|
||||||
|
## 4.2 Admin Review Tools
|
||||||
|
|
||||||
|
Admin sees:
|
||||||
|
- list of protests
|
||||||
|
- timestamps
|
||||||
|
- notes
|
||||||
|
- links
|
||||||
|
- driver details
|
||||||
|
- race context
|
||||||
|
|
||||||
|
Actions:
|
||||||
|
- no action
|
||||||
|
- warning
|
||||||
|
- time penalty (+5s / +10s / +30s)
|
||||||
|
- points deduction
|
||||||
|
- DSQ race
|
||||||
|
|
||||||
|
Everything updates automatically.
|
||||||
|
|
||||||
|
## 4.3 Automatic Classification Updates
|
||||||
|
|
||||||
|
Time penalties:
|
||||||
|
- re-sort results
|
||||||
|
- adjust finishing positions
|
||||||
|
- recalc points
|
||||||
|
- update team standings
|
||||||
|
|
||||||
|
Penalties:
|
||||||
|
- logged in history
|
||||||
|
- visible on driver/team pages
|
||||||
|
- part of season record
|
||||||
|
|
||||||
|
## 4.4 Consistency & Transparency
|
||||||
|
|
||||||
|
GridPilot helps:
|
||||||
|
- keep decisions structured
|
||||||
|
- avoid DM drama
|
||||||
|
- maintain fairness
|
||||||
|
- preserve season integrity
|
||||||
|
|
||||||
|
Admins stay in full control — GridPilot handles presentation & recalculation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 5. What We Must Consider (Key Constraints)
|
||||||
|
|
||||||
|
## 5.1 Content Ownership
|
||||||
|
|
||||||
|
Automated leagues need:
|
||||||
|
- admins (or bot accounts) who own the tracks
|
||||||
|
- 1 owned car per allowed class
|
||||||
|
- iRacing credits to host sessions
|
||||||
|
|
||||||
|
GridPilot cannot bypass iRacing content rules.
|
||||||
|
|
||||||
|
## 5.2 Avoiding Splits (Very Important)
|
||||||
|
|
||||||
|
Splits destroy community identity.
|
||||||
|
GridPilot must:
|
||||||
|
- keep leagues small (20–30 drivers)
|
||||||
|
- allow multiple parallel micro-series (F1-A, F1-B, etc.)
|
||||||
|
- unify standings across micro-series through stats (optional)
|
||||||
|
|
||||||
|
We scale *horizontally*, not vertically.
|
||||||
|
|
||||||
|
## 5.3 Admin Optionality
|
||||||
|
|
||||||
|
Automation is optional.
|
||||||
|
Manual control must always be possible.
|
||||||
|
|
||||||
|
## 5.4 Don’t Replace Community
|
||||||
|
|
||||||
|
GridPilot provides structure — not social control.
|
||||||
|
Discord remains important; we complement it.
|
||||||
|
|
||||||
|
## 5.5 Avoid excessive complexity
|
||||||
|
|
||||||
|
Penalty rules, team formats, automated templates —
|
||||||
|
all must stay simple, configurable, and not overwhelming.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 6. GridPilot Race Management Summary
|
||||||
|
|
||||||
|
GridPilot provides:
|
||||||
|
- professional team racing
|
||||||
|
- structured constructors scoring
|
||||||
|
- predefined (or custom) league formats
|
||||||
|
- optional auto-generated F1-style calendars
|
||||||
|
- clean protests and quick penalties
|
||||||
|
- automatic standings
|
||||||
|
- minimal admin workload
|
||||||
|
- consistent racing identity
|
||||||
|
- scalable competition model
|
||||||
|
|
||||||
|
We don’t replace iRacing —
|
||||||
|
we give league racing the **structure, fairness, and identity** it has always lacked.
|
||||||
224
docs/concept/RATING.md
Normal file
224
docs/concept/RATING.md
Normal file
@@ -0,0 +1,224 @@
|
|||||||
|
# GridPilot Rating
|
||||||
|
*Our own competition rating system designed for league racing — because iRating was never made for this.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 1. Why GridPilot Needs Its Own Rating
|
||||||
|
|
||||||
|
iRating works great for official races, but it's not built for leagues.
|
||||||
|
|
||||||
|
**League racing is fundamentally different:**
|
||||||
|
- you race against the same people each week
|
||||||
|
- racecraft matters more than raw pace
|
||||||
|
- team dynamics influence outcomes
|
||||||
|
- attendance and consistency matter
|
||||||
|
- incidents have real consequences
|
||||||
|
- formats vary massively between leagues
|
||||||
|
- results depend heavily on season structure
|
||||||
|
- small grids distort iRating logic
|
||||||
|
|
||||||
|
iRating can’t measure:
|
||||||
|
- season performance
|
||||||
|
- team contribution
|
||||||
|
- consistency
|
||||||
|
- clean driving
|
||||||
|
- decision-making
|
||||||
|
- rivalry strength
|
||||||
|
- long-term commitment
|
||||||
|
- reliability
|
||||||
|
|
||||||
|
So we build a rating *specifically for league racing* —
|
||||||
|
where context, progression, and human rivalry actually matter.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2. What GridPilot Rating Measures
|
||||||
|
|
||||||
|
GridPilot Rating = **league racing performance + racing behavior + reliability**.
|
||||||
|
|
||||||
|
It captures the full picture of a driver, not only their pace.
|
||||||
|
|
||||||
|
### **Core components**
|
||||||
|
- **Results Strength**
|
||||||
|
How well you finish relative to the field strength.
|
||||||
|
|
||||||
|
- **Consistency**
|
||||||
|
Stability of finishing positions over a season.
|
||||||
|
|
||||||
|
- **Clean Driving**
|
||||||
|
Incidents per race, weighted by severity.
|
||||||
|
|
||||||
|
- **Racecraft**
|
||||||
|
Positions gained/lost vs. incident involvement.
|
||||||
|
|
||||||
|
- **Reliability**
|
||||||
|
Attendance, DNS/DNF record.
|
||||||
|
|
||||||
|
- **Team Contribution**
|
||||||
|
Points earned for your team; lineup efficiency.
|
||||||
|
|
||||||
|
### **Why these matter**
|
||||||
|
A great league driver is not only fast.
|
||||||
|
A great league driver is:
|
||||||
|
- clean
|
||||||
|
- consistent
|
||||||
|
- reliable
|
||||||
|
- competitive
|
||||||
|
- predictable
|
||||||
|
- respected
|
||||||
|
- valuable to teams
|
||||||
|
|
||||||
|
Our rating reflects **real league value**, not just raw pace.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 3. Principles of GridPilot Rating
|
||||||
|
|
||||||
|
## **1. Competition over matchmaking**
|
||||||
|
iRating is designed for matchmaking.
|
||||||
|
GridPilot Rating is designed for **championships**.
|
||||||
|
|
||||||
|
## **2. Context matters**
|
||||||
|
Beating a strong field → worth more.
|
||||||
|
Clean races → rewarded.
|
||||||
|
Incidents → penalized.
|
||||||
|
Attendance → essential.
|
||||||
|
|
||||||
|
## **3. No punishing drivers for leagues with small grids**
|
||||||
|
In iRating, small splits cause unstable jumps.
|
||||||
|
GridPilot Rating normalizes for field size.
|
||||||
|
|
||||||
|
## **4. No obsession with “perfection”**
|
||||||
|
This is not a chess ELO.
|
||||||
|
This is racing.
|
||||||
|
Racing has chaos.
|
||||||
|
Rating should reflect that.
|
||||||
|
|
||||||
|
## **5. Transparent & understandable**
|
||||||
|
Drivers should always know:
|
||||||
|
> “Why did my rating change?”
|
||||||
|
|
||||||
|
Our UI makes this clear.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 4. Rating Inputs (Conceptual, not equations)
|
||||||
|
|
||||||
|
GridPilot Rating is built from weighted contributions:
|
||||||
|
|
||||||
|
### **1. Race Placement Score**
|
||||||
|
Normalized by:
|
||||||
|
- field size
|
||||||
|
- field strength
|
||||||
|
- track difficulty (optional future)
|
||||||
|
- gaps between positions
|
||||||
|
|
||||||
|
### **2. Incident Factor**
|
||||||
|
Scaled to:
|
||||||
|
- incident count
|
||||||
|
- impact on others
|
||||||
|
- severity
|
||||||
|
- penalty involvement
|
||||||
|
|
||||||
|
### **3. Reliability Score**
|
||||||
|
- attendance
|
||||||
|
- quitting early
|
||||||
|
- DNS
|
||||||
|
- DNF
|
||||||
|
|
||||||
|
### **4. Team Factor**
|
||||||
|
- points contributed relative to team total
|
||||||
|
- team finishing efficiency
|
||||||
|
- team strength
|
||||||
|
|
||||||
|
### **5. Season Factor**
|
||||||
|
Bonus for:
|
||||||
|
- championship position
|
||||||
|
- improvement
|
||||||
|
- performance under pressure
|
||||||
|
- completing the full season
|
||||||
|
|
||||||
|
Everything is transparent and cumulative.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 5. Why Teams Benefit from Rating
|
||||||
|
|
||||||
|
Teams need a way to scout drivers that isn’t:
|
||||||
|
- “Do you have 3k iRating?”
|
||||||
|
- “Are you fast in officials?”
|
||||||
|
- “Do you join our Discord?”
|
||||||
|
|
||||||
|
GridPilot Rating shows:
|
||||||
|
- reliability
|
||||||
|
- cleanliness
|
||||||
|
- consistency
|
||||||
|
- contribution
|
||||||
|
- teamwork
|
||||||
|
- multi-season performance
|
||||||
|
|
||||||
|
That’s what teams care about in real league competition.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 6. Why Admins Benefit
|
||||||
|
|
||||||
|
Admins get:
|
||||||
|
- balanced rosters
|
||||||
|
- fairer splits if needed
|
||||||
|
- data for assigning classes
|
||||||
|
- better recruitment
|
||||||
|
- fewer problems with unreliable drivers
|
||||||
|
- objective metrics behind decisions
|
||||||
|
|
||||||
|
Rating turns leagues into **professional, predictable competitions**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 7. Why Drivers Benefit
|
||||||
|
|
||||||
|
Drivers finally get:
|
||||||
|
- recognition for more than pace
|
||||||
|
- a way to show reliability
|
||||||
|
- stats that show improvement
|
||||||
|
- incentives to race clean
|
||||||
|
- a reason to finish the season
|
||||||
|
- meaningful identity across multiple leagues
|
||||||
|
|
||||||
|
GridPilot Rating makes league racing **feel like a true career**, not a collection of spreadsheets.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 8. How It Differs From iRating
|
||||||
|
|
||||||
|
| iRating | GridPilot Rating |
|
||||||
|
|--------|------------------|
|
||||||
|
| Matchmaking tool | Competition identity tool |
|
||||||
|
| Random opponents | Same rivals weekly |
|
||||||
|
| No context | Context-heavy |
|
||||||
|
| Pace only | Pace + behavior + consistency + reliability |
|
||||||
|
| Does not reward team play | Team contribution included |
|
||||||
|
| Penalizes small grids | Normalized for field size |
|
||||||
|
| No season meaning | Season progression core to system |
|
||||||
|
| Binary win/loss logic | Full racing context |
|
||||||
|
|
||||||
|
GridPilot Rating doesn’t replace iRating.
|
||||||
|
It fills the gap iRating never tried to solve.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 9. Why We're Building This
|
||||||
|
|
||||||
|
Because league racing deserves:
|
||||||
|
- fair recognition
|
||||||
|
- long-term meaning
|
||||||
|
- personal progression
|
||||||
|
- team value
|
||||||
|
- traits beyond speed
|
||||||
|
- a competitive environment that feels like real motorsport
|
||||||
|
|
||||||
|
No other platform gives league racers their own rating.
|
||||||
|
And no existing metric truly represents what makes someone great in a league.
|
||||||
|
|
||||||
|
GridPilot Rating changes that —
|
||||||
|
**by measuring the things that actually matter in league racing.**
|
||||||
204
docs/concept/SOCIAL.md
Normal file
204
docs/concept/SOCIAL.md
Normal file
@@ -0,0 +1,204 @@
|
|||||||
|
# GridPilot — Social Features
|
||||||
|
*The social layer that connects drivers, admins, teams, and leagues in one unified platform.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. The Purpose of GridPilot Social
|
||||||
|
|
||||||
|
Sim racers today are split across:
|
||||||
|
- Discord servers
|
||||||
|
- Reddit threads
|
||||||
|
- scattered DMs
|
||||||
|
- league-specific chats
|
||||||
|
- spreadsheets with usernames
|
||||||
|
|
||||||
|
There is **no central place** where drivers, admins, and teams discover each other or keep in touch.
|
||||||
|
|
||||||
|
GridPilot adds a lightweight, modern social layer designed specifically for the league racing world.
|
||||||
|
|
||||||
|
Not a full “social network,” not noisy, not chaotic —
|
||||||
|
just the tools needed to help people connect efficiently and meaningfully.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Unified User Identity
|
||||||
|
|
||||||
|
Every user has one identity across the entire platform:
|
||||||
|
|
||||||
|
- profile picture
|
||||||
|
- username
|
||||||
|
- country & time zone
|
||||||
|
- teams
|
||||||
|
- leagues they race in
|
||||||
|
- bio (optional)
|
||||||
|
- links (Twitch / YouTube / Discord / social media)
|
||||||
|
- availability preferences (days/times they race)
|
||||||
|
|
||||||
|
**Admins, drivers, team captains — all the same user type.**
|
||||||
|
|
||||||
|
There are no separate accounts or roles.
|
||||||
|
Roles are permissions, not different identities.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Messaging (Lightweight)
|
||||||
|
|
||||||
|
A minimal message system designed for utility, not noise.
|
||||||
|
|
||||||
|
### **Driver ↔ Driver**
|
||||||
|
- send quick messages (questions, coordination, friendly chatter)
|
||||||
|
|
||||||
|
### **Driver ↔ Admin**
|
||||||
|
- ask about sign-ups
|
||||||
|
- clarify rules
|
||||||
|
- discuss incidents (if needed)
|
||||||
|
- handle roster or team questions
|
||||||
|
|
||||||
|
### **Team Messaging**
|
||||||
|
- team chat for coordination
|
||||||
|
- optional channel for setup sharing or strategy
|
||||||
|
- not meant to replace Discord, but acts as a unified fallback
|
||||||
|
|
||||||
|
### **League Announcements**
|
||||||
|
- admins can broadcast updates
|
||||||
|
- drivers receive notifications (web/mobile)
|
||||||
|
|
||||||
|
This is *not* a Discord replacement — it fills the gaps Discord cannot cover.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Discoverability Between Users
|
||||||
|
|
||||||
|
GridPilot makes it easy for users to find the right people.
|
||||||
|
|
||||||
|
### **Find Drivers**
|
||||||
|
Admins or team captains can filter by:
|
||||||
|
- region
|
||||||
|
- time zone
|
||||||
|
- car classes driven
|
||||||
|
- experience level
|
||||||
|
- incident trends
|
||||||
|
- availability
|
||||||
|
- open-to-team-invite flag
|
||||||
|
|
||||||
|
### **Find Leagues**
|
||||||
|
Drivers can filter by:
|
||||||
|
- region
|
||||||
|
- event time
|
||||||
|
- car class
|
||||||
|
- competition level
|
||||||
|
- team / solo format
|
||||||
|
|
||||||
|
### **Find Teams**
|
||||||
|
Drivers can see:
|
||||||
|
- teams recruiting
|
||||||
|
- team bios
|
||||||
|
- roster
|
||||||
|
- history
|
||||||
|
- available seats
|
||||||
|
|
||||||
|
This enables a healthy “social marketplace” inside the platform — not chaos, but structure.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Social Timeline (v1: Very Light)
|
||||||
|
|
||||||
|
A simple, platform-wide activity feed such as:
|
||||||
|
|
||||||
|
- “User X joined League Y”
|
||||||
|
- “Team Z registered for the new season”
|
||||||
|
- “Driver A scored P1 in Race 3”
|
||||||
|
- “Season standings updated”
|
||||||
|
|
||||||
|
No memes, no fluff, no spam — just relevant racing activity.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Profiles for Leagues & Teams (Social Extension)
|
||||||
|
|
||||||
|
### **League Profiles**
|
||||||
|
- followers
|
||||||
|
- announcements
|
||||||
|
- pinned messages
|
||||||
|
- season previews
|
||||||
|
- open sign-ups
|
||||||
|
- links to streams
|
||||||
|
|
||||||
|
### **Team Profiles**
|
||||||
|
- roster
|
||||||
|
- captain
|
||||||
|
- recruiting status
|
||||||
|
- achievements
|
||||||
|
- highlights
|
||||||
|
- invites/private chat
|
||||||
|
|
||||||
|
This creates a natural social ecosystem around competition.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Notifications (Non-Intrusive)
|
||||||
|
|
||||||
|
Users get updates for:
|
||||||
|
- sign-up confirmations
|
||||||
|
- race day reminders
|
||||||
|
- new messages
|
||||||
|
- new followers
|
||||||
|
- schedule changes
|
||||||
|
- penalties published
|
||||||
|
- standings updates
|
||||||
|
|
||||||
|
Always optional.
|
||||||
|
Always configurable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Social Safety Features
|
||||||
|
|
||||||
|
GridPilot avoids drama-heavy social problems:
|
||||||
|
|
||||||
|
- block/mute user
|
||||||
|
- report message or behavior
|
||||||
|
- admin moderation tools inside a league
|
||||||
|
- no open global chat (avoids toxicity)
|
||||||
|
- no group spam
|
||||||
|
- no public “wall posts”
|
||||||
|
|
||||||
|
The platform focuses on **purposeful** communication only.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Why GridPilot’s Social Layer Is Unique
|
||||||
|
|
||||||
|
Current tools:
|
||||||
|
- Discord: chaotic, messy, isolated per league
|
||||||
|
- Reddit: fragmented
|
||||||
|
- Forums: outdated
|
||||||
|
- DMs: unstructured
|
||||||
|
- iRacing: no social features at all
|
||||||
|
|
||||||
|
GridPilot combines the best parts of community interaction:
|
||||||
|
- discoverability
|
||||||
|
- messaging
|
||||||
|
- profiles
|
||||||
|
- recruitment
|
||||||
|
- structured announcements
|
||||||
|
- identity across leagues
|
||||||
|
|
||||||
|
…without becoming a noisy distraction.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Summary
|
||||||
|
|
||||||
|
GridPilot’s social features give sim racers what they’re missing:
|
||||||
|
|
||||||
|
- a unified identity
|
||||||
|
- simple ways to connect
|
||||||
|
- ways for leagues to find drivers
|
||||||
|
- ways for drivers to find leagues
|
||||||
|
- team coordination tools
|
||||||
|
- non-chaotic messaging
|
||||||
|
- structured community activity
|
||||||
|
|
||||||
|
It’s the **social layer that sim racing has always lacked** —
|
||||||
|
lightweight, purposeful, and deeply integrated into competition.
|
||||||
270
docs/concept/STATS.md
Normal file
270
docs/concept/STATS.md
Normal file
@@ -0,0 +1,270 @@
|
|||||||
|
# GridPilot — In-Depth Stats & Scoring
|
||||||
|
*A modern statistics and scoring engine that gives meaning, context, and clarity to every race, every season, and every driver.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 1. Purpose of GridPilot Stats
|
||||||
|
iRacing’s official results are powerful, but extremely limited:
|
||||||
|
- no career progression
|
||||||
|
- no cross-season view
|
||||||
|
- no team context
|
||||||
|
- no advanced analytics
|
||||||
|
- no identity
|
||||||
|
|
||||||
|
GridPilot turns league racing into a structured competitive ecosystem by adding **deep, consistent, cross-league analytics** that drivers, teams, and admins can all rely on.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2. Core Data We Track
|
||||||
|
|
||||||
|
GridPilot automatically imports race metadata from iRacing and expands it into a full statistical model.
|
||||||
|
|
||||||
|
### **Per Race**
|
||||||
|
- finishing position
|
||||||
|
- starting position
|
||||||
|
- positions gained/lost
|
||||||
|
- incidents
|
||||||
|
- best lap
|
||||||
|
- average lap pace (optional if telemetry available)
|
||||||
|
- laps completed
|
||||||
|
- penalties applied
|
||||||
|
- classification after penalties
|
||||||
|
|
||||||
|
### **Per Driver (Season)**
|
||||||
|
- points
|
||||||
|
- average finish
|
||||||
|
- consistency rating
|
||||||
|
- race attendance
|
||||||
|
- clean race percentage
|
||||||
|
- total incidents
|
||||||
|
- incidents per lap
|
||||||
|
- podiums
|
||||||
|
- wins
|
||||||
|
- DNF count
|
||||||
|
- performance trend
|
||||||
|
|
||||||
|
### **Per Team (Season)**
|
||||||
|
- total team points
|
||||||
|
- points contribution per driver
|
||||||
|
- average team finish
|
||||||
|
- number of drivers scoring
|
||||||
|
- team attendance
|
||||||
|
- team success over time
|
||||||
|
|
||||||
|
### **All-Time Stats**
|
||||||
|
- total races
|
||||||
|
- total wins
|
||||||
|
- total podiums
|
||||||
|
- historical point totals
|
||||||
|
- incident history
|
||||||
|
- class-specific stats (e.g., GT4, F4, F3)
|
||||||
|
- multi-league performance overview
|
||||||
|
|
||||||
|
These stats give GridPilot the ability to create meaningful identity and competitive depth.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 3. Scoring Engine (Flexible + Transparent)
|
||||||
|
|
||||||
|
Each league defines its scoring rules, but GridPilot standardizes them into clear, consistent structures.
|
||||||
|
|
||||||
|
### **Supported Scoring Models**
|
||||||
|
- Formula-style points (F1, F2, F3, F4, GP2, etc.)
|
||||||
|
- Endurance-style points
|
||||||
|
- Fixed points per position
|
||||||
|
- Bonus points:
|
||||||
|
- fastest lap
|
||||||
|
- pole position
|
||||||
|
- clean race
|
||||||
|
- most positions gained
|
||||||
|
|
||||||
|
### **Drop Weeks**
|
||||||
|
- configurable number of drops
|
||||||
|
- visual indicator for dropped results
|
||||||
|
- fully automated recalculation
|
||||||
|
|
||||||
|
### **Team Scoring**
|
||||||
|
A true Constructors-style model:
|
||||||
|
- multiple drivers score per race
|
||||||
|
- flexible configuration (best 2 scores, all scores, custom rules)
|
||||||
|
- team standings calculated instantly
|
||||||
|
- team stats update automatically
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 4. Driver Performance Metrics (Advanced)
|
||||||
|
|
||||||
|
GridPilot doesn’t just store results — it analyzes them.
|
||||||
|
|
||||||
|
### **Key Driver Metrics**
|
||||||
|
- **Consistency Score**
|
||||||
|
Statistical deviation of finishing positions over time.
|
||||||
|
Lower = more consistent.
|
||||||
|
|
||||||
|
- **Pace Index** (optional if telemetry available)
|
||||||
|
Comparison of average lap times vs. field median.
|
||||||
|
|
||||||
|
- **Clean Driving Score**
|
||||||
|
Incidents per race + severity weighting.
|
||||||
|
|
||||||
|
- **Racecraft Score**
|
||||||
|
Positions gained/lost vs. incident involvement.
|
||||||
|
|
||||||
|
- **Progression Score**
|
||||||
|
Improvement across a season, shown as a trendline.
|
||||||
|
|
||||||
|
- **Clutch Factor**
|
||||||
|
Performance in high-pressure scenarios (late-season races, close battles).
|
||||||
|
|
||||||
|
### **Visibility**
|
||||||
|
All metrics appear on:
|
||||||
|
- driver profile
|
||||||
|
- season detail page
|
||||||
|
- league overview
|
||||||
|
- team contribution breakdown
|
||||||
|
|
||||||
|
Drivers finally see **how** they drive — not just where they finish.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 5. Team Metrics (Depth That Makes Teams Matter)
|
||||||
|
|
||||||
|
Teams get **quantitative identity**.
|
||||||
|
|
||||||
|
### **Team Performance Metrics**
|
||||||
|
- team points
|
||||||
|
- team pace
|
||||||
|
- average finishing position
|
||||||
|
- contribution per driver
|
||||||
|
- lineup efficiency (who delivers consistent points)
|
||||||
|
- recruitment performance (improvement after roster changes)
|
||||||
|
- team form (last 5 races)
|
||||||
|
|
||||||
|
### **Team Contribution Breakdown**
|
||||||
|
Each driver has:
|
||||||
|
- points contributed
|
||||||
|
- percentage of team output
|
||||||
|
- consistency
|
||||||
|
- clean driving impact
|
||||||
|
- reliability (attendance)
|
||||||
|
|
||||||
|
This creates real internal and external rivalries.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 6. Season Intelligence
|
||||||
|
|
||||||
|
GridPilot gives leagues a complete analytical picture:
|
||||||
|
|
||||||
|
### **Season Insights**
|
||||||
|
- top improvers
|
||||||
|
- most consistent drivers
|
||||||
|
- hard chargers
|
||||||
|
- clean drivers
|
||||||
|
- most valuable drivers (team scoring)
|
||||||
|
- pace distribution
|
||||||
|
- incident hotspots
|
||||||
|
- attendance map
|
||||||
|
|
||||||
|
### **League Health Metrics**
|
||||||
|
- retention
|
||||||
|
- average field size
|
||||||
|
- finishing rate
|
||||||
|
- incident averages
|
||||||
|
- multi-class balancing
|
||||||
|
|
||||||
|
Admins get clarity without spreadsheets.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 7. Classification Adjustments (Penalties Included)
|
||||||
|
|
||||||
|
Results are never final until all penalties are processed.
|
||||||
|
|
||||||
|
GridPilot automatically handles:
|
||||||
|
|
||||||
|
- time penalties (+5s / +10s / +30s / custom)
|
||||||
|
- points deductions
|
||||||
|
- disqualifications (race-level)
|
||||||
|
- attendance penalties (if used)
|
||||||
|
- warning tracking
|
||||||
|
|
||||||
|
After admin decisions:
|
||||||
|
- standings recalculate
|
||||||
|
- driver stats update
|
||||||
|
- team stats update
|
||||||
|
- classification changes are logged
|
||||||
|
- penalty history is visible
|
||||||
|
|
||||||
|
No manual recalculation.
|
||||||
|
No mistakes.
|
||||||
|
No drama.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 8. Global Scoring Vision (Future-Friendly)
|
||||||
|
|
||||||
|
GridPilot tracks:
|
||||||
|
- per-league points
|
||||||
|
- per-season points
|
||||||
|
- all-time points
|
||||||
|
- team points
|
||||||
|
- class-based points
|
||||||
|
|
||||||
|
This allows future scaling into:
|
||||||
|
- global leaderboards
|
||||||
|
- cross-league rankings
|
||||||
|
- multi-class ladders
|
||||||
|
- team world rankings
|
||||||
|
|
||||||
|
We don’t implement everything on day one —
|
||||||
|
but the **data model is built for it**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 9. Why GridPilot Stats Matter
|
||||||
|
|
||||||
|
For Drivers:
|
||||||
|
- proof of skill
|
||||||
|
- motivation
|
||||||
|
- long-term identity
|
||||||
|
- visible improvement
|
||||||
|
- fairness & transparency
|
||||||
|
|
||||||
|
For Teams:
|
||||||
|
- real constructors competition
|
||||||
|
- driver scouting
|
||||||
|
- lineup planning
|
||||||
|
- prestige and pride
|
||||||
|
|
||||||
|
For Admins:
|
||||||
|
- no spreadsheets
|
||||||
|
- no miscalculations
|
||||||
|
- clarity for the community
|
||||||
|
- instant transparency
|
||||||
|
- professionalism
|
||||||
|
|
||||||
|
For Leagues:
|
||||||
|
- structure
|
||||||
|
- identity
|
||||||
|
- competitiveness
|
||||||
|
- return of drivers season after season
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Summary
|
||||||
|
|
||||||
|
GridPilot’s scoring and analytics system turns scattered league racing into a **structured competitive ecosystem**:
|
||||||
|
|
||||||
|
- complete results
|
||||||
|
- meaningful metrics
|
||||||
|
- constructors-style team scoring
|
||||||
|
- clean & consistent standings
|
||||||
|
- penalty-aware classification
|
||||||
|
- multi-season depth
|
||||||
|
- driver identity
|
||||||
|
- team identity
|
||||||
|
- league clarity
|
||||||
|
|
||||||
|
This is the **foundation** that makes GridPilot more than a tool —
|
||||||
|
it becomes the home of competition in iRacing league racing.
|
||||||
211
docs/concept/TEAMS.md
Normal file
211
docs/concept/TEAMS.md
Normal file
@@ -0,0 +1,211 @@
|
|||||||
|
# GridPilot for Teams
|
||||||
|
*Teams are the backbone of real motorsport. GridPilot finally gives them the tools they’ve always needed in iRacing league racing.*
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Why Teams Matter
|
||||||
|
|
||||||
|
Teams add:
|
||||||
|
- identity
|
||||||
|
- rivalry
|
||||||
|
- long-term story
|
||||||
|
- shared goals
|
||||||
|
- consistency
|
||||||
|
- progression
|
||||||
|
- fun beyond solo racing
|
||||||
|
|
||||||
|
But in iRacing leagues today, teams are treated as:
|
||||||
|
- “a tag on a spreadsheet”
|
||||||
|
- “a logo in a Discord channel”
|
||||||
|
|
||||||
|
GridPilot fixes that by making teams **first-class citizens** of the platform.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Team Profiles
|
||||||
|
|
||||||
|
Every team gets its own home on GridPilot:
|
||||||
|
|
||||||
|
### **Team Profile Includes**
|
||||||
|
- team name
|
||||||
|
- logo & colors
|
||||||
|
- description/bio
|
||||||
|
- captain / co-captains
|
||||||
|
- full roster
|
||||||
|
- active seasons
|
||||||
|
- past seasons
|
||||||
|
- team standings
|
||||||
|
- points history
|
||||||
|
- achievements
|
||||||
|
|
||||||
|
### Why it matters
|
||||||
|
Drivers finally have somewhere to “belong,”
|
||||||
|
and teams become part of the league’s story — not a footnote.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Team Creation & Management
|
||||||
|
|
||||||
|
Teams can be created by any user:
|
||||||
|
|
||||||
|
### Team captains can:
|
||||||
|
- invite drivers
|
||||||
|
- approve join requests
|
||||||
|
- remove drivers
|
||||||
|
- assign roles (captain, strategist, reserve driver)
|
||||||
|
- manage the team profile
|
||||||
|
- mark the team as “recruiting”
|
||||||
|
|
||||||
|
### Drivers can:
|
||||||
|
- request to join
|
||||||
|
- switch teams between seasons
|
||||||
|
- follow recruiting teams
|
||||||
|
- represent their team in multiple leagues
|
||||||
|
|
||||||
|
Everything is clean, modern, and transparent.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Team Registration for Seasons
|
||||||
|
|
||||||
|
When a league supports team racing, teams can register directly:
|
||||||
|
|
||||||
|
### Team season registration:
|
||||||
|
1. captain chooses league
|
||||||
|
2. reviews schedule & format
|
||||||
|
3. submits team
|
||||||
|
4. roster automatically populated
|
||||||
|
5. drivers assigned to specific car slots if needed
|
||||||
|
6. team appears in league standings
|
||||||
|
|
||||||
|
No forms.
|
||||||
|
No DMs.
|
||||||
|
No spreadsheets.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Constructors-Style Team Competition
|
||||||
|
|
||||||
|
This is where GridPilot goes beyond what any league tool offers.
|
||||||
|
|
||||||
|
### **How it works**
|
||||||
|
- multiple drivers from a team race in parallel
|
||||||
|
- each race week can have different participating drivers
|
||||||
|
- **all scored points contribute to the team championship**
|
||||||
|
- standings update automatically from iRacing results
|
||||||
|
|
||||||
|
### **Why it’s superior**
|
||||||
|
- teams aren’t just “one driver per car slot”
|
||||||
|
- stronger teams can field more competitive drivers
|
||||||
|
- every driver matters
|
||||||
|
- team strategy becomes part of the championship
|
||||||
|
- it feels like real motorsport (F1: Constructors, WEC, GT teams)
|
||||||
|
|
||||||
|
This is a massive upgrade over the usual “driver only” league structure.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Team Standings & History
|
||||||
|
|
||||||
|
Each team gets:
|
||||||
|
- season standings
|
||||||
|
- total points
|
||||||
|
- podiums
|
||||||
|
- wins
|
||||||
|
- member contributions
|
||||||
|
- historical performance graphs
|
||||||
|
- list of every season ever raced
|
||||||
|
|
||||||
|
Over time, this becomes:
|
||||||
|
- reputation
|
||||||
|
- prestige
|
||||||
|
- an asset teams are proud of
|
||||||
|
|
||||||
|
Teams become part of the GridPilot universe, not just this week’s race.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Driver Contribution Breakdown
|
||||||
|
|
||||||
|
Teams can see:
|
||||||
|
- which driver scored points
|
||||||
|
- how many
|
||||||
|
- consistency over time
|
||||||
|
- incidents
|
||||||
|
- average finishing position
|
||||||
|
- contribution %, similar to "driver share"
|
||||||
|
|
||||||
|
This builds:
|
||||||
|
- internal competition
|
||||||
|
- motivation
|
||||||
|
- clarity
|
||||||
|
- lineup optimization
|
||||||
|
|
||||||
|
It also helps captains choose who drives what event.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Discoverability: Find & Recruit Drivers
|
||||||
|
|
||||||
|
Teams can mark themselves as:
|
||||||
|
- **Actively Recruiting**
|
||||||
|
- **Closed**
|
||||||
|
- **Looking for reserve drivers**
|
||||||
|
|
||||||
|
Drivers can:
|
||||||
|
- browse teams
|
||||||
|
- search by region / league / car class
|
||||||
|
- request to join
|
||||||
|
- follow teams they like
|
||||||
|
|
||||||
|
This solves the huge problem of:
|
||||||
|
> “Where do we find new drivers for our team?”
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Communication Tools (Lightweight)
|
||||||
|
|
||||||
|
Teams get:
|
||||||
|
- team announcements
|
||||||
|
- team chat
|
||||||
|
- direct messages
|
||||||
|
- lineup discussions
|
||||||
|
- strategy notes
|
||||||
|
|
||||||
|
Not a full Discord replacement —
|
||||||
|
but enough to organize race days without noise.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Why Teams Should Use GridPilot
|
||||||
|
|
||||||
|
Teams get what iRacing never gave them:
|
||||||
|
|
||||||
|
### ✔ Real constructors-style competition
|
||||||
|
### ✔ A permanent home
|
||||||
|
### ✔ A public identity
|
||||||
|
### ✔ A place to recruit
|
||||||
|
### ✔ A performance history
|
||||||
|
### ✔ a reason to stay long-term
|
||||||
|
### ✔ pride and prestige
|
||||||
|
### ✔ fewer spreadsheets
|
||||||
|
### ✔ clearer communication
|
||||||
|
|
||||||
|
Teams turn league racing into something that **feels like real motorsport**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Summary
|
||||||
|
|
||||||
|
GridPilot for Teams delivers:
|
||||||
|
- professional team identity
|
||||||
|
- constructors-style points
|
||||||
|
- automatic team standings
|
||||||
|
- clear contributor stats
|
||||||
|
- season + all-time history
|
||||||
|
- recruitment tools
|
||||||
|
- team chats & coordination
|
||||||
|
- smooth season registration
|
||||||
|
|
||||||
|
Teams finally become **true participants** in iRacing league racing —
|
||||||
|
not just a tag next to a driver name.
|
||||||
Reference in New Issue
Block a user