feat(admin): configurable core plugins with auto-install

[seanhanca]

Summary

Changes

Type

• Feature
• Bug fix
• Refactor
• Documentation
• CI / Tooling
• Plugin (new or update)
• Dependencies

Plugin(s) Affected

Checklist

• Tests pass locally
• Lint passes (npm run lint)
• Build succeeds (npm run build)
• No new lint warnings introduced
• Breaking changes documented below
• Database migration included (if Prisma schema changed)

Breaking Changes

None

Screenshots / Recordings

Summary by CodeRabbit

Release Notes

• New Features

  • Added admin panel for managing core plugins with a dedicated configuration interface.
  • Implemented dynamic core plugin system with database-driven configuration.
  • Added visual indicators and shields for core plugins that cannot be uninstalled.

• Bug Fixes

  • Fixed core plugin uninstall protection at UI and API levels.

• Dependencies

  • Updated testing framework to latest versions.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
naap-platform	Ready	Preview, Comment	Feb 10, 2026 7:12pm

[github-actions]

⚠️ This PR is very large (2344 lines changed). Please split it into smaller, focused PRs if possible.

[seanhanca]

@coderabbitai review

[coderabbitai]

✅ 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]

📝 Walkthrough

Walkthrough

PR introduces admin plugin management system with core plugin configuration endpoints and UI page. Refactors hardcoded core plugin lists to dynamic database lookups. Updates Vitest dependencies to 4.x, enhances CLI defaults and type safety, adds new AI completion options, and extends plugin type definitions.

Changes

Cohort / File(s)	Summary
Admin Plugin Management UI & API apps/web-next/src/app/(dashboard)/admin/plugins/page.tsx, apps/web-next/src/app/api/v1/admin/plugins/core/route.ts, apps/web-next/src/components/admin/AdminNav.tsx	New admin page for viewing and configuring core plugins with search/filtering UI; new GET/PUT API endpoints with admin auth validation, core status persistence, and auto-installation of newly core plugins for all users; admin navigation updated with Plugins tab.
Plugin Core Status System Refactoring apps/web-next/src/app/(dashboard)/settings/page.tsx, apps/web-next/src/app/api/v1/base/plugins/personalized/route.ts, apps/web-next/src/app/api/v1/base/plugins/preferences/route.ts, apps/web-next/src/app/api/v1/installations/[name]/route.ts	Replaces hardcoded CORE\_PLUGINS lists with dynamic database lookups (PluginPackage.isCore); adds isCore and installed flags to plugin objects; prevents uninstall of core plugins at UI and API levels; auto-creates user preferences for core plugins.
Testing Framework & Test Updates apps/web-next/package.json, apps/web-next/vitest.config.ts, apps/web-next/src/hooks/__tests__/\\*, apps/web-next/src/lib/plugins/__tests__/integration.test.ts	Upgrades Vitest from 2.x to 4.x with coverage v8; updates retry tests to use fake timers and manual flush instead of waitFor; refactors async token handling and logger assertions; adds coverage directory configuration.
CLI & Package Management Improvements packages/plugin-sdk/cli/commands/create.ts, packages/plugin-sdk/cli/commands/dev.ts, packages/plugin-sdk/cli/commands/github.ts, packages/plugin-sdk/cli/commands/package.ts, packages/plugin-sdk/cli/index.ts, packages/plugin-sdk/package.json	Renames Tool category to Developer Tools; adds defaults for plugin name, template, manifest fields; strengthens type safety with CreateAnswers interface; replaces skipMfValidation with skipBundleValidation; refactors build command to factory function; adds @inquirer/prompts dependency.
Plugin SDK Type & Service Enhancements packages/plugin-sdk/src/types/services.ts, packages/plugin-sdk/src/integrations/email/sendgrid.ts, packages/plugin-sdk/src/utils/api.ts, packages/types/src/plugin.ts	Adds stopSequences option to AICompletionOptions; introduces email options converter for SendGrid recipient objects; aliases internal import for API service origin; extends RuntimePlugin with isCore and installed boolean flags.

Sequence Diagram(s)

