Merge remote-tracking branch 'origin/staging' into feat/interfaces-merge

# Conflicts:
#	apps/sim/app/workspace/[workspaceId]/files/components/file-viewer/editor-context-menu.tsx
#	apps/sim/app/workspace/[workspaceId]/home/hooks/use-chat.ts
#	apps/sim/app/workspace/[workspaceId]/home/types.ts
#	apps/sim/app/workspace/[workspaceId]/tables/[tableId]/components/context-menu/context-menu.tsx
#	apps/sim/app/workspace/[workspaceId]/tables/[tableId]/components/table-grid/table-grid.tsx
#	apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/deploy/components/deploy-modal/components/chat/chat.tsx
#	apps/sim/components/chat/chat-context-kind-registry/chat-context-kind-registry.tsx
#	apps/sim/components/resources/file-view/components/rich-markdown-editor/rich-markdown-editor.tsx
#	apps/sim/components/resources/file-view/components/text-editor/text-editor.tsx
#	apps/sim/components/resources/file-view/components/use-selection-copy-bridge.test.tsx
#	apps/sim/components/resources/file-view/components/use-selection-copy-bridge.ts
#	apps/sim/components/ui/generated-password-input.tsx
#	apps/sim/lib/workflows/streaming/streaming.ts
#	apps/sim/stores/panel/types.ts
#	scripts/check-api-validation-contracts.ts

Author: waleedlatif1

.agents/skills/validate-integration/SKILL.md

@@ -295,13 +295,31 @@ Group findings by severity:
 
 After reporting, fix every **critical** and **warning** issue. Apply **suggestions** where they don't add unnecessary complexity.
 
+### Regenerate Derived Artifacts
+
+Several files are generated from tool and block definitions. Editing a tool or block WITHOUT regenerating them fails CI, so run these before pushing:
+
+```bash
+bun run tool-metadata:generate       # repo root — apps/sim/tools/generated/*
+cd apps/sim && bun run generate-docs # docs .mdx + lib/integrations/integrations.json + docs icons
+```
+
+- **`tool-metadata:generate`** — required whenever a tool's `outputs`, `params`, or descriptions change. CI enforces this with `bun run tool-metadata:check`, which fails with *"Generated tool metadata is stale"*. This is the easiest gate to miss, because nothing in the tool file hints that a generated artifact mirrors it.
+- **`generate-docs`** — required whenever block metadata changes (`bgColor`, `name`, `description`, operations, outputs). Regenerates the integration `.mdx`, `integrations.json`, and the docs copy of `components/icons.tsx`.
+
+**Always diff the regen output before committing.** These generators rewrite every file they own, so they will also sweep in unrelated drift that accumulated on the base branch — pages losing sections, unrelated icons appearing. Keep only the hunks belonging to the integration under validation and `git checkout --` the rest, otherwise an unrelated doc regression rides along in the PR. Verify no page was silently dropped by comparing the directory listing before and after.
+
+If an icon changed, `apps/sim/components/icons.tsx` is the source of truth and `apps/docs/components/icons.tsx` is its generated mirror — they must end up byte-identical for that component.
+
 ### Validation Output
 
 After fixing, confirm:
 1. `bun run lint` passes with no fixes needed
-2. TypeScript compiles clean (no type errors)
-3. Re-read all modified files to verify fixes are correct
-4. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
+2. TypeScript compiles clean (no type errors) — check the error list is empty for the files you touched; pre-existing unrelated errors in a worktree usually mean workspace packages resolve to the main checkout
+3. The integration's tests pass, and any test you added actually fails without its fix (revert it once and watch it go red)
+4. Derived artifacts regenerated and their diffs reviewed (see above)
+5. Re-read all modified files to verify fixes are correct
+6. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
 
 ## Checklist Summary
 
@@ -322,5 +340,8 @@ After fixing, confirm:
 - [ ] Validated `{Service}BlockMeta` exported with at least 7 templates
 - [ ] Reported all issues grouped by severity
 - [ ] Fixed all critical and warning issues
+- [ ] Ran `bun run tool-metadata:generate` if any tool outputs/params changed, and confirmed `bun run tool-metadata:check` passes
+- [ ] Ran `bun run generate-docs` if any block metadata changed, and reverted unrelated drift the generator swept in
 - [ ] Ran `bun run lint` after fixes
 - [ ] Verified TypeScript compiles clean
