Merge remote-tracking branch 'origin/staging' into feat/func-cli-resolver

# Conflicts:
#	apps/sim/executor/handlers/agent/agent-handler.ts
#	apps/sim/lib/copilot/vfs/workspace-vfs.ts
#	apps/sim/tools/generated/tool-metadata.ts
#	apps/sim/tools/generated/tool-outputs.ts

Author: icecrasher321

.claude/rules/sim-ui-copy.md

@@ -0,0 +1,46 @@
+---
+paths:
+  - "apps/sim/**/*.tsx"
+  - "apps/sim/components/emcn/**"
+---
+
+# UI Copy
+
+**Do not add subtitles, helper text, or descriptive copy beneath headings, labels, cards, or settings by default.** Prefer one concise, self-explanatory heading or label. Only add supporting copy when the user explicitly asks for it, or when it is necessary to prevent misunderstanding or error — and never use it to restate the heading.
+
+This applies to product surfaces: settings rows, modals, panels, cards, list rows, empty states, form fields, and section headers. Marketing surfaces (`app/(landing)`, docs) are governed by `constitution.md` instead.
+
+**Carve-out — settings section metadata.** `SettingsNavigationItem.description` in `components/settings/navigation.ts` stays required, and `SettingsPanel` keeps rendering it as the page subtitle. Settings sections are reached through a nav list where the description is the only thing distinguishing adjacent sections, so it earns its place by the "prevents misunderstanding" test. Keep those descriptions verb-first and one line, per `sim-settings-pages.md`. Everything else on a settings page — inline `<p>` blurbs under section headings, field hints, modal bodies, row subtitles — follows the default rule above.
+
+## The default is no description
+
+```tsx
+// ✗ Bad — the subtitle restates the heading
+<h3>API Keys</h3>
+<p className='text-[var(--text-muted)] text-caption'>Manage your API keys.</p>
+
+// ✗ Bad — decorative filler under a field label
+<ChipModalField title='Workspace name' hint='The name of your workspace.' />
+
+// ✓ Good — the label carries the whole meaning
+<h3>API Keys</h3>
+<ChipModalField title='Workspace name' />
+```
+
+If a heading needs a subtitle to be understood, the heading is wrong. Fix the heading — don't append a second line.
+
+## When supporting copy earns its place
+
+Keep (or add) a description only when it carries information the label cannot, and its absence would cause a mistake:
+
+- **Irreversible or destructive consequences** — "Deleting this workspace removes every workflow and log. This cannot be undone."
+- **A non-obvious format, unit, or bound** — "Comma-separated. Max 50 domains.", "Cost per 1M input tokens."
+- **A security or access implication** — "This key is shown once and grants full workspace access."
+- **A state the user cannot otherwise see** — "Inherited from your organization's policy."
+- **Instructional copy that advances a flow** — "We sent a 6-digit code to you@example.com."
+
+Everything else — restatements, "Manage your X", "Configure your Y", feature blurbs, encouragement — gets deleted.
+
+## Component APIs
+
+Description/hint slots on shared components are **optional**, never required, and must reserve no layout space when omitted. A component that forces every consumer to supply a subtitle forces every consumer to violate this rule. When adding a new shared component, ship it without a description slot and add one only once a real caller meets the bar above.

.cursor/rules/sim-ui-copy.mdc