sequenceDiagram
    participant Admin as Admin User
    participant Page as Admin Plugins Page
    participant API as Admin Core Plugins API
    participant DB as Database
    participant Prefs as User Preferences

    Admin->>Page: Access /admin/plugins
    Page->>API: GET /api/v1/admin/plugins/core
    API->>DB: Fetch all plugins with isCore status
    DB-->>API: Plugin list
    API-->>Page: Return plugins
    Page->>Page: Display Core & Available sections
    
    Admin->>Page: Toggle plugin isCore flag
    Page->>Page: Mark as pending change
    
    Admin->>Page: Click "Save Changes"
    Page->>API: PUT /api/v1/admin/plugins/core (corePluginNames)
    API->>DB: Update PluginPackage.isCore
    API->>DB: Identify newly added core plugins
    API->>Prefs: Create UserPluginPreference for all users (auto-install)
    DB-->>API: Updated plugins
    Prefs-->>API: Success
    API-->>Page: Return updated plugins & auto-installed list
    Page->>Page: Display success message
    Page->>Page: Refresh plugin display
    Page-->>Admin: Changes saved

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~70 minutes

Poem

🐰 A warren of plugins, once hardcoded in stone,
Now blossom through databases—seeds fully grown!
With admins at the helm and defaults in place,
The plugin ecosystem hops into space! 🌟✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main feature: allowing administrators to configure which plugins are core and implementing automatic installation for those plugins.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/core/admin-can-config-core-plugins

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 4

Caution

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

⚠️ Outside diff range comments (3)

packages/plugin-sdk/cli/commands/package.ts (1)

85-95: ⚠️ Potential issue | 🟠 Major

Add a deprecated alias for the old flag to avoid breaking CLI users.

Renaming --skip-mf-validation to --skip-bundle-validation will break existing scripts. Consider keeping the old flag as a deprecated alias and mapping both to the same behavior.

Proposed compatibility shim

 export const packageCommand = new Command('package')
   .description('Create distributable plugin package')
   .option('-o, --output <dir>', 'Output directory', 'dist')
   .option('--format <format>', 'Package format (tar, zip, oci)', 'zip')
   .option('--no-validate', 'Skip manifest validation')
   .option('--skip-bundle-validation', 'Skip UMD bundle validation')
