fix(tools): cut the settings-route registry edge and fix serializer test mocks

Two findings from review, both real.

The settings route still reached the registry:

  settings/[section]/page.tsx -> settings.tsx -> (dynamic import)
  ee/access-control/components/access-control.tsx -> group-detail.tsx
  -> tools/utils.ts -> tools/registry.ts

It reads `getTool(id)?.name` — metadata — so it moves to `getToolMetadata`.
The earlier audit missed it because it walked only from the canvas route, and
the edge hides behind a dynamic `import()` that a static walk skips.

Serializer tests mocked the wrong module. `Serializer` now reads params via
`getToolParams` from `@/tools/metadata`, but the tests still only mocked
`@/tools/utils`, so they controlled nothing and passed because the real
generated artifacts happen to agree with the fixtures.

Adds `toolsMetadataMock` to `@sim/testing/mocks`, backed by the same
`mockToolConfigs` as `toolsUtilsMock` so a test mocking both sees one consistent
tool universe, and mocks it in the three serializer suites.

Verified the mock is now load-bearing: pointing it at a sentinel param makes the
three user-only-required validation tests fail, and restoring it returns all 110
serializer tests to green. Before this they passed either way.

Author: waleedlatif1

.agents/skills/tool-registry-boundary/SKILL.md

@@ -48,6 +48,19 @@ Three non-obvious properties, each of which was measured and is easy to undo by
 - **Empty param entries are stripped.** The registry contains one (`stt_deepgram_v2`), which crashes callers that read `param.type` while iterating.
 - **Lookups resolve versions.** `getTool` maps an unversioned name onto the newest version, and 246 tools are versioned. A plain key lookup would silently report them missing — a quiet correctness bug, not a crash. `resolveToolId` reproduces that against the id set and is differentially tested against the original.
 
+## Testing code that reads tool metadata
+
+Mock the module the code under test actually reads. `vi.mock('@/tools/utils', () => toolsUtilsMock)` only controls `getTool`; code that reads `params`/`outputs`/`name` goes through `@/tools/metadata`, so mocking `tools/utils` there is a **no-op that still passes** — because the real generated artifacts happen to agree with the mock fixtures. The test looks green while controlling nothing.
+
+```ts
+import { blocksMock, toolsMetadataMock, toolsUtilsMock } from '@sim/testing/mocks'
+
+vi.mock('@/tools/utils', () => toolsUtilsMock)      // executable lookup
+vi.mock('@/tools/metadata', () => toolsMetadataMock) // params / outputs / name
+```
+
+Both are backed by the same `mockToolConfigs`, so mocking both gives one consistent tool universe. If you are unsure whether a mock is load-bearing, change a fixture value to a sentinel and confirm the test fails.
+
 ## How to verify an edge actually got cut
 
 Do not eyeball imports — the registry is reached through several redundant paths, so cutting one buys nothing while another survives. Walk the graph:

.claude/commands/tool-registry-boundary.md

@@ -47,6 +47,19 @@ Three non-obvious properties, each of which was measured and is easy to undo by
 - **Empty param entries are stripped.** The registry contains one (`stt_deepgram_v2`), which crashes callers that read `param.type` while iterating.
 - **Lookups resolve versions.** `getTool` maps an unversioned name onto the newest version, and 246 tools are versioned. A plain key lookup would silently report them missing — a quiet correctness bug, not a crash. `resolveToolId` reproduces that against the id set and is differentially tested against the original.
 
+## Testing code that reads tool metadata
+
+Mock the module the code under test actually reads. `vi.mock('@/tools/utils', () => toolsUtilsMock)` only controls `getTool`; code that reads `params`/`outputs`/`name` goes through `@/tools/metadata`, so mocking `tools/utils` there is a **no-op that still passes** — because the real generated artifacts happen to agree with the mock fixtures. The test looks green while controlling nothing.
+
+```ts
+import { blocksMock, toolsMetadataMock, toolsUtilsMock } from '@sim/testing/mocks'
+
+vi.mock('@/tools/utils', () => toolsUtilsMock)      // executable lookup
+vi.mock('@/tools/metadata', () => toolsMetadataMock) // params / outputs / name
+```
+
+Both are backed by the same `mockToolConfigs`, so mocking both gives one consistent tool universe. If you are unsure whether a mock is load-bearing, change a fixture value to a sentinel and confirm the test fails.
+
 ## How to verify an edge actually got cut
 
 Do not eyeball imports — the registry is reached through several redundant paths, so cutting one buys nothing while another survives. Walk the graph:

.cursor/commands/tool-registry-boundary.md

@@ -43,6 +43,19 @@ Three non-obvious properties, each of which was measured and is easy to undo by
 - **Empty param entries are stripped.** The registry contains one (`stt_deepgram_v2`), which crashes callers that read `param.type` while iterating.
 - **Lookups resolve versions.** `getTool` maps an unversioned name onto the newest version, and 246 tools are versioned. A plain key lookup would silently report them missing — a quiet correctness bug, not a crash. `resolveToolId` reproduces that against the id set and is differentially tested against the original.
 
+## Testing code that reads tool metadata
+
+Mock the module the code under test actually reads. `vi.mock('@/tools/utils', () => toolsUtilsMock)` only controls `getTool`; code that reads `params`/`outputs`/`name` goes through `@/tools/metadata`, so mocking `tools/utils` there is a **no-op that still passes** — because the real generated artifacts happen to agree with the mock fixtures. The test looks green while controlling nothing.
+
+```ts
+import { blocksMock, toolsMetadataMock, toolsUtilsMock } from '@sim/testing/mocks'
+
+vi.mock('@/tools/utils', () => toolsUtilsMock)      // executable lookup
+vi.mock('@/tools/metadata', () => toolsMetadataMock) // params / outputs / name
+```
+
+Both are backed by the same `mockToolConfigs`, so mocking both gives one consistent tool universe. If you are unsure whether a mock is load-bearing, change a fixture value to a sentinel and confirm the test fails.
+
 ## How to verify an edge actually got cut
 
 Do not eyeball imports — the registry is reached through several redundant paths, so cutting one buys nothing while another survives. Walk the graph:

apps/sim/ee/access-control/components/group-detail.tsx

@@ -76,7 +76,7 @@ import {
 import type { ProviderId } from '@/providers/types'
 import { getAllProviderIds, getProviderFromModel } from '@/providers/utils'
 import type { ProviderName } from '@/stores/providers'
-import { getTool } from '@/tools/utils'
+import { getToolMetadata } from '@/tools/metadata'
 
 const logger = createLogger('AccessControlGroupDetail')
 
@@ -733,7 +733,7 @@ function BlockToolRow({
   const checkboxId = `block-${block.type}`
 
   const toolItems = useMemo<DenylistGridItem[]>(
-    () => (block.tools?.access ?? []).map((id) => ({ id, label: getTool(id)?.name ?? id })),
+    () => (block.tools?.access ?? []).map((id) => ({ id, label: getToolMetadata(id)?.name ?? id })),
     [block.tools?.access]
   )
   const isExpandable = toolItems.length > 1

apps/sim/serializer/custom-block-lifecycle.test.ts

@@ -7,7 +7,7 @@
  *  - a deleted *input* on a live custom block no longer leaks its stale value into
  *    the child `inputMapping` (Bug 1).
  */
-import { toolsUtilsMock } from '@sim/testing/mocks'
+import { toolsMetadataMock, toolsUtilsMock } from '@sim/testing/mocks'
 import { beforeEach, describe, expect, it, vi } from 'vitest'
 
 // Build the custom-block configs INSIDE the factory (hoisted) so no top-level
@@ -33,6 +33,7 @@ vi.mock('@/blocks', async () => {
   return { getBlock, getAllBlocks: () => Object.values(mockBlockConfigs) }
 })
 vi.mock('@/tools/utils', () => toolsUtilsMock)
+vi.mock('@/tools/metadata', () => toolsMetadataMock)
 
 import { extractBlockParams, Serializer } from '@/serializer/index'
 

apps/sim/serializer/field-analysis.test.ts

@@ -5,12 +5,13 @@
  * (collectBlockFieldIssues / extractBlockParams) — the single source of truth
  * shared by the serializer's required-field validation and the copilot lint.
  */
-import { blocksMock, toolsUtilsMock } from '@sim/testing/mocks'
+import { blocksMock, toolsMetadataMock, toolsUtilsMock } from '@sim/testing/mocks'
 import { describe, expect, it, vi } from 'vitest'
 
 const { svcConfig } = vi.hoisted(() => ({ svcConfig: { value: null as any } }))
 
 vi.mock('@/tools/utils', () => toolsUtilsMock)
+vi.mock('@/tools/metadata', () => toolsMetadataMock)
 vi.mock('@/blocks', () => ({
   ...blocksMock,
   getBlock: (type: string) => (type === 'svc' ? svcConfig.value : blocksMock.getBlock(type)),

apps/sim/serializer/index.test.ts

@@ -18,13 +18,14 @@ import {
   createMinimalWorkflowState,
   createMissingMetadataWorkflow,
 } from '@sim/testing/factories'
-import { blocksMock, toolsUtilsMock } from '@sim/testing/mocks'
+import { blocksMock, toolsMetadataMock, toolsUtilsMock } from '@sim/testing/mocks'
 import { describe, expect, it, vi } from 'vitest'
 import { Serializer } from '@/serializer/index'
 import type { SerializedWorkflow } from '@/serializer/types'
 
 vi.mock('@/blocks', () => blocksMock)
 vi.mock('@/tools/utils', () => toolsUtilsMock)
+vi.mock('@/tools/metadata', () => toolsMetadataMock)
 
 describe('Serializer', () => {
   describe('serializeWorkflow', () => {

packages/testing/src/mocks/blocks.mock.ts

@@ -338,7 +338,25 @@ export const blocksMock = {
 
 /**
  * Pre-configured tools/utils mock for use with vi.mock('@/tools/utils', () => toolsUtilsMock).
+ *
+ * Only mocks the *executable* lookup. Code that reads a tool's shape now goes
+ * through `@/tools/metadata`, so mocking this alone leaves such code reading the
+ * real generated artifacts — see {@link toolsMetadataMock}.
  */
 export const toolsUtilsMock = {
   getTool: createMockGetTool(),
 }
+
+/**
+ * Pre-configured metadata mock for use with
+ * `vi.mock('@/tools/metadata', () => toolsMetadataMock)`.
+ *
+ * Backed by the same `mockToolConfigs` as {@link toolsUtilsMock}, so a test that
+ * mocks both sees one consistent tool universe. Mock this wherever the code under
+ * test reads `params`, `outputs` or `name` — mocking `@/tools/utils` there is a
+ * no-op that only appears to work because the real artifacts happen to agree.
+ */
+export const toolsMetadataMock = {
+  getToolMetadata: createMockGetTool(),
+  getToolParams: (toolId: string) => createMockGetTool()(toolId)?.params,
+}

packages/testing/src/mocks/index.ts

@@ -33,6 +33,7 @@ export {
   createMockGetTool,
   mockBlockConfigs,
   mockToolConfigs,
+  toolsMetadataMock,
   toolsUtilsMock,
 } from './blocks.mock'
 // Copilot HTTP mocks (for @/lib/copilot/request/http)