@@ -0,0 +1,44 @@
+---
+description: UI copy conventions — no default subtitles or helper text under headings, labels, cards, or settings
+globs: ["apps/sim/**/*.tsx"]
+---
+# UI Copy
+
+**Do not add subtitles, helper text, or descriptive copy beneath headings, labels, cards, or settings by default.** Prefer one concise, self-explanatory heading or label. Only add supporting copy when the user explicitly asks for it, or when it is necessary to prevent misunderstanding or error — and never use it to restate the heading.
+
+This applies to product surfaces: settings rows, modals, panels, cards, list rows, empty states, form fields, and section headers. Marketing surfaces (`app/(landing)`, docs) are governed by `constitution.mdc` instead.
+
+**Carve-out — settings section metadata.** `SettingsNavigationItem.description` in `components/settings/navigation.ts` stays required, and `SettingsPanel` keeps rendering it as the page subtitle. Settings sections are reached through a nav list where the description is the only thing distinguishing adjacent sections. Everything else on a settings page — inline `<p>` blurbs under section headings, field hints, modal bodies, row subtitles — follows the default rule above.
+
+## The default is no description
+
+```tsx
+// ✗ Bad — the subtitle restates the heading
+<h3>API Keys</h3>
+<p className='text-[var(--text-muted)] text-caption'>Manage your API keys.</p>
+
+// ✗ Bad — decorative filler under a field label
+<ChipModalField title='Workspace name' hint='The name of your workspace.' />
+
+// ✓ Good — the label carries the whole meaning
+<h3>API Keys</h3>
+<ChipModalField title='Workspace name' />
+```
+
+If a heading needs a subtitle to be understood, the heading is wrong. Fix the heading — don't append a second line.
+
+## When supporting copy earns its place
+
+Keep (or add) a description only when it carries information the label cannot, and its absence would cause a mistake:
+
+- **Irreversible or destructive consequences** — "Deleting this workspace removes every workflow and log. This cannot be undone."
+- **A non-obvious format, unit, or bound** — "Comma-separated. Max 50 domains.", "Cost per 1M input tokens."
+- **A security or access implication** — "This key is shown once and grants full workspace access."
+- **A state the user cannot otherwise see** — "Inherited from your organization's policy."
+- **Instructional copy that advances a flow** — "We sent a 6-digit code to you@example.com."
+
+Everything else — restatements, "Manage your X", "Configure your Y", feature blurbs, encouragement — gets deleted.
+
+## Component APIs
+
+Description/hint slots on shared components are **optional**, never required, and must reserve no layout space when omitted. A component that forces every consumer to supply a subtitle forces every consumer to violate this rule. When adding a new shared component, ship it without a description slot and add one only once a real caller meets the bar above.

.github/workflows/test-build.yml

@@ -178,8 +178,14 @@ jobs:
           fi
           bun run check:migrations "$BASE_REF"
 
-      - name: Type-check realtime server
-        run: bunx turbo run type-check --filter=@sim/realtime
+      # Every workspace, not just realtime. packages/emcn, packages/utils,
+      # apps/desktop and apps/docs had no type check in CI at all; apps/sim's
+      # source was covered only as a side effect of `next build` in the separate
+      # Build App job. Note this does NOT cover apps/sim's tests — its tsconfig
+      # excludes *.test.ts(x), and including them today surfaces ~2.2k errors,
+      # so that is its own cleanup rather than a gate to switch on here.
+      - name: Type-check all workspaces
+        run: bunx turbo run type-check
 
       # cloud-review-tools.test.ts runs the real helper on the runner, which shells
       # out to rg. Blacksmith's image ships it, GitHub's doesn't.

apps/docs/content/docs/en/integrations/airtable-service-account.mdx

@@ -69,12 +69,12 @@ Enterprise organizations can enable "Block API access to organization-owned base
 
 <Steps>
   <Step>
-    Open your workspace **Settings** and go to the **Integrations** tab
+    Open **Integrations** from your workspace sidebar
   </Step>
   <Step>
-    Search for "Airtable Service Account" and click it, then click **Add to Sim** and choose **Add personal access token**
+    Search for "Airtable" and open it, then click **Add to Sim** and choose **Add personal access token**
 
-    {/* TODO(screenshot): Integrations page with "Airtable Service Account" in the service list */}
+    {/* TODO(screenshot): Airtable integration page with the service-account connect option */}
   </Step>
   <Step>
     Paste the **Personal access token**, and optionally set a display name and description

apps/docs/content/docs/en/integrations/asana-service-account.mdx

@@ -73,12 +73,12 @@ If you're not on an Enterprise plan, a personal access token works identically o
 
 <Steps>
   <Step>
-    Open your workspace **Settings** and go to the **Integrations** tab
+    Open **Integrations** from your workspace sidebar
   </Step>
   <Step>
-    Search for "Asana Service Account" and click it, then click **Add to Sim** and choose **Add access token**
+    Search for "Asana" and open it, then click **Add to Sim** and choose **Add access token**
 
-    {/* TODO(screenshot): Integrations page with "Asana Service Account" in the service list */}
+    {/* TODO(screenshot): Asana integration page with the service-account connect option */}
   </Step>
   <Step>
     Paste the token — service account token or personal access token, both work in the same field — and optionally set a display name and description