+  .option('--skip-mf-validation', 'Deprecated: use --skip-bundle-validation')
   .action(async (options: {
     output: string;
     format: string;
     validate: boolean;
     skipBundleValidation?: boolean;
+    skipMfValidation?: boolean;
   }) => {
+    const skipBundleValidation = options.skipBundleValidation ?? options.skipMfValidation;
     const cwd = process.cwd();
     const manifestPath = path.join(cwd, 'plugin.json');
@@
-      if (manifest.frontend && !options.skipBundleValidation) {
+      if (manifest.frontend && !skipBundleValidation) {

Also applies to: 163-163

packages/plugin-sdk/cli/commands/create.ts (1)

55-113: ⚠️ Potential issue | 🟡 Minor

The when callback parameter should use Partial<CreateAnswers> instead of CreateAnswers.

Inquirer v9 does support generic answer typing (inquirer.prompt<T>()) and the when callback is correctly used here. However, per the @types/inquirer type definitions, the callback parameter should be typed as Partial<CreateAnswers> to reflect that not all answer properties are available when the callback executes:

when: (ans: Partial<CreateAnswers>) => 
  (ans.template || options?.template) !== 'frontend-only',

This is a minor type precision issue; the code will function correctly even without this change since TypeScript strict mode is disabled in the project configuration.

apps/web-next/src/app/api/v1/installations/[name]/route.ts (1)

27-45: ⚠️ Potential issue | 🟡 Minor

Move core plugin check after authentication.

The core plugin check (lines 27-34) executes before authentication validation (lines 36-45). This allows unauthenticated requests to probe which plugins are marked as core by observing different error messages ("Core plugins cannot be uninstalled" vs "Authentication required").

For consistency with preferences/route.ts and to avoid information disclosure, perform authentication first.

🔒 Proposed fix

 export async function DELETE(
   request: NextRequest,
   { params }: { params: Promise<{ name: string }> }
 ) {
   try {
     const { name } = await params;

     if (!name) {
       return errors.badRequest('Plugin name is required');
     }

-    // Check if this plugin is a core plugin (admin-configurable in PluginPackage)
-    const pkg = await prisma.pluginPackage.findFirst({
-      where: { name },
-      select: { isCore: true },
-    });
-    if (pkg?.isCore) {
-      return errors.badRequest('Core plugins cannot be uninstalled');
-    }
-
     // Get authenticated user
     const token = getAuthToken(request);
     if (!token) {
       return errors.unauthorized('Authentication required');
     }

     const user = await validateSession(token);
     if (!user) {
       return errors.unauthorized('Invalid session');
     }

+    // Check if this plugin is a core plugin (admin-configurable in PluginPackage)
+    const pkg = await prisma.pluginPackage.findFirst({
+      where: { name },
+      select: { isCore: true },
+    });
+    if (pkg?.isCore) {
+      return errors.badRequest('Core plugins cannot be uninstalled');
+    }
+
     // Remove user preference for this plugin (truly delete, not just disable)

🤖 Fix all issues with AI agents

In `@apps/web-next/package.json`:
- Line 62: Add an explicit coverage.include pattern in vitest.config.ts so
coverage reports include all intended files (e.g., add a glob for your src
and/or app files under coverage.include), and update test setup cleanup in
src/__tests__/setup.ts: keep vi.restoreAllMocks() for manual spies and add
vi.resetModules() (or change to vi.resetAllMocks()/vi.resetModules()
combination) to properly reset automocks between tests; locate and modify the
vitest config and the setup file where vi.restoreAllMocks() is called to
implement these changes.

In `@apps/web-next/src/app/api/v1/base/plugins/personalized/route.ts`:
- Around line 200-232: The GET handler currently mutates state by auto-creating
preferences (corePluginsToAutoInstall, prisma.userPluginPreference.createMany,
and updating preferencesMap); remove that side-effect from this GET route and
instead implement a dedicated non-GET flow: extract the auto-install logic into
a new POST endpoint (e.g., POST /api/v1/base/plugins/sync-core) or move it into
the existing admin/user PUT workflow invoked at login, keeping the same creation
payload (userId, pluginName, enabled, order, pinned) and skipDuplicates
behavior; update the GET handler to only read from preferencesMap and
globalPlugins and call the new POST/PUT flow from the login sequence or admin
sync job as appropriate.

In `@packages/plugin-sdk/cli/commands/github.ts`:
- Around line 223-226: Update the transformer callback passed to the input(...)
call that populates the token variable so it matches `@inquirer/prompts` v8.x
signature; change the transformer in the input invocation (the anonymous
function currently declared as transformer: (value: string) => ...) to accept
the second meta parameter (meta: { isFinal: boolean }) and use both params,
e.g., transformer: (value: string, meta: { isFinal: boolean }) =>
'*'.repeat(value.length), so the input(...) call aligns with the new API.

In `@packages/plugin-sdk/src/integrations/email/sendgrid.ts`:
- Around line 87-102: The sendTemplate path is passing EmailRecipient objects
directly into SendGrid fields (options.from / options.replyTo) instead of
normalized strings; reuse the existing convertOptions method inside sendTemplate
to map options to plain string fields before building the SendGrid payload.
Update sendTemplate to call this.convertOptions(options) and use its returned
from/replyTo (and cc/bcc if applicable) when constructing the template email so
SendGrid receives string addresses rather than objects.

🧹 Nitpick comments (8)

packages/plugin-sdk/cli/commands/dev.ts (1)

52-53: Restore a typed process handle instead of any.

Using any here removes type safety for .kill() and stream access. Consider a type-only alias to Execa’s child process type and drop the lint override.

♻️ Proposed refactor

-// eslint-disable-next-line `@typescript-eslint/no-explicit-any`
-const processes: { name: string; process: any }[] = [];
+type ExecaChildProcess = import('execa').ExecaChildProcess;
+const processes: { name: string; process: ExecaChildProcess }[] = [];

apps/web-next/src/lib/plugins/__tests__/integration.test.ts (1)

174-176: Avoid brittle logger assertion on extra args.
Pinning an explicit undefined second param can make the test fail if the logger starts emitting metadata. Consider asserting just the first argument.

✅ Suggested adjustment

-    expect(mockContext.logger.info).toHaveBeenCalledWith('[my-plugin] test message', undefined);
+    const [msg] = mockContext.logger.info.mock.calls[0] ?? [];
+    expect(msg).toBe('[my-plugin] test message');

apps/web-next/src/hooks/__tests__/useJobFeedStream.test.ts (1)

143-164: Move timer cleanup to afterEach for test reliability.

If this test fails before reaching vi.useRealTimers() on line 163, fake timers remain active for subsequent tests, potentially causing flaky failures. Since afterEach is already imported on line 5, use it for cleanup:

♻️ Proposed refactor to use afterEach for timer cleanup

Add an afterEach block after beforeEach:

afterEach(() => {
  vi.useRealTimers();
});

Then remove lines 162-163 from within the test:

     expect(result.current.error!.type).toBe('no-provider');
     expect(result.current.connected).toBe(false);
-
-    vi.useRealTimers();
   });

apps/web-next/src/hooks/__tests__/useDashboardQuery.test.ts (1)

76-97: Move timer cleanup to afterEach for test reliability.

Same issue as in useJobFeedStream.test.ts: if this test fails before reaching vi.useRealTimers() on line 96, fake timers remain active for subsequent tests. Unlike the sibling test file, afterEach is not imported here.

♻️ Proposed refactor to add afterEach cleanup

Update the import on line 5:

-import { describe, it, expect, vi, beforeEach } from 'vitest';
+import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';

Add an afterEach block after beforeEach:

afterEach(() => {
  vi.useRealTimers();
});

Then remove lines 95-96 from within the test:

     expect(result.current.data).toBeNull();
-
-    vi.useRealTimers();
   });

apps/web-next/src/app/api/v1/base/plugins/preferences/route.ts (1)

15-22: Consider extracting isCorePlugin to a shared utility.

This helper is duplicated across multiple route files (preferences/route.ts, installations/[name]/route.ts, and inline in personalized/route.ts). Extracting it to a shared module (e.g., @/lib/plugins/core.ts) would improve maintainability and ensure consistent behavior.

♻️ Suggested shared utility

// apps/web-next/src/lib/plugins/core.ts
import { prisma } from '@/lib/db';

export async function isCorePlugin(pluginName: string): Promise<boolean> {
  const pkg = await prisma.pluginPackage.findFirst({
    where: { name: pluginName },
    select: { isCore: true },
  });
  return pkg?.isCore ?? false;
}

Then import and use in each route file.

apps/web-next/src/app/api/v1/admin/plugins/core/route.ts (1)

106-133: Performance concern: Auto-install loop may not scale well.

For large user bases, this implementation has performance issues:

1. prisma.user.findMany() (line 108) loads all users into memory
2. For each newly core plugin, a separate query fetches existing preferences (N+1 pattern)

For production systems with many users, consider using a single SQL statement or batched processing.

♻️ Suggested optimization using raw SQL or batched approach

     // Auto-install newly-core plugins for all existing users who don't have them
     if (newlyCore.length > 0) {
-      const allUsers = await prisma.user.findMany({ select: { id: true } });
-
-      for (const pluginName of newlyCore) {
-        // Find users who already have a preference for this plugin
-        const existingPrefs = await prisma.userPluginPreference.findMany({
-          where: { pluginName },
-          select: { userId: true },
-        });
-        const usersWithPref = new Set(existingPrefs.map((p) => p.userId));
-
-        // Create preferences for users who don't have one
-        const missingUsers = allUsers.filter((u) => !usersWithPref.has(u.id));
-        if (missingUsers.length > 0) {
-          await prisma.userPluginPreference.createMany({
-            data: missingUsers.map((u) => ({
-              userId: u.id,
-              pluginName,
-              enabled: true,
-              order: 0,
-              pinned: false,
-            })),
-            skipDuplicates: true,
-          });
-        }
-      }
+      // Batch insert for all newly-core plugins using a single query per plugin
+      for (const pluginName of newlyCore) {
+        await prisma.$executeRaw`
+          INSERT INTO "UserPluginPreference" ("id", "userId", "pluginName", "enabled", "order", "pinned", "createdAt", "updatedAt")
+          SELECT gen_random_uuid(), u.id, ${pluginName}, true, 0, false, NOW(), NOW()
+          FROM "User" u
+          WHERE NOT EXISTS (
+            SELECT 1 FROM "UserPluginPreference" upp
+            WHERE upp."userId" = u.id AND upp."pluginName" = ${pluginName}
+          )
+        `;
+      }
     }

Note: Adjust table/column names to match your actual Prisma schema.

apps/web-next/src/app/(dashboard)/admin/plugins/page.tsx (2)

57-63: Add loadPlugins to useEffect dependency array or suppress warning.

The loadPlugins function is called in the effect but not listed in the dependency array. While loadPlugins is wrapped in useCallback with an empty dependency array (making it stable), the linter will flag this.

♻️ Suggested fix

   useEffect(() => {
     if (!isAdmin) {
       router.push('/dashboard');
       return;
     }
     loadPlugins();
-  }, [isAdmin]);
+  }, [isAdmin, loadPlugins]);

