aafe527d51
All checks were successful
Reindex Knowledge Base / reindex (push) Successful in 5s
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
87 lines
6.3 KiB
Markdown
87 lines
6.3 KiB
Markdown
# 14. Risk Register and Open Questions
|
|
|
|
[< Back to Index](README.md)
|
|
|
|
---
|
|
|
|
## Risk Register
|
|
|
|
| Risk | Likelihood | Impact | Mitigation |
|
|
|---|---|---|---|
|
|
| Milestone queries become slow at scale | Low | Medium | Queries go through `player_season_stats` materialized view keyed on `(team_id, player_id)`, not raw stratplay scans. Ensure appropriate indexes on the materialized view. |
|
|
| Milestone thresholds too easy, Full Evolution trivial | Medium | Medium | Admin-tunable thresholds; monitor completion rate and adjust; launch conservatively |
|
|
| Milestone thresholds too hard, players don't notice evolution is happening | Medium | Medium | Lower thresholds; T1 should complete for any card played in ~2 weeks of casual play |
|
|
| Retroactive backfill gives some cards immediate T4 on launch | Low | Medium | Evaluate whether progress_since should be launch date rather than card.created_at; see Open Question 2 |
|
|
| Cosmetic pricing too low, not a meaningful sink | Low | Low | Monitor purchase rates; adjust cosmetic catalog pricing post-launch |
|
|
| Cosmetic pricing too high, nobody buys them | Medium | Medium | Start at lower price points; increase for new cosmetics based on demand data |
|
|
| Rating boosts break 108-sum column invariant | Low | High | Unit test suite for `apply_evolution_boosts()`; validation on every boost application |
|
|
| Variant rows conflict with existing `UNIQUE(player_id, variant)` constraint | Low | High | Validate constraint behavior in dev before migration; existing data has variant=0 only |
|
|
| API variant resolution adds latency to card embed | Low | Low | Single additional DB lookup; index on card_state by card_id |
|
|
| Trade cosmetic-stripping creates player frustration | Low | Low | Clear in-game warning before trade completes; cosmetics are team purchases, not card upgrades |
|
|
| Player collusion to farm milestones via exhibition | Low | Low | Future safeguard: mode restrictions via game_mode field; low priority since exhibition outcomes are real D20 games |
|
|
| APNG file sizes too large for mobile Discord clients | Medium | Medium | pngquant compression, frame count reduction, file size budget enforcement (see [08-display.md § 8.6.8](08-display.md#868-file-size-budget)) |
|
|
| Animated render pipeline too slow for batch operations | Low | Low | Animated variants are rare (premium purchases only); batch re-renders can run in background |
|
|
| APNG not supported on older Discord mobile clients | Low | Low | Graceful degradation: first frame renders as static PNG; bot can check URL extension to warn user |
|
|
|
|
---
|
|
|
|
## Open Questions
|
|
|
|
1. **Progress start date — all-time vs acquisition date vs launch date:** Currently specified as
|
|
`card.created_at`. Three options exist: (a) all-time for that player_id on that team (most
|
|
rewarding, may cause immediate tier completions on launch), (b) card acquisition date (natural,
|
|
but retroactive depth varies by card age), (c) system launch date (clean cold start, no
|
|
retroactive credit). Which is preferred for the launch experience?
|
|
|
|
2. **Immediate Full Evolution on backfill:** Some veteran players may have cards where enough
|
|
historical games exist to hit T4 immediately on launch day. Is this a good thing (reward
|
|
loyal players) or a bad thing (deflates the progression experience)? One mitigation: cap
|
|
retroactive credit at T2 on launch, let players play their way to T3-T4.
|
|
|
|
3. ~~**Boost allocation player choice (Phase 4):**~~ **RESOLVED — CUT.** Boost direction override
|
|
was removed entirely. Auto-detected profile determines distribution; no player customization.
|
|
Cosmetics are the sole currency sink.
|
|
|
|
4. **Maximum evolved card count visibility:** With all cards evolving simultaneously, the
|
|
`!evo status` embed could become overwhelming for large rosters. Should it default to showing
|
|
only cards close to a tier milestone (within 20% of threshold)? Or only T3+ cards?
|
|
|
|
5. **Season-specific evolution tracks:** Time-limited evolution tracks tied to current season
|
|
events are a strong engagement feature. Should these be a separate PRD, or designed into
|
|
the track schema from the start?
|
|
|
|
6. ~~**HoF cards on Legend track:**~~ **RESOLVED in v4.0.** Tracks are now universal (not
|
|
rarity-gated). HoF cards follow the same track as all other cards, receive the same flat rating
|
|
boosts, and get the full visual rework at T4. They do not receive a rarity upgrade (already
|
|
at ceiling). The flat delta naturally provides diminishing returns for elite cards.
|
|
|
|
7. **Quality start definition:** The D20 system does not natively track innings pitched per
|
|
appearance. "6+ innings, 3 or fewer ER" requires a proxy calculation based on the outcome
|
|
simulation. How is this currently exposed from the game engine, if at all? If not available,
|
|
this milestone type may need to be replaced with a simpler proxy (e.g., "pitcher records a win
|
|
with fewer than N walks allowed").
|
|
|
|
8. **Cosmetic catalog scope:** The cosmetics listed in [08-display.md](08-display.md) are
|
|
illustrative. Should cosmetics be designed in detail before Phase 3 begins, or is it
|
|
acceptable to ship with one or two cosmetics and expand the catalog over time?
|
|
|
|
9. **Cosmetic CSS implementation detail:** The card HTML template currently uses hardcoded inline
|
|
styles for backgrounds (`#ACE6FF`, `#EAA49C`) and gradients (`blue-gradient`, `red-gradient`).
|
|
Cosmetics need to override these. Options: (a) pass cosmetic flags as Jinja2 template variables
|
|
and use conditionals in the template, (b) inject a cosmetic CSS override block after `style.html`,
|
|
(c) build a cosmetic theme system with named CSS classes. Which approach best balances flexibility
|
|
with maintainability?
|
|
|
|
10. ~~**Variant hash collision handling:**~~ **RESOLVED.** The `UNIQUE(player_id, variant)`
|
|
constraint catches collisions at the DB level. No application-level check needed. With 32-bit
|
|
hashes (~4 billion values) and realistic catalog sizes, collision probability is negligible.
|
|
|
|
11. ~~**APNG render determinism:**~~ **RESOLVED in v4.0.** The render pipeline uses the
|
|
`--anim-progress` CSS custom property for deterministic per-frame control. CSS `@keyframes`
|
|
are not used for animated cosmetics. See [08-display.md § 8.6.4](08-display.md#864-deterministic-frame-control).
|
|
|
|
---
|
|
|
|
*End of PRD: Card Evolution System v4.1*
|
|
*Status: Full review with Cal complete (2026-03-11). Next step: Confirm Phase 1 scope, create Gitea milestone and issue breakdown.*
|