+- [ ] Verified added tests fail without their fix

.claude/commands/validate-integration.md

@@ -294,13 +294,31 @@ Group findings by severity:
 
 After reporting, fix every **critical** and **warning** issue. Apply **suggestions** where they don't add unnecessary complexity.
 
+### Regenerate Derived Artifacts
+
+Several files are generated from tool and block definitions. Editing a tool or block WITHOUT regenerating them fails CI, so run these before pushing:
+
+```bash
+bun run tool-metadata:generate       # repo root — apps/sim/tools/generated/*
+cd apps/sim && bun run generate-docs # docs .mdx + lib/integrations/integrations.json + docs icons
+```
+
+- **`tool-metadata:generate`** — required whenever a tool's `outputs`, `params`, or descriptions change. CI enforces this with `bun run tool-metadata:check`, which fails with *"Generated tool metadata is stale"*. This is the easiest gate to miss, because nothing in the tool file hints that a generated artifact mirrors it.
+- **`generate-docs`** — required whenever block metadata changes (`bgColor`, `name`, `description`, operations, outputs). Regenerates the integration `.mdx`, `integrations.json`, and the docs copy of `components/icons.tsx`.
+
+**Always diff the regen output before committing.** These generators rewrite every file they own, so they will also sweep in unrelated drift that accumulated on the base branch — pages losing sections, unrelated icons appearing. Keep only the hunks belonging to the integration under validation and `git checkout --` the rest, otherwise an unrelated doc regression rides along in the PR. Verify no page was silently dropped by comparing the directory listing before and after.
+
+If an icon changed, `apps/sim/components/icons.tsx` is the source of truth and `apps/docs/components/icons.tsx` is its generated mirror — they must end up byte-identical for that component.
+
 ### Validation Output
 
 After fixing, confirm:
 1. `bun run lint` passes with no fixes needed
-2. TypeScript compiles clean (no type errors)
-3. Re-read all modified files to verify fixes are correct
-4. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
+2. TypeScript compiles clean (no type errors) — check the error list is empty for the files you touched; pre-existing unrelated errors in a worktree usually mean workspace packages resolve to the main checkout
+3. The integration's tests pass, and any test you added actually fails without its fix (revert it once and watch it go red)
+4. Derived artifacts regenerated and their diffs reviewed (see above)
+5. Re-read all modified files to verify fixes are correct
+6. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
 
 ## Checklist Summary
 
@@ -321,5 +339,8 @@ After fixing, confirm:
 - [ ] Validated `{Service}BlockMeta` exported with at least 7 templates
 - [ ] Reported all issues grouped by severity
 - [ ] Fixed all critical and warning issues
+- [ ] Ran `bun run tool-metadata:generate` if any tool outputs/params changed, and confirmed `bun run tool-metadata:check` passes
+- [ ] Ran `bun run generate-docs` if any block metadata changed, and reverted unrelated drift the generator swept in
 - [ ] Ran `bun run lint` after fixes
 - [ ] Verified TypeScript compiles clean
+- [ ] Verified added tests fail without their fix

.claude/rules/sim-settings-pages.md

@@ -167,11 +167,32 @@ Any settings surface with editable state uses **one** shared stack — never
 hand-roll a Save button, a Discard button, a `beforeunload`, or an "Unsaved
 changes" modal:
 
