XNCF Extension Library Guide (Senparc.Xncf.xxx)

This page analyzes official extensions from the NcfPackageSources source perspective and was checked against the development line on 2026-08-13. Their internals are not prerequisites for Template-based business modules. This page fills the missing half beside “NCF libraries”: XNCF extension modules (Senparc.Xncf.xxx).

1. Why It Feels Like “XNCF Is Missing”

The “NCF Libraries” section mainly covers Senparc.Ncf.*, which is the runtime foundation layer (Core, Repository, Service, Database, etc.).

But in NCF architecture, Senparc.Xncf.* is the capability assembly layer. Without it, docs cover the “foundation” but not the “building blocks”.

2. NCF Definition as a Modular Framework

In NCF, modularization is not just folder separation. It is a runtime-governable capability system where units are discoverable, installable, enable/disable-able, and operable.

Think in two layers:

  • Senparc.Ncf.*: framework foundation layer (shared runtime capabilities and constraints).
  • Senparc.Xncf.*: capability module layer (feature delivery by installable modules).

2.1 XNCF as a Single-Granularity Module Unit (Key)

A Senparc.Xncf.xxx module is a single-granularity capability unit:

  • Own Register metadata and lifecycle (install/update/uninstall).
  • Can declare its own database, menu, Function, and MCP capability.
  • Can be independently enabled, disabled, operated, and secured.

This is the core engineering value of NCF modularity: capabilities are split into governable minimal units instead of being fused into a monolith.

3. Why Developers Should Care About XNCF Modules

  • Lower coupling: clear boundaries, less cross-module entanglement.
  • Independent evolution: module-level version iteration.
  • Controlled release: module-level rollout and rollback.
  • Stronger security: high-risk capabilities (for example Terminal/DatabaseToolkit) can be isolated.
  • Better team collaboration: module-level ownership and cleaner PR boundaries.

4. Common XNCF Module Map in the Current Version

4.1 System Baseline Modules

  • Senparc.Xncf.SystemCore (v0.1.1): system core services
  • Senparc.Xncf.SystemManager (v1.1.3): system administration
  • Senparc.Xncf.SystemPermission (v0.2.0): permission / role management
  • Senparc.Xncf.XncfModuleManager (v0.1.2): XNCF module management core
  • Senparc.Xncf.Menu (v0.1): menu management
  • Senparc.Xncf.Tenant (v0.1): multi-tenancy
  • Senparc.Xncf.AreasBase (v0.1): area base module

4.2 AI / Agent / RAG Modules

  • Senparc.Xncf.AIKernel — model/vector configuration and optional local fine-tuning through a separately deployed worker.
  • Senparc.Xncf.PromptRange
  • Senparc.Xncf.AgentsManager
  • Senparc.Xncf.KnowledgeBase
  • Senparc.Xncf.MCP
  • Senparc.Xncf.AIAgentsHub
  • Senparc.Xncf.NeuCharWorkflow — server-side visual orchestration built from Functions, system nodes, and controlled Agents. See NeuChar Workflow.

4.3 Tooling and Ops Modules

  • Senparc.Xncf.XncfBuilder
  • Senparc.Xncf.Sandbox (lab sandbox orchestration via Docker/Wasm; see Sandbox environment setup)
  • Senparc.Xncf.DesktopBridge (protected HTTP/SSE bridge, device pairing, and activity notifications for a desktop companion)
  • Senparc.Xncf.DatabaseToolkit
  • Senparc.Xncf.FileManager
  • Senparc.Xncf.Terminal
  • Senparc.Xncf.FirmwareUpdate
  • Senparc.Xncf.ChangeNamespace
  • Senparc.Xncf.WeixinManager
  • Senparc.Xncf.Dapr (microservice integration; project version 0.11.0-preview2)
  • Senparc.Xncf.Accounts
  • Senparc.Xncf.Installer

Contract packages include AIKernel.Abstractions, AgentsManager.Abstractions, MCP.Abstractions, PromptRange.Abstractions, NeuCharWorkflow.Abstractions, and Sandbox.Abstractions; these provide shared contracts rather than standalone modules. EmailExtension, OfficeExtension, SmsExtension, and ReloadPage are source-only unpublished extensions.

For full versions, order, and scenario guidance:

4.4 Recent Module Entry Points

  • AIKernel local fine-tuning: administer datasets and bounded LoRA/QLoRA jobs, inspect persisted training events, and evaluate adapters before separately deploying an inference model. Training is disabled by default, requires an authenticated companion worker, and does not replace KnowledgeBase retrieval. See the concepts, setup, and operator guide.
  • NeuCharWorkflow: create, test, trigger, observe, and replay server-side workflows. The module supports manual, interval, and Webhook triggers; it can invoke enabled XNCF Functions, Agents/Agent groups/A2A objects, and built-in control nodes. Start with NeuChar Workflow.
  • Sandbox: creates disposable Docker/Wasm experiment sessions. Its image, registry, and host preparation details are intentionally maintained in Sandbox environment setup.
  • XncfBuilder: supports both trusted direct scaffolding and the isolated development workflow: source snapshot, constrained AI edits, Sandbox preview, human review, and guarded merge. Template/application users should start with the usage guide; source contributors can continue with the source analysis.
  • DesktopBridge: connects an NCF host to an authorized desktop companion through a protected HTTP/SSE bridge, device pairing, and activity notifications. Treat the bridge token as an application secret, not as a substitute for TLS, network controls, or Admin authorization.

5. Developer Guidance: Design XNCF as Single-Granularity Units

Recommended baseline rules:

  1. One module should focus on one capability domain.
  2. Keep module boundaries explicit: DB/config/auth/menu/function scope.
  3. Prefer [FunctionRender] for executable capability declaration.
  4. Enable EnableMcpServer only when needed, with explicit security controls.
  5. Run high-risk modules with least privilege and audit logging.
  6. Keep Function implementations and DTOs under Application/AppServices and Application/DTOs to match the current XncfBuilder template.
  7. Use resource files and [LocalizedDescription] for multilingual menus, descriptions, and parameters instead of hard-coding one language.

6. Where to Continue Reading