0.10.0 by Producdevity · Pull Request #156 · Producdevity/EmuReady

Producdevity · 2025-08-25T22:27:37Z

Description

Fixes # (issue)

Type of change

How Has This Been Tested?

Screenshots (if applicable)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my code
I have made corresponding changes to the documentation
I have checked that all checks (lint, typecheck, test) pass

Notes for reviewers

Summary by CodeRabbit

New Features
- Comment voting and reporting on listings
- PC listing create/update capabilities
- Preferences management (devices/SOCs/profiles)
- Trust info endpoint for user reputation
- Emulator config retrieval for listings
UX Improvements
- Clearer form validation and error messages; improved custom-field initialization
API/Integrations
- Mobile API expanded (81 endpoints); updated descriptions and new listings/trust endpoints
Performance/Reliability
- Service worker cache updated for fresher assets
Documentation
- Added v0.10.0 EmuReady release notes
Chores
- Version bumped to 0.10.0

… API

…ore and pcListings modules

vercel · 2025-08-25T22:27:43Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
emuready	Ready	Preview	Comment	Aug 27, 2025 10:30am
emuready (staging)	Ready	Preview	Comment	Aug 27, 2025 10:30am

coderabbitai · 2025-08-25T22:27:44Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing Touches

🧪 Generate unit tests

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch staging

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

Visit our Status Page to check the current availability of CodeRabbit.
Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

claude · 2025-08-25T22:27:55Z

Claude finished @Producdevity's task —— View job

PR Review Complete ✅

I've reviewed this v0.10.0 PR and here's my comprehensive feedback:

Todo List:

Read repository guidelines (CLAUDE.md)
Review form validation changes
Analyze error handling improvements
Check API router modifications
Review migration files
Assess custom field components
Evaluate security implications
Check for performance considerations
Provide comprehensive feedback

Overall Assessment

This PR shows excellent code quality with significant improvements in error handling, validation, and code organization. The changes demonstrate mature software engineering practices.

Strengths 🌟

1. Error Handling Architecture (`src/lib/errors.ts`)

Outstanding systematic approach with centralized error constants and factory functions
Proper separation of concerns with AppError, ValidationError, and ResourceError classes
Type-safe error codes using as const assertions
Excellent resource-specific error helpers that provide consistent messaging
Good security practice with sanitized error messages

2. Form Validation Enhancements

FormValidationSummary.tsx: Robust error collection and display with proper TypeScript generics
CustomFieldRenderer.tsx: Well-structured validation logic with proper empty value detection
formHelpers.ts: Clean utility function for custom field initialization with proper fallbacks

3. Database & Migration

Safe migration using IF NOT EXISTS for enum values - prevents production deployment issues
Proper handling of existing values in dev/staging environments

4. API Router Improvements (`listings/core.ts`)

Excellent security: Proper access control for banned users and rejected listings
Performance optimizations: Batch queries to avoid N+1 problems
Proper transaction handling with savepoints for validation
Comprehensive trust system integration

Minor Issues & Recommendations 🔍

1. Code Quality

src/lib/errors.ts:221-224 - Potential copy-paste error:

// This message appears to be malformed
alreadyExists: (modelName: string) =>
  AppError.conflict(
    `Permission with this key already exists A device with model name "${modelName}" already exists for this brand`,
  ),

Recommendation: Should be:

alreadyExists: (modelName: string) =>
  AppError.conflict(
    `A device with model name "${modelName}" already exists for this brand`,
  ),

2. Security Considerations

Access control is well-implemented with proper role-based permissions
CAPTCHA integration is correctly implemented with proper error handling
Input validation is thorough with custom field validation

3. Performance

Excellent batch query optimization in listings router to prevent N+1 queries
Proper caching invalidation after mutations
Materialized vote counts usage is appropriate

4. Error Message Consistency

FormValidationSummary.tsx:30 - Generic fallback could be more specific:

errorMessages.push(`Custom field ${index + 1} has an error`)

Recommendation: Consider including field name when available:

const fieldName = fieldDef?.label || `field ${index + 1}`;
errorMessages.push(`${fieldName} has an error`)

Test Coverage Assessment 📊

The PR indicates all tests pass, which is good. However, I recommend adding tests for:

Error handling edge cases in the new AppError class
Custom field validation scenarios with various field types
Form validation summary with different error structures
Migration rollback scenarios (if applicable)

Security Review ✅

