You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each hero should be tagged as **core** or **support** in the hero data. Goal suggestions (weekly/daily) should then use this to:
6
+
1. Only suggest CS/kill/networth goals for core heroes
7
+
2. Only suggest deny/partner networth goals for support heroes
8
+
3. Label goals as `core_only`, `support_only`, or `anyone` so the UI can communicate who each goal is for
9
+
10
+
---
11
+
12
+
## Part 1 — Hero Role Tagging
13
+
14
+
### Data Source
15
+
16
+
OpenDota's hero data includes `primary_attr` and typical role lists. The simplest approach is a static map in `heroes.js` (or `heroes.rs`) marking each hero as core or support based on their most common position.
17
+
18
+
Rough split:
19
+
-**Core** (pos 1/2/3): carries, mids, offlaners — heroes primarily played for farm/damage
20
+
-**Support** (pos 4/5): heroes primarily played for utility, healing, disable
21
+
22
+
A hero can be tagged as **flex** if they're commonly played in both roles (e.g. Invoker, Rubick, Lone Druid).
23
+
24
+
### Frontend (`src/lib/heroes.js`)
25
+
26
+
Add a `heroRoles` map:
27
+
```js
28
+
exportconstheroRoles= {
29
+
1:"core", // Anti-Mage
30
+
2:"core", // Axe
31
+
5:"support", // Crystal Maiden
32
+
// ...
33
+
};
34
+
35
+
exportfunctiongetHeroRole(heroId) {
36
+
return heroRoles[heroId] ??"flex";
37
+
}
38
+
```
39
+
40
+
### Backend (`src-tauri/src/database.rs` or a new `heroes.rs`)
41
+
42
+
Add a Rust equivalent for use in suggestion generation:
43
+
```rust
44
+
fn get_hero_role(hero_id: i32) ->&'static str {
45
+
match hero_id {
46
+
1 => "core",
47
+
5 => "support",
48
+
// ...
49
+
_ => "flex",
50
+
}
51
+
}
52
+
```
53
+
54
+
---
55
+
56
+
## Part 2 — Goal Suggestion Role Awareness
57
+
58
+
### Existing suggestion system
59
+
60
+
`generate_hero_suggestion()` currently only generates last-hits suggestions — it doesn't differentiate core vs support.
61
+
62
+
### Changes needed
63
+
64
+
1.**Skip CS suggestions for support heroes** — if`get_hero_role(hero_id) == "support"`, don't suggest a last-hits goal. Instead suggest a deny goal.
65
+
2. **Skip deny suggestions for core heroes** — if `get_hero_role(hero_id) == "core"`, don't suggest deny goals.
66
+
3.**PartnerNetworth suggestions** — only relevant for support heroes (pos 4/5).
67
+
68
+
---
69
+
70
+
## Part 3 — Goal `applicability` Tag
71
+
72
+
Add an `applicability` field to the `Goal`struct (and DB column) to communicate who the goal is intended for:
73
+
74
+
```
75
+
core_only — only evaluated for core heroes/matches
76
+
support_only — only evaluated for support heroes/matches
77
+
anyone — evaluated for all heroes (default)
78
+
```
79
+
80
+
This can be:
81
+
-**Auto-derived** from `hero_scope` at display time:
-`tauri.conf.json`: `"decorations": false` added to the window — hides the native Windows title bar
6
+
-`src/lib/TitleBar.svelte`: New component with drag region, title text, and Minimize / Maximize / Close buttons
7
+
-`src/routes/+layout.svelte`: TitleBar imported and placed above the main app layout
8
+
-`src/app.css`: `#svelte` changed from `display: contents` to `display: flex; flex-direction: column` so the title bar and page content stack vertically
9
+
-`.loading-screen`, `.login-screen`, `.app-layout` changed from `height: 100vh` to `flex: 1`
10
+
- Update banner adjusted to `top: 32px` so it doesn't overlap the title bar
11
+
12
+
## Steps to test
13
+
14
+
1. Build and launch the app
15
+
2.**Title bar visible**: A 32px bar appears at the very top with "DOTA KEEPER" label and three window control buttons on the right
16
+
3.**Dragging**: Click and drag on the title bar (anywhere except the buttons) — the window should move
17
+
4.**Minimize**: Click the `–` button — window minimises to taskbar
18
+
5.**Maximize/Restore**: Click the `□` button — window toggles between maximized and its normal size
19
+
6.**Double-click to maximize**: Double-click the title bar drag area — should toggle maximize
20
+
7.**Close**: Click the `✕` button — window closes (app exits)
21
+
8.**Close button hover**: Hovering the close button should turn it red (`#c42b1c`)
22
+
9.**Content not obscured**: Page content starts below the title bar — no overlap
23
+
10.**Login screen**: Log out and verify the login screen also sits below the title bar with no overlap
24
+
11.**Update banner (if available)**: If an update is available, the banner appears below the title bar, not behind it
- Added `wght@600;700` to the Barlow font Google Fonts URL (previously only 300/400/500 were loaded, causing browser-synthesized bold which looks heavy)
6
+
- Added explicit `font-weight: 400` to `body` in `app.css`
7
+
8
+
## Steps to test
9
+
10
+
1. Launch the app
11
+
2. Navigate through all pages (Dashboard, Matches, Analysis, Goals, Challenges, Settings)
12
+
3. Verify that body text reads cleanly and is not excessively bold or dark
13
+
4. Check the Analysis page specifically — it had the most complaints about heavy text
14
+
5. Nav items, filter chips, and section labels should look crisp but not overpowering
15
+
16
+
## Note
17
+
18
+
This fix requires an internet connection at app startup to download the new font weights from Google Fonts. On first load after the update, the fonts will be cached for subsequent offline use.
`get_active_weekly_challenge` in `database.rs` now queries `status IN ('active', 'completed')` instead of `status = 'active'` only. This means a completed challenge is still returned, so the frontend shows the progress view instead of the option-selection view.
6
+
7
+
## Steps to test
8
+
9
+
### Scenario A — Challenge already completed
10
+
1. Accept a weekly challenge
11
+
2. Play enough games to complete it (the status becomes `'completed'`)
12
+
3. Navigate away from the Challenges page and back
13
+
4.**Expected:** The progress view is shown with "Completed!" status, not the "Choose a challenge" selection cards
14
+
15
+
### Scenario B — No challenge accepted yet
16
+
1. Ensure no challenge has been accepted this week (or use a fresh DB)
17
+
2. Navigate to Challenges
18
+
3.**Expected:** The three option cards are still shown normally
19
+
20
+
### Scenario C — Challenge active (in progress)
21
+
1. Accept a challenge
22
+
2. Before completing it, navigate away and back
23
+
3.**Expected:** The progress view is shown with current progress
24
+
25
+
### Scenario D — Confirm no duplicate acceptance possible
26
+
1. With a completed challenge visible in the progress view, verify there is no "Accept" button shown
27
+
2.**Expected:** The accept option should not be reachable
0 commit comments