​

Plan: Remove Tool-step enabledIntegrations

​

Goal

Remove the Tool-channel step control enabledIntegrations (integration-identifier filter) and all related UI, schema, DTO, sanitize, render, and worker filtering logic. After removal, Tool steps always deliver to all active Tool integrations in the environment (previous empty/undefined behavior).

​

Out of scope

• enabledProviders in libs/maily-core (editor suggestion providers) — different concept; leave untouched.
• libs/internal-sdk — auto-generated; do not edit.
• DB migration — not required (see Compat).

​

Files / symbols to change

​

Delete

​

Dashboard

​

Schemas / DTOs / sanitize

​

API / Worker

​

Compat / migration notes

• Persisted workflow step control values may still contain enabledIntegrations.
• Prefer no DB migration:
  • sanitizeTool only copies known keys → next normalize/save strips the field.
  • Worker ignores the key after removal (always uses active integrations).
  • Zod/JSON schema is .strict() / additionalProperties: false → if raw validation runs before sanitize, the stale key may surface as a step-issue until the workflow is re-saved. Acceptable; matches existing unknown-key handling.
• In-flight bridge outputs that still include the key: framework output schema will reject unknown properties if validated; renderer no longer emits it. Low risk for new traffic.

​

Verification

1. Ripgrep confirms no Tool-channel enabledIntegrations / ToolEnabledProviders / filterToolIntegrationsByEnabledIdentifiers remain (except intentional non-Tool enabledProviders in maily-core).
2. Unit tests:
   • apps/worker — send-message-tool.usecase.spec.ts
   • libs/application-generic — tool-control.schema.spec.ts
   • packages/framework — tool.schema.test.ts
3. Manual (optional): open a Tool step in dashboard — “Enabled Providers” UI gone; send still fans out to all active Tool integrations.