lark-ui/src/routes/app/settings/+page.svelte (3)

18-20: Minor: Missing semicolon on line 19.

For consistency with the rest of the file, add a semicolon after $state(false) on line 19.

-    let goalUpdating = $state(false)

+    let goalUpdating = $state(false);

---

32-35: Consider validating the parsed goal value.

If localStorage contains a corrupted or out-of-range value, parseInt could return NaN or a value outside the slider bounds (50-150). Consider adding validation:

             const savedGoal = localStorage.getItem('hourGoal');
             if (savedGoal) {

-                hourGoal = parseInt(savedGoal, 10);

+                const parsed = parseInt(savedGoal, 10);

+                if (!isNaN(parsed) && parsed >= 50 && parsed <= 150) {p; parsed <= 150) {

+                    hourGoal = parsed;

+                }
             }}

---

63-71: The "Saving..." state will never be visible.

localStorage.setItem is synchronous, so goalUpdating is set to true and immediately back to false within the same event loop tick. The button will never show "Saving..." to the user.

If the loading state is intentional for UX consistency, consider keeping goalUpdating but removing its use in the button, or simply remove the goalUpdating state entirely since it serves no practical purpose here.

lark-ui/src/routes/app/roulette/+page.svelte (1)

46-46: Consider: hardcoded balance threshold.

The 0.1 threshold is hardcoded here and on line 118/123. The backend uses GAME_CONFIG.MIN_BALANCE_TO_PLAY which could differ. If the backend minimum changes, the frontend check would be out of sync, potentially allowing users to attempt plays that will fail server-side.

This is low-risk but worth noting for future maintainability.

owl-api/src/game/game.controller.ts (1)

17-20: Add rate limiting to prevent rapid gambling exploitation.

This endpoint allows wagering ALL unspent hours with no cooldown. A user could rapidly hit this endpoint to either exploit favorable outcomes or accidentally lose everything. Consider adding a stricter rate limit via @Throttle() decorator or implementing a cooldown period in the service.

Example rate limit decorator

+import { Throttle } from '@nestjs/throttler';

+
 @Post('buckshot-roulette')

+@Throttle({ default: { limit: 1, ttl: 60000 } }) // 1 request per minute
 async playBuckshotRoulette(@Req() req: Request) {{

owl-api/src/game/game.service.ts (2)

60-60: Consider using cryptographically secure randomness for gambling outcomes.

Math.random() is not cryptographically secure. While this is server-side code (reducing external exploitation risk), for a gambling feature, using crypto.randomInt() or similar would be more appropriate.

Example using Node.js crypto

import { randomInt } from 'crypto';


// Replace Math.random() < 0.4 with:th:

const won = randomInt(100)  40; // 40% win probability

---

114-130: Consider database-level aggregation for better performance.

Fetching all transactions and filtering in memory (lines 121-123) won't scale well for users with many games. Database aggregation would be more efficient.

Example using Prisma aggregate

const [stats] = await this.prisma.$queryRaw[{wins: bigint, losses: bigint, net: number}]>gt;`

  SELECT 

    COUNT(*) FILTER (WHERE cost < 0) as wins,ns,

    COUNT(*) FILTER (WHERE cost > 0) as losses,es,

    -SUM(cost) as net

  FROM transactions 

  WHERE user_id = ${userId} AND item_id = ${gameItem.itemId}

`;

owl-api/src/game/game.module.ts (1)

8-13: Import ShopModule instead of providing ShopService directly.

ShopModule already provides ShopService, so providing it again here creates unnecessary duplication. Import ShopModule and remove ShopService from the providers array to reuse the existing service instance.

Regarding PrismaService: While providing it directly in each module is not ideal for singleton behavior, this pattern is used consistently throughout the codebase. Consider addressing this separately across all modules if singleton database connections are required.

Configuration used: defaults

Review profile: CHILL

Plan: Pro

lark-ui/src/lib/ProgressBar.svelte (1)

12-21: Consider using parseFloat and adding an upper bound check.

The current validation is solid (checking for NaN and positive values), but two potential improvements:

1. parseInt truncates decimals (e.g., "50.5" becomes 50), which is inconsistent with the decimal hour values used elsewhere in this component.
2. No upper bound—a maliciously large value in localStorage could cause UI issues.

♻️ Suggested improvement

     const savedGoal = localStorage.getItem('hourGoal');
     if (savedGoal) {

-        const parsed = parseInt(savedGoal, 10);

-        if (!Number.isNaN(parsed) && parsed > 0) {d > 0) {

+        const parsed = parseFloat(savedGoal);

+        if (!Number.isNaN(parsed) && parsed > 0 && parsed <= 1000) {; parsed <= 1000) {
             goalHours = parsed;
         }
     }  }

Configuration used: defaults

Review profile: CHILL

Plan: Pro