No security vulnerabilities detected
Proper input sanitization and validation
Access control is well-implemented
CAPTCHA integration follows security best practices
SQL injection protection through Prisma ORM usage

Performance Considerations ⚡

Batch queries prevent N+1 problems
Proper indexing assumed from query patterns
Caching invalidation is appropriate
Transaction scoping is well-managed

Conclusion

This is a high-quality PR that demonstrates excellent software engineering practices. The error handling improvements, form validation enhancements, and performance optimizations are all well-implemented.

Recommendation: ✅ Approve - The minor issues identified are not blocking and can be addressed in future iterations.

The single copy-paste error in errors.ts:221-224 should be fixed, but it doesn't affect functionality significantly.

Producdevity · 2025-08-25T22:33:47Z

@coderabbitai review

coderabbitai · 2025-08-25T22:33:54Z

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

coderabbitai

Actionable comments posted: 12

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (11)

src/app/listings/components/shared/CustomFieldRenderer.tsx (1)

55-61: Required boolean fields will be treated as invalid when false.

required is set to a message for all required fields, but boolean controls typically submit false legitimately. In RHF, required on a checkbox forces “truthy,” contradicting your “Boolean fields are always valid” comment. Mark booleans as not required and keep your custom validate.
   function getValidationRules(): ValidationRules {
     return {
-      required: props.fieldDef.isRequired ? `${props.fieldDef.label} is required` : false,
+      required:
+        props.fieldDef.type === CustomFieldType.BOOLEAN
+          ? false
+          : props.fieldDef.isRequired
+            ? `${props.fieldDef.label} is required`
+            : false,
       validate: props.fieldDef.isRequired
         ? (value: unknown) => {
           // Boolean fields are always valid
           if (props.fieldDef.type === CustomFieldType.BOOLEAN) return true

src/lib/errors.ts (1)

219-225: Copy/paste bug in device.alreadyExists message

User-facing string includes a stray “Permission with this key already exists” prefix. Fix to avoid confusing error text.

Apply this diff:

   static device = {
     notFound: () => AppError.notFound('Device'),
     alreadyExists: (modelName: string) =>
-      AppError.conflict(
-        `Permission with this key already exists A device with model name "${modelName}" already exists for this brand`,
-      ),
+      AppError.conflict(
+        `A device with model name "${modelName}" already exists for this brand`,
+      ),
     inUse: (count: number) => AppError.resourceInUse('device', count),
   }

docs/MOBILE_API.md (1)

257-262: Wrong description for listings.getEmulatorConfig

Currently says “Delete a comment”. Should reflect the emulator configuration fetch used by mobile listing flows.

Apply this diff:
 #### 34. **getEmulatorConfig**
 - **Method**: GET
 - **Path**: `/listings.getEmulatorConfig`
-- **Description**: Delete a comment
+- **Description**: Get emulator configuration for listing creation/edit
 - **Tags**: listings

public/api-docs/mobile-openapi.json (1)

7967-7969: Copy/paste error: getEmulatorConfig summary/description says “Delete a comment”

This endpoint retrieves emulator config but the summary/description say “Delete a comment”. Fix to avoid misleading API consumers.

Apply this diff:
-        "summary": "Delete a comment",
-        "description": "Delete a comment",
+        "summary": "Get emulator config for a listing",
+        "description": "Get emulator configuration payload for the given listing/emulator type",

src/server/api/routers/pcListings.ts (7)

413-445: Critical: returned listing may not reflect newly saved customFieldValues (and lacks atomicity).

You update the listing (include current customFieldValues), then deleteMany and createMany new values, and finally return the pre-mutation updatedPcListing. Callers won’t see the new custom fields. Also, delete/create should be atomic.

Wrap in a transaction and re-fetch after writes:

-    const updatedPcListing = await ctx.prisma.pcListing.update({
-      where: { id },
-      data: { ...updateData, updatedAt: new Date() },
-      include: {
-        game: { include: { system: true } },
-        cpu: { include: { brand: true } },
-        gpu: { include: { brand: true } },
-        emulator: true,
-        performance: true,
-        author: true,
-        customFieldValues: { include: { customFieldDefinition: true } },
-      },
-    })
-
-    // Handle custom field values if provided
-    if (customFieldValues) {
-      // Delete existing custom field values
-      await ctx.prisma.pcListingCustomFieldValue.deleteMany({ where: { pcListingId: id } })
-
-      // Create new custom field values
-      if (customFieldValues.length > 0) {
-        await ctx.prisma.pcListingCustomFieldValue.createMany({
-          data: customFieldValues.map((cfv) => ({
-            pcListingId: id,
-            customFieldDefinitionId: cfv.customFieldDefinitionId,
-            value: cfv.value,
-          })),
-        })
-      }
-    }
-
-    return updatedPcListing
+    const updatedPcListing = await ctx.prisma.$transaction(async (tx) => {
+      // 1) Update core fields
+      await tx.pcListing.update({
+        where: { id },
+        data: { ...updateData, updatedAt: new Date() },
+      })
+
+      // 2) Replace custom field values if provided
+      if (customFieldValues) {
+        await tx.pcListingCustomFieldValue.deleteMany({ where: { pcListingId: id } })
+        if (customFieldValues.length > 0) {
+          await tx.pcListingCustomFieldValue.createMany({
+            data: customFieldValues.map((cfv) => ({
+              pcListingId: id,
+              customFieldDefinitionId: cfv.customFieldDefinitionId,
+              value: cfv.value,
+            })),
+          })
+        }
+      }
+
+      // 3) Return fresh view with includes
+      return tx.pcListing.findUniqueOrThrow({
+        where: { id },
+        include: {
+          game: { include: { system: true } },
+          cpu: { include: { brand: true } },
+          gpu: { include: { brand: true } },
+          emulator: true,
+          performance: true,
+          author: true,
+          customFieldValues: { include: { customFieldDefinition: true } },
+        },
+      })
+    })
+
+    return updatedPcListing

Also applies to: 430-441

725-751: Same issue in updateAdmin: response may exclude the newly written customFieldValues. Make atomic.

The admin path updates the listing, then mutates custom fields, and returns the pre-mutation entity. Mirror the transaction-and-refetch pattern.

-      const updatedPcListing = await ctx.prisma.pcListing.update({
-        where: { id },
-        data: { ...data, updatedAt: new Date() },
-        include: pcListingDetailInclude,
-      })
-
-      // Handle custom field values if provided
-      if (customFieldValues) {
-        // Delete existing custom field values
-        await ctx.prisma.pcListingCustomFieldValue.deleteMany({
-          where: { pcListingId: id },
-        })
-
-        // Create new custom field values
-        if (customFieldValues.length > 0) {
-          await ctx.prisma.pcListingCustomFieldValue.createMany({
-            data: customFieldValues.map((cfv) => ({
-              pcListingId: id,
-              customFieldDefinitionId: cfv.customFieldDefinitionId,
-              value: cfv.value,
-            })),
-          })
-        }
-      }
-
-      return updatedPcListing
+      const updatedPcListing = await ctx.prisma.$transaction(async (tx) => {
+        await tx.pcListing.update({
+          where: { id },
+          data: { ...data, updatedAt: new Date() },
+        })
+
+        if (customFieldValues) {
+          await tx.pcListingCustomFieldValue.deleteMany({ where: { pcListingId: id } })
+          if (customFieldValues.length > 0) {
+            await tx.pcListingCustomFieldValue.createMany({
+              data: customFieldValues.map((cfv) => ({
+                pcListingId: id,
+                customFieldDefinitionId: cfv.customFieldDefinitionId,
+                value: cfv.value,
+              })),
+            })
+          }
+        }
+
+        return tx.pcListing.findUniqueOrThrow({
+          where: { id },
+          include: pcListingDetailInclude,
+        })
+      })
+
+      return updatedPcListing

1118-1121: Bug: missing throw/return on forbidden comment edit.

The code calls AppError.forbidden(...) but does not throw or return, so unauthorized users will still edit the comment.

Apply this diff:

-      if (!canEdit) {
-        AppError.forbidden('You do not have permission to edit this comment')
-      }
+      if (!canEdit) {
+        throw AppError.forbidden('You do not have permission to edit this comment')
+      }

1154-1156: Bug: missing throw/return on forbidden comment delete.

Same issue as updateComment; execution proceeds without stopping.

-      if (!canDelete) {
-        AppError.forbidden('You do not have permission to delete this comment')
-      }
+      if (!canDelete) {
+        throw AppError.forbidden('You do not have permission to delete this comment')
+      }

1409-1411: Bug: verification path does not return/throw when listing is missing.

Currently it evaluates ResourceError.pcListing.notFound() and continues, allowing a verification to be created for a non-existent listing.

-      if (!pcListing) {
-        ResourceError.pcListing.notFound()
-      }
+      if (!pcListing) {
+        throw ResourceError.pcListing.notFound()
+      }

1237-1254: Bug: report creation path lacks throws for bad requests.

Both “cannot report own listing” and “already reported” should stop execution.

-      if (pcListing.authorId === userId) {
-        AppError.badRequest('You cannot report your own listing')
-      }
+      if (pcListing.authorId === userId) {
+        throw AppError.badRequest('You cannot report your own listing')
+      }
...
-      if (existingReport) {
-        AppError.badRequest('You have already reported this listing')
-      }
+      if (existingReport) {
+        throw AppError.badRequest('You have already reported this listing')
+      }

329-339: Align AppError/ResourceError Handling: Always Throw

The grep output confirms mixed use of return and throw for AppError/ResourceError across the pcListings router (dozens of occurrences spanning lines 103–1448). To ensure tRPC clients receive proper exceptions (not serialized data), pick one approach—always throw—and apply it consistently.

Next steps:

Decide on a single error semantics: use throw for all AppError and ResourceError cases in this router.

Replace every

return ResourceError.…()
return AppError.…()

with

throw ResourceError.…()
throw AppError.…()

Consult the grep output for all affected locations (e.g., lines 104, 213, 220–221, 239–240, 267–269, 333–335, 407–409, 453–455, 501–503, 507–510, 521–523, 542–544, 548–553, 562–564, 589–591, 618–620, 722–724, 776–778, 796–798, 832–838, 849–851, 880–886, 902–904, 1058–1060, 1066–1068, 1112–1115, 1144–1147, 1174–1176, 1233–1235, 1325–1327, 1446–1448).

Example refactor:

 // before
 if (!pcListing) return ResourceError.pcListing.notFound()
 
 // after
 if (!pcListing) throw ResourceError.pcListing.notFound()

After making changes, re-run the provided grep script to verify no remaining return AppError/return ResourceError usages.

🧹 Nitpick comments (25)

package.json (1)
3-3: Automate CACHE_NAME sync in the npm version lifecycle

Verified that both public/service-worker.js and public/sw-register.js have their CACHE_NAME set to emuready_v0.10.0, matching the "version": "0.10.0" in package.json. ✅

To eliminate manual edits on each release, hook your existing version:sync script into npm version:

• File: package.json
 "scripts": {
+    "version": "npm run version:sync && git add -A",
   "version:sync": "node scripts/sync-version.js"
 }
This way a single npm version <new> will update your package version, rewrite both cache-name constants, and stage everything for commit in one go.
public/service-worker.js (1)
132-134: Docstring nit: clarify the policy is stale‑while‑revalidate with TTL gating.

The handler still serves stale cache immediately if present and revalidates in the background (SWr). The current comment “to prevent stale data” can mislead.
- * Implements cache policies based on resource type to prevent stale data.
+ * Implements stale-while-revalidate caching with TTL gating per resource type:
+ *   serve cached if present, revalidate in background, and stamp freshness.
public/sw-register.js (1)

1-1: CACHE_NAME bump mirrors the service worker.

Good consistency with public/service-worker.js. Minor note: since the SW’s activate event already deletes old caches, this page-load cleanup is redundant but harmless. Keep if you want belt-and-suspenders behavior; otherwise you can drop the window-level cleanup to reduce work on slow devices.

src/app/listings/components/shared/CustomFieldRenderer.tsx (1)

55-73: Optional: extract the emptiness check into a shared helper for consistency.

FormValidationSummary and custom field components likely need the same notion of “empty.” Centralizing this reduces drift and future bugs.

I can extract isValueEmpty into formHelpers.ts (or a new validators.ts) and update call sites. Want me to push that refactor?
RELEASE_NOTES.md (1)
1-12: Great release notes; minor markdownlint: avoid using bold as headings (MD036).

Several sections use **...** where ### headings would satisfy linters and improve structure. Consider converting emphasized lines like “IGDB Integration for Game Search (BETA)” to proper subheadings.

Example edit:
-**🔍 IGDB Integration for Game Search (BETA)**
+### 🔍 IGDB Integration for Game Search (BETA)
lint-staged.config.mjs (1)
7-9: Nit: Fix filename in the header comment to match .mjs

The JSDoc header says lint-staged.config.js, but the file is .mjs. Align to avoid confusion in future searches and reviews.

Apply this diff:
- * @filename: lint-staged.config.js
+ * @filename: lint-staged.config.mjs
src/lib/errors.ts (1)
136-141: Type consistency: make AppError.captcha return type never

All other throw helpers are typed as never; captcha should match for better type-narrowing downstream.

Apply this diff:
-  static captcha(message?: string) {
+  static captcha(message?: string): never {
     throw new TRPCError({
       code: ERROR_CODES.BAD_REQUEST,
       message: message ? `CAPTCHA verification failed: ${message}` : ERROR_MESSAGES.INVALID_CAPTCHA,
     })
   }
docs/MOBILE_API.md (1)
1-9: Optional: markdownlint MD036 (“emphasis used instead of heading”)

The auto-generated timestamp line uses italics; some linters prefer a heading. Optional change if you want a cleaner lint pass for docs.

Apply this diff:
-*Auto-generated on: 2025-08-25T04:27:54.741Z*
+### Auto-generated on: 2025-08-25T04:27:54.741Z
public/api-docs/mobile-openapi.json (4)
935-958: Prevent duplicate IDs in GetUserVotesSchema

Consider enforcing unique IDs to avoid redundant lookups on the server.

Apply this diff:
               "commentIds": {
                 "type": "array",
                 "items": {
                   "type": "string",
                   "format": "uuid"
                 },
                 "minItems": 1,
-                "maxItems": 100
+                "maxItems": 100,
+                "uniqueItems": true
               }
959-991: Align examples/validation for ReportCommentSchema

Schema looks good. Two improvements:

Clients may send empty strings for optional description; if provided, enforce min length 1.

Add description to enum for clarity.

Apply this diff:
               "reason": {
                 "type": "string",
                 "enum": [
                   "INAPPROPRIATE_CONTENT",
                   "SPAM",
                   "MISLEADING_INFORMATION",
                   "OTHER"
-                ]
+                ],
+                "description": "Reason for reporting the comment"
               },
               "description": {
                 "type": "string",
-                "maxLength": 1000
+                "maxLength": 1000,
+                "minLength": 1
               }
5-5: Global note: auth status text conflicts with security configuration

The intro says Clerk-protected routes “isn't implemented yet”, but many paths now declare security: [{"ClerkAuth": []}] and a global security requirement exists. Update the note to reflect current reality or remove it.

Would you like me to propose an updated intro paragraph that matches the current auth model?

909-991: Optional: reduce schema duplication and improve OAS compatibility

Multiple schemas embed a local definitions object and then $ref into it. This pattern is non-idiomatic in OpenAPI 3.0 and can confuse tooling. Prefer defining the schema object inline under components.schemas (or $ref to another components.schemas.*), and avoid type arrays in favor of nullable: true.

If helpful, I can open a follow-up PR to:

Flatten VoteCommentSchema/GetUserVotesSchema/ReportCommentSchema into components.schemas without nested definitions.

Run an OpenAPI linter (Spectral) pass and fix OAS 3.0 compliance warnings.

Also applies to: 8109-8558
src/app/listings/[id]/components/EditListingModal.tsx (2)
65-75: Guard against undefined arrays when initializing custom fields.

If emulator.customFieldDefinitions or customFieldValues is ever undefined/null, initializeCustomFieldValues will throw. The server route likely includes definitions, but this guard costs nothing and prevents a hard crash when data contracts drift.

Apply this diff:
-      const defaultCustomFieldValues = initializeCustomFieldValues(
-        listingQuery.data.customFieldValues,
-        listingQuery.data.emulator.customFieldDefinitions,
-      )
+      const defaultCustomFieldValues = initializeCustomFieldValues(
+        listingQuery.data.customFieldValues ?? [],
+        listingQuery.data.emulator.customFieldDefinitions ?? [],
+      )
191-219: Optional: reuse the shared PerformanceSelector for parity with PC modal.

This manual SelectInput is fine, but using the shared PerformanceSelector (as in EditPcListingModal) would reduce divergence and ensure consistent error/render behavior.

If you want, I can draft the small refactor.
src/app/pc-listings/[id]/components/EditPcListingModal.tsx (2)
76-90: Harden initializeCustomFieldValues call.

Add nullish guards to avoid crashes if the server ever omits customFieldDefinitions or customFieldValues.
-      const defaultCustomFieldValues = initializeCustomFieldValues(
-        pcListingQuery.data.customFieldValues,
-        pcListingQuery.data.emulator.customFieldDefinitions,
-      )
+      const defaultCustomFieldValues = initializeCustomFieldValues(
+        pcListingQuery.data.customFieldValues ?? [],
+        pcListingQuery.data.emulator.customFieldDefinitions ?? [],
+      )
50-52: Consolidate to a Single Performance-Scales Endpoint

Both api.listings.performanceScales (in the listings router) and api.performanceScales.get (in the performanceScales router) exist and currently return the same data—an ascending list of scales—but via two different handlers. Maintaining both invites drift and extra upkeep. I recommend picking one (ideally the more flexible api.performanceScales.get) and using it everywhere.

• Replace all calls to
api.listings.performanceScales.useQuery(...)
with
api.performanceScales.get.useQuery(...)
in these files:
– src/app/pc-listings/[id]/components/EditPcListingModal.tsx (lines ~50–52)
– src/app/pc-listings/PcListingsPage.tsx
– src/app/v2/listings/V2ListingsPage.tsx
– src/app/listings/ListingsPage.tsx
– src/app/listings/new/NewListingPage.tsx
– src/app/listings/[id]/components/EditListingModal.tsx
– …and any other usages of api.listings.performanceScales shown by your ripgrep search.

• After migrating, remove the performanceScales field from the listings router in
src/server/api/routers/listings/core.ts to avoid duplication.

This will keep your API surface clean and reduce future maintenance risk.
src/app/listings/components/shared/FormValidationSummary.tsx (1)
45-58: Tighten fallback detection for custom-field errors without messages.

The current fallback checks any truthy fieldError.value, which is usually fine, but can also trip when value exists for non-required errors in some RHF shapes. Prefer checking for an error-like object shape.
-    const customFieldErrors = props.errors.customFieldValues
-    if (customFieldErrors && Array.isArray(customFieldErrors)) {
-      const hasEmptyRequiredFields = customFieldErrors.some((fieldError) => fieldError?.value)
-      if (hasEmptyRequiredFields) errorMessages.push('Please fill in all required custom fields')
-    }
+    const customFieldErrors = props.errors.customFieldValues
+    if (Array.isArray(customFieldErrors)) {
+      const hasCustomFieldIssues = customFieldErrors.some((fe) => {
+        const v = (fe as any)?.value
+        return v && typeof v === 'object' && ('type' in v || 'ref' in v || 'message' in v)
+      })
+      if (hasCustomFieldIssues) errorMessages.push('Please fill in all required custom fields')
+    }
src/app/listings/components/shared/utils/formHelpers.ts (1)
26-40: Optional: default empty arrays for resilience and DX.

Allow callers to omit undefined by giving parameters default values.
-export function initializeCustomFieldValues(
-  existingValues: CustomFieldValue[],
-  fieldDefinitions: CustomFieldDefinition[],
-): { customFieldDefinitionId: string; value: unknown }[] {
+export function initializeCustomFieldValues(
+  existingValues: CustomFieldValue[] = [],
+  fieldDefinitions: CustomFieldDefinition[] = [],
+): { customFieldDefinitionId: string; value: unknown }[] {
src/server/api/routers/pcListings.ts (1)
949-963: Nit: event type constant is identical for upvote/downvote.

Both branches emit NOTIFICATION_EVENTS.LISTING_VOTED. If you intended different events for like/dislike, branch on value. Otherwise, consider inlining the constant.
-    notificationEventEmitter.emitNotificationEvent({
-      eventType: value ? NOTIFICATION_EVENTS.LISTING_VOTED : NOTIFICATION_EVENTS.LISTING_VOTED,
+    notificationEventEmitter.emitNotificationEvent({
+      eventType: NOTIFICATION_EVENTS.LISTING_VOTED,
src/server/api/routers/listings/core.ts (6)
723-725: Use a consistent “owner” truth value across the method

After the refactor above, keep a single const isOwner = ... declaration and reuse it. Multiple derivations of ownership increase drift risk.
-    const isOwner = listing.authorId === ctx.session.user.id
+    const isOwner = listing.authorId === ctx.session.user.id
(No functional change; ensure only one declaration remains after the moderator-path refactor.)

807-815: Unify edit-time limit math to the shared constant

You define EDIT_TIME_LIMIT already; re-deriving milliseconds here is error-prone.
-        const timeLimit = EDIT_TIME_LIMIT_MINUTES * 60 * 1000
+        const timeLimit = EDIT_TIME_LIMIT
821-852: Consider post-update cache invalidation to reflect edits immediately

Create flow invalidates list pages, sitemap, and tags when status is APPROVED. Edits (notes/performance/custom fields) won’t propagate until TTL unless you revalidate.

Example (outside the transaction, after it resolves):
const updated = await ctx.prisma.$transaction(/* ...existing code... */)

// Optional: only when visible entities may be affected
if (listing.status === ApprovalStatus.APPROVED) {
  await invalidateListPages()
  await invalidateSitemap()
  await revalidateByTag('listings')
  await revalidateByTag(`game-${updated.gameId}`)
  await revalidateByTag(`device-${updated.deviceId}`)
  await revalidateByTag(`emulator-${updated.emulatorId}`)
}

return updated
If you want this, I can open a small follow-up PR wiring the IDs you need for tag invalidation.

565-575: Standardize error surface in vote(): mix of ResourceError and AppError

This branch returns ResourceError.listing.notFound(), but the “toggle/remove” branch above returns AppError.notFound('Listing') (Line 523). Mixing shapes complicates client handling.

Apply this diff to the earlier branch for consistency:
-      if (!listingForRemoval) return AppError.notFound('Listing')
+      if (!listingForRemoval) return ResourceError.listing.notFound()
If the intended convention is “always ResourceError for listing flows,” consider aligning the other “not found”s similarly in this file.

854-856: Align error propagation style in getForUserEdit (throw vs return)

This procedure “returns” ResourceError.listing.canOnlyEditOwn() on authorization failure but “throws” for not-found. Pick one style for predictable client contracts (the rest of this file mostly “returns” ResourceError.*).

Apply this diff:
-      if (!listing) throw ResourceError.listing.notFound()
+      if (!listing) return ResourceError.listing.notFound()
Optionally, convert the canOnlyEditOwn() branch to throw instead—just be consistent across procedures.

Also applies to: 882-890

705-780: Minor consistency: prefer a single permission helper

You use both roleIncludesRole and hasPermission in this file to test moderator capabilities. Prefer one (the newer hasPermission?), to avoid drift.

If we standardize on hasPermission, I can sweep the file in a follow-up PR.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

MCP integration is disabled by default for public repositories
Jira integration is disabled by default for public repositories
Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 7f6d773 and b14f7d2.

📒 Files selected for processing (17)

RELEASE_NOTES.md (1 hunks)
docs/MOBILE_API.md (12 hunks)
lint-staged.config.mjs (1 hunks)
package.json (1 hunks)
prisma/migrations/20250825_add_missing_trust_actions/migration.sql (1 hunks)
public/api-docs/mobile-openapi.json (3 hunks)
public/service-worker.js (1 hunks)
public/sw-register.js (1 hunks)
src/app/listings/[id]/components/EditListingModal.tsx (2 hunks)
src/app/listings/components/shared/CustomFieldRenderer.tsx (2 hunks)
src/app/listings/components/shared/FormValidationSummary.tsx (1 hunks)
src/app/listings/components/shared/custom-fields/CustomFieldTypeDriverVersion.tsx (0 hunks)
src/app/listings/components/shared/utils/formHelpers.ts (1 hunks)
src/app/pc-listings/[id]/components/EditPcListingModal.tsx (2 hunks)
src/lib/errors.ts (2 hunks)
src/server/api/routers/listings/core.ts (12 hunks)
src/server/api/routers/pcListings.ts (3 hunks)

💤 Files with no reviewable changes (1)

src/app/listings/components/shared/custom-fields/CustomFieldTypeDriverVersion.tsx

🧰 Additional context used

🪛 Biome (2.1.2)

src/server/api/routers/pcListings.ts

[error] 386-386: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.

The declaration is defined in this switch clause:

Safe fix: Wrap the declaration in a block.

(lint/correctness/noSwitchDeclarations)

[error] 387-387: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.

The declaration is defined in this switch clause:

Safe fix: Wrap the declaration in a block.

(lint/correctness/noSwitchDeclarations)

[error] 388-388: Other switch clauses can erroneously access this declaration.
Wrap the declaration in a block to restrict its access to the switch clause.

The declaration is defined in this switch clause:

Safe fix: Wrap the declaration in a block.

(lint/correctness/noSwitchDeclarations)

🪛 markdownlint-cli2 (0.17.2)

RELEASE_NOTES.md

5-5: Emphasis used instead of a heading