Add A New Connector

Use this page when you are adding a built-in connector and want the shortest current path without rereading the full feature specs.

What This Covers

Add a connector that fits an existing live domain such as mail, contact, calendar, workspace-chat, work-item, code-repository, file-resource, business-record, or knowledge-page.
Put stable connector metadata in the shared registry and executable behavior in the API runtime manifest.
Keep provider-specific code inside the provider adapter or owning auth/credential path.
Pick the right verification lanes: unit/contract tests, real-provider E2E, local prompt packs, and browser review.
This page covers built-in connectors. Future custom/literal MCP connector work is a separate path.

Fast Path

Confirm whether the connector uses OAuth, a user-managed API key/PAT, or a deployment API key.
Confirm which existing live domain owns the provider’s data. If none fits, define the shared domain before provider code.
Add the connector definition in packages/domain/src/connectors/connectorRegistry.ts.
Add executable behavior in the API runtime manifest and provider adapter.
Add focused tests for registry shape, auth behavior, live adapter behavior, web add/connect UX, and any CMS credential surface.
Audit shared seams before coding provider-local behavior: resource selection, dependent provider options, OAuth scope union, provider-family resource scopes, source provenance, fallback states, env examples, evals, and local prompt-pack coverage.
Add or update deterministic chat evals when routing, grounding, no-match behavior, or a shared domain contract changes.
Run real-provider E2E when provider auth/runtime wiring changed and the needed REAL_PROVIDER_E2E_* fixture env is configured.
Run local prompt packs when the connector should answer in chat and a local connector is connected with representative data. Cover normal all-source chat and focused connector/account/library chat when the connector has focus-sensitive behavior.

Most connector additions should be readable from the registry entry, runtime manifest, provider adapter, and tests. Avoid provider-specific UI branches, prompt branches, or route forks unless the shared contract cannot represent the behavior.

Start With The Connector Prompt Templates

New built-in connectors should normally start from PROMPT_TEMPLATES.md. The templates keep provider research, live-domain mapping, eval coverage, real-provider smoke, prompt packs, and indexed follow-up criteria in one handoff instead of letting implementation details scatter across a chat.

Use Connector Implementation Intake first when the provider, domain, auth strategy, scopes, resource config, query modes, or indexed stance is not already fully resolved. Run that intake in Plan Mode when available. The intake should inspect the repo and official provider docs, then return a completed New Connector Implementation prompt.

Paste the completed New Connector Implementation prompt into a fresh implementation chat. Use Plan Mode for that second chat when the developer expects more product, API, auth, or security questions before coding; use normal mode when the completed prompt is decision-complete enough to implement directly.

Most new connectors should use live-first-indexed-later unless there is a measured product need or accepted storage requirement for indexed support now. Ship only the live runtime/catalog mode until indexed support actually exists, and record the criteria that would justify later embeddings, sync, or retained storage.

The optional inputs are the extra context fields, not the connector-onboarding process. In the intake template, Known product intent and Known implementation preference can be blank when unknown. In the implementation prompt, Special concerns and Research / references can be blank, and Hard blockers requiring human decision should be none unless no safe default exists. The rest of the placeholders should be filled by intake from repo inspection, official provider docs, and provider/API research.

Skip the templates only for small changes against an existing connector, such as adding focused tests, fixing a provider adapter bug, or updating docs for a verified current behavior. A normal new connector should use the prompt-template flow.

If the generated connector prompt over-specifies provider-local behavior, misses shared seams, or contradicts current contracts, fix PROMPT_TEMPLATES.md and correct the implementation plan in the same PR. Keep the template connector-agnostic so the next connector does not inherit one provider’s temporary assumptions.

Expected Path For An Existing Domain

Confirm the connector belongs to an existing domain and does not require a new canonical live tool contract.
Add one connector definition in packages/domain/src/connectors/connectorRegistry.ts.
Add one runtime extension/manifest entry in apps/api/src/connectors/providerManifests.ts for executable behavior.
Implement one provider adapter for the existing domain contract.
Keep shared domain behavior in the domain contract or canonical live tool, and keep the provider adapter limited to provider API details such as auth, request parameters, paging, and payload normalization.
Add only the unavoidable provider-specific auth or config code, while keeping connector auth ids/callbacks separate from workforce SSO and preserving the repo’s account-selection behavior. Built-in OAuth provider client credentials must be added through deployment-owned env/Kubernetes/external secrets, not customer CMS records. User-managed API-key/PAT connectors must use API-owned encrypted user credential storage and provider validation. Deployment API-key connectors must use the shared credential profile and secret-store contract instead of Better Auth OAuth or provider-local env/file reads.
Register real-provider smoke inputs if the connector has a real-provider lane, but keep required env limited to the true fixture identity or scope inputs. Prefer manifest-owned default bounded smoke queries over extra required env vars when the provider can share one stable default.
Run the targeted connector tests, cd apps/api && bun run check-types, the shared chat eval lanes when the connector changes canonical live-domain behavior, and the real-provider lane when the wiring changed. For chat-capable connectors, verify both normal all-source chat selection and focused connector/account/library chats where focus applies.

