ADR-029: External Intelligence Providers for SONA Learning

[grparry]

Problem

When ruvllm operates inside a larger system — a workflow engine, CI/CD pipeline, or coding assistant — the real quality signal lives outside ruvllm. The external system knows whether tests passed, whether the human reviewer approved the output, whether acceptance criteria were met. But there's no clean way to feed that data into SONA's learning loops.

Today the options are:

1. Fork ruvllm and add custom signal-loading code (works but creates merge burden)
2. Accept hardcoded quality scores (SONA can't learn the difference between good and bad work)

Proposal

A trait-based extension point — IntelligenceProvider — following the same pattern as LlmBackend and WasmKernelPack:

pub trait IntelligenceProvider: Send + Sync {
    fn name(&self) -> &str;
    fn load_signals(&self) -> Result<Vec<QualitySignal>>;
    fn quality_weights(&self) -> Option<QualityWeights> { None }
}

Providers register with IntelligenceLoader and get called during load_all(). A built-in FileSignalProvider covers the common case where non-Rust systems write a JSON file to .claude/intelligence/data/.

Zero overhead when unused. Fully backward compatible.

Context

• ADR-002 defines quality_score: f32 in the Witness Log and envisions quality data feeding SONA — but doesn't address external ingestion
• ADR-CE-021 (Shared SONA) establishes multiple systems contributing trajectories
• This fills the gap between those decisions and what's available today

Full proposal

PR #190 contains the complete ADR with considered alternatives, code examples, implementation phases, and consequences.