perf(dev): SIM_DEV_MINIMAL_REGISTRY mode to slash local dev-server RAM (#5223)

* perf(dev): SIM_DEV_MINIMAL_REGISTRY mode to slash local dev-server RAM

Adds a dev-only escape hatch (`bun run dev:minimal`, or `dev:full:minimal` with
the realtime server): when SIM_DEV_MINIMAL_REGISTRY=1, a Turbopack/webpack
resolve-alias swaps the two heavy registries for tiny curated variants —
`@/tools/registry` → 2 tools, `@/blocks/registry-maps` → ~20 core blocks. The
shared workspace layout drags the full ~247-tool registry (~2,074 modules) into
every route via providers/utils → tools/params, and the editor/executor pull all
~268 block configs; aliasing both stops Turbopack from compiling those graphs at
all.

To make the blocks alias clean, the heavy block import maps move out of
registry.ts into registry-maps.ts (registry.ts keeps only its accessors,
importing the maps); its public API is unchanged and full builds/tests use the
full maps. The alias is gated on isDev + the flag and is never applied in
production.

Measured (Turbopack dev, authenticated, /logs): peak next-server RSS ~16 GB →
~4.7 GB, compile 4.9 min → ~18 s; the workflow editor route similarly drops to
~5 GB / ~17 s. Only http_request + function_execute and the curated core blocks
work in minimal mode; unset the flag for the full set.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* perf(dev): add table block to minimal registry; doc block registration in registry-maps

Adds the Table block to the SIM_DEV_MINIMAL_REGISTRY curated set so the
tables surface works under dev:minimal. Updates the integration skills/rules
and CLAUDE.md to point block registration at blocks/registry-maps.ts (the
BLOCK_REGISTRY / BLOCK_META_REGISTRY maps), reflecting that registry.ts now
holds only the accessor functions.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* chore(dev): rename dev:full:minimal → dev:full:minimal-registry

Matches the dev:full:* formatting and makes the suffix self-explanatory —
it is the registry that's minimal, not the dev stack.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: TheodoreSpeaks

.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.

.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.

CLAUDE.md

@@ -469,7 +469,7 @@ New integrations are built in order: **Tools** → **Block** → **Icon** → (o
 
 Two hard rules that the skills assume:
 
-- **Tool IDs are `snake_case`** (`service_action`) and must be registered in `tools/registry.ts`; blocks register in `blocks/registry.ts` (alphabetically).
+- **Tool IDs are `snake_case`** (`service_action`) and must be registered in `tools/registry.ts`; blocks register in `blocks/registry-maps.ts` — the `BLOCK_REGISTRY` config map and `BLOCK_META_REGISTRY` catalog-meta map (alphabetically). `blocks/registry.ts` holds only the accessor functions (`getBlock`, `getAllBlocks`, …).
 - **`tools.config.tool` runs during serialization (before variable resolution)** — never do `Number()` or other type coercions there, or dynamic references like `<Block.output>` are destroyed. Put all type coercions in `tools.config.params`, which runs during execution after variables resolve.
 
 For the full authoring instructions — SubBlock property tables, `condition`/`dependsOn`/`required`/`mode`/`canonicalParamId` syntax, required block metadata (`integrationType`, `tags`, `authMode`, `docsLink`, `{Service}BlockMeta`), file-input/`normalizeFileInput` patterns, and checklists — use the skills: `/add-integration` (end-to-end), `/add-tools`, `/add-block`, `/add-trigger`.

apps/sim/blocks/registry-maps.minimal.ts

@@ -0,0 +1,55 @@
+import { AgentBlock } from '@/blocks/blocks/agent'
+import { ApiBlock } from '@/blocks/blocks/api'
+import { ApiTriggerBlock } from '@/blocks/blocks/api_trigger'
+import { ChatTriggerBlock } from '@/blocks/blocks/chat_trigger'
+import { ConditionBlock } from '@/blocks/blocks/condition'
+import { EvaluatorBlock } from '@/blocks/blocks/evaluator'
+import { FunctionBlock } from '@/blocks/blocks/function'
+import { GenericWebhookBlock } from '@/blocks/blocks/generic_webhook'
+import { InputTriggerBlock } from '@/blocks/blocks/input_trigger'
+import { KnowledgeBlock } from '@/blocks/blocks/knowledge'
+import { ManualTriggerBlock } from '@/blocks/blocks/manual_trigger'
+import { MemoryBlock } from '@/blocks/blocks/memory'
+import { NoteBlock } from '@/blocks/blocks/note'
+import { ResponseBlock } from '@/blocks/blocks/response'
+import { RouterBlock } from '@/blocks/blocks/router'
+import { ScheduleBlock } from '@/blocks/blocks/schedule'
+import { StartTriggerBlock } from '@/blocks/blocks/start_trigger'
+import { StarterBlock } from '@/blocks/blocks/starter'
+import { TableBlock } from '@/blocks/blocks/table'
+import { VariablesBlock } from '@/blocks/blocks/variables'
+import { WorkflowBlock } from '@/blocks/blocks/workflow'
+import type { BlockConfig, BlockMeta } from '@/blocks/types'
+
+/**
+ * Dev-only minimal block maps. Swapped in for `@/blocks/registry-maps` via a
+ * resolve-alias when `SIM_DEV_MINIMAL_REGISTRY=1` (see next.config.ts) so the
+ * dev server only compiles a curated core set of block configs instead of all
+ * ~268. Only these blocks resolve in the editor/executor in minimal mode; unset
+ * the flag for the full set. NEVER aliased in production.
+ */
+export const BLOCK_REGISTRY: Record<string, BlockConfig> = {
+  agent: AgentBlock,
+  api: ApiBlock,
+  api_trigger: ApiTriggerBlock,
+  chat_trigger: ChatTriggerBlock,
+  condition: ConditionBlock,
+  evaluator: EvaluatorBlock,
+  function: FunctionBlock,
+  generic_webhook: GenericWebhookBlock,
+  input_trigger: InputTriggerBlock,
+  knowledge: KnowledgeBlock,
+  manual_trigger: ManualTriggerBlock,
+  memory: MemoryBlock,
+  note: NoteBlock,
+  response: ResponseBlock,
+  router: RouterBlock,
+  schedule: ScheduleBlock,
+  start_trigger: StartTriggerBlock,
+  starter: StarterBlock,
+  table: TableBlock,
+  variables: VariablesBlock,
+  workflow: WorkflowBlock,
+}
+
+export const BLOCK_META_REGISTRY: Record<string, BlockMeta> = {}