List view

• v3.0.0

  Goal: simplify internal architecture so the bot stays easy to change, scales cleanly within its current product shape, and remains maintainable over time. Keep this practical. - no framework rewrite - no enterprise patterns - no speculative abstractions - no UX churn unless architecture forces it Start with one umbrella issue and expand later once `v2.0.0` is underway. ## Focus areas - clearer boundaries between Discord UI, services, and persistence - one place for prediction submission rules - one place for scoring and recalculation rules - fewer fragile dict-shaped contracts across the codebase - less repeated admin-panel state handling This milestone is intentionally parked for later; it exists to preserve direction, not to pull work forward.

  Due by May 17, 2026

  •0/1 issues closed
  0% complete1 open0 closed

• v2.0.0

  Goal: one hosted bot instance can serve many Discord guilds, with one isolated league per guild. Keep this simple. - no plugin system - no generic tenancy layer - no shared cross-guild standings - no multiple leagues per guild - no broad config framework unless a concrete need appears Use the current v1.1.x bot as the baseline and change only what multi-guild safety actually requires. --- ## Scope track **Goal:** make the product boundary explicit before widening the data model. ### Start here - #176 -- narrow the target to one self-hosted bot instance serving many guilds, with one league per guild --- ## Data isolation track **Goal:** make guild ownership explicit and stop global queries from mixing league state. ### Recommended order - #195 -- add guild ownership to fixtures and migrate existing data - #196 -- scope fixture queries and week allocation by guild - #197 -- scope standings and late-review queries by guild These three issues are the core of v2.0.0. --- ## Runtime/config track **Goal:** remove the remaining process-wide assumptions that break down once one bot serves many guilds. ### Recommended order - #198 -- add minimal guild config for admin roles and channels - #199 -- make bot workflows and background tasks guild-aware Keep this narrow. The config slice for this milestone is only what multi-guild support needs. --- ## Verification track **Goal:** prove that one guild cannot see or affect another guild's league state. ### Final issue - #200 -- add multi-guild isolation coverage --- ## Cross-issue notes - Use `fixtures.guild_id` as the root scope. Do not add `guild_id` to child tables unless a real query forces it. - Existing single-guild data should migrate forward into one guild cleanly. - Keep the current admin panel and `/predict` UX unless guild isolation forces a change. - Week numbers should become per-guild, not global. - Process-local cooldowns must become `(guild_id, user_id)` scoped. - Global env/config assumptions like one `REMINDER_CHANNEL_ID` should move behind minimal guild config. - Backup and restore stay whole-database in `v2.0.0`; per-guild export/import is out of scope. ## Related issues outside this milestone - #52 is broader than this milestone. v2.0.0 only takes the narrow admin-role/channel slice needed for multi-guild support. - #114 may become simpler after minimal guild config exists, but it is not a blocker for the first multi-guild cut. - #50 and #51 stay out. Configurable scoring and season management are separate problems.

  Due by May 3, 2026

  •0/7 issues closed
  0% complete7 open0 closed