Since loadPlugins has useCallback with [] deps, adding it won't cause re-renders.

---

93-122: Consider adding a confirmation dialog before saving.

Marking a plugin as core auto-installs it for all users in the system. Given this significant impact, a confirmation dialog would help prevent accidental changes.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Vitest 4.0 breaking changes migration guide

💡 Result:

Vitest 4.0 migration (breaking changes checklist)

1. Coverage defaults changed (biggest “gotcha”)

   • V8 coverage remapping changed (more accurate) → expect different numbers.
   • Removed: coverage.ignoreEmptyLines, coverage.experimentalAstAwareRemapping.
   • Removed: coverage.all and coverage.extensions; by default v4 reports only covered files. You should now set coverage.include explicitly (and then coverage.exclude as needed). [1]

2. Test file exclude defaults are simpler

   • By default, Vitest now mainly excludes only node_modules and .git. If you relied on automatic excludes like dist/, you must add them back or use test.dir for better performance. [1]

3. Pool/worker config rework

   • maxThreads / maxForks → maxWorkers
   • singleThread / singleFork → maxWorkers: 1, isolate: false (and add vi.resetModules() in a setup file if you relied on module resets)
   • poolOptions removed; options moved top-level; vmThreads.memoryLimit → vmMemoryLimit
   • Env vars: VITEST_MAX_THREADS / VITEST_MAX_FORKS → VITEST_MAX_WORKERS [1]

