5f8819bb46
Provide non-obvious business rules and constraints for economy, inventory, quest, moderation, trade, and trivia modules to reduce context-gathering overhead for AI tools. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
11 lines
1.5 KiB
Markdown
11 lines
1.5 KiB
Markdown
# Moderation Module
|
|
|
|
- Case IDs are sequential strings formatted as `CASE-XXXX` (zero-padded to 4 digits). Generated by querying the latest case and incrementing. Not a DB sequence -- concurrent inserts could theoretically collide, but in practice moderation actions are low-frequency.
|
|
- Only `WARN` type cases are created with `active: true`. All other case types (TIMEOUT, BAN, KICK, NOTE) default to `active: false`. The `active` flag is specifically for tracking unresolved warnings.
|
|
- `issueWarning` has two side effects beyond creating the case:
|
|
- **DM notification**: sends the user a warning embed via DM. Fails silently if the user has DMs disabled. Controlled by `config.dmOnWarn` (defaults to true if unset).
|
|
- **Auto-timeout**: if active warning count >= `autoTimeoutThreshold`, the user is automatically timed out for 24 hours and a separate `TIMEOUT` case is created with `moderatorId: "0"` (system). The timeout target (Discord GuildMember) is passed in from the command layer.
|
|
- `clearCase` sets `active: false` and records who cleared it and why. It works on any case type, not just warnings.
|
|
- The service does **not** perform Discord actions (kick, ban, timeout) directly -- it only manages database records. The bot command layer is responsible for calling Discord APIs and then recording cases here. The one exception is auto-timeout in `issueWarning`, where the Discord member object is passed in.
|
|
- `searchCases` supports pagination via `limit`/`offset` (default limit 50).
|