Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="app/src/main/java/app/gamenative/ui/screen/library/LibraryAppScreen.kt">

<violation number="1" location="app/src/main/java/app/gamenative/ui/screen/library/LibraryAppScreen.kt:334">
P2: Implicit ACTION_VIEW launch is unguarded and can crash with ActivityNotFoundException when no handler exists.</violation>
</file>

<file name="app/src/main/java/app/gamenative/utils/HltbService.kt">

<violation number="1" location="app/src/main/java/app/gamenative/utils/HltbService.kt:95">
P2: HttpURLConnection POST has no explicit connect/read timeout, so a hung network request can block indefinitely.</violation>

<violation number="2" location="app/src/main/java/app/gamenative/utils/HltbService.kt:139">
P2: `getStats()` performs cache load/JSON decode synchronously on the caller context, which is Main at the UI call site, risking UI jank.</violation>
</file>

<file name="app/src/main/java/app/gamenative/ui/screen/library/appscreen/BaseAppScreen.kt">

<violation number="1" location="app/src/main/java/app/gamenative/ui/screen/library/appscreen/BaseAppScreen.kt:907">
P2: Broad `Exception` catch in `LaunchedEffect` swallows coroutine cancellation instead of rethrowing `CancellationException`.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/app/gamenative/utils/HltbService.kt`:
- Around line 137-147: getStats blocks the main thread because
HltbCache.get(name) synchronously reads PrefManager.hltbCache via runBlocking
and is invoked from a LaunchedEffect (BaseAppScreen); fix it by moving the whole
function body off the main thread: wrap the contents of suspend fun
getStats(name: String): Stats? in withContext(Dispatchers.IO) so HltbCache.get,
any PrefManager.hltbCache access, auth/fetchAuth and search calls run on the IO
dispatcher and then return the result back to the caller.
- Around line 95-110: The HttpURLConnection in search() (variable conn) lacks
connect/read timeouts and isn't guaranteed to be disconnected, which can hang or
leak resources; fix by setting conn.connectTimeout and conn.readTimeout to
sensible values before writing/connecting, and wrap the request/response
handling in a try/finally so conn.disconnect() is always called in the finally
block (keep the existing outputStream.use for writing and preserve the response
handling logic that reads conn.inputStream). Ensure you reference the conn
variable in search() and perform timeouts/disconnect on that same
HttpURLConnection instance.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/app/gamenative/utils/HltbService.kt`:
- Around line 169-209: HltbCache is not thread-safe: protect mem, stamps, loaded
and the load/save sequence with a lock (e.g., a Kotlin Mutex or synchronized
block) so concurrent calls to get()/put() (and load()/save()) cannot mutate
LinkedHashMaps concurrently; move setting loaded = true to after successful
decode/population (inside load() after parsing loop) so a second thread won't
see loaded==true before data is populated; wrap accesses in get(name), put(name,
stats), load(), and save() with the same lock and ensure save() reads from the
guarded mem/stamps, using key(name) and PrefManager.hltbCache as before.

---

Nitpick comments:
In `@app/src/main/java/app/gamenative/utils/HltbService.kt`:
- Around line 115-135: The code is caching and returning a Stats object even
when the chosen HLTB match (the local variable best / g) has all comp_* fields
equal to zero or when the fuzzy match is a poor match; after you pick the best
item in the loop that uses normalize(...) and levenshtein(...), add a guard that
reads g.optLong("comp_main"), "comp_plus", "comp_100", and "comp_all" and if
they are all zero then skip creating/writing the Stats (do not cache or return
it) or return null/empty; additionally enforce a Levenshtein threshold (e.g.
bestDist <= max(1, norm.length * 0.3)) before accepting the match — if bestDist
is too large, treat as no reliable match and skip caching/returning; ensure this
logic is applied where Stats(...) is constructed and wherever caching is
performed so you don't store 12-hour placeholders for empty entries.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="app/src/main/java/app/gamenative/utils/HltbService.kt">

<violation number="1" location="app/src/main/java/app/gamenative/utils/HltbService.kt:143">
P1: `HltbCache` is not thread-safe but is accessed from `Dispatchers.IO` (a multi-threaded dispatcher) here. The backing `mutableMapOf` collections (`mem`, `stamps`) are plain `LinkedHashMap` instances with no synchronization. Concurrent calls to `getStats` from multiple game screens will race on `get()`/`put()`, risking `ConcurrentModificationException` or silent data corruption.

Additionally, `load()` sets `loaded = true` *before* the decode/populate block runs, so a second thread entering `get()` while the first is still decoding will see `loaded == true`, skip loading, and read empty maps — causing unnecessary network fetches.

