feat: build educational SoloQ player coach - #254
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 29c0848c56
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| npx prisma db push # create tables | ||
| cd ../.. | ||
| docker compose -f docker-compose.database.yml up -d | ||
| npx prisma migrate deploy --schema workers/data-sync/prisma/schema.prisma |
There was a problem hiding this comment.
Provide a complete baseline before using migrate deploy
On the newly created Docker database from the preceding command, this applies the entire migration history from scratch, but that history does not contain CREATE TABLE statements for several current models. For example, 20260525000001_sprint_roster_status_user_language/migration.sql immediately runs ALTER TABLE "User", while no earlier migration creates User, so the documented local setup aborts before Prisma generation or seeding. Retain the prior schema-push bootstrap or add a complete baseline migration before recommending this command.
Useful? React with 👍 / 👎.
| SELECT create_hypertable('"HeroKill"', 'syncedAt', chunk_time_interval => INTERVAL '7 days', if_not_exists => TRUE, migrate_data => TRUE); | ||
| SELECT create_hypertable('"ObjectiveKill"', 'syncedAt', chunk_time_interval => INTERVAL '7 days', if_not_exists => TRUE, migrate_data => TRUE); | ||
| SELECT create_hypertable('"StructureDestruction"', 'syncedAt', chunk_time_interval => INTERVAL '7 days', if_not_exists => TRUE, migrate_data => TRUE); | ||
| SELECT create_hypertable('"WardEvent"', 'syncedAt', chunk_time_interval => INTERVAL '7 days', if_not_exists => TRUE, migrate_data => TRUE); | ||
| SELECT create_hypertable('"Transaction"', 'syncedAt', chunk_time_interval => INTERVAL '7 days', if_not_exists => TRUE, migrate_data => TRUE); |
There was a problem hiding this comment.
Convert existing primary keys before creating hypertables
When upgrading a database created using the previously documented prisma db push flow, these event tables already exist with an id-only primary key, as defined by the pre-change Prisma schema. The preceding CREATE TABLE IF NOT EXISTS statements therefore do not install the new composite keys, and TimescaleDB rejects create_hypertable(..., 'syncedAt') because the existing unique primary-key index omits the partitioning column. This blocks the migration on existing installations; explicitly replace the keys or rebuild the tables before conversion.
Useful? React with 👍 / 👎.
| const completed = rows.current.length >= TARGET_MATCHES; | ||
| const successful = outcome === 'target_achieved' || outcome === 'improved'; | ||
| const nextStatus = completed && goal.status === 'ACTIVE' | ||
| ? successful ? 'ACHIEVED' : 'FAILED' |
There was a problem hiding this comment.
Require the configured target before marking a goal achieved
For a goal with a numeric target, outcomeFor can return improved merely because the first five matches are 5% better than the baseline even when the target is still missed. Treating that outcome as successful persists ACHIEVED—for example, a KDA target of 5 becomes achieved at 2.2 after improving from 2.0—and the goal then stops being active. Only target_achieved should complete goals that have targetValue; baseline improvement can be used for targetless goals.
Useful? React with 👍 / 👎.
| <div style={{ marginTop: '0.8rem', padding: '0.8rem', borderRadius: 8, background: 'rgba(34,211,238,0.04)', border: '1px solid rgba(34,211,238,0.16)' }}> | ||
| <div style={{ display: 'flex', justifyContent: 'space-between', gap: '0.6rem', flexWrap: 'wrap' }}> | ||
| <strong style={{ fontSize: '0.78rem' }}>Comparación con jugadores de Pred.gg</strong> | ||
| {benchmark.benchmark.rating?.percentile != null && <span style={{ color: 'var(--accent-cyan)', fontSize: '0.67rem', fontWeight: 700 }}>Top {(benchmark.benchmark.rating.percentile * 100).toFixed(1)}% en Pred.gg</span>} |
There was a problem hiding this comment.
Display the complement of the rating percentile
Pred.gg's percentile represents the fraction of players below the player, so rendering it directly as a “Top” percentage reverses the ranking. The existing scouting page correctly uses 100 - percentile * 100; with the new expression, a player at percentile 0.90 is labeled top 90% instead of top 10%, materially misleading the benchmark shown to the player.
Useful? React with 👍 / 👎.
Closes #253
Qué incorpora
Salvaguardas del acompañante
Validación
Datos y límites
Producción no se ha modificado.