4. Workspace/projects

   • workspace is replaced by projects (and you can’t point to an external workspace file the old way—move it into vitest.config.*). [1]

5. Browser Mode provider changes

   • Browser provider config now uses provider factories (and preview is no longer the default).
   • @vitest/browser can be removed; migrate imports:
     • @vitest/browser/context → vitest/browser
     • @vitest/browser/utils → vitest/browser (utils) [1]

6. Reporter breaking changes

   • Removed reporter hooks: onCollected, onSpecsCollected, onPathsCollected, onTaskUpdate, onFinished (use the newer reporter APIs).
   • basic reporter removed (use ['default', { summary: false }]).
   • verbose reporter now prints as a flat list; use tree to restore prior behavior. [1]

7. Mocking behavior changes

   • vi.restoreAllMocks() no longer resets spy state; it only restores manual vi.spyOn spies (automocks no longer affected).
   • vi.fn().getMockName() default name changed (may affect snapshots).
   • Constructor mocking/spying now works, but your mock implementation must be a function or class (arrow functions will fail when called with new). [1]

8. Vite runtime internals: vite-node replaced

   • Vitest moved to Vite’s Module Runner; notable removals/renames:
     • VITE_NODE_DEPS_MODULE_DIRECTORIES → VITEST_MODULE_DIRECTORIES
     • Removed vitest/execute
     • No more __vitest_executor; now moduleRunner
     • Custom environments should use viteEnvironment (not transformMode) [1]

For the official migration doc and the release announcement (links to changelog), see: the Vitest Migration Guide and Vitest 4.0 blog post. [1] [2]

Sources: Migration Guide (Vitest) [1]; “Vitest 4.0 is out!” (Vitest blog) [2].

---

🏁 Script executed:

# Find vitest config in apps/web-next
find apps/web-next -name "vitest.config.*" -o -name "vitest.setup.*"

Repository: livepeer/naap

Length of output: 87

---

🏁 Script executed:

# Check if there's coverage configuration in package.json or separate config
cat apps/web-next/package.json | grep -A 20 -B 2 "coverage"

Repository: livepeer/naap

Length of output: 1117

---

🏁 Script executed:

# Search for test files that might use old patterns
fd -e "\.test\." -e "\.spec\." apps/web-next | head -20

Repository: livepeer/naap

Length of output: 414

---

🏁 Script executed:

# Search for vi.restoreAllMocks usage (potential breaking change)
rg "vi\.restoreAllMocks\|restoreAllMocks" apps/web-next --type js --type ts