For the current domains, the canonical tools stay the same:

mail-live-query
contact-live-query
calendar-live-query
workspace-chat-live-query
work-item-live-query
code-repository-live-query
business-record-live-query
knowledge-page-live-query
connector-resource-list

Adding a connector inside one of those domains should usually not require a new tool id, a new planner branch, or a provider-specific eval tree.

Before implementing the provider adapter, build a provider capability/facet checklist from official provider docs and the canonical domain contract:

Objects users can ask about, such as messages, events, files, repositories, issues, pull requests, comments, people, or tasks.
Metadata facets and filters, such as labels, milestones, categories, folders, status/state, assignee, author, reviewer, language, path, branch/ref, participants, timestamps, visibility, and relationships.
Which canonical live domain owns each object or facet. If none fits, define the new domain contract before coding.
Whether those facets have their own provider inventory API, not only fields on returned object rows. If they do, expose a bounded facet-list path in the shared live domain contract instead of inferring inventory from sampled objects.
Which filters can be expressed through shared structured query/filter contracts, and which provider-specific qualifiers or post-filters the adapter must apply.
Unsupported or weak live-query areas that need no-match/fallback copy, deterministic eval decoys, and real-provider smoke coverage.

This checklist is especially important for provider families. A single upstream provider may expose sibling connector keys across multiple domains, and the same provider account or parent resource can appear in unrelated evidence. Tests should include overlap decoys for same provider, repo/project/folder/account, author, update time, label, milestone, and status so all-scope chat does not route to the wrong sibling domain.

For contact, source semantics are shared domain behavior. Provider adapters must normalize into the canonical contact/person result shape and keep sourceKind explicit, such as saved-contact for Google saved contacts and Microsoft /me/contacts results, directory-person or organization-contact when Microsoft Graph Search reports those semantics, and relevant-person for relevance-ranked people when no more specific source kind is reliable. Do not collapse saved contacts, directory people, organization contacts, and relevance-ranked people into one ambiguous source type, and do not add indexed contact mode until a separate storage/retention design is accepted.

For calendar, source semantics are shared domain behavior. Provider adapters must normalize Google Calendar and Microsoft Graph events into the canonical calendar-event result shape, preserve connector/provider label, event start/end windows, all-day state, calendar label, organizer, attendees, response status, visibility/sensitivity, recurrence/series metadata, and private/limited-detail source kinds. Calendar source-attribution answers must name the connector/provider and calendar label instead of raw source-kind values or internal event record labels. Relative date-window prompts use typed planner windows before runtime derives exact provider bounds, and adapters must filter provider-returned records outside those bounds before grounding. Calendar connectors are live-only; do not add Meltano taps, sync actions, embeddings, or indexed calendar storage until a separate measured live-query gap or accepted retention requirement justifies it.

For workspace-chat, objective latest-message behavior is shared domain behavior. A prompt such as “latest message” must check every eligible connected workspace-chat provider/resource in scope, preserve connector configuration limits, and present provider-timestamped evidence newest-first across providers. Provider adapters may use native structural recency filters to make this accurate, but they should not decide latest by semantic prompt matching. Common temporal language such as today, yesterday, a week ago, last Friday, and explicit dates is parsed once in chat orchestration and passed as canonical timeMin/timeMax/timeZone; do not add provider-local natural-language date parsing. Displayed source metadata must stay curated and user-safe: omit missing labels instead of inventing placeholders, and do not expose raw provider ids in the Sources panel.

For code-repository, source semantics are shared domain behavior. Provider adapters must normalize repositories, code files, and commits into the canonical result groups, preserve user-recognizable repository labels, file paths, refs, commit shas, languages, URLs, snippets, and source metadata, and keep bounded file reads transient. GitHub Repositories is the first implemented provider for this domain. Do not force repository/code/commit semantics into file-resource, and do not add indexed repository/code storage until a separate measured live-query gap or accepted retention requirement justifies it.

