Tracking Issue: deliver a bounded Source Connector SDK

Feature description

Define a bounded Source Connector SDK for user-managed integrations with Wiki, RAG/knowledge systems, ticketing systems, OA/document platforms, and similar external Sources.

The SDK should make supported customization possible without allowing a connector to bypass Source provenance, write directly to Memory or Artifacts, inject arbitrary model context, or become an unbounded in-process workflow engine.

Problem and proposed solution

#1240 defines Source identity and materialization, while #1363 delivers the first supported document Source integration. That first integration should prove the contract before PowerContext exposes a general connector surface. After that gate, users need a stable way to add organization-specific systems without forking PowerContext.

Define a versioned connector contract with:

• connector identity, version, capabilities, configuration schema, and compatibility range;
• discovery and incremental synchronization with durable checkpoints;
• captured, referenced, or hybrid materialization as accepted by #1240;
• exact external object/version identity, provenance, content digest, timestamps, and tombstones;
• provider-supported create/update/delete handling without rewriting historical evidence;
• polling, webhook, manual import, and on-demand reference capabilities declared explicitly;
• bounded batching, concurrency, retry/backoff, rate-limit, cancellation, and failure isolation;
• credential references supplied by the operator, never serialized into Source metadata or diagnostics;
• per-connector status, lag, failed-item reporting, and redacted health checks;
• installation, upgrade, disable, disconnect, and ownership semantics;
• contract fixtures and one reference connector after the RFC is accepted.

The RFC should choose a safe execution boundary. Options may include an administrator-installed Python package, a sidecar process, or a protocol adapter. Uploading arbitrary executable code through the public API should not be the default.

Connectors produce accepted Source observations only. Existing Runtime processing decides whether those Sources later produce Memory or Artifact Candidates.

Acceptance criteria

• A third-party connector can be installed explicitly, declare its capabilities, validate configuration, and pass a shared conformance suite.
• Repeated synchronization is idempotent, and external updates preserve exact old observations required by existing citations.
• External deletion or permission loss produces an explicit tombstone/unavailable state rather than silently rewriting history.
• A connector cannot write Memory, approve Candidates, commit Artifacts, publish Skills, or inject PreparedContext directly.
• Credentials and provider response bodies are absent from Source metadata, logs, status responses, and error messages.
• One connector failure does not block unrelated connectors or normal Runtime requests.
• Users can inspect last success, checkpoint, lag, item counts, bounded failure categories, and recovery guidance.
• Disconnect and retention behavior are documented, including which historical evidence remains and which live references become unavailable.

Alternatives considered

• Add every provider directly to the core repository: does not scale to private OA, Wiki, and ticketing systems.
• Expose a generic webhook that accepts arbitrary text only: useful as a basic capture path, but insufficient for checkpoints, updates, deletion, permission loss, and exact provenance.
• Allow connectors to write Memory or custom database rows: bypasses Source authority, review, lineage, and Runtime boundaries.
• Start with a connector marketplace: premature before one supported connector and the SDK conformance contract are proven.

Additional context

Depends on the accepted Source contract from #1240 and should follow the supported first integration tracked by #1363.

• I am willing to contribute code, docs, or design feedback.

Start by reading the accepted Source contract in #1240 and the supported first integration tracked by #1363. Then define the versioned connector contract and safe execution boundary in an RFC, using the listed acceptance criteria and conformance-suite requirements as the completion checklist. Done means one reference connector and shared fixtures demonstrate bounded, idempotent Source synchronization without bypassing Runtime boundaries.