feat: device import from integrations

[Marfuen]

Summary

• Adds device_sync as a new IntegrationCapability so any integration (platform or dynamic) can declare device import support
• Builds GenericDeviceSyncService — a two-phase sync service (import active devices, remove disappeared ones) mirroring the existing employee sync pattern
• Extends the sync controller with discovery (?syncType=device), provider selection (device-sync-provider), and dynamic device sync trigger endpoints
• Adds useDeviceSync hook and DeviceSyncProviderSelector component to the Devices tab in People
• Extends the daily Trigger.dev schedule to trigger device syncs for orgs with a deviceSyncProvider set

Test plan

• GenericDeviceSyncService has 7 unit tests covering: create, update, skip (no member), inactive exclusion, remove stale, keep current, false-delete guard
• Trigger schedule tests pass (107/107)
• Manual: navigate to People → Devices tab, verify sync provider selector renders
• Manual: connect an integration with device_sync capability, select it, click "Sync now"
• Manual: verify devices appear in the table after sync

🤖 Generated with Claude Code

---

Summary by cubic

Adds device import from integrations with a new device_sync capability, a two‑phase sync (import + prune), provider selection, and scheduled runs. Validates deviceSyncDefinition on dynamic integrations and safely handles ownership changes, unique conflicts, and pruning.

• New Features

  • Platform: device_sync capability and SyncDevice schema in @trycompai/integration-platform; dynamic integrations can store deviceSyncDefinition.
  • API: GET/POST /v1/integrations/sync/device-sync-provider, GET /available-providers?syncType=device, and POST /dynamic/:provider/devices; OAuth refresh support; logs persisted to check runs.
  • Service: GenericDeviceSyncService imports active devices (member email match, serial/external ID), updates memberId on ownership changes, guards prune when none processed, and falls back on P2002 conflicts.
  • DB: Device.source enum + integrationConnectionId + externalDeviceId; Organization.deviceSyncProvider; DynamicIntegration.deviceSyncDefinition; index on Device.integrationConnectionId.
  • Scheduler: new run-device-sync task in @trigger.dev; daily orchestrator triggers device sync for orgs with a provider set; integration checks still batch-triggered.
  • App: useDeviceSync hook and DeviceSyncProviderSelector on People → Devices; improved error handling when setting provider; “Sync now” button.
  • Tests: unit tests for GenericDeviceSyncService; schedule tests updated.

• Migration

  • Run Prisma migration.
  • Ensure manifests declare device_sync and include a deviceSyncDefinition.
  • Configure scheduler envs (SERVICE_TOKEN_TRIGGER, BASE_URL) for @trigger.dev.
  • Adoption: connect a device_sync integration, set the provider in Devices, then click “Sync now”.

^{Written for commit d45f2da. Summary will update on new commits.}

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
app	Ready	Preview, Comment	May 13, 2026 2:00pm
comp-framework-editor	Ready	Preview, Comment	May 13, 2026 2:00pm
portal	Ready	Preview, Comment	May 13, 2026 2:00pm

[cubic-dev-ai]

7 issues found across 20 files

Confidence score: 2/5

• There is high regression risk in apps/api/src/integration-platform/services/generic-device-sync.service.ts: skipped devices are omitted from syncedIdentifiers, which can cause valid provider devices to be deleted in Phase 2, and existing-device updates do not refresh memberId ownership changes.
• apps/app/src/app/(app)/[orgId]/people/devices/hooks/useDeviceSync.ts currently updates local provider state even when apiClient.post fails, creating a concrete user-facing inconsistency where failed saves appear successful.
• apps/api/src/trigger/integration-platform/run-device-sync.ts and apps/api/src/trigger/integration-platform/run-integration-checks-schedule.ts can misreport system health (expiring valid credentials on generic 401s and returning success: true on failed batch triggering), which makes operational failures harder to detect and recover from.
• Pay close attention to apps/api/src/integration-platform/services/generic-device-sync.service.ts, apps/app/src/app/(app)/[orgId]/people/devices/hooks/useDeviceSync.ts, apps/api/src/trigger/integration-platform/run-device-sync.ts, apps/api/src/trigger/integration-platform/run-integration-checks-schedule.ts, and apps/api/src/integration-platform/controllers/dynamic-integrations.controller.ts - data deletion risk, false-success UI/state, incorrect connection erroring, misleading run status, and unhandled validation exceptions should be addressed before merge.

Prompt for AI agents (unresolved issues)

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


<file name="apps/app/src/app/(app)/[orgId]/people/devices/hooks/useDeviceSync.ts">

<violation number="1" location="apps/app/src/app/(app)/[orgId]/people/devices/hooks/useDeviceSync.ts:82">
P1: Check `apiClient.post` errors before updating local provider state; this currently treats failed saves as success.</violation>
</file>

<file name="apps/api/src/trigger/integration-platform/run-integration-checks-schedule.ts">

<violation number="1" location="apps/api/src/trigger/integration-platform/run-integration-checks-schedule.ts:219">
P2: `success` is always returned as `true` even when task batch triggering throws, so partial/failed runs are reported as successful.</violation>
</file>

<file name="apps/api/src/trigger/integration-platform/run-device-sync.ts">

<violation number="1" location="apps/api/src/trigger/integration-platform/run-device-sync.ts:52">
P1: Don’t mark connection credentials as expired on every 401; internal service-token auth failures also return 401 and will incorrectly flip valid connections to error.</violation>
</file>

<file name="apps/api/src/integration-platform/controllers/dynamic-integrations.controller.ts">

<violation number="1" location="apps/api/src/integration-platform/controllers/dynamic-integrations.controller.ts:70">
P2: Handle invalid `deviceSyncDefinition` with `safeParse` and return a 400 error instead of letting `parse` throw.</violation>

<violation number="2" location="apps/api/src/integration-platform/controllers/dynamic-integrations.controller.ts:183">
P2: Use `safeParse` for `deviceSyncDefinition` in create flow to avoid unhandled parse exceptions.</violation>
</file>

<file name="apps/api/src/integration-platform/services/generic-device-sync.service.ts">

<violation number="1" location="apps/api/src/integration-platform/services/generic-device-sync.service.ts:98">
P1: Devices skipped for missing member are excluded from `syncedIdentifiers`, which can cause Phase 2 to delete still-present provider devices.</violation>

<violation number="2" location="apps/api/src/integration-platform/services/generic-device-sync.service.ts:135">
P1: Existing-device updates never refresh `memberId`, so device ownership changes from the provider are not applied.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}