Wrap `HltbCache.get`, `put`, `load`, and `save` with `synchronized(lock)` (or use a `Mutex` for a coroutine-friendly approach), and move `loaded = true` to *after* the populate step completes.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@app/src/main/java/app/gamenative/ui/screen/library/components/HltbHeroStrip.kt`:
- Around line 64-77: The external-link Icon in HltbHeroStrip.kt (the branch
checking stats.gameId > 0 and the Icon with clickable modifier) needs two fixes:
wrap the context.startActivity(Intent(Intent.ACTION_VIEW,
Uri.parse("${HltbService.GAME_URL}${stats.gameId}"))) call in a try/catch that
catches ActivityNotFoundException and logs/ignores it to avoid crashes, and
increase the touch target to at least 48dp by using an IconButton or wrapping
the Icon in a Box/Modifier with minimumInteractiveComponentSize(48.dp) (or a
48.dp clickable Box) and add semantics role = Role.Button for accessibility so
the element is both safe and reachable.

In `@app/src/test/java/app/gamenative/utils/HltbCacheTest.kt`:
- Around line 83-96: The test put_evictsOldestWhenCapReached doesn't assert that
the oldest entry was removed; update the test in HltbCacheTest (function
put_evictsOldestWhenCapReached) to, after inserting "Overflow Game", assert that
HltbCache.get("Game 0") is null (or absent) and optionally assert the cache size
remains ≤ HltbCache.MAX_ENTRIES to confirm eviction occurred; keep the existing
assertNotNull(HltbCache.get("Overflow Game")) and use sampleStats as before.
- Around line 71-79: The test get_returnsNullAfterTtlExpires doesn't actually
exercise TTL expiry; update it so it either (A) is renamed to
get_returnsEntryWithinTtl and only asserts that HltbCache.put("Celeste",
sampleStats) + HltbCache.get("Celeste") returns non-null, or (B) modify
HltbCache to accept an injectable time provider (or clock) and in the test
simulate advancing time > TTL (the 12-hour TTL constant) then assert
HltbCache.get("Celeste") returns null; refer to HltbCache.put and HltbCache.get
and the TTL constant when making the changes.

---

Nitpick comments:
In `@app/src/main/java/app/gamenative/utils/HltbService.kt`:
- Line 47: The shared mutable property auth in HltbService is accessed from
multiple coroutines without synchronization; mark the property as volatile by
adding the Kotlin `@Volatile` annotation to its declaration (i.e., change the
declaration of auth to `@Volatile` private var auth: Auth? = null) so writes in
fetchAuth() and other assignment sites are promptly visible to readers and avoid
redundant concurrent fetches.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="app/src/main/java/app/gamenative/utils/HltbService.kt">

<violation number="1" location="app/src/main/java/app/gamenative/utils/HltbService.kt:197">
P2: Cache size cap (`MAX_ENTRIES`) is not enforced during persisted cache load, allowing startup state to exceed the documented 200-entry limit.</violation>
</file>

<file name="app/src/test/java/app/gamenative/utils/HltbCacheTest.kt">

<violation number="1" location="app/src/test/java/app/gamenative/utils/HltbCacheTest.kt:72">
P3: Test name `get_returnsNullAfterTtlExpires` is misleading — it only asserts the entry exists immediately after `put` and never exercises expiry. Either rename to something like `get_returnsEntryWithinTtl` or inject a time provider so TTL expiration can actually be simulated; as-is this gives false confidence that TTL logic is covered.</violation>

<violation number="2" location="app/src/test/java/app/gamenative/utils/HltbCacheTest.kt:95">
P2: Eviction test doesn't actually verify eviction. After inserting the overflow entry, add `assertNull(HltbCache.get("Game 0"))` to confirm the oldest entry was evicted. Without this, a regression in eviction logic (wrong victim, or no eviction at all) would still pass.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@app/src/main/java/app/gamenative/utils/HltbService.kt`:
- Line 165: The helper function secs(s: Long) is misnamed and unclear because it
accepts seconds and returns a formatted hours string; rename the function to a
clearer name such as formatHours(seconds: Long) or secondsToHoursLabel(seconds:
Long), update its parameter name from s to seconds, and change its signature and
all call sites that reference secs (e.g., the places currently calling secs(...)
around the HltbService usage) to use the new name and parameter. Keep the
implementation logic identical (return "--" when seconds <= 0 else format hours
with "%.1f".format(seconds / 3600.0)) and update any imports or references in
HltbService to avoid unresolved symbol errors.
- Around line 166-167: HltbService.normalize and HltbCache.key are identical; to
avoid future divergence, remove the duplicate implementation by making
HltbCache.key delegate to the single canonical normalizer or extract a shared
private helper used by both. Concretely, replace the body of HltbCache.key with
a call to HltbService.normalize(...) (or move the regex logic into a private
top-level function like normalizedKey(...) and use that from both
HltbService.normalize and HltbCache.key), ensuring visibility allows the call
and updating references accordingly.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@app/src/main/java/app/gamenative/utils/HltbService.kt`:
- Around line 16-17: The normalizedKey function compiles two Regex instances on
every call causing unnecessary allocations; hoist the two Regex patterns
(Regex("[^\\p{L}\\p{N}]") and Regex("\\s+")) to file-level val constants and
reuse them inside normalizedKey so the function simply calls .replace with the
precompiled regexes and then .trim(); update references inside normalizedKey
accordingly to eliminate per-call compilation.
- Around line 159-171: The code relies on a hidden sentinel where search(name)
null means multiple things (no match, error, or auth invalidation), making retry
logic in getStats brittle; change search(...) to return an explicit sealed
result (e.g., sealed class SearchResult { data class Found(val stats: Stats),
object NoMatch, object AuthInvalidated }) and update getStats to pattern-match
that result: on Found use the stats and cache it, on NoMatch return null
immediately, and on AuthInvalidated call fetchAuth(), update auth, re-run search
and then proceed only if Found; also update any callers of search and add a
short comment on auth field to document that AuthInvalidated is the only code
path that triggers a refresh.

In `@app/src/test/java/app/gamenative/utils/HltbServiceIntegrationTest.kt`:
- Around line 84-99: The test currently hardcodes expected Origin/Referer values
using "http://localhost:${server.port}" which can mismatch MockWebServer's
actual URL; update the assertions that inspect initRequest.getHeader("Origin")
and initRequest.getHeader("Referer") to derive expectations from
server.url("/").toString() (use the URL without a trailing slash for the Origin
expectation and with a trailing slash for the Referer expectation) so the
assertions reflect the real base URL the HltbService was configured with.