Table of Contents

Architecture and decisions

WeavePort adds plugin execution to the application you already own. It is a library embedded in each application, with domain contracts, authorization and durable state supplied by that application. One PluginHost owns one explicit shared worker budget; creating multiple hosts creates independent budgets. It is not a distributed scheduler or a machine-wide singleton.

Ownership

  • Applications authenticate callers, select immutable tenant/plugin/profile identity and grant callback operations. Plugin payloads cannot establish authority.
  • Applications own business schemas, workflow state, journals, idempotency and reconciliation. Domain concepts stay out of the platform.
  • Hosting owns single-flight sessions, per-tenant admission, deadlines, pristine workers, idle release and cleanup accounting. A used worker is never reassigned to another customer.
  • Author SDKs own protocol details; the client SDK owns bounded unary/stream calls. A gateway selects a preconfigured binding through a credential and cannot register executables remotely.

Package boundaries

WeavePort.Abstractions defines the shared contracts. Hosting depends on abstractions and caller-owned logging abstractions. The author SDK has no hosting dependency. WeavePort.Sdk.Client adapts host sessions. Optional Composition and Gateway packages implement separate concerns; applications choose them explicitly. Testing helpers belong to verification and are not application prerequisites.

All current core packages target .NET 10. The compatibility matrix identifies exact versions; API/protocol version 1 does not establish equality of artifact bytes.

Execution boundary

Native ProcessProfile launches explicitly trusted same-user code with private cooperative workspaces and stdio or opt-in Unix sockets. Admission memory reservations are not hard resource limits. Native processes cannot contain malicious code or escaped descendants.

DockerProfile requests container resource and operating-system restrictions. Effective protection depends on the actual engine/kernel/deployment. Its regression fixtures remain available; historical container measurements do not qualify the current native release for a new platform.

Lifecycle decisions

Keep stateful workers by default; idle release and prewarming are opt-in. Bound both tenant and shared capacity. Cleanup-uncertain workers remain reserved and unavailable. Disposed sessions release registration, while outstanding callbacks retain their own admission until actual completion.

Cancellation means that the caller stopped waiting, not that an external action failed. Complete independent cleanup attempts even when cancellation callbacks throw, report failures and retain uncertain business outcomes. See worker lifecycle and the recovery runbook.

Deferred work

The four core packages are publicly available at 0.3.1. Windows qualification, stronger native containment, distributed scheduling, application signing/notarization and automatic updates/migrations remain separate work. Integrations with the owner's applications follow their own development schedule.

The historical evidence guide explains where earlier design alternatives, measurements and rejected experiments are retained, including the limits of public access to pre-baseline history. This guide retains the decisions that still govern current code.

Optional MCP protocol

Current source also supports explicitly selected local MCP tools through the same process lifecycle; native remains the default. See MCP plugins for exact revisions, result semantics and support limits. MCP does not introduce AI concepts or implicit host authority into native plugins.