v0.7.16: security hardening, db o11y and profiling, settings UI

Author: waleedlatif1

.claude/commands/add-block.md

@@ -600,17 +600,20 @@ export const ServiceV2Block: BlockConfig = {
 
 ## Registering Blocks
 
-After creating the block, remind the user to:
-1. Import in `apps/sim/blocks/registry.ts`
-2. Add to the `registry` object (alphabetically):
+After creating the block, remind the user to register it in `apps/sim/blocks/registry-maps.ts` (the data maps live here; `registry.ts` holds only the accessor functions). Add the import and an entry to each map alphabetically:
 
 ```typescript
-import { ServiceBlock } from '@/blocks/blocks/service'
+import { ServiceBlock, ServiceBlockMeta } from '@/blocks/blocks/service'
 
-export const registry: Record<string, BlockConfig> = {
+export const BLOCK_REGISTRY: Record<string, BlockConfig> = {
   // ... existing blocks ...
   service: ServiceBlock,
 }
+
+export const BLOCK_META_REGISTRY: Record<string, BlockMeta> = {
+  // ... existing metas ...
+  service: ServiceBlockMeta,
+}
 ```
 
 ## Complete Example
@@ -840,7 +843,7 @@ Derive templates from the service's real use cases. Each prompt should name a co
 - [ ] Tools.access lists all tool IDs (snake_case)
 - [ ] Tools.config.tool returns correct tool ID (snake_case)
 - [ ] Outputs match tool outputs
-- [ ] Block registered in registry.ts
+- [ ] Block + meta registered in registry-maps.ts (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`)
 - [ ] If icon missing: asked user to provide SVG
 - [ ] If triggers exist: `triggers` config set, trigger subBlocks spread
 - [ ] Optional/rarely-used fields set to `mode: 'advanced'`

.claude/commands/add-integration.md

@@ -364,17 +364,25 @@ export const tools: Record<string, ToolConfig> = {
 }
 ```
 
-### Block Registry (`apps/sim/blocks/registry.ts`)
+### Block Registry (`apps/sim/blocks/registry-maps.ts`)
+
+The data maps (`BLOCK_REGISTRY` + `BLOCK_META_REGISTRY`) live in `registry-maps.ts`; `registry.ts` holds only the accessor functions. Add the import and an entry to each map alphabetically:
 
 ```typescript
 // Add import (alphabetically)
-import { {Service}Block } from '@/blocks/blocks/{service}'
+import { {Service}Block, {Service}BlockMeta } from '@/blocks/blocks/{service}'
 
-// Add to registry (alphabetically)
-export const registry: Record<string, BlockConfig> = {
+// Add to the config map (alphabetically)
+export const BLOCK_REGISTRY: Record<string, BlockConfig> = {
   // ... existing blocks ...
   {service}: {Service}Block,
 }
+
+// Add to the catalog-meta map (alphabetically)
+export const BLOCK_META_REGISTRY: Record<string, BlockMeta> = {
+  // ... existing metas ...
+  {service}: {Service}BlockMeta,
+}
 ```
 
 ### Trigger Registry (`apps/sim/triggers/registry.ts`) - If triggers exist
@@ -443,7 +451,7 @@ If creating V2 versions (API-aligned outputs):
 - [ ] Configured tools.access with all tool IDs
 - [ ] Configured tools.config.tool selector
 - [ ] Defined outputs matching tool outputs
-- [ ] Registered block in `blocks/registry.ts`
+- [ ] Registered block + meta in `blocks/registry-maps.ts` (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`)
 - [ ] If triggers: set `triggers.enabled` and `triggers.available`
 - [ ] If triggers: spread trigger subBlocks with `getTrigger()`
 - [ ] Exported `{Service}BlockMeta` with at least 7 templates

.claude/commands/validate-integration.md

@@ -24,7 +24,7 @@ Read **every** file for the integration — do not skip any:
 apps/sim/tools/{service}/          # All tool files, types.ts, index.ts
 apps/sim/blocks/blocks/{service}.ts # Block definition
 apps/sim/tools/registry.ts          # Tool registry entries for this service
-apps/sim/blocks/registry.ts         # Block registry entry for this service
+apps/sim/blocks/registry-maps.ts    # Block + meta registry entry (BLOCK_REGISTRY / BLOCK_META_REGISTRY)
 apps/sim/components/icons.tsx        # Icon definition
 apps/sim/lib/auth/auth.ts           # OAuth config — should use getCanonicalScopesForProvider()
 apps/sim/lib/oauth/oauth.ts         # OAuth provider config — single source of truth for scopes
@@ -190,7 +190,7 @@ For **each tool** in `tools.access`:
 - [ ] `bgColor` uses the service's brand color hex
 - [ ] `icon` references the correct icon component from `@/components/icons`
 - [ ] `authMode` is set correctly (`AuthMode.OAuth` or `AuthMode.ApiKey`)
-- [ ] Block is registered in `blocks/registry.ts` alphabetically
+- [ ] Block + meta are registered in `blocks/registry-maps.ts` (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`) alphabetically
 
 ### BlockMeta
 - [ ] `{Service}BlockMeta` is exported in the same file as the block

.claude/rules/sim-integrations.md

@@ -13,7 +13,7 @@ The full authoring instructions — tool/block/icon/trigger scaffolding, SubBloc
 
 ## Hard rules (don't get these wrong)
 
-- Tool IDs are `snake_case` (`service_action`). Register tools in `tools/registry.ts`, blocks in `blocks/registry.ts` (alphabetically), triggers in `triggers/registry.ts`.
+- Tool IDs are `snake_case` (`service_action`). Register tools in `tools/registry.ts`, blocks in `blocks/registry-maps.ts` (the `BLOCK_REGISTRY` config map + `BLOCK_META_REGISTRY` catalog-meta map, alphabetically — `blocks/registry.ts` holds only the accessor functions), triggers in `triggers/registry.ts`.
 - Type coercions (`Number()`, etc.) belong in `tools.config.params` (runs at execution, after variable resolution) — never in `tools.config.tool` (runs at serialization; coercing there destroys dynamic `<Block.output>` references).
 - `canonicalParamId` must NOT match any subblock's `id`, must be unique per operation/condition context, and all subblocks in a canonical group must share the same `required` status. The `inputs` section and the params function reference canonical IDs, not raw subblock IDs.
 - Blocks must also set the catalog/UI metadata fields `integrationType`, `tags`, `authMode`, `docsLink`, and export a `{Service}BlockMeta` — see the `/add-block` skill's BlockMeta section for details.

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

@@ -101,6 +101,46 @@ Adding a new settings page:
   Conditional items become array spreads: `...(canManage ? [{…}] : [])`. Never
   hand-roll the `<DropdownMenu>` + `<MoreHorizontal>` trigger per page.
 
+## Save / Discard + unsaved-changes guard
+
+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`** (`…/components/save-discard-actions/save-discard-actions`)
+  — the canonical dirty-gated **Discard + Save** chip pair. Renders nothing when
+  `!dirty`; otherwise a fragment so it composes beside sibling chips (a detail
+  view's Delete / Remove override, a Share chip). Props: `dirty`, `saving`,
+  `onSave`, `onDiscard`, `saveDisabled?`, `saveLabel?`, `savingLabel?`. Put it in
+  the `SettingsPanel actions` slot (top-level pages) or the detail header bar.
+- **`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
+  apply for free) and returns `{ showUnsavedModal, setShowUnsavedModal, guardBack,
+  confirmDiscard }` for a detail view's **in-view back** chip.
+  - **Top-level pages** (whitelabeling, sso): call it **unassigned** —
+    `useSettingsUnsavedGuard({ isDirty: hasChanges })` — they only need the
+    store-sync; the sidebar/`beforeunload` do the rest.
+  - **Detail sub-views** (data-retention, access-control group-detail): route the
+    back chip through `onClick={() => guard.guardBack(closeFn)}` and render the
+    shared `<UnsavedChangesModal open={guard.showUnsavedModal}
+    onOpenChange={guard.setShowUnsavedModal} onDiscard={guard.confirmDiscard} />`
+    (from `@/app/workspace/[workspaceId]/components/credential-detail`). The
+    in-view header **Discard** chip (via `SaveDiscardActions onDiscard`) is a
+    *reset to original* — distinct from the back-confirm's discard, which leaves.
+- **`useSettingsBeforeUnload`** is mounted **once** in the settings shell
+  (`settings/[section]/settings.tsx`) — never add a per-page `beforeunload`.
+- **Dirty *computation* stays local** (shapes differ: field-compare vs
+  normalize+stringify) — only how dirty is *consumed* is shared. Derive it (a
+  `const`/`useMemo`), never store it in `useState`.
+- **CRITICAL — rules of hooks:** call `useSettingsUnsavedGuard(...)`
+  **unconditionally, before every early-return gate** (entitlement / loading /
+  not-entitled `return <SettingsEmptyState>`). A hook placed after a gate is
+  skipped on gated renders and crashes.
+- The route-based credential detail keeps its own `useUnsavedChangesGuard` (it
+  guards real `router.push` navigation + browser Back via a history sentinel);
+  it already shares `UnsavedChangesModal`, so copy stays unified.
+
 ## Detail sub-views (the one exception)
 
 A drill-down view reached from a list row (selected MCP server, workflow MCP
@@ -119,5 +159,6 @@ A settings page is design-system-clean when:
 - [ ] Header chips are in `actions`; a standalone search is in the `search` prop.
 - [ ] Its `NavigationItem` has an accurate, consistent-length `description`.
 - [ ] Detail sub-views and entitlement/loading gates keep their own chrome (intentional).
+- [ ] If it has editable state: Save/Discard go through `SaveDiscardActions`, dirty is wired via `useSettingsUnsavedGuard` (called before any early-return gate), and there is **no** hand-rolled Save button / `beforeunload` / "Unsaved changes" modal.
 - [ ] No business logic, handlers, or conditional rendering changed by the migration.
 - [ ] `tsc`, `biome`, and the page's tests pass.

.claude/skills/add-settings-page/SKILL.md

@@ -29,7 +29,15 @@ Key paths:
    bar, scroll region, content column, or title block. Put header buttons in
    `actions`, a standalone search in `search={{ value, onChange, placeholder }}`,
    and the page content as `children`. Modals go beside the panel inside a `<>`.
-4. **Verify:** `cd apps/sim && bunx tsc --noEmit`; `bunx biome check --write <file>`.
+4. **If the page has editable state**, wire the shared save/discard stack — put
+   `SaveDiscardActions` (dirty-gated Discard+Save chips) in `actions`, and call
+   `useSettingsUnsavedGuard({ isDirty })` **before any early-return gate**.
+   Detail sub-views additionally route the back chip through
+   `guard.guardBack(closeFn)` and render the shared `UnsavedChangesModal`. Never
+   hand-roll a Save button, a `beforeunload`, or an "Unsaved changes" modal —
+   they're centralized. See the "Save / Discard + unsaved-changes guard" section
+   in `.claude/rules/sim-settings-pages.md`.
+5. **Verify:** `cd apps/sim && bunx tsc --noEmit`; `bunx biome check --write <file>`.
 
 ## Mode B — Audit existing settings pages
 
@@ -44,6 +52,11 @@ For each page component, confirm the checklist in `.claude/rules/sim-settings-pa
    `git grep -n "text-\[var(--text-body)\] text-lg" -- 'apps/sim/**/settings/' 'apps/sim/ee/'`
 3. Confirm each page imports `SettingsPanel` and that its `NavigationItem` has an
    accurate `description` of consistent length with its peers.
+   - Editable pages: confirm Save/Discard go through `SaveDiscardActions` and
+     dirty is wired via `useSettingsUnsavedGuard` (called before early-return
+     gates) — flag any hand-rolled Save button, `beforeunload`, or unsaved modal.
+     `git grep -n "beforeunload" -- 'apps/sim/**/settings/' 'apps/sim/ee/'`
+     should only hit the centralized `use-settings-before-unload.ts`.
 4. When migrating a page, change ONLY the structural shell→`SettingsPanel` swap:
    move header chips to `actions`, the standalone search to `search`, delete the
    `<h1>` title block, replace the three closing `</div>` (column/scroll/shell)

.cursor/commands/add-block.md

@@ -608,17 +608,20 @@ export const ServiceV2Block: BlockConfig = {
 
 ## Registering Blocks
 
-After creating the block, remind the user to:
-1. Import in `apps/sim/blocks/registry.ts`
-2. Add to the `registry` object (alphabetically):
+After creating the block, remind the user to register it in `apps/sim/blocks/registry-maps.ts` (the data maps live here; `registry.ts` holds only the accessor functions). Add the import and an entry to each map alphabetically:
 
 ```typescript
-import { ServiceBlock } from '@/blocks/blocks/service'
+import { ServiceBlock, ServiceBlockMeta } from '@/blocks/blocks/service'
 
-export const registry: Record<string, BlockConfig> = {
+export const BLOCK_REGISTRY: Record<string, BlockConfig> = {
   // ... existing blocks ...
   service: ServiceBlock,
 }
+
+export const BLOCK_META_REGISTRY: Record<string, BlockMeta> = {
+  // ... existing metas ...
+  service: ServiceBlockMeta,
+}
 ```
 
 ## Complete Example
@@ -847,7 +850,7 @@ Derive templates from the service's real use cases. Each prompt should name a co
 - [ ] Tools.access lists all tool IDs (snake_case)
 - [ ] Tools.config.tool returns correct tool ID (snake_case)
 - [ ] Outputs match tool outputs
-- [ ] Block registered in registry.ts
+- [ ] Block + meta registered in registry-maps.ts (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`)
 - [ ] If icon missing: asked user to provide SVG
 - [ ] If triggers exist: `triggers` config set, trigger subBlocks spread
 - [ ] Optional/rarely-used fields set to `mode: 'advanced'`

.cursor/commands/add-integration.md

@@ -337,17 +337,25 @@ export const tools: Record<string, ToolConfig> = {
 }
 ```
 
-### Block Registry (`apps/sim/blocks/registry.ts`)
+### Block Registry (`apps/sim/blocks/registry-maps.ts`)
+
+The data maps (`BLOCK_REGISTRY` + `BLOCK_META_REGISTRY`) live in `registry-maps.ts`; `registry.ts` holds only the accessor functions. Add the import and an entry to each map alphabetically:
 
 ```typescript
 // Add import (alphabetically)
-import { {Service}Block } from '@/blocks/blocks/{service}'
+import { {Service}Block, {Service}BlockMeta } from '@/blocks/blocks/{service}'
 
-// Add to registry (alphabetically)
-export const registry: Record<string, BlockConfig> = {
+// Add to the config map (alphabetically)
+export const BLOCK_REGISTRY: Record<string, BlockConfig> = {
   // ... existing blocks ...
   {service}: {Service}Block,
 }
+
+// Add to the catalog-meta map (alphabetically)
+export const BLOCK_META_REGISTRY: Record<string, BlockMeta> = {
+  // ... existing metas ...
+  {service}: {Service}BlockMeta,
+}
 ```
 
 ### Trigger Registry (`apps/sim/triggers/registry.ts`) - If triggers exist
@@ -416,7 +424,7 @@ If creating V2 versions (API-aligned outputs):
 - [ ] Configured tools.access with all tool IDs
 - [ ] Configured tools.config.tool selector
 - [ ] Defined outputs matching tool outputs
-- [ ] Registered block in `blocks/registry.ts`
+- [ ] Registered block + meta in `blocks/registry-maps.ts` (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`)
 - [ ] If triggers: set `triggers.enabled` and `triggers.available`
 - [ ] If triggers: spread trigger subBlocks with `getTrigger()`
 

.cursor/commands/validate-integration.md

@@ -19,7 +19,7 @@ Read **every** file for the integration — do not skip any:
 apps/sim/tools/{service}/          # All tool files, types.ts, index.ts
 apps/sim/blocks/blocks/{service}.ts # Block definition
 apps/sim/tools/registry.ts          # Tool registry entries for this service
-apps/sim/blocks/registry.ts         # Block registry entry for this service
+apps/sim/blocks/registry-maps.ts    # Block + meta registry entry (BLOCK_REGISTRY / BLOCK_META_REGISTRY)
 apps/sim/components/icons.tsx        # Icon definition
 apps/sim/lib/auth/auth.ts           # OAuth config — should use getCanonicalScopesForProvider()
 apps/sim/lib/oauth/oauth.ts         # OAuth provider config — single source of truth for scopes
@@ -185,7 +185,7 @@ For **each tool** in `tools.access`:
 - [ ] `bgColor` uses the service's brand color hex
 - [ ] `icon` references the correct icon component from `@/components/icons`
 - [ ] `authMode` is set correctly (`AuthMode.OAuth` or `AuthMode.ApiKey`)
-- [ ] Block is registered in `blocks/registry.ts` alphabetically
+- [ ] Block + meta are registered in `blocks/registry-maps.ts` (`BLOCK_REGISTRY` / `BLOCK_META_REGISTRY`) alphabetically
 
 ### BlockMeta
 - [ ] `{Service}BlockMeta` is exported in the same file as the block

.cursor/rules/sim-integrations.mdc

@@ -10,7 +10,7 @@ The full authoring instructions — tool/block/icon/trigger scaffolding, SubBloc
 
 ## Hard rules (don't get these wrong)
 
-- Tool IDs are `snake_case` (`service_action`). Register tools in `tools/registry.ts`, blocks in `blocks/registry.ts` (alphabetically), triggers in `triggers/registry.ts`.
+- Tool IDs are `snake_case` (`service_action`). Register tools in `tools/registry.ts`, blocks in `blocks/registry-maps.ts` (the `BLOCK_REGISTRY` config map + `BLOCK_META_REGISTRY` catalog-meta map, alphabetically — `blocks/registry.ts` holds only the accessor functions), triggers in `triggers/registry.ts`.
 - Type coercions (`Number()`, etc.) belong in `tools.config.params` (runs at execution, after variable resolution) — never in `tools.config.tool` (runs at serialization; coercing there destroys dynamic `<Block.output>` references).
 - `canonicalParamId` must NOT match any subblock's `id`, must be unique per operation/condition context, and all subblocks in a canonical group must share the same `required` status. The `inputs` section and the params function reference canonical IDs, not raw subblock IDs.
 - Blocks must also set the catalog/UI metadata fields `integrationType`, `tags`, `authMode`, `docsLink`, and export a `{Service}BlockMeta` — see the `/add-block` skill's BlockMeta section for details.