Repository: livepeer/naap

Length of output: 39

---

🏁 Script executed:

# Search for workspace configuration that might need updating
rg "workspace\|maxThreads\|maxForks" apps/web-next

Repository: livepeer/naap

Length of output: 39

---

🏁 Script executed:

# Read the vitest.config.ts file
cat apps/web-next/vitest.config.ts

Repository: livepeer/naap

Length of output: 1366

---

🏁 Script executed:

# Find test files correctly
fd --full-path 'apps/web-next' -e test.ts -e test.tsx -e spec.ts -e spec.tsx

Repository: livepeer/naap

Length of output: 503

---

🏁 Script executed:

# Also check for setup files
fd --full-path 'apps/web-next' -name "*.setup.*"

Repository: livepeer/naap

Length of output: 287

---

🏁 Script executed:

# Check the setup file
cat apps/web-next/src/__tests__/setup.ts

Repository: livepeer/naap

Length of output: 1007

---

🏁 Script executed:

# Check one of the test files for patterns
cat apps/web-next/src/__tests__/api/auth.test.ts

Repository: livepeer/naap

Length of output: 3209

---

🏁 Script executed:

# Check another test file
cat apps/web-next/src/__tests__/page.test.tsx

Repository: livepeer/naap

Length of output: 1165

---

Add coverage.include to vitest.config.ts and update mock restoration strategy for Vitest 4.0.

This major version upgrade from Vitest 2.x to 4.x requires configuration adjustments beyond version number changes:

1. Coverage configuration: Vitest 4.0 now reports only covered files by default. Add explicit coverage.include pattern to vitest.config.ts to ensure all relevant files are included in coverage reporting.

2. Mock restoration behavior change: vi.restoreAllMocks() in src/__tests__/setup.ts no longer resets spy state for automocks (only for manual vi.spyOn()). If automocks require reset between tests, add vi.resetModules() in the setup file or refactor the cleanup strategy to properly isolate automocks.

🤖 Prompt for AI Agents

In `@apps/web-next/package.json` at line 62, Add an explicit coverage.include
pattern in vitest.config.ts so coverage reports include all intended files
(e.g., add a glob for your src and/or app files under coverage.include), and
update test setup cleanup in src/__tests__/setup.ts: keep vi.restoreAllMocks()
for manual spies and add vi.resetModules() (or change to
vi.resetAllMocks()/vi.resetModules() combination) to properly reset automocks
between tests; locate and modify the vitest config and the setup file where
vi.restoreAllMocks() is called to implement these changes.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Side effect in GET request breaks REST semantics.

The auto-install logic creates userPluginPreference records during a GET request (lines 208-218). This makes the endpoint non-idempotent and could cause issues with:

• HTTP caching (GET responses may be cached but side effects won't repeat)
• Retry logic (multiple retries won't cause duplicate inserts due to skipDuplicates, but it's still unexpected)
• API semantics (clients don't expect GET to modify state)

Consider moving this to a dedicated endpoint (e.g., POST /api/v1/base/plugins/sync-core) called during login, or handle it entirely in the admin PUT endpoint which already auto-installs for existing users.

🤖 Prompt for AI Agents

In `@apps/web-next/src/app/api/v1/base/plugins/personalized/route.ts` around lines
200 - 232, The GET handler currently mutates state by auto-creating preferences
(corePluginsToAutoInstall, prisma.userPluginPreference.createMany, and updating
preferencesMap); remove that side-effect from this GET route and instead
implement a dedicated non-GET flow: extract the auto-install logic into a new
POST endpoint (e.g., POST /api/v1/base/plugins/sync-core) or move it into the
existing admin/user PUT workflow invoked at login, keeping the same creation
payload (userId, pluginName, enabled, order, pinned) and skipDuplicates
behavior; update the GET handler to only read from preferencesMap and
globalPlugins and call the new POST/PUT flow from the login sequence or admin
sync job as appropriate.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

@inquirer/prompts v8.x input transformer callback signature documentation

💡 Result:

In @inquirer/prompts v8.x, the input() prompt’s transformer option uses this callback signature:

transformer?: (value: string, meta: { isFinal: boolean }) => string;

• value: the current raw text in the input buffer
• meta.isFinal: becomes true once the prompt is submitted (completed); otherwise false while the user is still typing
• The transformer is visual-only (it changes what’s displayed, not the returned answer) [1][2].

Sources: @inquirer/input options docs (the input prompt that @inquirer/prompts re-exports) [1][2].

References: [1] (npmjs.com) [2] (npm.io)

Citations:

• 1: https://www.npmjs.com/package/%40inquirer/input?utm_source=openai
• 2: https://npm.io/package/%40inquirer/input

---

Update transformer callback to accept the meta parameter from @inquirer/prompts v8.x.

The transformer callback signature in @inquirer/prompts v8.x is (value: string, meta: { isFinal: boolean }) => string. The current implementation only accepts the value parameter and omits the meta object. Update to:

transformer: (value: string, meta: { isFinal: boolean }) => '*'.repeat(value.length),

🤖 Prompt for AI Agents

In `@packages/plugin-sdk/cli/commands/github.ts` around lines 223 - 226, Update
the transformer callback passed to the input(...) call that populates the token
variable so it matches `@inquirer/prompts` v8.x signature; change the transformer
in the input invocation (the anonymous function currently declared as
transformer: (value: string) => ...) to accept the second meta parameter (meta:
{ isFinal: boolean }) and use both params, e.g., transformer: (value: string,
meta: { isFinal: boolean }) => '*'.repeat(value.length), so the input(...) call
aligns with the new API.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Ensure template sends also normalize EmailRecipient objects.

convertOptions() fixes send()/sendHtml(), but sendTemplate() still uses options.from / options.replyTo directly (Lines 117–119), which will pass objects into from/reply_to. That yields invalid SendGrid payloads when callers pass EmailRecipient objects. Please reuse the converter there too.

✅ Suggested update in sendTemplate

   async sendTemplate(
     to: string | string[],
     templateId: string,
     variables: Record<string, unknown>,
     options?: EmailOptions
   ): Promise<void> {
     const toArray = Array.isArray(to) ? to : [to];
+    const converted = this.convertOptions(options);
     
     const response = await this.request('POST', '/mail/send', {
       personalizations: [{
         to: toArray.map(email => ({ email })),
         dynamic_template_data: variables,
       }],
-      from: { email: options?.from || this.fromEmail || 'noreply@example.com' },
+      from: { email: converted.from || this.fromEmail || 'noreply@example.com' },
       template_id: templateId,
-      reply_to: options?.replyTo ? { email: options.replyTo } : undefined,
+      reply_to: converted.replyTo ? { email: converted.replyTo } : undefined,
     });

📝 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

	/** Convert EmailOptions (with EmailRecipient objects) to plain string fields for sendMail */
	private convertOptions(options?: EmailOptions): {
	from?: string;
	replyTo?: string;
	cc?: string[];
	bcc?: string[];
	} {
	if (!options) return {};
	const toEmail = (r?: { email: string }) => r?.email;
	return {
	...(options.from ? { from: toEmail(options.from) } : {}),
	...(options.replyTo ? { replyTo: toEmail(options.replyTo) } : {}),
	...(options.cc ? { cc: options.cc.map(r => r.email) } : {}),
	...(options.bcc ? { bcc: options.bcc.map(r => r.email) } : {}),
	};
	}
	async sendTemplate(
	to: string | string[],
	templateId: string,
	variables: Record<string, unknown>,
	options?: EmailOptions
	): Promise<void> {
	const toArray = Array.isArray(to) ? to : [to];
	const converted = this.convertOptions(options);
	const response = await this.request('POST', '/mail/send', {
	personalizations: [{
	to: toArray.map(email => ({ email })),
	dynamic_template_data: variables,
	}],
	from: { email: converted.from || this.fromEmail || 'noreply@example.com' },
	template_id: templateId,
	reply_to: converted.replyTo ? { email: converted.replyTo } : undefined,
	});
	}

🤖 Prompt for AI Agents

In `@packages/plugin-sdk/src/integrations/email/sendgrid.ts` around lines 87 -
102, The sendTemplate path is passing EmailRecipient objects directly into
SendGrid fields (options.from / options.replyTo) instead of normalized strings;
reuse the existing convertOptions method inside sendTemplate to map options to
plain string fields before building the SendGrid payload. Update sendTemplate to
call this.convertOptions(options) and use its returned from/replyTo (and cc/bcc
if applicable) when constructing the template email so SendGrid receives string
addresses rather than objects.