2026-03-13 16:22:34 -05:00
|
|
|
/**
|
|
|
|
|
* `definePlugin` — the top-level helper for authoring a Paperclip plugin.
|
|
|
|
|
*
|
|
|
|
|
* Plugin authors call `definePlugin()` and export the result as the default
|
|
|
|
|
* export from their worker entrypoint. The host imports the worker module,
|
|
|
|
|
* calls `setup()` with a `PluginContext`, and from that point the plugin
|
|
|
|
|
* responds to events, jobs, webhooks, and UI requests through the context.
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §14.1 — Example SDK Shape
|
|
|
|
|
*
|
|
|
|
|
* @example
|
|
|
|
|
* ```ts
|
|
|
|
|
* // dist/worker.ts
|
|
|
|
|
* import { definePlugin } from "@paperclipai/plugin-sdk";
|
|
|
|
|
*
|
|
|
|
|
* export default definePlugin({
|
|
|
|
|
* async setup(ctx) {
|
|
|
|
|
* ctx.logger.info("Linear sync plugin starting");
|
|
|
|
|
*
|
|
|
|
|
* // Subscribe to events
|
|
|
|
|
* ctx.events.on("issue.created", async (event) => {
|
|
|
|
|
* const config = await ctx.config.get();
|
|
|
|
|
* await ctx.http.fetch(`https://api.linear.app/...`, {
|
|
|
|
|
* method: "POST",
|
|
|
|
|
* headers: { Authorization: `Bearer ${await ctx.secrets.resolve(config.apiKeyRef as string)}` },
|
|
|
|
|
* body: JSON.stringify({ title: event.payload.title }),
|
|
|
|
|
* });
|
|
|
|
|
* });
|
|
|
|
|
*
|
|
|
|
|
* // Register a job handler
|
|
|
|
|
* ctx.jobs.register("full-sync", async (job) => {
|
|
|
|
|
* ctx.logger.info("Running full-sync job", { runId: job.runId });
|
|
|
|
|
* // ... sync logic
|
|
|
|
|
* });
|
|
|
|
|
*
|
|
|
|
|
* // Register data for the UI
|
|
|
|
|
* ctx.data.register("sync-health", async ({ companyId }) => {
|
|
|
|
|
* const state = await ctx.state.get({
|
|
|
|
|
* scopeKind: "company",
|
|
|
|
|
* scopeId: String(companyId),
|
|
|
|
|
* stateKey: "last-sync",
|
|
|
|
|
* });
|
|
|
|
|
* return { lastSync: state };
|
|
|
|
|
* });
|
|
|
|
|
* },
|
|
|
|
|
* });
|
|
|
|
|
* ```
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
import type { PluginContext } from "./types.js";
|
|
|
|
|
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
// Health check result
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Optional plugin-reported diagnostics returned from the `health()` RPC method.
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §13.2 — `health`
|
|
|
|
|
*/
|
|
|
|
|
export interface PluginHealthDiagnostics {
|
|
|
|
|
/** Machine-readable status: `"ok"` | `"degraded"` | `"error"`. */
|
|
|
|
|
status: "ok" | "degraded" | "error";
|
|
|
|
|
/** Human-readable description of the current health state. */
|
|
|
|
|
message?: string;
|
|
|
|
|
/** Plugin-reported key-value diagnostics (e.g. connection status, queue depth). */
|
|
|
|
|
details?: Record<string, unknown>;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
// Config validation result
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Result returned from the `validateConfig()` RPC method.
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §13.3 — `validateConfig`
|
|
|
|
|
*/
|
|
|
|
|
export interface PluginConfigValidationResult {
|
|
|
|
|
/** Whether the config is valid. */
|
|
|
|
|
ok: boolean;
|
|
|
|
|
/** Non-fatal warnings about the config. */
|
|
|
|
|
warnings?: string[];
|
|
|
|
|
/** Validation errors (populated when `ok` is `false`). */
|
|
|
|
|
errors?: string[];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
// Webhook handler input
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Input received by the plugin worker's `handleWebhook` handler.
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §13.7 — `handleWebhook`
|
|
|
|
|
*/
|
|
|
|
|
export interface PluginWebhookInput {
|
|
|
|
|
/** Endpoint key matching the manifest declaration. */
|
|
|
|
|
endpointKey: string;
|
|
|
|
|
/** Inbound request headers. */
|
|
|
|
|
headers: Record<string, string | string[]>;
|
|
|
|
|
/** Raw request body as a UTF-8 string. */
|
|
|
|
|
rawBody: string;
|
|
|
|
|
/** Parsed JSON body (if applicable and parseable). */
|
|
|
|
|
parsedBody?: unknown;
|
|
|
|
|
/** Unique request identifier for idempotency checks. */
|
|
|
|
|
requestId: string;
|
|
|
|
|
}
|
|
|
|
|
|
[codex] Add plugin orchestration host APIs (#4114)
## Thinking Path
> - Paperclip orchestrates AI agents for zero-human companies.
> - The plugin system is the extension path for optional capabilities
that should not require core product changes for every integration.
> - Plugins need scoped host APIs for issue orchestration, documents,
wakeups, summaries, activity attribution, and isolated database state.
> - Without those host APIs, richer plugins either cannot coordinate
Paperclip work safely or need privileged core-side special cases.
> - This pull request adds the plugin orchestration host surface, scoped
route dispatch, a database namespace layer, and a smoke plugin that
exercises the contract.
> - The benefit is a broader plugin API that remains company-scoped,
auditable, and covered by tests.
## What Changed
- Added plugin orchestration host APIs for issue creation, document
access, wakeups, summaries, plugin-origin activity, and scoped API route
dispatch.
- Added plugin database namespace tables, schema exports, migration
checks, and idempotent replay coverage under migration
`0059_plugin_database_namespaces`.
- Added shared plugin route/API types and validators used by server and
SDK boundaries.
- Expanded plugin SDK types, protocol helpers, worker RPC host behavior,
and testing utilities for orchestration flows.
- Added the `plugin-orchestration-smoke-example` package to exercise
scoped routes, restricted database namespaces, issue orchestration,
documents, wakeups, summaries, and UI status surfaces.
- Kept the new orchestration smoke fixture out of the root pnpm
workspace importer so this PR preserves the repository policy of not
committing `pnpm-lock.yaml`.
- Updated plugin docs and database docs for the new orchestration and
database namespace surfaces.
- Rebased the branch onto `public-gh/master`, resolved conflicts, and
removed `pnpm-lock.yaml` from the final PR diff.
## Verification
- `pnpm install --frozen-lockfile`
- `pnpm --filter @paperclipai/db typecheck`
- `pnpm exec vitest run packages/db/src/client.test.ts`
- `pnpm exec vitest run server/src/__tests__/plugin-database.test.ts
server/src/__tests__/plugin-orchestration-apis.test.ts
server/src/__tests__/plugin-routes-authz.test.ts
server/src/__tests__/plugin-scoped-api-routes.test.ts
server/src/__tests__/plugin-sdk-orchestration-contract.test.ts`
- From `packages/plugins/examples/plugin-orchestration-smoke-example`:
`pnpm exec vitest run --config ./vitest.config.ts`
- `pnpm --dir
packages/plugins/examples/plugin-orchestration-smoke-example run
typecheck`
- `pnpm --filter @paperclipai/server typecheck`
- PR CI on latest head `293fc67c`: `policy`, `verify`, `e2e`, and
`security/snyk` all passed.
## Risks
- Medium risk: this expands plugin host authority, so route auth,
company scoping, and plugin-origin activity attribution need careful
review.
- Medium risk: database namespace migration behavior must remain
idempotent for environments that may have seen earlier branch versions.
- Medium risk: the orchestration smoke fixture is intentionally excluded
from the root workspace importer to avoid a `pnpm-lock.yaml` PR diff;
direct fixture verification remains listed above.
- Low operational risk from the PR setup itself: the branch is rebased
onto current `master`, the migration is ordered after upstream
`0057`/`0058`, and `pnpm-lock.yaml` is not in the final diff.
> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.
Roadmap checked: this work aligns with the completed Plugin system
milestone and extends the plugin surface rather than duplicating an
unrelated planned core feature.
## Model Used
- OpenAI Codex, GPT-5-based coding agent in a tool-enabled CLI
environment. Exact hosted model build and context-window size are not
exposed by the runtime; reasoning/tool use were enabled for repository
inspection, editing, testing, git operations, and PR creation.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] If this change affects the UI, I have included before/after
screenshots (N/A: no core UI screen change; example plugin UI contract
is covered by tests)
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge
---------
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-04-20 08:52:51 -05:00
|
|
|
export interface PluginApiRequestInput {
|
|
|
|
|
routeKey: string;
|
|
|
|
|
method: string;
|
|
|
|
|
path: string;
|
|
|
|
|
params: Record<string, string>;
|
|
|
|
|
query: Record<string, string | string[]>;
|
|
|
|
|
body: unknown;
|
|
|
|
|
actor: {
|
|
|
|
|
actorType: "user" | "agent";
|
|
|
|
|
actorId: string;
|
|
|
|
|
agentId?: string | null;
|
|
|
|
|
userId?: string | null;
|
|
|
|
|
runId?: string | null;
|
|
|
|
|
};
|
|
|
|
|
companyId: string;
|
|
|
|
|
headers: Record<string, string>;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
export interface PluginApiResponse {
|
|
|
|
|
status?: number;
|
|
|
|
|
headers?: Record<string, string>;
|
|
|
|
|
body?: unknown;
|
|
|
|
|
}
|
|
|
|
|
|
2026-03-13 16:22:34 -05:00
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
// Plugin definition
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* The plugin definition shape passed to `definePlugin()`.
|
|
|
|
|
*
|
|
|
|
|
* The only required field is `setup`, which receives the `PluginContext` and
|
|
|
|
|
* is where the plugin registers its handlers (events, jobs, data, actions,
|
|
|
|
|
* tools, etc.).
|
|
|
|
|
*
|
|
|
|
|
* All other lifecycle hooks are optional. If a hook is not implemented the
|
|
|
|
|
* host applies default behaviour (e.g. restarting the worker on config change
|
|
|
|
|
* instead of calling `onConfigChanged`).
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §13 — Host-Worker Protocol
|
|
|
|
|
*/
|
|
|
|
|
export interface PluginDefinition {
|
|
|
|
|
/**
|
|
|
|
|
* Called once when the plugin worker starts up, after `initialize` completes.
|
|
|
|
|
*
|
|
|
|
|
* This is where the plugin registers all its handlers: event subscriptions,
|
|
|
|
|
* job handlers, data/action handlers, and tool registrations. Registration
|
|
|
|
|
* must be synchronous after `setup` resolves — do not register handlers
|
|
|
|
|
* inside async callbacks that may resolve after `setup` returns.
|
|
|
|
|
*
|
|
|
|
|
* @param ctx - The full plugin context provided by the host
|
|
|
|
|
*/
|
|
|
|
|
setup(ctx: PluginContext): Promise<void>;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Called when the host wants to know if the plugin is healthy.
|
|
|
|
|
*
|
|
|
|
|
* The host polls this on a regular interval and surfaces the result in the
|
|
|
|
|
* plugin health dashboard. If not implemented, the host infers health from
|
|
|
|
|
* worker process liveness.
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §13.2 — `health`
|
|
|
|
|
*/
|
|
|
|
|
onHealth?(): Promise<PluginHealthDiagnostics>;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Called when the operator updates the plugin's instance configuration at
|
|
|
|
|
* runtime, without restarting the worker.
|
|
|
|
|
*
|
|
|
|
|
* If not implemented, the host restarts the worker to apply the new config.
|
|
|
|
|
*
|
|
|
|
|
* @param newConfig - The newly resolved configuration
|
|
|
|
|
* @see PLUGIN_SPEC.md §13.4 — `configChanged`
|
|
|
|
|
*/
|
|
|
|
|
onConfigChanged?(newConfig: Record<string, unknown>): Promise<void>;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Called when the host is about to shut down the plugin worker.
|
|
|
|
|
*
|
|
|
|
|
* The worker has at most 10 seconds (configurable via plugin config) to
|
|
|
|
|
* finish in-flight work and resolve this promise. After the deadline the
|
|
|
|
|
* host sends SIGTERM, then SIGKILL.
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §12.5 — Graceful Shutdown Policy
|
|
|
|
|
*/
|
|
|
|
|
onShutdown?(): Promise<void>;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Called to validate the current plugin configuration.
|
|
|
|
|
*
|
|
|
|
|
* The host calls this:
|
|
|
|
|
* - after the plugin starts (to surface config errors immediately)
|
|
|
|
|
* - after the operator saves a new config (to validate before persisting)
|
|
|
|
|
* - via the "Test Connection" button in the settings UI
|
|
|
|
|
*
|
|
|
|
|
* @param config - The configuration to validate
|
|
|
|
|
* @see PLUGIN_SPEC.md §13.3 — `validateConfig`
|
|
|
|
|
*/
|
|
|
|
|
onValidateConfig?(config: Record<string, unknown>): Promise<PluginConfigValidationResult>;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Called to handle an inbound webhook delivery.
|
|
|
|
|
*
|
|
|
|
|
* The host routes `POST /api/plugins/:pluginId/webhooks/:endpointKey` to
|
|
|
|
|
* this handler. The plugin is responsible for signature verification using
|
|
|
|
|
* a resolved secret ref.
|
|
|
|
|
*
|
|
|
|
|
* If not implemented but webhooks are declared in the manifest, the host
|
|
|
|
|
* returns HTTP 501 for webhook deliveries.
|
|
|
|
|
*
|
|
|
|
|
* @param input - Webhook delivery metadata and payload
|
|
|
|
|
* @see PLUGIN_SPEC.md §13.7 — `handleWebhook`
|
|
|
|
|
*/
|
|
|
|
|
onWebhook?(input: PluginWebhookInput): Promise<void>;
|
[codex] Add plugin orchestration host APIs (#4114)
## Thinking Path
> - Paperclip orchestrates AI agents for zero-human companies.
> - The plugin system is the extension path for optional capabilities
that should not require core product changes for every integration.
> - Plugins need scoped host APIs for issue orchestration, documents,
wakeups, summaries, activity attribution, and isolated database state.
> - Without those host APIs, richer plugins either cannot coordinate
Paperclip work safely or need privileged core-side special cases.
> - This pull request adds the plugin orchestration host surface, scoped
route dispatch, a database namespace layer, and a smoke plugin that
exercises the contract.
> - The benefit is a broader plugin API that remains company-scoped,
auditable, and covered by tests.
## What Changed
- Added plugin orchestration host APIs for issue creation, document
access, wakeups, summaries, plugin-origin activity, and scoped API route
dispatch.
- Added plugin database namespace tables, schema exports, migration
checks, and idempotent replay coverage under migration
`0059_plugin_database_namespaces`.
- Added shared plugin route/API types and validators used by server and
SDK boundaries.
- Expanded plugin SDK types, protocol helpers, worker RPC host behavior,
and testing utilities for orchestration flows.
- Added the `plugin-orchestration-smoke-example` package to exercise
scoped routes, restricted database namespaces, issue orchestration,
documents, wakeups, summaries, and UI status surfaces.
- Kept the new orchestration smoke fixture out of the root pnpm
workspace importer so this PR preserves the repository policy of not
committing `pnpm-lock.yaml`.
- Updated plugin docs and database docs for the new orchestration and
database namespace surfaces.
- Rebased the branch onto `public-gh/master`, resolved conflicts, and
removed `pnpm-lock.yaml` from the final PR diff.
## Verification
- `pnpm install --frozen-lockfile`
- `pnpm --filter @paperclipai/db typecheck`
- `pnpm exec vitest run packages/db/src/client.test.ts`
- `pnpm exec vitest run server/src/__tests__/plugin-database.test.ts
server/src/__tests__/plugin-orchestration-apis.test.ts
server/src/__tests__/plugin-routes-authz.test.ts
server/src/__tests__/plugin-scoped-api-routes.test.ts
server/src/__tests__/plugin-sdk-orchestration-contract.test.ts`
- From `packages/plugins/examples/plugin-orchestration-smoke-example`:
`pnpm exec vitest run --config ./vitest.config.ts`
- `pnpm --dir
packages/plugins/examples/plugin-orchestration-smoke-example run
typecheck`
- `pnpm --filter @paperclipai/server typecheck`
- PR CI on latest head `293fc67c`: `policy`, `verify`, `e2e`, and
`security/snyk` all passed.
## Risks
- Medium risk: this expands plugin host authority, so route auth,
company scoping, and plugin-origin activity attribution need careful
review.
- Medium risk: database namespace migration behavior must remain
idempotent for environments that may have seen earlier branch versions.
- Medium risk: the orchestration smoke fixture is intentionally excluded
from the root workspace importer to avoid a `pnpm-lock.yaml` PR diff;
direct fixture verification remains listed above.
- Low operational risk from the PR setup itself: the branch is rebased
onto current `master`, the migration is ordered after upstream
`0057`/`0058`, and `pnpm-lock.yaml` is not in the final diff.
> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.
Roadmap checked: this work aligns with the completed Plugin system
milestone and extends the plugin surface rather than duplicating an
unrelated planned core feature.
## Model Used
- OpenAI Codex, GPT-5-based coding agent in a tool-enabled CLI
environment. Exact hosted model build and context-window size are not
exposed by the runtime; reasoning/tool use were enabled for repository
inspection, editing, testing, git operations, and PR creation.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] If this change affects the UI, I have included before/after
screenshots (N/A: no core UI screen change; example plugin UI contract
is covered by tests)
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge
---------
Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-04-20 08:52:51 -05:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Called for manifest-declared scoped JSON API routes under
|
|
|
|
|
* `/api/plugins/:pluginId/api/*` after the host has enforced auth, company
|
|
|
|
|
* access, capabilities, and checkout policy.
|
|
|
|
|
*/
|
|
|
|
|
onApiRequest?(input: PluginApiRequestInput): Promise<PluginApiResponse>;
|
2026-03-13 16:22:34 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
// PaperclipPlugin — the sealed object returned by definePlugin()
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* The sealed plugin object returned by `definePlugin()`.
|
|
|
|
|
*
|
|
|
|
|
* Plugin authors export this as the default export from their worker
|
|
|
|
|
* entrypoint. The host imports it and calls the lifecycle methods.
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §14 — SDK Surface
|
|
|
|
|
*/
|
|
|
|
|
export interface PaperclipPlugin {
|
|
|
|
|
/** The original plugin definition passed to `definePlugin()`. */
|
|
|
|
|
readonly definition: PluginDefinition;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
// definePlugin — top-level factory
|
|
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Define a Paperclip plugin.
|
|
|
|
|
*
|
|
|
|
|
* Call this function in your worker entrypoint and export the result as the
|
|
|
|
|
* default export. The host will import the module and call lifecycle methods
|
|
|
|
|
* on the returned object.
|
|
|
|
|
*
|
|
|
|
|
* @param definition - Plugin lifecycle handlers
|
|
|
|
|
* @returns A sealed `PaperclipPlugin` object for the host to consume
|
|
|
|
|
*
|
|
|
|
|
* @example
|
|
|
|
|
* ```ts
|
|
|
|
|
* import { definePlugin } from "@paperclipai/plugin-sdk";
|
|
|
|
|
*
|
|
|
|
|
* export default definePlugin({
|
|
|
|
|
* async setup(ctx) {
|
|
|
|
|
* ctx.logger.info("Plugin started");
|
|
|
|
|
* ctx.events.on("issue.created", async (event) => {
|
|
|
|
|
* // handle event
|
|
|
|
|
* });
|
|
|
|
|
* },
|
|
|
|
|
*
|
|
|
|
|
* async onHealth() {
|
|
|
|
|
* return { status: "ok" };
|
|
|
|
|
* },
|
|
|
|
|
* });
|
|
|
|
|
* ```
|
|
|
|
|
*
|
|
|
|
|
* @see PLUGIN_SPEC.md §14.1 — Example SDK Shape
|
|
|
|
|
*/
|
|
|
|
|
export function definePlugin(definition: PluginDefinition): PaperclipPlugin {
|
|
|
|
|
return Object.freeze({ definition });
|
|
|
|
|
}
|