-- **`saveDiscardActions(config)`** (`…/components/save-discard-actions/save-discard-actions`)
-  — returns the canonical dirty-gated **Discard + Save** `SettingsAction[]` (empty
-  when not dirty). Spread it into a `SettingsPanel` `actions` array, beside any
+- **`saveDiscardActions(config)`** (`@/components/settings/save-discard-actions`)
+  — returns the canonical **Discard + Save** `SettingsAction[]`. **Save is always
+  rendered** (primary), disabled until there is something to save, so every
+  editable surface announces its primary action in the same place and a create
+  form is never a page with no visible way to commit it; **Discard appears only
+  when dirty**. Spread it into a `SettingsPanel` `actions` array, beside any
   sibling actions (a detail view's Delete / Remove override). Config: `dirty`,
-  `saving`, `onSave`, `onDiscard`, `saveDisabled?`, `saveLabel?`, `savingLabel?`.
+  `saving`, `onSave`, `onDiscard`, `saveDisabled?`, `saveTooltip?`, `creating?`,
+  `saveLabel?`, `savingLabel?`. Create flows pass `creating` — the
+  Create / Creating... labels come as a pair and can never drift apart.
+  `saveLabel`/`savingLabel` are only for genuinely bespoke wording (SSO's
+  `Update`); never hand-roll the pair to get a create label.
+- **`<SaveDiscardChips {...config} />`** (same module) — the identical rule
+  rendered as chips, for surfaces whose header takes a `ReactNode` instead of
+  action data (`CredentialDetailLayout`: skills, secrets, connected credentials).
+  Both stacks derive from the one function; never hand-roll a Save chip.
+
+`CredentialDetailLayout` stays slot-driven for exactly two reasons: its back
+control is a real `<ChipLink href>` (deep-linkable / middle-clickable, which
+`SettingsBackAction`'s `onSelect` cannot express), and actions like
+`SkillImportButton` own a hidden file input and their own pending state.
+**Everything else in one of those headers should be `SettingsAction` data**
+rendered through `<SettingsActionChips actions={…} />` from
+`@/components/settings/settings-header` — that is the shared chip path, and it
+is what keeps tone/icon/variant/tooltip handling from drifting between the two
+shells. Reach for it before hand-rolling a `Chip`.
 - **`useSettingsUnsavedGuard({ isDirty })`** (`…/settings/hooks/use-settings-unsaved-guard`)
   — syncs the page's local `isDirty` into the shared `useSettingsDirtyStore` (so
   the sidebar's **section-switch** confirm + the centralized `beforeunload` both

.cursor/commands/validate-integration.md

@@ -289,13 +289,31 @@ Group findings by severity:
 
 After reporting, fix every **critical** and **warning** issue. Apply **suggestions** where they don't add unnecessary complexity.
 
+### Regenerate Derived Artifacts
+
+Several files are generated from tool and block definitions. Editing a tool or block WITHOUT regenerating them fails CI, so run these before pushing:
+
+```bash
+bun run tool-metadata:generate       # repo root — apps/sim/tools/generated/*
+cd apps/sim && bun run generate-docs # docs .mdx + lib/integrations/integrations.json + docs icons
+```
+
+- **`tool-metadata:generate`** — required whenever a tool's `outputs`, `params`, or descriptions change. CI enforces this with `bun run tool-metadata:check`, which fails with *"Generated tool metadata is stale"*. This is the easiest gate to miss, because nothing in the tool file hints that a generated artifact mirrors it.
+- **`generate-docs`** — required whenever block metadata changes (`bgColor`, `name`, `description`, operations, outputs). Regenerates the integration `.mdx`, `integrations.json`, and the docs copy of `components/icons.tsx`.
+
+**Always diff the regen output before committing.** These generators rewrite every file they own, so they will also sweep in unrelated drift that accumulated on the base branch — pages losing sections, unrelated icons appearing. Keep only the hunks belonging to the integration under validation and `git checkout --` the rest, otherwise an unrelated doc regression rides along in the PR. Verify no page was silently dropped by comparing the directory listing before and after.
+
+If an icon changed, `apps/sim/components/icons.tsx` is the source of truth and `apps/docs/components/icons.tsx` is its generated mirror — they must end up byte-identical for that component.
+
 ### Validation Output
 
 After fixing, confirm:
 1. `bun run lint` passes with no fixes needed
-2. TypeScript compiles clean (no type errors)
-3. Re-read all modified files to verify fixes are correct
-4. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
+2. TypeScript compiles clean (no type errors) — check the error list is empty for the files you touched; pre-existing unrelated errors in a worktree usually mean workspace packages resolve to the main checkout
+3. The integration's tests pass, and any test you added actually fails without its fix (revert it once and watch it go red)
+4. Derived artifacts regenerated and their diffs reviewed (see above)
+5. Re-read all modified files to verify fixes are correct
+6. Any remaining unknown response schemas were explicitly reported to the user instead of guessed
 
 ## Checklist Summary
 
@@ -316,5 +334,8 @@ After fixing, confirm:
 - [ ] Validated `{Service}BlockMeta` exported with at least 7 templates
 - [ ] Reported all issues grouped by severity
 - [ ] Fixed all critical and warning issues
+- [ ] Ran `bun run tool-metadata:generate` if any tool outputs/params changed, and confirmed `bun run tool-metadata:check` passes
+- [ ] Ran `bun run generate-docs` if any block metadata changed, and reverted unrelated drift the generator swept in
 - [ ] Ran `bun run lint` after fixes
 - [ ] Verified TypeScript compiles clean
+- [ ] Verified added tests fail without their fix

apps/docs/components/icons.tsx

@@ -8767,12 +8767,12 @@ export function LogfireIcon(props: SVGProps<SVGSVGElement>) {
   return (
     <svg
       {...props}
-      viewBox='0 0 138 120'
+      viewBox='0 0 750 750'
       fill='currentColor'
       role='img'
       xmlns='http://www.w3.org/2000/svg'
     >
-      <path d='M137.041 90.563 73.326 2.241c-2.005-2.757-6.628-2.757-8.613 0L.998 90.563A5.32 5.32 0 0 0 0 93.664a5.331 5.331 0 0 0 3.641 5.05l63.715 20.851h.01a5.306 5.306 0 0 0 3.292 0h.01l63.715-20.85a5.265 5.265 0 0 0 3.392-3.406 5.247 5.247 0 0 0-.749-4.746h.015ZM69.022 14.412 94.56 49.815l-23.882-7.813c-.185-.06-.38-.05-.564-.094a3.484 3.484 0 0 0-.548-.09c-.185-.025-.36-.095-.544-.095-.185 0-.354.07-.539.095-.184.02-.369.05-.548.09-.19.035-.384.035-.554.094L43.644 49.77l-.15.05L69.032 14.41h-.01ZM32.94 64.438l27.802-9.104 2.968-.967v52.838L13.86 90.887 32.94 64.438Zm41.399 42.757V54.367l30.77 10.071 19.079 26.434-49.854 16.323h.005Z' />
+      <path d='M 741.496094 539.726562 L 398.203125 63.890625 C 387.398438 49.039062 362.480469 49.039062 351.789062 63.890625 L 8.492188 539.726562 C 6.746094 542.160156 5.414062 544.804688 4.496094 547.65625 C 3.578125 550.511719 3.117188 553.4375 3.117188 556.433594 C 3.117188 557.929688 3.238281 559.414062 3.472656 560.890625 C 3.703125 562.371094 4.050781 563.820312 4.511719 565.242188 C 4.972656 566.664062 5.539062 568.042969 6.214844 569.378906 C 6.890625 570.710938 7.667969 571.984375 8.542969 573.199219 C 9.417969 574.410156 10.378906 575.550781 11.433594 576.613281 C 12.484375 577.675781 13.613281 578.648438 14.816406 579.535156 C 16.023438 580.421875 17.289062 581.207031 18.617188 581.898438 C 19.941406 582.585938 21.316406 583.167969 22.734375 583.640625 L 366.03125 695.972656 L 366.085938 695.972656 C 368.96875 696.914062 371.921875 697.382812 374.953125 697.382812 C 377.984375 697.382812 380.941406 696.914062 383.824219 695.972656 L 383.875 695.972656 L 727.175781 583.644531 C 729.316406 582.953125 731.347656 582.015625 733.265625 580.839844 C 735.183594 579.660156 736.941406 578.273438 738.527344 576.679688 C 740.117188 575.082031 741.496094 573.324219 742.667969 571.398438 C 743.835938 569.476562 744.765625 567.441406 745.449219 565.296875 C 746.15625 563.15625 746.601562 560.96875 746.785156 558.722656 C 746.96875 556.480469 746.882812 554.246094 746.53125 552.023438 C 746.183594 549.796875 745.574219 547.644531 744.710938 545.566406 C 743.84375 543.488281 742.746094 541.542969 741.414062 539.726562 Z M 375.011719 129.460938 L 512.605469 320.195312 L 383.929688 278.105469 C 382.941406 277.78125 381.882812 277.835938 380.894531 277.597656 C 379.917969 277.355469 378.933594 277.195312 377.933594 277.113281 C 376.945312 276.976562 376 276.601562 375.011719 276.601562 C 374.015625 276.601562 373.097656 276.976562 372.101562 277.113281 C 371.109375 277.21875 370.121094 277.382812 369.152344 277.597656 C 368.128906 277.785156 367.082031 277.785156 366.167969 278.105469 L 238.269531 319.953125 L 237.460938 320.222656 L 375.070312 129.453125 L 375.015625 129.453125 Z M 180.597656 398.976562 L 330.394531 349.929688 L 346.386719 344.71875 L 346.386719 629.386719 L 77.804688 541.472656 Z M 403.65625 629.332031 L 403.65625 344.71875 L 569.445312 398.976562 L 672.246094 541.390625 L 403.628906 629.332031 Z M 403.65625 629.332031 ' />
     </svg>
   )
 }

apps/docs/content/docs/en/agents/custom-tools.mdx

@@ -156,7 +156,7 @@ From **Settings → Custom Tools** you can:
 
 <FAQ items={[
   { question: "Can I use custom tools in standalone blocks (not agents)?", answer: "No. Custom tools are designed for use within Agent blocks, where the AI model decides when to call them. For deterministic tool execution, use the Function block instead." },
-  { question: "How do I pass API keys to my custom tool code?", answer: "Use environment variables with double curly brace syntax: {{MY_API_KEY}}. Create the environment variable in Settings → Secrets, and it will be injected at execution time without appearing in logs." },
+  { question: "How do I pass API keys to my custom tool code?", answer: "Use double curly brace syntax such as {{MY_API_KEY}} for a value saved under Settings → Secrets. The real value is injected at execution time, while exact occurrences are masked in the trace copy. If the tool returns the secret, the raw result still reaches the Agent. See Execution log protection under Secrets for details." },
   { question: "Can I use external npm packages?", answer: "No. Custom tool code runs in a sandboxed environment with access to built-in Node.js modules and fetch(), but not external packages. For complex dependencies, consider calling an external API that wraps the functionality you need." },
   { question: "What's the difference between custom tools and the Function block?", answer: "Custom tools are called by AI agents when they decide the tool is relevant — the agent chooses when to use it. Function blocks run deterministically at a fixed point in the workflow. Use custom tools for agent-driven actions and Function blocks for predictable data transformations." },
   { question: "Are custom tools shared across the workspace?", answer: "Yes. Custom tools are workspace-scoped, so all workspace members can use them in their workflows." },

apps/docs/content/docs/en/agents/mcp.mdx

@@ -72,6 +72,8 @@ Authorization: Bearer {{MCP_API_TOKEN}}
 
 When you type `{{` in the URL or header fields, a dropdown appears showing available workspace environment variables.
 
+When a saved secret is successfully substituted this way, exact occurrences of its value are masked in stored MCP tool-call traces. The real URL or header value still reaches the MCP server unchanged. See [Execution log protection](/platform/credentials#execution-log-protection) for the exact scope and limitations.
+
 ### Testing and Validation
 
 Click **Test Connection** before saving to verify the server is reachable and discover available tools. The test response shows the number of tools found and the protocol version.
@@ -169,4 +171,4 @@ import { FAQ } from '@/components/ui/faq'
   { question: "How do I update MCP tool schemas after a server changes its available tools?", answer: "Click the Refresh button on the MCP server in your workspace settings. This fetches the latest tool schemas from the server and automatically updates any agent blocks that use those tools with the new parameter definitions." },
   { question: "Can permission groups restrict access to MCP tools?", answer: "Yes. On Enterprise-entitled workspaces, any workspace admin can create a permission group that disables MCP tools for its members using the disableMcpTools option. When this is enabled, affected users will not be able to add or use MCP tools in workflows that belong to that workspace." },
   { question: "What happens if an MCP server goes offline during workflow execution?", answer: "If the MCP server is unreachable during execution, the tool call will fail and return an error. In an Agent block, the AI may attempt to handle the failure gracefully. In a standalone MCP Tool block, the workflow step will fail. Check MCP server logs and verify the server is running and accessible to troubleshoot connectivity issues." },
-]} />
+]} />