Imported from Lalitkishore2/LADA-AI (src/plugin-sdk/AGENTS.md). Install upstream with npx skills add Lalitkishore2/LADA-AI --skill plugin-sdk. Copyright stays with the author.

Plugin SDK Boundary

This directory is the public contract between plugins and core. Changes here can affect bundled plugins and third-party plugins.

Source Of Truth

• Docs:
  • docs/plugins/sdk-overview.md
  • docs/plugins/sdk-entrypoints.md
  • docs/plugins/sdk-runtime.md
  • docs/plugins/sdk-migration.md
  • docs/plugins/architecture.md
• Definition files:
  • package.json
  • scripts/lib/plugin-sdk-entrypoints.json
  • src/plugin-sdk/entrypoints.ts
  • src/plugin-sdk/api-baseline.ts
  • src/plugin-sdk/plugin-entry.ts
  • src/plugin-sdk/core.ts
  • src/plugin-sdk/provider-entry.ts

Boundary Rules

• Prefer narrow, purpose-built subpaths over broad convenience re-exports.
• Do not expose implementation convenience from src/channels/**, src/agents/**, src/plugins/**, or other internals unless you are intentionally promoting a supported public contract.
• Keep public SDK entrypoints cheap at module load. If a helper is only needed on async paths such as send, monitor, probe, directory-live, login, or setup, prefer a narrow *.runtime subpath over re-exporting it through a broad SDK barrel that hot channel entrypoints import on startup.
• Keep SDK facades acyclic. Do not add back-edge re-exports that route a lightweight contract file back through heavier policy or runtime modules.
• Do not mix static and dynamic imports for the same runtime surface when shaping SDK seams. If a surface must stay lazy, keep the eager side on a light contract file and the deferred side on a dedicated runtime subpath.
• Prefer api.runtime or a focused SDK facade over telling extensions to reach into host internals directly.
• When core or tests need bundled plugin helpers, prefer the plugin package api.ts or runtime-api.ts plus generic SDK capabilities. Do not add a provider-named src/plugin-sdk/<id>.ts seam just to make core aware of a bundled channel's private helpers.
• For provider work, prefer family-level seams over provider-specific seams. Shared helpers should describe a reusable behavior such as replay policy, tool-schema compat, payload normalization, stream-wrapper composition, or transport decoration. Avoid adding a new SDK export that only wraps one provider's local implementation unless there is already a second consumer.
• Prefer named helpers over raw options objects when the options encode a stable contract. Example: export a helper for "OpenAI-style Anthropic tool payload compat" instead of making every plugin pass the same mode flags.
• Keep transport/runtime policy and plugin-facing helpers aligned. If the same behavior is used in plugin registration and in core runtime paths, expose one shared helper instead of letting the two paths drift.

Verification

• If you touch SDK seams that affect lazy loading, hot channel entrypoints, or bundled plugin import topology, run pnpm build.
• If the change can alter bundled channel startup cost, also run the isolated entrypoint profiler for the affected plugin: LADA_LOCAL_CHECK=0 node scripts/profile-extension-memory.mjs --extension <id> --skip-combined --concurrency 1

Expanding The Boundary

• Additive, backwards-compatible changes are the default.
• When adding or changing a public subpath, keep these aligned:
  • docs in docs/plugins/*
  • scripts/lib/plugin-sdk-entrypoints.json
  • src/plugin-sdk/entrypoints.ts
  • package.json exports
  • API baseline and export checks
• If a bundled channel/helper need crosses package boundaries, first ask whether the need is truly generic. If yes, add a narrow generic subpath. If not, keep it plugin-local through api.ts / runtime-api.ts.
• When expanding provider-facing seams, update or add the matching narrow tests that lock the contract: Plugin SDK baseline/export checks for public subpaths and the most direct provider/plugin tests for the behavior you are centralizing.
• Breaking removals or renames are major-version work, not drive-by cleanup.