For business-record, source semantics are shared domain behavior. Provider adapters must normalize business objects into the canonical business-record result shape, preserve provider-native model/list names, custom fields/columns, relationships, owner/customer/company fields, monetary values, quantities, dates, URLs, and coverage hints structurally, and disclose inaccessible or unavailable models/lists. Odoo is the first implemented provider for this domain; SharePoint lists also use this domain for lists, columns, listItems, custom fields, people/lookup columns, and bounded aggregates where safe. Do not add write methods, webhooks, indexed storage, Meltano taps, embeddings, XML-RPC, JSON-RPC, Graph write calls, or provider-specific chat branches for these providers.

For knowledge-page, source semantics are shared domain behavior. Provider adapters must normalize wiki/knowledge containers, pages, labels/facets, comments, ancestors, children, page metadata, and hierarchy/attachment metadata into the canonical knowledge-page result shape. Confluence spaces, SharePoint sites, and OneNote notebooks are all knowledge containers. Confluence Cloud uses Atlassian OAuth and an explicit site/cloud id; Confluence Data Center can use either a signed-in user’s own PAT or a customer CMS-managed dedicated service/bot PAT. SharePoint and OneNote use Microsoft Graph delegated OAuth with connector-level selected sites/notebooks. Do not add indexed sync, Meltano taps, embeddings, whole-wiki/tenant/notebook semantic recall, write methods, attachment/media content extraction, Cloud API-token Basic auth, app-only OneNote, SharePoint REST/CSOM, deprecated OneNote search, or provider-specific chat branches.

When one provider family spans multiple live domains, make the domain boundary explicit in shared orchestration and tests. Focused connector scopes should advertise the selected connectors’ registered live domains to the classifier, and domain prompts/evals should include overlapping metadata decoys so shared routing does not widen to a sibling domain merely because both domains mention the same repository, path, branch, author, update time, project, label, or milestone. For example, pull-request reviews, PR changed files, and issue/PR milestones remain work-item evidence, while repository files and commits remain code-repository evidence.

What The Registry Owns

The shared connector registry is now the source of truth for:

connectorKey
display name and description
auth strategy (oauth, user-api-key, or deployment-api-key)
OAuth binding (authProviderId, oauthProviderKey, scopes) when the connector uses OAuth
deployment credential profile metadata when the connector uses a deployment API key
supported and default-enabled modes
selectable resource kinds
default selected resource kinds and resourceSelectionPolicy
duplicate-add identity through connectionScope
default customer policy and seed-managed CMS catalog rows

What The Runtime Extension Owns

The API runtime extension/manifest is now the source of truth for executable behavior:

live-domain membership
provider-backed option dependencies
dynamic select config-field defaults, when the UI should preselect a value
indexed tap dispatch
live adapter registration
eval scenario-pack participation
real-provider smoke registration, including any shared default bounded smoke queries

That means catalog seed data comes from the domain registry, while runtime fanout, eval registration, and smoke registration derive from the API runtime extension.

File-resource connectors that support browse/focus/library selection should expose provider files and folders through the shared resource-list adapter contract. If the provider has shared resources, expose them as navigation roots such as owned files, shared-with-me, and shared drives/libraries through provider-agnostic location rows. Location rows are openable but not selectable focus refs. Selectable shared files and folders should carry locationKind and an optional opaque containerSourceId so later child listing and focused reads resolve the same shared container without UI/provider branches. Folder rows may include optional direct child counts (files, folders, and complete/partial state). Keep this metadata connector-agnostic and optional: the shared Library/focus transfer picker can hide browse navigation for known-empty folders while still allowing them to be added, upload current-folder picking can still open zero-child folders as destinations, and missing count metadata must not be treated as empty. If the connector should support live file-content answers, add a provider implementation behind file-resource-live-query for provider search plus bounded transient reads; focused selected-file reads should use the shared file-access adapter registry for safe text-like extraction. SharePoint document libraries use this file-resource shape under selected SharePoint sites. Do not add provider-specific chat branches.

Adding Writable File/Upload Support

File and folder browsing does not make a connector upload-capable. Upload support is a separate provider-backed write capability:

Add the connector to the shared upload/write capability registry in packages/domain/src/connectors/providerBackedUploadCapability.ts with the config values that prove write access.
Add the provider runtime upload adapter in apps/api/src/uploads/providerUploadAdapters.ts for folder listing and file creation/upload.
Add or update connector scope truth so reauthorization requests the provider write scope without narrowing sibling connector scopes on the same linked account. Configure/settings upgrades must use the shared pending-settings OAuth continuation so the setting is applied automatically after consent.
Add tests that prove read/list-only connections stay out of upload destinations, adapter-supported read-only connections can be reauthorized, and unsupported providers are not shown as upload candidates.
Update the canonical Library/connectors specs, provider setup docs, file-upload support docs, and real-provider smoke or manual provider checks where applicable.

Current state: Google Drive has the first upload adapter. OneDrive remains browse/focus-only for Library until a Microsoft Graph upload adapter and write scopes are implemented.

Upload folder browsing must stay on the provider-backed upload adapter, even when a connector also exposes shared files and folders through the read/focus resource-list adapter. Shared read locations such as Shared with me, Shared Drives, and future provider equivalents can be browsed, focused, searched live, and embedded where supported, but they are not Library upload destinations unless a separate accepted write policy and upload adapter explicitly support that surface.

Resource defaults and scoped-resource policy are runtime truth, not CMS copy. New connector definitions should set:

resourceTypes: the supported resource kinds
defaultResourceTypes: only when the default should be narrower than all supported resources
resourceSelectionPolicy: none, optional, or required
connectionScopeConfigKeys: only when one linked OAuth account may create more than one connector of the same connectorKey and a required config value, such as Jira siteId, disambiguates each instance

The web create/settings flow uses those fields generically to hide meaningless scope controls, prevent all resources from being turned off, and remove impossible duplicate rows from the add-connector picker.

Connector select config fields that need a preselected value should declare defaultValue in the runtime manifest. The shared web create/settings editors consume that metadata generically for select controls, so access-mode defaults such as Google Drive read-only must not be hardcoded in provider-specific UI branches.

Provider-family resource scoping is separate from connector-level scoped-resource selection and must be an explicit runtime-manifest opt-in. Use it only when sibling connector keys share one linked account and one upstream resource boundary, such as GitHub repository limits across Repositories, Issues, and Pull Requests. Do not infer family scoping from a shared OAuth provider alone. Keep scoped resource types provider-owned and open-ended instead of turning the first provider’s resource type into a closed app enum. The account-level family scope is an inherited default, and a connector’s own resource selection is an explicit override that should be visible in settings.

Canonical live tools can have multiple provider adapters. Tool results, chat sources, and connector remediation records must carry the connector/provider key whenever a shared tool id could represent more than one connector. Do not infer Jira, GitHub, Google, Microsoft, or another provider from a shared domain tool id such as work-item-live-query; fallback inference is safe only for provider-specific tool ids or data-driven single-provider registry cases with tests that fail when the domain gains another provider.

Customer CMS does not expose connector OAuth provider rows as an operator policy surface. Those rows are hidden seed-managed relationship metadata. The customer-facing availability control is the connector record’s isEnabled field; provider-family lists should be derived from the availability of their child connectors.

What Still Stays Manual

Provider-specific Better Auth or OAuth setup when the upstream provider flow is materially different
Provider-specific option loading when the provider API shape is unique
The provider adapter itself
Provider write/upload adapters and accepted write scopes for file providers that should receive Library device uploads
Any brand-new domain, because a new domain still needs a canonical tool contract, orchestration policy, and scenario-pack design

How To Verify It

Start with the narrow gates:

Run connector registry/contract tests for the changed package.
Run adapter tests for provider API success, auth failure, unavailable resources, timeout, malformed payloads, no-match behavior, and normalization.
Run the relevant app type checks, especially cd apps/api && bun run check-types when API runtime code changed.
Run web or CMS tests when add/connect/settings, credential profiles, or operator fields changed.

Add shared chat gates when the connector changes what chat can know or cite:

Run bun run test:api:chat:runtime-smoke and bun run test:api:chat:review from repo root when a canonical live domain changes.
Add deterministic evals with provider-shaped mocked data for routing, grounding, source metadata, no-match behavior, follow-ups, source switching, and sibling-domain decoys.
Cover normal all-source chat and focused chat separately. Normal all-source checks catch source-choice and best-judgment gaps; focused connector/account/library checks catch focus-boundary, account-scope, and selected-resource regressions.
If the connector exposes rich facets, test both inventory prompts and filtered-object prompts. Inventory evidence proves what is configured or visible; it does not prove a returned object currently uses that facet.
If the connector joins business-record, include model-list, field-list, record-search/list/detail, no-match, unavailable-model, custom-field, relationship, and source-switch checks.
If the connector joins knowledge-page, include knowledge-container list/detail, page title/text search, page-list/detail, recent pages, hierarchy, provider facets, provenance follow-ups, no-match/inaccessible selected-resource cases, unsupported attachment/media-content, indexed-recall, and write cases, company-managed service/bot provenance where applicable, and source-switch checks against work-item, file-resource, and business-record connectors.

Add real-provider E2E when provider auth/runtime wiring changed or could drift:

Manually add the connector through the web product flow with a dedicated test account or deployment credential.
For OAuth connectors, get the linked provider account id from the Better Auth account collection/model for the connector OAuth provider. Use account.accountId, not the connector id, display email, provider subject label, or Better Auth row _id.
Put that value in the connector’s real-provider fixture env var, normally REAL_PROVIDER_E2E_<CONNECTOR>_ACCOUNT_ID, in the local API real-provider E2E env setup.
Run bun run test:api:connectors:real-provider:doctor <provider>.
If the configured account id is stale, the doctor prints safe candidate accountId values for that provider id, plus owner id and scope coverage. It never prints access tokens, refresh tokens, API keys, secrets, or emails.
Run bun run test:api:connectors:real-provider:e2e <provider> or bun run test:api:connectors:real-provider:e2e:all for every configured provider.

Do not inspect or print real .env files while setting up this lane. Keep apps/api/.env.example authoritative for new fixture variables, and use repo-owned safe helpers such as env:refresh, real-provider doctors, and agent-browser:* login commands without echoing secrets.

User-managed and deployment API-key connectors are different from OAuth connectors: they do not use Better Auth linked-account ids for provider access. User-managed connectors validate an encrypted per-user credential at API runtime, while deployment API-key connectors use customer CMS profile readiness and the declared secret slots. Real-provider E2E may need other REAL_PROVIDER_E2E_* fixture env vars, such as a base URL, API key, database, resource id, model, or query pin.

Confluence real-provider E2E supports optional fixture groups for Cloud OAuth, Data Center user PAT, and Data Center deployment PAT. Configure only the group you can safely run. Each configured group should cover bounded space listing, page search/list/detail, comments, labels, tree metadata, attachment metadata, and auth/readiness failure states without printing tokens or PAT values.

Add local prompt packs when the connector should answer in chat:

Start the local stack and sign in with bun run agent-browser:login:web.
Add the connector manually in the web app. For user-managed API-key/PAT connectors, enter the test user’s credential in the web setup flow. For deployment API-key connectors, configure and validate the credential profile in the customer CMS first.
Generate a gitignored pack with bun run chat:prompt-pack:local -- --force.
Run bounded browser-backed normal all-source checks first, for example bun run chat:prompt-pack:run:local -- --connector odoo --domain business-record --limit <n>.
Add focused connector/account/library checks when the connector has focus-sensitive behavior, resource selection, or multi-account ambiguity. Focused success is not enough by itself because it does not prove normal all-source source-choice behavior.
Review failures as source-grounding and answer-quality issues, not just UI rendering issues.

Local prompt packs do not require REAL_PROVIDER_E2E_* env vars. They use the connectors visible to the logged-in local web user. Real-provider E2E and prompt packs are complementary: E2E proves fixture auth/runtime wiring, while prompt packs prove the local chat path can use connected sources in a user-visible way.

For every newly implemented connector key, also browser-check connector catalog visibility before relying on prompt packs. The key should appear in the addable provider/account picker when registry policy, runtime support, and deployment config make it addable; the add flow should show any required resource-selection state; and connected rows/settings should expose remediation actions such as reauthorize or reconnect when recovery is present. If provider-backed setup options or required resource pickers need more auth scopes, the outer add/settings flow should show a clear reauthorize action before nested limit editors or pickers become the main path. If the key is absent, diagnose CMS seed/catalog freshness, addability policy, runtime manifest registration, and deployment config before treating the prompt pack as unavailable.