apps/docs/content/docs/en/integrations/attio-service-account.mdx

@@ -61,12 +61,12 @@ The API key is bearer credentials for your Attio workspace. Treat it like a pass
 
 <Steps>
   <Step>
-    Open your workspace **Settings** and go to the **Integrations** tab
+    Open **Integrations** from your workspace sidebar
   </Step>
   <Step>
-    Search for "Attio Service Account" and click it, then click **Add to Sim** and choose **Add API key**
+    Search for "Attio" and open it, then click **Add to Sim** and choose **Add API key**
 
-    {/* TODO(screenshot): Integrations page with "Attio Service Account" in the service list */}
+    {/* TODO(screenshot): Attio integration page with the service-account connect option */}
   </Step>
   <Step>
     Paste the API key and optionally set a display name and description

apps/docs/content/docs/en/integrations/calcom-service-account.mdx

@@ -45,12 +45,12 @@ The API key carries the full privileges of the user who created it — there is
 
 <Steps>
   <Step>
-    Open your workspace **Settings** and go to the **Integrations** tab
+    Open **Integrations** from your workspace sidebar
   </Step>
   <Step>
-    Search for "Cal.com Service Account" and click it, then click **Add to Sim** and choose **Add API key**
+    Search for "Cal.com" and open it, then click **Add to Sim** and choose **Add API key**
 
-    {/* TODO(screenshot): Integrations page with "Cal.com Service Account" in the service list */}
+    {/* TODO(screenshot): Cal.com integration page with the service-account connect option */}
   </Step>
   <Step>
     Paste the API key, and optionally set a display name and description

apps/docs/content/docs/en/integrations/clickup-service-account.mdx

@@ -45,12 +45,12 @@ The API token carries the creating user's full access to every workspace they be
 
 <Steps>
   <Step>
-    Open your workspace **Settings** and go to the **Integrations** tab
+    Open **Integrations** from your workspace sidebar
   </Step>
   <Step>
-    Search for "ClickUp Service Account" and click it, then click **Add to Sim** and choose **Add API token**
+    Search for "ClickUp" and open it, then click **Add to Sim** and choose **Add API token**
 
-    {/* TODO(screenshot): Integrations page with "ClickUp Service Account" in the service list */}
+    {/* TODO(screenshot): ClickUp integration page with the service-account connect option */}
   </Step>
   <Step>
     Paste the API token (`pk_...`) and optionally set a display name and description

apps/docs/content/docs/en/integrations/google-service-account.mdx

@@ -140,15 +140,15 @@ Once Google Cloud and Workspace are configured, add the service account as a cre
 
 <Steps>
   <Step>
-    Open your workspace **Settings** and go to the **Integrations** tab
+    Open **Integrations** from your workspace sidebar
   </Step>
   <Step>
-    Search for "Google Service Account" and click **Connect**
+    Search for "Google Drive" and open it — any Google integration works, since they share one service account — then click **Add to Sim** and choose **Add service account**
 
     <div className="flex justify-center">
       <Image
         src="/static/credentials/integrations-service-account.png"
-        alt="Integrations page showing Google Service Account"
+        alt="Google Drive integration page with the service-account connect option"
         width={800}
         height={150}
         className="my-4"
@@ -171,7 +171,7 @@ Once Google Cloud and Workspace are configured, add the service account as a cre
     Give the credential a display name (the service account email is used by default)
   </Step>
   <Step>
-    Click **Save**
+    Click **Add service account**
   </Step>
 </Steps>
 

apps/docs/content/docs/en/integrations/hubspot-service-account.mdx

@@ -97,12 +97,12 @@ The access token is bearer credentials for your entire portal, limited only by i
 
 <Steps>
   <Step>
-    Open your workspace **Settings** and go to the **Integrations** tab
+    Open **Integrations** from your workspace sidebar
   </Step>
   <Step>
-    Search for "HubSpot Service Account" and click it, then click **Add to Sim** and choose **Add private app token**
+    Search for "HubSpot" and open it, then click **Add to Sim** and choose **Add private app token**
 
-    {/* TODO(screenshot): Integrations page with "HubSpot Service Account" in the service list */}
+    {/* TODO(screenshot): HubSpot integration page with the service-account connect option */}
   </Step>
   <Step>
     Paste the **Private app access token**, and optionally set a display name and description