agent: @U0AJM7X8FBR read the mono repo, then ULTRATHINK about our non-technical#295
Open
sweetmantech wants to merge 2 commits intotestfrom
Open
agent: @U0AJM7X8FBR read the mono repo, then ULTRATHINK about our non-technical#295sweetmantech wants to merge 2 commits intotestfrom
sweetmantech wants to merge 2 commits intotestfrom
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (8)
📒 Files selected for processing (24)
💤 Files with no reviewable changes (24)
📝 WalkthroughWalkthroughRemoves multiple content-related API routes and supporting lib/content modules, removes WhatsApp integration from coding-agent, standardizes many function signatures/arrow styles, adds JSDoc params, and performs whitespace/formatting cleanup across numerous files. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ❌ 1❌ Failed checks (1 warning)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
lib/mcp/tools/registerWebDeepResearchTool.ts (2)
1-1:⚠️ Potential issue | 🟠 MajorFile should be organized into a domain-specific subfolder.
According to the coding guidelines, MCP tool files should follow the pattern
lib/mcp/tools/[domain]/register[ToolName]Tool.ts. This file is currently at the root of thetools/directory instead of being organized into a domain folder.Consider moving this file to one of:
lib/mcp/tools/research/registerWebDeepResearchTool.tslib/mcp/tools/search/registerWebDeepResearchTool.tslib/mcp/tools/web/registerWebDeepResearchTool.tsThis follows the same organizational pattern as other tools in the codebase (e.g.,
lib/mcp/tools/artists/registerCreateNewArtistTool.ts,lib/mcp/tools/search/registerSearchGoogleImagesTool.ts).As per coding guidelines: "MCP tool files should be located in
lib/mcp/tools/[domain]/register[ToolName]Tool.tsand follow the documented tool registration pattern"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/mcp/tools/registerWebDeepResearchTool.ts` at line 1, Move registerWebDeepResearchTool.ts into a domain subfolder under lib/mcp/tools (e.g., lib/mcp/tools/research/registerWebDeepResearchTool.ts or lib/mcp/tools/search/registerWebDeepResearchTool.ts) so it follows the pattern used by other tools; update any internal imports/exports and paths inside the file that reference its old location and adjust all call sites or re-exports that import McpServer or registerWebDeepResearchTool (look for symbol registerWebDeepResearchTool and the import of McpServer from "@modelcontextprotocol/sdk/server/mcp.js") to the new module path so builds and registrations continue to work.
27-67:⚠️ Potential issue | 🔴 CriticalCritical: Missing authentication and access control.
This MCP tool lacks any authentication or authorization checks. According to the coding guidelines, all MCP tools must use
resolveAccountId()for validation and access control before performing operations. Without this, the tool allows unauthenticated access to the Perplexity deep research API, which could result in:
- Unauthorized API usage and associated costs
- Potential abuse of the research functionality
- No audit trail of who requested the research
Add authentication at the start of the tool handler:
async (args: WebDeepResearchArgs, extra) => { try { const accountId = await resolveAccountId(extra); const { messages } = args; // ... rest of the implementationAs per coding guidelines: "MCP tools should never manually extract
accountIdfromextra.authInfo; always useresolveAccountId()for validation and access control"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/mcp/tools/registerWebDeepResearchTool.ts` around lines 27 - 67, The handler registered in registerWebDeepResearchTool currently omits authentication and must call resolveAccountId for validation; update the server.registerTool handler signature to accept the second parameter (extra), call await resolveAccountId(extra) at the start (before using args), and proceed only after it returns (use the resolved accountId for any access-control/audit needs); ensure you don't read accountId directly from extra.authInfo and keep the rest of the logic (messages validation, chatWithPerplexity call, citations handling, error handling) unchanged in the async (args: WebDeepResearchArgs, extra) => { ... } function.lib/coding-agent/mergeGithubBranch.ts (1)
46-51:⚠️ Potential issue | 🟠 MajorGuard JSON parsing in error response to prevent unexpected throws.
Line 50 calls
JSON.parse(errorBody)without error handling. If the response isn't valid JSON (e.g., HTML error page, plain text), the function throws instead of returning the declaredMergeGithubBranchResult. This violates the error handling requirement forlib/**/*.tsfiles.Suggested fix
const errorBody = await response.text(); console.error( `[coding-agent] branch merge failed for ${repo} (${head} → ${base}): ${response.status} ${errorBody}`, ); - const error = JSON.parse(errorBody); - return { ok: false, message: error.message }; + try { + const error = JSON.parse(errorBody) as { message?: string }; + return { ok: false, message: error.message || `GitHub merge failed with status ${response.status}` }; + } catch { + return { ok: false, message: `GitHub merge failed with status ${response.status}` }; + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/coding-agent/mergeGithubBranch.ts` around lines 46 - 51, The JSON.parse call on errorBody in mergeGithubBranch (lib/coding-agent/mergeGithubBranch.ts) can throw if the response isn't JSON; wrap the parse in a try/catch, attempt parsing to extract error.message, and on failure fall back to using the raw errorBody (or a generic message) so the function still returns a valid MergeGithubBranchResult { ok: false, message: ... } instead of throwing; update the code around the errorBody handling and the return to use the parsed message when available and the raw text otherwise.app/api/transcribe/route.ts (1)
9-25:⚠️ Potential issue | 🟠 MajorMissing authentication and invalid account_id source: endpoint accepts untrusted request body.
This endpoint violates two critical guidelines:
No authentication: The route must call
validateAuthContext()per AGENTS.md requirements. Currently any caller can invoke this endpoint.
account_idfrom request body: Per coding guidelines, never useaccount_idin request bodies—always derive it from authentication. Line 12 extractsaccount_iddirectly from the untrusted request body, allowing attackers to trigger transcriptions charged to arbitrary accounts.The
account_idandartist_account_idshould be derived fromvalidateAuthContext()instead of accepting them from callers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/api/transcribe/route.ts` around lines 9 - 25, The POST handler currently trusts request body fields and lacks authentication; call validateAuthContext() at the start of the POST function to authenticate the request and use the returned auth context to derive account_id and artist_account_id instead of reading them from the body; remove extraction/validation of account_id and artist_account_id from req.json(), validate that validateAuthContext() returns the required ids (or return 401/403 if missing), and keep only audio_url and optional title/include_timestamps from the body in the function that performs transcription.lib/mcp/tools/transcribe/registerTranscribeAudioTool.ts (1)
8-14:⚠️ Potential issue | 🔴 CriticalRemove
account_idfrom schema and derive it from authentication usingresolveAccountId().Per coding guidelines, MCP tools must never accept
account_idin request schemas. Instead, useresolveAccountId()with authentication context to validate access. Seelib/mcp/tools/sandbox/registerPromptSandboxTool.tsfor the correct pattern: include optionalaccount_idin the schema to support org key overrides, then callresolveAccountId({authInfo, accountIdOverride: args.account_id})to resolve and validate against the authenticated account.The current implementation bypasses access control by accepting
account_iddirectly from the caller without authentication validation.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/mcp/tools/transcribe/registerTranscribeAudioTool.ts` around lines 8 - 14, The schema currently accepts account_id directly; remove the required account_id field from transcribeAudioSchema and instead make account_id optional to support org-key overrides, then in the tool handler call resolveAccountId({ authInfo, accountIdOverride: args.account_id }) to derive and validate the effective account ID from auth; update any references in registerTranscribeAudioTool.ts to use the resolved accountId (not args.account_id) for storage/access control and mirror the pattern used in registerPromptSandboxTool.ts.lib/github/findOrgReposByAccountId.ts (1)
16-31:⚠️ Potential issue | 🟠 MajorPaginate org repo listing to avoid missing matches.
Line 16 fetches only the first 100 repos. If the org has more than 100 repositories, Line 31 can miss valid account matches entirely.
Proposed pagination fix
- const response = await fetch(`https://api.github.com/orgs/recoupable/repos?per_page=100`, { - headers: { - Authorization: `Bearer ${token}`, - Accept: "application/vnd.github.v3+json", - "User-Agent": "Recoup-API", - }, - }); - - if (!response.ok) { - console.error(`GitHub API error listing org repos: ${response.status}`); - return []; - } - - const repos = (await response.json()) as Array<{ name: string; html_url: string }>; - - return repos.filter(repo => repo.name.includes(accountId)).map(repo => repo.html_url); + const matches: string[] = []; + let page = 1; + + while (true) { + const response = await fetch( + `https://api.github.com/orgs/recoupable/repos?per_page=100&page=${page}`, + { + headers: { + Authorization: `Bearer ${token}`, + Accept: "application/vnd.github.v3+json", + "User-Agent": "Recoup-API", + }, + }, + ); + + if (!response.ok) { + console.error(`GitHub API error listing org repos: ${response.status}`); + return []; + } + + const repos = (await response.json()) as Array<{ name: string; html_url: string }>; + matches.push(...repos.filter(repo => repo.name.includes(accountId)).map(repo => repo.html_url)); + + if (repos.length < 100) break; + page += 1; + } + + return matches;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/github/findOrgReposByAccountId.ts` around lines 16 - 31, The current fetch in findOrgReposByAccountId only requests the first page (per_page=100) and can miss repos; change the logic to paginate the GitHub API by iterating pages (e.g., page=1..N) and accumulate results into the repos array until a page returns fewer than per_page items or an empty array; update the fetch call that uses `token`/`Authorization` to include the `page` query param, merge each page's JSON into the `repos` variable before applying the existing `filter(repo => repo.name.includes(accountId)).map(repo => repo.html_url)`, and ensure you handle non-ok responses per page (log and exit/return) and respect rate-limit headers if needed.
🧹 Nitpick comments (22)
lib/ai/isEmbedModel.ts (1)
6-7: Incomplete@paramdocumentation — add a description for clarity.The
@param mtag was added but without a description, which doesn't provide much value to developers reading the code. Either remove it or complete it with a meaningful description.📝 Suggested JSDoc improvement
* Embed models typically have 0 output pricing since they only produce embeddings. - * - * `@param` m + * + * `@param` m - The language model entry to evaluate + * `@returns` True if the model is an embedding model, false otherwise */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/ai/isEmbedModel.ts` around lines 6 - 7, Update the incomplete JSDoc for the isEmbedModel function by adding a concise description for the `@param` m tag (e.g., "model identifier string or Model object to check whether it is an embedding model") so the parameter purpose is clear; edit the JSDoc block above the isEmbedModel function in lib/ai/isEmbedModel.ts to replace the empty `@param` m with that description (or remove the tag if you prefer), and ensure the description matches the actual accepted type/usage of m in the function.lib/supabase/account_artist_ids/getAccountArtistIds.ts (1)
11-13: Add short descriptions for nested JSDoc params.
@param params.artistIdsand@param params.accountIdsare currently undocumented placeholders. Adding one-line descriptions makes call-site intent clearer and keeps generated docs useful.Suggested JSDoc refinement
- * `@param` params.artistIds - * `@param` params.accountIds + * `@param` params.artistIds - Optional list of artist account IDs to filter by `artist_id`. + * `@param` params.accountIds - Optional list of account IDs to filter by `account_id` when `artistIds` is not provided.As per coding guidelines: "lib/supabase/**/*.ts: Supabase database functions should import from
@/lib/supabase/serverClientand follow the documented pattern with JSDoc comments, error handling, and return types".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/supabase/account_artist_ids/getAccountArtistIds.ts` around lines 11 - 13, Update the JSDoc for the getAccountArtistIds function to include one-line descriptions for the nested params: add brief descriptions for params.artistIds (e.g., "array of artist IDs to filter by") and params.accountIds (e.g., "array of account IDs to filter by") so the generated docs and call-sites are clearer; ensure these `@param` entries appear under the existing `@param` params block and follow the same JSDoc style used in other Supabase functions (brief, present-tense single-line descriptions).lib/transcribe/types.ts (1)
59-60: Complete the@paramJSDoc for maintainability.
@param errorcurrently lacks a description, so the expected input and behavior are still unclear to readers.Suggested doc tweak
- * `@param` error + * `@param` error - Unknown thrown value from transcription flow; normalized into a user-facing message and HTTP status.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/transcribe/types.ts` around lines 59 - 60, Update the JSDoc for the parameter named "error" in lib/transcribe/types.ts to clearly state that "error" is the error object or value returned/raised during transcription (e.g., Error | string | unknown), describe what it represents (the failure cause from the transcription process), note whether it can be null/undefined or a serialized error, and explain how callers should handle or log it (e.g., contains message and optional stack). Target the existing JSDoc `@param` error tag and replace the placeholder with this concise description so readers know the expected type and semantics.lib/emails/processAndSendEmail.ts (1)
38-38: Add a short description for@param input.
@param inputis currently undocumented; a brief description improves generated docs and onboarding readability.✍️ Suggested doc tweak
- * `@param` input + * `@param` input Email payload and optional room metadata used to build and send the message.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/emails/processAndSendEmail.ts` at line 38, Add a one-line JSDoc description for the `input` parameter of the processAndSendEmail function in lib/emails/processAndSendEmail.ts: update the function's JSDoc block to include an `@param input` entry describing the shape/purpose of the argument (e.g., what properties it carries such as recipient, subject, body, and any flags) so generated docs and new contributors understand what to pass into processAndSendEmail.lib/prompts/getSystemPrompt.ts (1)
16-16: Documentparams.orgIdwith an explicit description.Line 16 adds the new JSDoc param but leaves its meaning implicit. Add expected value semantics (including personal-account fallback) to make the API self-explanatory.
✏️ Suggested update
- * `@param` params.orgId + * `@param` params.orgId - The organization ID; null/undefined means personal account context🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/prompts/getSystemPrompt.ts` at line 16, The JSDoc for params.orgId in getSystemPrompt (the function defined in lib/prompts/getSystemPrompt.ts) is missing an explicit description; update the `@param` params.orgId entry to state that it is the organization identifier (string) used to select org-specific system prompts and rules, and document that when orgId is omitted or null the function should fall back to the user's personal-account defaults (or global default prompt) — mention expected type, allowed empty/null behavior, and the fallback semantics so callers know how org-specific vs personal prompts are chosen.lib/coding-agent/parseMergeTestToMainActionId.ts (1)
4-6: JSDoc@paramlacks description.The
@param actionIdannotation would be more helpful with a description of the expected format, e.g.,@param actionId - The action ID to parse, expected format: "merge_test_to_main:{owner}/{repo}".📝 Suggested improvement
* Parses a merge_test_to_main action ID like "merge_test_to_main:recoupable/api" * into the repo string, or null if the format doesn't match. * - * `@param` actionId + * `@param` actionId - The action ID to parse, expected format: "merge_test_to_main:{owner}/{repo}" + * `@returns` The repository string (e.g., "recoupable/api") or null if format doesn't match */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/coding-agent/parseMergeTestToMainActionId.ts` around lines 4 - 6, The JSDoc for the parseMergeTestToMainActionId function is missing a description for the `@param` actionId; update the JSDoc above the parseMergeTestToMainActionId function to document actionId (e.g., "@param actionId - The action ID to parse, expected format: 'merge_test_to_main:{owner}/{repo}'") and optionally add a brief `@returns` description matching the function's output so callers know what is returned.lib/composio/getCallbackUrl.ts (1)
20-23: JSDoc parameter documentation is out of order.The
@param optionson line 22 appears after the specific property documentation (options.destination,options.roomId), which is backwards from standard JSDoc conventions. The parent parameter should come first.📝 Suggested JSDoc fix
/** * Build callback URL for OAuth redirects. * + * `@param` options - Callback configuration options * `@param` options.destination - Where to redirect: "chat" or "connectors" * `@param` options.roomId - For chat destination, the room ID to return to - * `@param` options * `@returns` Full callback URL with success indicator */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/composio/getCallbackUrl.ts` around lines 20 - 23, The JSDoc params are out of order in getCallbackUrl: move the parent param declaration "@param options" to appear before the child property docs ("@param options.destination" and "@param options.roomId") so the parent is documented first; update the JSDoc block above the getCallbackUrl function to list "@param options" (with its description) first, then the specific option properties in any order, ensuring the tags reference the same "options" identifier.lib/coding-agent/parseMergeActionId.ts (1)
4-6: JSDoc@paramlacks description.Same observation as in
parseMergeTestToMainActionId.ts— the annotation would benefit from a description of the expected input format.📝 Suggested improvement
* Parses a merge action ID like "merge_pr:recoupable/api#42" * into { repo, number } or null if the format doesn't match. * - * `@param` actionId + * `@param` actionId - The action ID to parse, expected format: "merge_pr:{owner}/{repo}#{number}" + * `@returns` Object with repo and PR number, or null if format doesn't match */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/coding-agent/parseMergeActionId.ts` around lines 4 - 6, The JSDoc for parseMergeActionId.ts is missing a description for the `@param` actionId; update the JSDoc for the parseMergeActionId function to describe the expected input format (e.g., what shape or example string actionId should be, whether it can be undefined/null and how it is parsed) mirroring the style used in parseMergeTestToMainActionId.ts so callers understand the input contract and edge cases.lib/catalog/getCatalogDataAsCSV.ts (1)
4-8: JSDoc param lacks description.The
@param catalogIdannotation is present but missing a description. Adding a brief description improves code maintainability.📝 Suggested improvement
/** * Gets all catalog songs and formats them as CSV for the scorer - * - * `@param` catalogId + * + * `@param` catalogId - The unique identifier of the catalog to fetch songs from */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/catalog/getCatalogDataAsCSV.ts` around lines 4 - 8, The JSDoc for getCatalogDataAsCSV is missing a description for the `@param` catalogId; update the function's JSDoc block in getCatalogDataAsCSV to add a brief description for the catalogId parameter (e.g., "catalogId - the ID of the catalog to retrieve songs from") so the param annotation documents what value is expected and improves maintainability.lib/spotify/getSpotifyFollowers.ts (1)
38-43: Minor: Stray asterisk in JSDoc creates unnecessary blank line.Line 40 has a lone asterisk that adds a blank line in the JSDoc comment. While not functionally problematic, it's inconsistent with typical JSDoc formatting.
📝 Suggested cleanup
/** * Get Spotify follower count for an artist - * * `@param` artistName - The name of the artist to search for * `@returns` Promise<number> - The follower count of the first matching artist */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/spotify/getSpotifyFollowers.ts` around lines 38 - 43, Remove the stray asterisk in the JSDoc block above the getSpotifyFollowers function so the comment has consistent JSDoc formatting (no blank line caused by a lone "*"); edit the block comment that documents getSpotifyFollowers to remove the extra "*" line and ensure the description, `@param` and `@returns` lines remain intact.lib/mcp/tools/transcribe/registerTranscribeAudioTool.ts (1)
18-21: Incomplete JSDoc documentation.The JSDoc block is essentially empty with no meaningful description for the function or its
serverparameter. Consider adding a description of what this tool registration does.📝 Suggested improvement
-/** - * - * `@param` server - */ +/** + * Registers the transcribe_audio tool with the MCP server. + * Enables audio transcription using OpenAI Whisper with file storage. + * + * `@param` server - The MCP server instance to register the tool with + */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/mcp/tools/transcribe/registerTranscribeAudioTool.ts` around lines 18 - 21, The JSDoc for registerTranscribeAudioTool is empty; update it to describe the purpose (registers a transcribe-audio tool on the given server to handle audio transcription requests, middleware, routes and any config) and document the server parameter (type, expected interface e.g., Express or Fastify server instance, which routes/methods will be used and whether it is mutated). Add `@param` {Type} server and a short `@returns` description if the function returns anything, and include any important side effects or thrown errors.app/api/transcribe/route.ts (1)
5-8: Empty JSDoc provides no value.The JSDoc block is essentially a placeholder with no meaningful description. Per coding guidelines, API routes should have proper JSDoc comments that describe the endpoint's purpose.
📝 Suggested improvement
-/** - * - * `@param` req - */ +/** + * Transcribes audio files using OpenAI Whisper and saves results to storage. + * + * `@param` req - The incoming request containing audio_url, account_id, artist_account_id, and optional title/include_timestamps + * `@returns` JSON response with transcription results or error + */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/api/transcribe/route.ts` around lines 5 - 8, Replace the empty JSDoc block with a concise comment that describes this API route's purpose, the incoming parameter (req: NextRequest/Request), expected request shape (e.g., multipart/form-data audio file or JSON fields), and the response shape/status codes; update the JSDoc immediately above the exported route handler (the function that accepts req) to include `@param` {Request} req and `@returns` {Response} (or appropriate types) and a short summary of behavior (e.g., "Accepts audio upload, transcribes audio, returns transcription JSON or error status").lib/catalog/getCatalogs.ts (1)
11-15: Tighten JSDoc parameter docs for maintainability.Please add a short description for
@param accountIdso the contract is clear in generated docs and editor hovers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/catalog/getCatalogs.ts` around lines 11 - 15, The JSDoc for getCatalogs is missing a description for the accountId param; update the comment block above the exported function getCatalogs(accountId: string) to include a short `@param` description (e.g., "accountId - ID of the account to fetch catalogs for") so generated docs and editor hovers clearly document the contract.lib/transcribe/processAudioTranscription.ts (1)
10-12: JSDoc is a good addition — finish parameter descriptions.Consider adding concise descriptions for
@param paramsand@param contentTypeto make usage intent explicit.Also applies to: 69-72
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/transcribe/processAudioTranscription.ts` around lines 10 - 12, Update the JSDoc for the processAudioTranscription function in lib/transcribe/processAudioTranscription.ts to include concise descriptions for the `@param` entries: describe the structure and purpose of the params object (what keys it contains and which are required) and explain contentType (expected MIME type values, e.g., "audio/wav" or "audio/mpeg", and how it affects processing). Also add any notes about expected types or units (e.g., sample rate, base64 vs raw buffer) and indicate optional vs required fields for clarity.lib/transcribe/saveAudioToFiles.ts (1)
5-8: Nice JSDoc addition — add a briefparamsdescription.A short description of expected fields in
paramswould improve maintainability and editor discoverability.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/transcribe/saveAudioToFiles.ts` around lines 5 - 8, Update the JSDoc for the saveAudioToFiles function to include a brief description of the params object and the expected fields; specifically document the `params` parameter (e.g., list each property used by the function and its type/optional status such as audio data buffer, file name/output path, format/options) so editors and readers can see what keys `params` should contain when calling saveAudioToFiles.lib/credits/getCreditUsage.ts (1)
4-10: Minor: Stray blank line in JSDoc.Line 6 introduces an extra blank
*line in the JSDoc block. While harmless, it creates inconsistent spacing between the description and parameters.📝 Proposed fix
/** * Calculates the total spend in USD for a given language model usage. - * * `@param` usage - The language model usage data * `@param` modelId - The ID of the model used * `@returns` The total spend in USD or 0 if calculation fails */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/credits/getCreditUsage.ts` around lines 4 - 10, The JSDoc for the getCreditUsage function contains a stray blank "*" line between the description and the param list; remove that extra blank JSDoc line so the description, parameter tags (e.g., `@param` usage, `@param` modelId) and return tag sit directly together, ensuring consistent spacing and formatting for the getCreditUsage JSDoc block.lib/github/expandSubmoduleEntries.ts (1)
14-22: Fix invalid JSDoc parameter paths.Line 14 and Lines 18-22 use
@paramnames that don’t map to actual parameters (regularEntries,submoduleEntries,repo), which breaks generated docs and editor hints.Proposed JSDoc cleanup
- * `@param` regularEntries.regularEntries * `@param` regularEntries - Non-submodule file tree entries * `@param` submoduleEntries - Submodule references (type "commit" from GitHub Trees API) * `@param` repo - Repository context for fetching .gitmodules - * `@param` regularEntries.submoduleEntries - * `@param` regularEntries.repo - * `@param` regularEntries.repo.owner - * `@param` regularEntries.repo.repo - * `@param` regularEntries.repo.branch🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/github/expandSubmoduleEntries.ts` around lines 14 - 22, The JSDoc `@param` names in expandSubmoduleEntries are incorrect and don't match the actual function parameters; update the JSDoc to use the real parameter names (regularEntries, submoduleEntries, repo) and their correct nested properties (e.g., repo.owner, repo.repo, repo.branch) instead of invalid paths like regularEntries.regularEntries or repeating `@param` regularEntries; make sure each `@param` line matches the function signature in expandSubmoduleEntries and describes the correct types and fields so editor tooling and generated docs are accurate.lib/supabase/storage/uploadFileByKey.ts (1)
6-11: Consider adding descriptions to JSDoc@paramtags.The JSDoc block now includes
@paramannotations, but they lack descriptions. For better documentation clarity and IDE support, consider adding brief descriptions:-* `@param` key -* `@param` file -* `@param` options -* `@param` options.contentType -* `@param` options.upsert +* `@param` key - The storage path/key for the file +* `@param` file - The file or blob to upload +* `@param` options - Upload configuration options +* `@param` options.contentType - MIME type of the file +* `@param` options.upsert - Whether to overwrite existing files🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/supabase/storage/uploadFileByKey.ts` around lines 6 - 11, The JSDoc for uploadFileByKey is missing descriptions for its `@param` tags; update the JSDoc above the uploadFileByKey function to add brief descriptions for each parameter (key: the storage path or object key to upload to; file: the File/Blob or stream being uploaded; options: optional settings object; options.contentType: MIME type to set for the uploaded file; options.upsert: boolean that controls whether to overwrite existing objects), keeping each `@param` line concise to improve IDE hints and generated docs.lib/supabase/song_artists/insertSongArtists.ts (1)
8-9: JSDoc@paramtag is missing its description.The
@param songArtiststag should include a description for clarity.📝 Suggested fix
* - * `@param` songArtists + * `@param` songArtists - Array of song-artist relationships to insert */🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/supabase/song_artists/insertSongArtists.ts` around lines 8 - 9, The JSDoc for the insertSongArtists function is missing a description for the `@param` songArtists tag; update the JSDoc above the insertSongArtists function (or whichever exported function in lib/supabase/song_artists/insertSongArtists.ts handles inserting song artists) to include a brief description of the parameter (e.g., what songArtists contains, expected type/shape, and any required fields or constraints) so callers and generated docs clearly understand the input.lib/flamingo/getFlamingoPresetsHandler.ts (1)
13-13: JSDoc@paramtag is missing its description.The
@param requesttag was added but lacks a description. For consistency with the existing@returnstag and documentation standards, consider adding a brief description.📝 Suggested fix
- * `@param` request + * `@param` request - The incoming Next.js request object🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/flamingo/getFlamingoPresetsHandler.ts` at line 13, Add a brief description to the JSDoc `@param` request tag in the getFlamingoPresetsHandler function's comment: update the JSDoc block above getFlamingoPresetsHandler (the handler that accepts a request) to describe what the request parameter is (e.g., "the incoming HTTP request" or "the request object containing query/body parameters") so the `@param` request tag is not empty and matches the existing `@returns` documentation style.app/api/songs/analyze/presets/route.ts (1)
31-31: JSDoc@paramtag is missing its description.Same observation as in the handler file - the
@param requesttag should include a description for consistency.📝 Suggested fix
- * `@param` request + * `@param` request - The incoming Next.js request object🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@app/api/songs/analyze/presets/route.ts` at line 31, Update the JSDoc for the route handler so the "@param request" tag includes a short description (e.g., "the incoming Request object containing song data and query params") — locate the JSDoc above the exported handler function in app/api/songs/analyze/presets/route.ts and replace the bare "@param request" with a descriptive "@param request" entry that clearly states what the request represents and any expected shape or usage.lib/supabase/files/createFileRecord.ts (1)
31-31: Rename this operation to match Supabase naming conventions.
createFileRecordbreaks the repo’s Supabase naming standard. Please rename it to aninsert*form (for example,insertFileRecord) to keep operations consistent and discoverable.As per coding guidelines "For Supabase operations, ensure: Follow naming convention: select*, insert*, update*, delete*, get* (for complex queries)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@lib/supabase/files/createFileRecord.ts` at line 31, The function createFileRecord should be renamed to follow Supabase naming conventions—change its declaration and all references to insertFileRecord (update the exported name, function identifier, and any imports/usages across the codebase) and ensure any tests or type exports that reference CreateFileRecordParams or FileRecord remain intact; refactor callers to import/Call insertFileRecord instead of createFileRecord and run the build/tests to confirm no remaining references.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@app/api/accounts/`[id]/route.ts:
- Around line 26-27: The JSDoc contains a redundant/malformed tag "@param
params.params" that conflicts with the correct "@param params - Route params
containing the account ID"; remove the incorrect "@param params.params" tag and,
if you need to document nested properties, replace with proper JSDoc like
"@param {object} params" and "@param {string} params.id" in the same comment
block (look for the JSDoc above the route handler function that references
params).
In `@app/api/coding-agent/`[platform]/route.ts:
- Around line 25-30: The guard around Slack URL verification is too permissive:
change the conditional that checks body?.type === "url_verification" &&
body?.challenge to also assert the challenge is a string (e.g., typeof
body.challenge === "string") so only string challenges are echoed; update the
logic around the body produced by request.clone().json() accordingly and only
return Response.json({ challenge: body.challenge }) when both type is
"url_verification" and challenge is a string.
- Around line 13-14: Remove the malformed "@param params.params" JSDoc entry and
keep a single, correct `@param` that matches the route handler's signature (e.g.,
"@param params - Route params containing the platform name" or "@param
params.platform - The platform name" if you prefer to document the property),
updating the JSDoc block above the route handler in route.ts so the param name
matches the actual function parameter names.
In `@lib/catalog/formatCatalogSongsAsCSV.ts`:
- Around line 9-12: The CSV construction in formatCatalogSongsAsCSV (the
songs.map block) doesn't escape embedded double-quotes or newlines in song.name,
song.album, or artist names; update this mapping to run each field (song.isrc,
song.name, song.album and every artist.name) through an escape helper that
replaces any `"` with `""` and preserves newlines, then wrap the escaped field
in double quotes (or omit quotes for numeric/isrc if desired); build artistNames
by escaping each artist.name before joining, and use those escaped values when
constructing the CSV line so fields with quotes/newlines are valid.
In `@lib/coding-agent/bot.ts`:
- Around line 12-13: The docstring above the bot initialization function in
lib/coding-agent/bot.ts is stale — it only mentions the Slack adapter; update
the comment for the exported bot initialization function (the function that
"Creates a new Chat bot instance configured with the Slack adapter") to
accurately state that it initializes both Slack and GitHub adapters, and adjust
any parameter/return descriptions to mention both adapters and their roles
(e.g., SlackAdapter, GitHubAdapter or adapter initialization) so the docstring
matches the actual behavior.
In `@lib/coding-agent/postGitHubComment.ts`:
- Around line 15-22: In postGitHubComment, guard the token before making the
fetch call: check that the variable token (or process.env.GITHUB_TOKEN if used)
is defined and non-empty and if not, throw or return a clear configuration error
instead of proceeding to the fetch that sets Authorization: `token ${token}`;
update the start of the function (before the fetch call) to validate token and
surface an explicit error message so the external GitHub API is not invoked with
an undefined token.
In `@lib/coding-agent/types.ts`:
- Line 9: Add backward-compatibility for the persisted thread key by keeping the
old property name alongside the new one: add an optional threadId?: string
declaration in the same interface/type where slackThreadId?: string is defined,
and update any state load/deserialization logic to prefer slackThreadId but fall
back to threadId when slackThreadId is absent (ensure reads/assignments
reference slackThreadId and threadId by name).
In `@lib/credits/handleChatCredits.ts`:
- Around line 11-21: The JSDoc for handleChatCredits is malformed: remove the
incorrect nested `@param` lines like `@param usage.usage`, `@param usage.model`,
and `@param usage.accountId`, and replace them with correct, separate `@param`
entries that match the function signature (e.g., `@param usage` describing the
usage object, `@param model` describing the model ID, and `@param accountId`
describing the optional account ID); update descriptions so `usage` documents
its structure (token counts or fields) and `model`/`accountId` are documented as
independent parameters to match the handleChatCredits function.
In `@lib/emails/processAndSendEmail.ts`:
- Around line 63-65: The error message in processAndSendEmail (the error
response building that uses RECOUP_FROM_EMAIL and to.join(", ")) leaks recipient
emails; change the fallback error string to a generic non-PII message (e.g.,
"Failed to send email") instead of including to.join(", "), and ensure any
logging that needs recipients is kept server-side only (use RECOUP_FROM_EMAIL if
you must include sender but avoid including the `to` array in the returned
error).
In `@lib/flamingo/presets/condenseRepetitions.ts`:
- Around line 13-14: The condenseRepetitions function only tokenizes on commas,
so space-delimited runs like "oh oh oh" are ignored; update the tokenization and
rejoin logic in condenseRepetitions to handle both comma+space and plain
whitespace separators (modify the tokens = text.split(...) call to split on
/(?:,\s*|\s+)/ or equivalent) and ensure the subsequent rejoin uses the
appropriate separator (use a single space for space-delimited tokens or
normalize using the same separator logic where the join currently assumes
commas).
In `@lib/github/getRepoFileTree.ts`:
- Around line 42-44: The error log in getRepoFileTree discards repo context;
change the branch where repoResponse.ok is false to include the owner and repo
information (use the owner and repo variables passed into getRepoFileTree) in
the process error message so you log something like "GitHub API error fetching
repo owner/repo: status" (or equivalent) instead of just the status; update the
console.error call referring to repoResponse to include those identifiers to
restore debuggability.
- Around line 53-55: In getRepoFileTree (the tree fetch check where
treeResponse.ok is tested) update the error logging to include the branch/ref
context: when treeResponse is not ok, log the repository + the ref/branch
variable (e.g., ref, branchName or the function's ref parameter) alongside
treeResponse.status so failures can be correlated to the specific branch; locate
the block checking treeResponse.ok and append the ref/branch value to the
console.error message.
In `@lib/github/getRepoGitModules.ts`:
- Around line 6-11: Update the JSDoc for getRepoGitModules to remove the
malformed nested `@param` tags (owner.owner, owner.repo, owner.branch) and replace
them with correctly formatted `@param` entries that match the function's
destructured parameters (owner, repo, branch); ensure each `@param` has a short
description and correct type annotation so IDEs and doc generators parse them
correctly and delete any duplicate or incorrect tags.
In `@lib/github/resolveSubmodulePath.ts`:
- Around line 9-12: The JSDoc for resolveSubmodulePath contains malformed `@param`
annotations; remove the incorrect lines that declare "@param
githubRepo.githubRepo" and "@param githubRepo.path" and keep the correct
parameter docs that describe "githubRepo - The parent GitHub repository URL" and
"path - The file path to resolve" so the JSDoc matches the function signature in
resolveSubmodulePath.
In `@lib/mcp/tools/artistSocials/registerUpdateArtistSocialsTool.ts`:
- Around line 58-59: The handler in registerUpdateArtistSocialsTool currently
returns the raw error.message to callers via getToolResultError, exposing
internal details; change it to always return a generic client-facing message
such as "Failed to update artist socials." while sending the original error to
server logs (use the existing logger or console.error) for diagnostics.
Specifically, in the error catch path that builds errorMessage before calling
getToolResultError, replace the conditional that returns error.message with a
fixed sanitized string and ensure the caught error is logged with the server
logger (e.g., logger.error or console.error) so internals are not leaked to
callers.
In `@lib/mcp/tools/flamingo/registerAnalyzeMusicTool.ts`:
- Around line 53-54: The change currently returns err.message to clients in
registerAnalyzeMusicTool's error path; instead, log the full error (including
stack) internally and return a generic client-safe message via
getToolResultError. Update the catch handling around the Music analysis call
(the block that builds const message = err instanceof Error ? err.message : ...)
to call your logger (e.g., processLogger or console.error) with the full err
object/stack, then call getToolResultError with a non-sensitive message like
"Music analysis failed" (avoid embedding err.message). Ensure you still preserve
the original err for internal diagnostics but do not forward it to the tool
response.
---
Outside diff comments:
In `@app/api/transcribe/route.ts`:
- Around line 9-25: The POST handler currently trusts request body fields and
lacks authentication; call validateAuthContext() at the start of the POST
function to authenticate the request and use the returned auth context to derive
account_id and artist_account_id instead of reading them from the body; remove
extraction/validation of account_id and artist_account_id from req.json(),
validate that validateAuthContext() returns the required ids (or return 401/403
if missing), and keep only audio_url and optional title/include_timestamps from
the body in the function that performs transcription.
In `@lib/coding-agent/mergeGithubBranch.ts`:
- Around line 46-51: The JSON.parse call on errorBody in mergeGithubBranch
(lib/coding-agent/mergeGithubBranch.ts) can throw if the response isn't JSON;
wrap the parse in a try/catch, attempt parsing to extract error.message, and on
failure fall back to using the raw errorBody (or a generic message) so the
function still returns a valid MergeGithubBranchResult { ok: false, message: ...
} instead of throwing; update the code around the errorBody handling and the
return to use the parsed message when available and the raw text otherwise.
In `@lib/github/findOrgReposByAccountId.ts`:
- Around line 16-31: The current fetch in findOrgReposByAccountId only requests
the first page (per_page=100) and can miss repos; change the logic to paginate
the GitHub API by iterating pages (e.g., page=1..N) and accumulate results into
the repos array until a page returns fewer than per_page items or an empty
array; update the fetch call that uses `token`/`Authorization` to include the
`page` query param, merge each page's JSON into the `repos` variable before
applying the existing `filter(repo => repo.name.includes(accountId)).map(repo =>
repo.html_url)`, and ensure you handle non-ok responses per page (log and
exit/return) and respect rate-limit headers if needed.
In `@lib/mcp/tools/registerWebDeepResearchTool.ts`:
- Line 1: Move registerWebDeepResearchTool.ts into a domain subfolder under
lib/mcp/tools (e.g., lib/mcp/tools/research/registerWebDeepResearchTool.ts or
lib/mcp/tools/search/registerWebDeepResearchTool.ts) so it follows the pattern
used by other tools; update any internal imports/exports and paths inside the
file that reference its old location and adjust all call sites or re-exports
that import McpServer or registerWebDeepResearchTool (look for symbol
registerWebDeepResearchTool and the import of McpServer from
"@modelcontextprotocol/sdk/server/mcp.js") to the new module path so builds and
registrations continue to work.
- Around line 27-67: The handler registered in registerWebDeepResearchTool
currently omits authentication and must call resolveAccountId for validation;
update the server.registerTool handler signature to accept the second parameter
(extra), call await resolveAccountId(extra) at the start (before using args),
and proceed only after it returns (use the resolved accountId for any
access-control/audit needs); ensure you don't read accountId directly from
extra.authInfo and keep the rest of the logic (messages validation,
chatWithPerplexity call, citations handling, error handling) unchanged in the
async (args: WebDeepResearchArgs, extra) => { ... } function.
In `@lib/mcp/tools/transcribe/registerTranscribeAudioTool.ts`:
- Around line 8-14: The schema currently accepts account_id directly; remove the
required account_id field from transcribeAudioSchema and instead make account_id
optional to support org-key overrides, then in the tool handler call
resolveAccountId({ authInfo, accountIdOverride: args.account_id }) to derive and
validate the effective account ID from auth; update any references in
registerTranscribeAudioTool.ts to use the resolved accountId (not
args.account_id) for storage/access control and mirror the pattern used in
registerPromptSandboxTool.ts.
---
Nitpick comments:
In `@app/api/songs/analyze/presets/route.ts`:
- Line 31: Update the JSDoc for the route handler so the "@param request" tag
includes a short description (e.g., "the incoming Request object containing song
data and query params") — locate the JSDoc above the exported handler function
in app/api/songs/analyze/presets/route.ts and replace the bare "@param request"
with a descriptive "@param request" entry that clearly states what the request
represents and any expected shape or usage.
In `@app/api/transcribe/route.ts`:
- Around line 5-8: Replace the empty JSDoc block with a concise comment that
describes this API route's purpose, the incoming parameter (req:
NextRequest/Request), expected request shape (e.g., multipart/form-data audio
file or JSON fields), and the response shape/status codes; update the JSDoc
immediately above the exported route handler (the function that accepts req) to
include `@param` {Request} req and `@returns` {Response} (or appropriate types) and
a short summary of behavior (e.g., "Accepts audio upload, transcribes audio,
returns transcription JSON or error status").
In `@lib/ai/isEmbedModel.ts`:
- Around line 6-7: Update the incomplete JSDoc for the isEmbedModel function by
adding a concise description for the `@param` m tag (e.g., "model identifier
string or Model object to check whether it is an embedding model") so the
parameter purpose is clear; edit the JSDoc block above the isEmbedModel function
in lib/ai/isEmbedModel.ts to replace the empty `@param` m with that description
(or remove the tag if you prefer), and ensure the description matches the actual
accepted type/usage of m in the function.
In `@lib/catalog/getCatalogDataAsCSV.ts`:
- Around line 4-8: The JSDoc for getCatalogDataAsCSV is missing a description
for the `@param` catalogId; update the function's JSDoc block in
getCatalogDataAsCSV to add a brief description for the catalogId parameter
(e.g., "catalogId - the ID of the catalog to retrieve songs from") so the param
annotation documents what value is expected and improves maintainability.
In `@lib/catalog/getCatalogs.ts`:
- Around line 11-15: The JSDoc for getCatalogs is missing a description for the
accountId param; update the comment block above the exported function
getCatalogs(accountId: string) to include a short `@param` description (e.g.,
"accountId - ID of the account to fetch catalogs for") so generated docs and
editor hovers clearly document the contract.
In `@lib/coding-agent/parseMergeActionId.ts`:
- Around line 4-6: The JSDoc for parseMergeActionId.ts is missing a description
for the `@param` actionId; update the JSDoc for the parseMergeActionId function to
describe the expected input format (e.g., what shape or example string actionId
should be, whether it can be undefined/null and how it is parsed) mirroring the
style used in parseMergeTestToMainActionId.ts so callers understand the input
contract and edge cases.
In `@lib/coding-agent/parseMergeTestToMainActionId.ts`:
- Around line 4-6: The JSDoc for the parseMergeTestToMainActionId function is
missing a description for the `@param` actionId; update the JSDoc above the
parseMergeTestToMainActionId function to document actionId (e.g., "@param
actionId - The action ID to parse, expected format:
'merge_test_to_main:{owner}/{repo}'") and optionally add a brief `@returns`
description matching the function's output so callers know what is returned.
In `@lib/composio/getCallbackUrl.ts`:
- Around line 20-23: The JSDoc params are out of order in getCallbackUrl: move
the parent param declaration "@param options" to appear before the child
property docs ("@param options.destination" and "@param options.roomId") so the
parent is documented first; update the JSDoc block above the getCallbackUrl
function to list "@param options" (with its description) first, then the
specific option properties in any order, ensuring the tags reference the same
"options" identifier.
In `@lib/credits/getCreditUsage.ts`:
- Around line 4-10: The JSDoc for the getCreditUsage function contains a stray
blank "*" line between the description and the param list; remove that extra
blank JSDoc line so the description, parameter tags (e.g., `@param` usage, `@param`
modelId) and return tag sit directly together, ensuring consistent spacing and
formatting for the getCreditUsage JSDoc block.
In `@lib/emails/processAndSendEmail.ts`:
- Line 38: Add a one-line JSDoc description for the `input` parameter of the
processAndSendEmail function in lib/emails/processAndSendEmail.ts: update the
function's JSDoc block to include an `@param input` entry describing the
shape/purpose of the argument (e.g., what properties it carries such as
recipient, subject, body, and any flags) so generated docs and new contributors
understand what to pass into processAndSendEmail.
In `@lib/flamingo/getFlamingoPresetsHandler.ts`:
- Line 13: Add a brief description to the JSDoc `@param` request tag in the
getFlamingoPresetsHandler function's comment: update the JSDoc block above
getFlamingoPresetsHandler (the handler that accepts a request) to describe what
the request parameter is (e.g., "the incoming HTTP request" or "the request
object containing query/body parameters") so the `@param` request tag is not empty
and matches the existing `@returns` documentation style.
In `@lib/github/expandSubmoduleEntries.ts`:
- Around line 14-22: The JSDoc `@param` names in expandSubmoduleEntries are
incorrect and don't match the actual function parameters; update the JSDoc to
use the real parameter names (regularEntries, submoduleEntries, repo) and their
correct nested properties (e.g., repo.owner, repo.repo, repo.branch) instead of
invalid paths like regularEntries.regularEntries or repeating `@param`
regularEntries; make sure each `@param` line matches the function signature in
expandSubmoduleEntries and describes the correct types and fields so editor
tooling and generated docs are accurate.
In `@lib/mcp/tools/transcribe/registerTranscribeAudioTool.ts`:
- Around line 18-21: The JSDoc for registerTranscribeAudioTool is empty; update
it to describe the purpose (registers a transcribe-audio tool on the given
server to handle audio transcription requests, middleware, routes and any
config) and document the server parameter (type, expected interface e.g.,
Express or Fastify server instance, which routes/methods will be used and
whether it is mutated). Add `@param` {Type} server and a short `@returns`
description if the function returns anything, and include any important side
effects or thrown errors.
In `@lib/prompts/getSystemPrompt.ts`:
- Line 16: The JSDoc for params.orgId in getSystemPrompt (the function defined
in lib/prompts/getSystemPrompt.ts) is missing an explicit description; update
the `@param` params.orgId entry to state that it is the organization identifier
(string) used to select org-specific system prompts and rules, and document that
when orgId is omitted or null the function should fall back to the user's
personal-account defaults (or global default prompt) — mention expected type,
allowed empty/null behavior, and the fallback semantics so callers know how
org-specific vs personal prompts are chosen.
In `@lib/spotify/getSpotifyFollowers.ts`:
- Around line 38-43: Remove the stray asterisk in the JSDoc block above the
getSpotifyFollowers function so the comment has consistent JSDoc formatting (no
blank line caused by a lone "*"); edit the block comment that documents
getSpotifyFollowers to remove the extra "*" line and ensure the description,
`@param` and `@returns` lines remain intact.
In `@lib/supabase/account_artist_ids/getAccountArtistIds.ts`:
- Around line 11-13: Update the JSDoc for the getAccountArtistIds function to
include one-line descriptions for the nested params: add brief descriptions for
params.artistIds (e.g., "array of artist IDs to filter by") and
params.accountIds (e.g., "array of account IDs to filter by") so the generated
docs and call-sites are clearer; ensure these `@param` entries appear under the
existing `@param` params block and follow the same JSDoc style used in other
Supabase functions (brief, present-tense single-line descriptions).
In `@lib/supabase/files/createFileRecord.ts`:
- Line 31: The function createFileRecord should be renamed to follow Supabase
naming conventions—change its declaration and all references to insertFileRecord
(update the exported name, function identifier, and any imports/usages across
the codebase) and ensure any tests or type exports that reference
CreateFileRecordParams or FileRecord remain intact; refactor callers to
import/Call insertFileRecord instead of createFileRecord and run the build/tests
to confirm no remaining references.
In `@lib/supabase/song_artists/insertSongArtists.ts`:
- Around line 8-9: The JSDoc for the insertSongArtists function is missing a
description for the `@param` songArtists tag; update the JSDoc above the
insertSongArtists function (or whichever exported function in
lib/supabase/song_artists/insertSongArtists.ts handles inserting song artists)
to include a brief description of the parameter (e.g., what songArtists
contains, expected type/shape, and any required fields or constraints) so
callers and generated docs clearly understand the input.
In `@lib/supabase/storage/uploadFileByKey.ts`:
- Around line 6-11: The JSDoc for uploadFileByKey is missing descriptions for
its `@param` tags; update the JSDoc above the uploadFileByKey function to add
brief descriptions for each parameter (key: the storage path or object key to
upload to; file: the File/Blob or stream being uploaded; options: optional
settings object; options.contentType: MIME type to set for the uploaded file;
options.upsert: boolean that controls whether to overwrite existing objects),
keeping each `@param` line concise to improve IDE hints and generated docs.
In `@lib/transcribe/processAudioTranscription.ts`:
- Around line 10-12: Update the JSDoc for the processAudioTranscription function
in lib/transcribe/processAudioTranscription.ts to include concise descriptions
for the `@param` entries: describe the structure and purpose of the params object
(what keys it contains and which are required) and explain contentType (expected
MIME type values, e.g., "audio/wav" or "audio/mpeg", and how it affects
processing). Also add any notes about expected types or units (e.g., sample
rate, base64 vs raw buffer) and indicate optional vs required fields for
clarity.
In `@lib/transcribe/saveAudioToFiles.ts`:
- Around line 5-8: Update the JSDoc for the saveAudioToFiles function to include
a brief description of the params object and the expected fields; specifically
document the `params` parameter (e.g., list each property used by the function
and its type/optional status such as audio data buffer, file name/output path,
format/options) so editors and readers can see what keys `params` should contain
when calling saveAudioToFiles.
In `@lib/transcribe/types.ts`:
- Around line 59-60: Update the JSDoc for the parameter named "error" in
lib/transcribe/types.ts to clearly state that "error" is the error object or
value returned/raised during transcription (e.g., Error | string | unknown),
describe what it represents (the failure cause from the transcription process),
note whether it can be null/undefined or a serialized error, and explain how
callers should handle or log it (e.g., contains message and optional stack).
Target the existing JSDoc `@param` error tag and replace the placeholder with this
concise description so readers know the expected type and semantics.
Comment on lines
+26
to
27
| * @param params.params | ||
| * @param params - Route params containing the account ID |
There was a problem hiding this comment.
Duplicate/confusing JSDoc @param tags.
Line 26 adds @param params.params which is incorrectly formatted and redundant with line 27's @param params - Route params containing the account ID. The params.params syntax doesn't follow JSDoc conventions for nested properties (which would be @param {object} params followed by @param {string} params.id).
📝 Suggested fix - remove the redundant tag
* `@param` request - The request object
- * `@param` params.params
* `@param` params - Route params containing the account ID
* `@returns` A NextResponse with account data📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| * @param params.params | |
| * @param params - Route params containing the account ID | |
| * `@param` request - The request object | |
| * `@param` params - Route params containing the account ID | |
| * `@returns` A NextResponse with account data |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@app/api/accounts/`[id]/route.ts around lines 26 - 27, The JSDoc contains a
redundant/malformed tag "@param params.params" that conflicts with the correct
"@param params - Route params containing the account ID"; remove the incorrect
"@param params.params" tag and, if you need to document nested properties,
replace with proper JSDoc like "@param {object} params" and "@param {string}
params.id" in the same comment block (look for the JSDoc above the route handler
function that references params).
Comment on lines
+13
to
14
| * @param params.params | ||
| * @param params - Route params containing the platform name |
There was a problem hiding this comment.
Fix the malformed JSDoc param reference.
@param params.params is unclear and does not map cleanly to the actual handler signature context.
✏️ Suggested doc fix
- * `@param` params.params
- * `@param` params - Route params containing the platform name
+ * `@param` context - Route context
+ * `@param` context.params - Route params containing the platform name🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@app/api/coding-agent/`[platform]/route.ts around lines 13 - 14, Remove the
malformed "@param params.params" JSDoc entry and keep a single, correct `@param`
that matches the route handler's signature (e.g., "@param params - Route params
containing the platform name" or "@param params.platform - The platform name" if
you prefer to document the property), updating the JSDoc block above the route
handler in route.ts so the param name matches the actual function parameter
names.
Comment on lines
+25
to
30
| const body = await request | ||
| .clone() | ||
| .json() | ||
| .catch(() => null); | ||
| if (body?.type === "url_verification" && body?.challenge) { | ||
| return Response.json({ challenge: body.challenge }); |
There was a problem hiding this comment.
Keep URL verification strict on challenge type.
The current guard accepts any truthy challenge, which can echo non-string payloads. Keep it string-validated.
🛡️ Suggested fix
- if (body?.type === "url_verification" && body?.challenge) {
+ if (body?.type === "url_verification" && typeof body?.challenge === "string") {
return Response.json({ challenge: body.challenge });
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@app/api/coding-agent/`[platform]/route.ts around lines 25 - 30, The guard
around Slack URL verification is too permissive: change the conditional that
checks body?.type === "url_verification" && body?.challenge to also assert the
challenge is a string (e.g., typeof body.challenge === "string") so only string
challenges are echoed; update the logic around the body produced by
request.clone().json() accordingly and only return Response.json({ challenge:
body.challenge }) when both type is "url_verification" and challenge is a
string.
Comment on lines
+9
to
12
| const csvLines = songs.map(song => { | ||
| const artistNames = song.artists.map(artist => artist.name).join(", "); | ||
| return `${song.isrc},"${song.name}","${song.album}","${artistNames}"`; | ||
| }); |
There was a problem hiding this comment.
Consider escaping CSV special characters.
The current implementation wraps fields in double quotes, but doesn't escape embedded double quotes or handle newlines within field values. If song.name, song.album, or artist names contain " characters, the resulting CSV will be malformed.
🛡️ Suggested fix for proper CSV escaping
+const escapeCSV = (value: string) => value.replace(/"/g, '""');
+
export function formatCatalogSongsAsCSV(songs: CatalogSong[]): string {
const csvLines = songs.map(song => {
- const artistNames = song.artists.map(artist => artist.name).join(", ");
- return `${song.isrc},"${song.name}","${song.album}","${artistNames}"`;
+ const artistNames = song.artists.map(artist => artist.name).join(", ");
+ return `${song.isrc},"${escapeCSV(song.name)}","${escapeCSV(song.album)}","${escapeCSV(artistNames)}"`;
});🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@lib/catalog/formatCatalogSongsAsCSV.ts` around lines 9 - 12, The CSV
construction in formatCatalogSongsAsCSV (the songs.map block) doesn't escape
embedded double-quotes or newlines in song.name, song.album, or artist names;
update this mapping to run each field (song.isrc, song.name, song.album and
every artist.name) through an escape helper that replaces any `"` with `""` and
preserves newlines, then wrap the escaped field in double quotes (or omit quotes
for numeric/isrc if desired); build artistNames by escaping each artist.name
before joining, and use those escaped values when constructing the CSV line so
fields with quotes/newlines are valid.
Comment on lines
+12
to
13
| * Creates a new Chat bot instance configured with the Slack adapter. | ||
| */ |
There was a problem hiding this comment.
Docstring is inaccurate after the adapter refactor.
The function initializes both Slack and GitHub adapters, so the description should reflect both.
✏️ Suggested doc fix
- * Creates a new Chat bot instance configured with the Slack adapter.
+ * Creates a new Chat bot instance configured with Slack and GitHub adapters.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| * Creates a new Chat bot instance configured with the Slack adapter. | |
| */ | |
| * Creates a new Chat bot instance configured with Slack and GitHub adapters. | |
| */ |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@lib/coding-agent/bot.ts` around lines 12 - 13, The docstring above the bot
initialization function in lib/coding-agent/bot.ts is stale — it only mentions
the Slack adapter; update the comment for the exported bot initialization
function (the function that "Creates a new Chat bot instance configured with the
Slack adapter") to accurately state that it initializes both Slack and GitHub
adapters, and adjust any parameter/return descriptions to mention both adapters
and their roles (e.g., SlackAdapter, GitHubAdapter or adapter initialization) so
the docstring matches the actual behavior.
Comment on lines
53
to
55
| if (!treeResponse.ok) { | ||
| console.error(`GitHub API error fetching tree for ${repoInfo.owner}/${repoInfo.repo}@${defaultBranch}: ${treeResponse.status}`); | ||
| console.error(`GitHub API error fetching tree: ${treeResponse.status}`); | ||
| return null; |
There was a problem hiding this comment.
Same concern: restore branch context for tree fetch errors.
Including the branch name helps distinguish failures across different refs of the same repository.
🔍 Suggested fix
if (!treeResponse.ok) {
- console.error(`GitHub API error fetching tree: ${treeResponse.status}`);
+ console.error(`GitHub API error fetching tree for ${repoInfo.owner}/${repoInfo.repo}@${defaultBranch}: ${treeResponse.status}`);
return null;
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| if (!treeResponse.ok) { | |
| console.error(`GitHub API error fetching tree for ${repoInfo.owner}/${repoInfo.repo}@${defaultBranch}: ${treeResponse.status}`); | |
| console.error(`GitHub API error fetching tree: ${treeResponse.status}`); | |
| return null; | |
| if (!treeResponse.ok) { | |
| console.error(`GitHub API error fetching tree for ${repoInfo.owner}/${repoInfo.repo}@${defaultBranch}: ${treeResponse.status}`); | |
| return null; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@lib/github/getRepoFileTree.ts` around lines 53 - 55, In getRepoFileTree (the
tree fetch check where treeResponse.ok is tested) update the error logging to
include the branch/ref context: when treeResponse is not ok, log the repository
+ the ref/branch variable (e.g., ref, branchName or the function's ref
parameter) alongside treeResponse.status so failures can be correlated to the
specific branch; locate the block checking treeResponse.ok and append the
ref/branch value to the console.error message.
Comment on lines
+6
to
+11
| * @param owner.owner | ||
| * @param owner - The GitHub repository owner | ||
| * @param repo - The GitHub repository name | ||
| * @param branch - The branch to fetch from | ||
| * @param owner.repo | ||
| * @param owner.branch |
There was a problem hiding this comment.
Malformed JSDoc parameter documentation.
The @param tags appear incorrectly formatted. The function uses destructured parameters (owner, repo, branch), not nested object properties. @param owner.owner, @param owner.repo, and @param owner.branch are syntactically incorrect and will confuse IDEs/documentation generators.
📝 Proposed fix for JSDoc
/**
* Fetches and parses .gitmodules from a GitHub repository.
*
- * `@param` owner.owner
* `@param` owner - The GitHub repository owner
* `@param` repo - The GitHub repository name
* `@param` branch - The branch to fetch from
- * `@param` owner.repo
- * `@param` owner.branch
* `@returns` Array of submodule entries, or null if .gitmodules doesn't exist or fetch fails
*/📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| * @param owner.owner | |
| * @param owner - The GitHub repository owner | |
| * @param repo - The GitHub repository name | |
| * @param branch - The branch to fetch from | |
| * @param owner.repo | |
| * @param owner.branch | |
| /** | |
| * Fetches and parses .gitmodules from a GitHub repository. | |
| * | |
| * `@param` owner - The GitHub repository owner | |
| * `@param` repo - The GitHub repository name | |
| * `@param` branch - The branch to fetch from | |
| * `@returns` Array of submodule entries, or null if .gitmodules doesn't exist or fetch fails | |
| */ |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@lib/github/getRepoGitModules.ts` around lines 6 - 11, Update the JSDoc for
getRepoGitModules to remove the malformed nested `@param` tags (owner.owner,
owner.repo, owner.branch) and replace them with correctly formatted `@param`
entries that match the function's destructured parameters (owner, repo, branch);
ensure each `@param` has a short description and correct type annotation so IDEs
and doc generators parse them correctly and delete any duplicate or incorrect
tags.
Comment on lines
+9
to
+12
| * @param githubRepo.githubRepo | ||
| * @param githubRepo - The parent GitHub repository URL | ||
| * @param path - The file path to resolve | ||
| * @param githubRepo.path |
There was a problem hiding this comment.
Malformed JSDoc parameter annotations.
The added @param entries are incorrect:
@param githubRepo.githubRepoimplies a nested property that doesn't exist@param githubRepo.pathis misplaced —pathis a sibling parameter, not nested undergithubRepo
The original documentation on lines 10-11 already correctly describes these parameters. Remove the stray lines 9 and 12.
📝 Proposed fix
/**
* Resolves a file path that may be inside a git submodule.
* If the path falls within a submodule, returns the submodule's repo URL
* and the relative path within it. Otherwise returns the original values.
*
- * `@param` githubRepo.githubRepo
* `@param` githubRepo - The parent GitHub repository URL
* `@param` path - The file path to resolve
- * `@param` githubRepo.path
* `@returns` The resolved repo URL and path
*/📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| * @param githubRepo.githubRepo | |
| * @param githubRepo - The parent GitHub repository URL | |
| * @param path - The file path to resolve | |
| * @param githubRepo.path | |
| /** | |
| * Resolves a file path that may be inside a git submodule. | |
| * If the path falls within a submodule, returns the submodule's repo URL | |
| * and the relative path within it. Otherwise returns the original values. | |
| * | |
| * `@param` githubRepo - The parent GitHub repository URL | |
| * `@param` path - The file path to resolve | |
| * `@returns` The resolved repo URL and path | |
| */ |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@lib/github/resolveSubmodulePath.ts` around lines 9 - 12, The JSDoc for
resolveSubmodulePath contains malformed `@param` annotations; remove the incorrect
lines that declare "@param githubRepo.githubRepo" and "@param githubRepo.path"
and keep the correct parameter docs that describe "githubRepo - The parent
GitHub repository URL" and "path - The file path to resolve" so the JSDoc
matches the function signature in resolveSubmodulePath.
Comment on lines
+58
to
59
| error instanceof Error ? error.message : "Failed to update artist socials."; | ||
| return getToolResultError(errorMessage); |
There was a problem hiding this comment.
Return sanitized errors from MCP tool handlers.
Line 58/Line 59 can expose internal exception text to callers. Prefer a generic client-facing message and keep specifics in server logs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@lib/mcp/tools/artistSocials/registerUpdateArtistSocialsTool.ts` around lines
58 - 59, The handler in registerUpdateArtistSocialsTool currently returns the
raw error.message to callers via getToolResultError, exposing internal details;
change it to always return a generic client-facing message such as "Failed to
update artist socials." while sending the original error to server logs (use the
existing logger or console.error) for diagnostics. Specifically, in the error
catch path that builds errorMessage before calling getToolResultError, replace
the conditional that returns error.message with a fixed sanitized string and
ensure the caught error is logged with the server logger (e.g., logger.error or
console.error) so internals are not leaked to callers.
Comment on lines
+53
to
54
| const message = err instanceof Error ? err.message : "Flamingo inference failed"; | ||
| return getToolResultError(`Music analysis failed: ${message}`); |
There was a problem hiding this comment.
Avoid exposing raw internal error messages to tool clients.
Line 53/Line 54 currently forwards err.message directly. That can leak internals (provider details, stack-context fragments, etc.). Return a generic client-safe error and keep detailed diagnostics in logs.
Suggested hardening
- } catch (err) {
- const message = err instanceof Error ? err.message : "Flamingo inference failed";
- return getToolResultError(`Music analysis failed: ${message}`);
+ } catch (err) {
+ console.error("analyze_music failed:", err);
+ return getToolResultError("Music analysis failed");
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@lib/mcp/tools/flamingo/registerAnalyzeMusicTool.ts` around lines 53 - 54, The
change currently returns err.message to clients in registerAnalyzeMusicTool's
error path; instead, log the full error (including stack) internally and return
a generic client-safe message via getToolResultError. Update the catch handling
around the Music analysis call (the block that builds const message = err
instanceof Error ? err.message : ...) to call your logger (e.g., processLogger
or console.error) with the full err object/stack, then call getToolResultError
with a non-sensitive message like "Music analysis failed" (avoid embedding
err.message). Ensure you still preserve the original err for internal
diagnostics but do not forward it to the tool response.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated PR from coding agent.
Summary by CodeRabbit
Bug Fixes
Removed Features
Chores