Sibling connectors that share one OAuth provider still need connector-specific presentation. Verify the dashboard row, add/connect modal, focus/source picker, chat source, and activity/status surfaces use the connector key’s rendered avatar/icon, display name, domains, resource labels, and source metadata. Do not let child connectors silently fall back to only the parent provider icon or name unless that is an explicit registry-owned presentation decision. Check the rendered avatar itself, not only the icon class or catalog field, because invalid icon ids can leave plausible DOM classes while showing a blank mark.

Run bun run test:api:connectors:realtime when connector status publishing or realtime/status recovery payloads changed. Use root bun run test:connectors:realtime for the broader automated API/queue/web status bundle. Use repo-safe wrappers for write-capable CMS/auth/API integration lanes instead of direct bun test against a non-test database.

Manual testing is still highly recommended for new or changed connectors. A human should exercise the real add/connect/settings and chat-answer flow before PR handoff, especially when connector accuracy, source attribution, provider setup, or user trust is affected.

How To Upgrade Meltano

See Meltano for the runtime pins, upgrade commands, Docker/local rebuild steps, and connector smoke gates.

Manual QA For Connector Policy Changes

When connector availability or customer CMS policy changes, visually verify the user-facing flow:

Disable an unconnected connector in cms-customer, then confirm the web add-connector flow does not allow adding it even if the modal was already open.
Disable a connector that already has a connection, then confirm the connector dashboard row remains visible with workspace-friendly policy-disabled copy and only safe actions such as disconnect remain available.
Start or continue a focused chat that uses that connector, then confirm the response stays scoped, explains that the connector is turned off for the workspace, and does not ask for alternate sources or use another connector.
Re-enable the connector in cms-customer, then confirm normal connector management actions return after the web app refreshes its catalog state.

Current Limits

Jira is still the reference work-item connector and remains live-only in V1.
Do not add Jira embeddings or indexed ingestion unless a separate measured gap shows the live path is insufficient.
GitHub Issues and GitHub Pull Requests also use the shared work-item domain, including labels and milestones as work-item metadata/facet inventory, while GitHub Repositories is the reference code-repository connector. All three GitHub connectors are live-only and read-only at runtime.
Do not add GitHub indexed sync, Meltano taps, embeddings, semantic whole-codebase recall, or retained repository/code/issue/PR snapshots unless a separate measured gap and accepted privacy/storage design justify retaining GitHub data.
Google Contacts and Microsoft Contacts are the reference contact connectors and remain live-only for storage.
Do not add contact embeddings, contact sync, Meltano taps, or indexed contact mode unless a separate measured gap and accepted privacy/storage design justify retaining contact copies.
Google Calendar and Microsoft Calendar are the reference calendar connectors and remain live-only for storage.
Do not add calendar embeddings, calendar sync, Meltano taps, or indexed calendar mode unless a separate measured gap and accepted privacy/storage design justify retaining calendar copies.
Cross-domain packs are explicit on purpose. Add them only when the user task genuinely spans both domains, such as mail + work-item.
Odoo is the reference business-record connector and remains live-only in V1. It supports user-managed API-key access and company-managed deployment API-key access. Do not add indexed Odoo sync, write support, webhooks, XML-RPC, JSON-RPC, or fallback API paths.
Confluence is the reference knowledge-page connector and remains live-only in V1. It supports Cloud OAuth, Data Center user-managed PAT access, and Data Center company-managed service/bot PAT access. Do not add indexed Confluence sync, write support, attachment content extraction, Cloud API-token Basic auth, or retained page content.

Planned / Not Yet Implemented

Future custom or literal MCP connector onboarding is a separate feature path.
The registry/runtime-extension flow on this page describes built-in connectors that use the existing canonical live-query domains.
Persisted connector enable/disable is intentionally not part of the current connector onboarding path. A future lifecycle feature must update API, live access, sync, Meltano, cleanup, and realtime status behavior together.

Canonical Sources

packages/domain/src/connectors/connectorRegistry.ts
apps/api/src/connectors/connectorRuntimeExtensions.ts
apps/api/src/connectors/providerManifests.ts
apps/api/src/connectors/syncTriggerRunner.ts
apps/meltano/scripts/bootstrapLocalRuntime.ts
docker-compose.yml
apps/api/src/connectors/canonicalLiveToolDefinitions.ts
apps/api/src/mastra/tools/canonicalLiveToolRegistry.ts
apps/api/src/mastra/evals/scenarios/liveConnectorScenarioPacks.ts
docs/features/connectors/spec.md
docs/features/live-query/spec.md
PROMPT_TEMPLATES.md
apps/support-dev/src/content/docs/dependencies/meltano.md