Rust Sentinel Module + Provider-Scoped ModelRegistry + ModelCapabilities Type System

[joelteply]

Summary

• Declarative pipeline execution engine — Sentinels execute step-based pipelines entirely in Rust with 9 step types (Shell, LLM, Command, Condition, Loop, Parallel, Emit, Watch, Sentinel)
• Universal CommandExecutor — Routes commands to either Rust modules (direct) or TypeScript server (via Unix socket), with agentic loop support via execute_ts_json
• Provider-scoped ModelRegistry — Fixes cross-provider context window collisions (e.g., same Llama model at 1400 on Candle vs 131072 on Together). Internal keys are now ${provider}:${modelId} with secondary index for fast unscoped lookups
• ModelCapabilities type system — Comprehensive enums and interfaces for quantization formats (FP32→Q2_K, GPTQ, AWQ), PEFT methods (LoRA, QLoRA, DoRA, IA3), inference runtimes, hardware profiles, and adapter stacking — the "knowing" layer for algorithmic model selection

Key Components

Component	Purpose
SentinelRunner	Rust-native pipeline step executor (9 step types, 103 Rust tests)
CommandExecutor	Universal Rust↔TypeScript command bridge via Unix socket
ModelRegistry	Provider-scoped model metadata cache with normalization chain
ModelCapabilities	Type system for LoRA/PEFT/quantization/hardware profiles
ModelContextWindows	7 functions now provider-aware, inference speed bug fixed

Provider-Scoped Registry Architecture

register(metadata)     →  key = "${provider}:${modelId}"
                           secondary: modelId → Set<provider>

get(modelId)           →  single provider? return it
                           multiple? return largest context window

get(modelId, provider) →  exact scoped lookup with normalization
                           (date-suffix strip, prefix match)

Bug fixed: getInferenceSpeed() now correctly returns 40 TPS for local providers (candle/ollama/sentinel) instead of assuming 1000 TPS (cloud) for any registry hit.

Consumer cleanup: Deleted 3 duplicated isLocal workaround patterns from ChatRAGBuilder, passed provider through 8 consumer files.

ModelCapabilities — The "Knowing" Layer

Defines everything needed for algorithmic model selection and LoRA genome paging:

• QuantFormat — 14 quantization levels (FP32 → Q2_K, GPTQ, AWQ)
• AdapterMethod — 8 PEFT techniques (LoRA, QLoRA, DoRA, IA3, prefix/prompt tuning)
• AdapterTarget — 9 targetable transformer layers (attention Q/K/V/O, MLP, embeddings)
• InferenceRuntime — 9 runtimes (Candle, llama.cpp, MLX, Ollama, vLLM, cloud)
• ModelAdapterProfile — composite type combining quantization + fine-tuning + hardware
• Query helpers: isFineTunable(), supportsLoRA(), supportsAdapterStacking(), estimateAdapterVramMB(), fitsInVram()

Test Results

• 103 Rust pipeline tests passing
• 58 TypeScript unit tests passing (12 provider-scoped, 21 ModelCapabilities, 25 existing)
• Deployed and verified: Candle personas produce coherent output with correct context windows

Test plan

• Rust commands route via ModuleRegistry (health-check)
• TypeScript commands route via Unix socket (list, file/load)
• Pipeline sentinel executes all 9 step types
• Provider-scoped registry: same model on two providers returns correct context window
• Unscoped lookup returns largest context window (backward compat)
• getInferenceSpeed returns correct TPS for local vs cloud
• ChatRAGBuilder workarounds removed, provider passed through
• ModelCapabilities type system: all enums, interfaces, query helpers tested
• Full deploy + AI persona chat verification

[Copilot]

Pull request overview

This PR implements a complete Rust-based sentinel execution engine with universal command routing. The changes represent a significant architectural shift, moving pipeline execution from TypeScript to Rust and establishing a bidirectional command bridge between the two layers.

Changes:

• New Rust CommandExecutor module for universal command routing (Rust-to-Rust direct, Rust-to-TypeScript via Unix socket)
• Complete removal of TypeScript sentinel implementations (BuildSentinel, OrchestratorSentinel, VisualSentinel, TaskSentinel, AgentSentinel)
• Refactored command implementations to delegate to Rust SentinelModule
• Updated logging paths from .sentinel-workspaces/ to .continuum/jtag/logs/system/sentinels/
• New comprehensive LoRA mesh distribution architecture documentation

Reviewed changes

Copilot reviewed 42 out of 43 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
command_executor.rs	New universal command executor with socket-based TypeScript bridge
logger.rs	Updated sentinel log paths, dual payload pattern support
sentinel.ts	Complete TypeScript bindings for Rust SentinelModule
CommandRouterServer.ts	Enhanced routing through JTAGSystemServer command interface
SentinelRunServerCommand.ts	Simplified to fire-and-forget Rust delegation
sentinel/status, logs/*	Migrated to Rust SentinelModule queries
Multiple .ts files	Removed legacy TypeScript sentinel implementations
LORA-MESH-DISTRIBUTION.md	New 830-line architecture document

Files not reviewed (1)

• src/debug/jtag/package-lock.json: Language not supported

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The global executor initialization using std::sync::OnceLock doesn't handle re-initialization gracefully. If init_executor is called twice, the second call is silently ignored (line 134 uses let _ =). This could mask bugs where the executor is initialized with the wrong registry.

Consider either:

1. Panicking if already initialized (fail-fast)
2. Returning a Result to indicate if initialization succeeded
3. Adding a debug log when re-initialization is attempted

[Copilot]

The logger payload extraction logic at lines 563-569 creates an inconsistency where the same data can be passed either nested under "payload" or at the top level. This dual-pattern support increases complexity and makes the API ambiguous for callers.

Consider standardizing on one pattern across the codebase, or document this behavior clearly in the command schema.

[Copilot]

The CommandRouterServer now requires JTAGSystemServer to be initialized before it can route commands (line 123-128). However, there's no explicit initialization order guarantee or error handling if the system isn't ready yet. If a Rust worker tries to execute a command before JTAGSystemServer is fully initialized, it will fail with "JTAGSystemServer not initialized".

Consider adding initialization ordering documentation or a startup sequencing mechanism to ensure the server is ready before workers connect.

[Copilot]

The pipeline execution in sentinel/run (lines 55-61) passes the entire pipeline definition through an environment variable (PIPELINE_JSON). Large pipeline definitions could exceed environment variable size limits (typically 128KB on Linux, 32KB on Windows).

Consider passing the pipeline via a temporary file instead, or implementing a size check with an appropriate error message.

Suggested change

	// Use sentinel/run which spawns a task for the pipeline
	const result = await rustClient.sentinelRun({
	type: 'pipeline',
	command: 'pipeline', // Internal: tells Rust this is a pipeline
	args: [],
	workingDir,
	env: { PIPELINE_JSON: JSON.stringify(pipeline) },
	// Serialize pipeline and enforce a conservative env var size limit
	const pipelineJson = JSON.stringify(pipeline);
	const maxEnvSize = process.platform === 'win32' ? 32 * 1024 : 128 * 1024;
	if (pipelineJson.length > maxEnvSize) {
	throw new Error(
	`Pipeline definition is too large to pass via environment variable (size=${pipelineJson.length} bytes, limit=${maxEnvSize} bytes). ` +
	'Please reduce the pipeline size or use a different execution mechanism that does not rely on environment variables.'
	);
	}
	// Use sentinel/run which spawns a task for the pipeline
	const result = await rustClient.sentinelRun({
	type: 'pipeline',
	command: 'pipeline', // Internal: tells Rust this is a pipeline
	args: [],
	workingDir,
	env: { PIPELINE_JSON: pipelineJson },

[Copilot]

WorkerClient now duplicates the command in both 'type' and 'command' fields (lines 238-244) for Rust IPC compatibility. This creates redundancy and increases the chance of inconsistency if one field is updated but not the other.

Consider updating the Rust IPC layer to accept 'type' consistently, or create a mapping layer that doesn't require duplicating data in the request object.