Refresh repository documentation
Some checks failed
Deploy to Production / test (push) Failing after 33s

- Rewrite AGENTS and README files to match the current app layout
- Document API routes, trivia UI, and the active panel design language
This commit is contained in:
syntaxbullet
2026-04-09 21:10:10 +02:00
parent 8369d10bab
commit 6abbd4652a
17 changed files with 893 additions and 639 deletions

View File

@@ -1,10 +1,32 @@
# Quest Module
# Quest module
- Quests are **event-driven**. The `handleEvent` method is called by system event listeners (not by commands directly). It matches events by exact name or prefix (e.g., trigger `ITEM_COLLECT` matches event `ITEM_COLLECT:101`), enabling both generic and specific quest triggers.
- Max active quests is controlled by `gameSettingsService`, not hardcoded. Default is 3.
- `assignQuest` uses `onConflictDoNothing` -- re-assigning an already-assigned quest silently no-ops. This is intentional to avoid duplicate quest entries.
- Quest progress is a simple integer counter. The `weight` parameter in `handleEvent` allows a single event to advance progress by more than 1 (useful for bulk actions).
- Quest completion is **automatic**: when progress >= target during `handleEvent`, `completeQuest` is called within the same transaction. There is no manual "turn in" step.
- Rewards (xp and balance) are distributed via `economyService` and `levelingService` inside the completion transaction. The `QUEST.COMPLETED` event is emitted with `systemEvents.emit` (fire-and-forget, not async) for bot-layer notifications.
- `requirements` and `rewards` are stored as JSON columns. Always expect `{ target: number }` for requirements and `{ xp?: number, balance?: number }` for rewards.
- Completed quests are never deleted -- they stay in `userQuests` with a `completedAt` timestamp. `getAvailableQuests` excludes any quest the user has ever been assigned (completed or not).
## Model
- quests are event-driven
- user progress is stored in `user_quests`
- completion is automatic once progress reaches the quest target
## Main methods
- `assignQuest()`
- `updateProgress()`
- `handleEvent()`
- `completeQuest()`
- `getUserQuests()`
- `getAvailableQuests()`
- `createQuest()`
- `getAllQuests()`
- `deleteQuest()`
- `updateQuest()`
## Rules
- max active quests comes from `gameSettingsService`
- `assignQuest()` uses `onConflictDoNothing()`
- `handleEvent()` matches either exact trigger names or `trigger:` prefixes, for example `ITEM_COLLECTED:42`
- rewards can include balance and XP and are paid inside the completion transaction
## Notes
- completed assignments remain in `user_quests`
- `EVENTS.QUEST.COMPLETED` is emitted for the bot/UI layer after reward distribution