perf(tools): guard the tool-registry client boundary in CI

[waleedlatif1]

Stacked on #6155 → #6153 → #6152 → #6151. Bases retarget as each merges.

Makes the win from #6155 permanent.

Why a lint and not a convention

The registry was 71–82% of every workspace route's module graph, and the two edges that put it there were invisible at the call site:

• providers/utils.ts imported mergeToolParameters
• mcp-dynamic-args.tsx imported formatParameterLabel

Neither looks remotely like "pull in 4,700 modules of SDK clients." A reviewer will not catch the third one either.

What it does

check-tool-registry-boundary.ts walks the value-import graph — skipping import type, which is erased at compile time — from the workspace layout and the four routes that mount inside it, and fails if @/tools/registry is reachable, printing the exact chain.

✓ app/workspace/layout.tsx — 1063 modules, registry unreachable
✓ app/workspace/[workspaceId]/w/page.tsx — 1908 modules, registry unreachable
✓ app/workspace/[workspaceId]/logs/page.tsx — 1543 modules, registry unreachable
✓ app/workspace/[workspaceId]/tables/page.tsx — 1217 modules, registry unreachable
✓ app/workspace/[workspaceId]/files/page.tsx — 1310 modules, registry unreachable

Verified it can fail

Reintroduced a getTool import in serializer/index.ts:

❌ app/workspace/[workspaceId]/w/page.tsx can reach @/tools/registry via:
     apps/sim/app/workspace/[workspaceId]/w/page.tsx
     apps/sim/app/workspace/[workspaceId]/w/components/sidebar/hooks/index.ts
     apps/sim/app/workspace/[workspaceId]/w/components/sidebar/hooks/use-workflow-operations.ts
     apps/sim/stores/workflow-diff/store.ts
     apps/sim/serializer/index.ts
     apps/sim/tools/utils.ts
     apps/sim/tools/registry.ts

Exit 1 with the regression, exit 0 after removing it.

No allowlist, on purpose

The fix for a failure is always to move the symbol the file actually needs into a registry-free module — the way mergeToolParameters and formatParameterLabel were. An allowlist would let the graph silently grow back one entry at a time.

--verbose prints per-route module counts, which is also the fastest way to see whether a change moved the graph.

Test plan

• Passes on the current tree (5 routes)
• Fails (exit 1) with an injected getTool import, with a correct chain
• Wired into CI next to the other graph audits
• Skill updated with the guard and the no-allowlist rule

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 1, 2026 6:08pm

[cursor]

PR Summary

Low Risk
Adds static analysis and CI only; no application runtime or auth/data-path changes.

Overview
Adds a CI guard so workspace routes cannot silently pull @/tools/registry (~4,700 modules) back into client-reachable graphs after the boundary work in earlier PRs.

scripts/check-tool-registry-boundary.ts discovers every page.tsx and layout.tsx under app/workspace, walks value imports and re-exports (skipping import type), and fails with the full import chain if tools/registry.ts is reachable. --verbose prints per-entry module counts. There is no allowlist — failures are fixed by moving symbols to registry-free modules (as documented for mergeToolParameters / formatParameterLabel).

Wired as bun run check:tool-registry-boundary in root package.json and the "Tool registry client-boundary audit" step in .github/workflows/test-build.yml. The tool-registry-boundary skill/command docs add a "The guard" section describing the check and remediation.

^{Reviewed by Cursor Bugbot for commit 1ea6bb3. Configure here.}

[greptile-apps]

Greptile Summary

This PR adds a CI audit that traverses workspace-route imports and rejects paths reaching the executable tool registry.

• Adds the graph-walking boundary checker and package script.
• Runs the checker in the test/build workflow.
• Documents the guard, diagnostics, and no-allowlist policy across agent command surfaces.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking gap in the audit's coverage of dynamic import() and require() edges.

The CI check correctly covers static local import and re-export paths, but existing workspace code demonstrates runtime import forms that its parser does not traverse, leaving those forms outside the promised boundary.

Files Needing Attention: scripts/check-tool-registry-boundary.ts

Important Files Changed

Filename	Overview
scripts/check-tool-registry-boundary.ts	Adds the route graph walker and registry check, but its edge extraction omits dynamic import() and require().
.github/workflows/test-build.yml	Adds the boundary audit to the existing test/build job.
package.json	Exposes the new checker through a Bun package script.
.agents/skills/tool-registry-boundary/SKILL.md	Documents how to run and remediate failures from the new guard.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  CI[CI boundary audit] --> E[Five workspace entries]
  E --> P[Parse static imports and re-exports]
  P --> R[Resolve local modules]
  R -->|new edge| P
  R --> F{Registry reachable?}
  F -->|Yes| Fail[Fail with import chain]
  F -->|No| Pass[Pass audit]
  E -. omitted .-> D[Dynamic import / require edges]

Loading

_{Reviews (1): Last reviewed commit: "perf(tools): guard the tool-registry cli..." | Re-trigger Greptile}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1ea6bb3. Configure here.}

[waleedlatif1]

Note on the 4/5 score above

That review ran at ~06:00 UTC against an earlier head; the branch is now at a later commit and Greptile has not re-run despite repeated triggers (it does not appear to re-review on force-push for these stacked bases). Flagging it so the stale score isn't read as an open concern.

Its stated reason — the guard not traversing dynamic import() / require() edges, and guarding the wrong layout — has since been fixed, with each fix verified rather than asserted. Every review thread on this PR is resolved, and the reasoning is in the thread replies.

The full Test and Build workflow was dispatched against the stack head and passed. Note that ci.yml only fires for PRs targeting main/staging/dev, so stacked PRs don't get it automatically — worth re-checking when each retargets to staging on merge.