[routing] ChainWeaver trace feedback loop — use execution outcomes to improve routing

[dgenio]

Context

ChainWeaver captures runtime tool execution traces (#11) and proposes candidate flows from observed patterns (#12). contextweaver scores and routes tools based on static metadata. Currently, there is no feedback loop: contextweaver cannot learn from ChainWeaver's execution outcomes to improve future routing.

The weaver-spec architecture defines three layers (contextweaver → agent-kernel → ChainWeaver) with data flowing in both directions. The forward path is clear: contextweaver produces RoutingDecision, which informs execution. The return path — execution outcomes informing routing — is missing.

Why it matters

• Closes the learning loop — successful flow executions should boost the tools involved in future routing. Failed sequences should be negatively weighted. Without this, routing never improves from experience.
• Pillar 3 — "Create optimized aggregations and chains" requires learning which chains work. The traces are the signal.
• Ecosystem integration — this is the primary data channel from ChainWeaver back to contextweaver, making the two repos mutually reinforcing.

Proposal

TraceIngestor protocol + implementation

@runtime_checkable
class TraceIngestor(Protocol):
    def ingest(self, trace: ExecutionTrace) -> None:
        """Process a completed execution trace to update routing heuristics."""
        ...

class ChainWeaverTraceIngestor:
    """Ingests ChainWeaver execution traces to update routing signals."""
    
    def __init__(
        self,
        co_occurrence: CoOccurrenceTracker,     # from #156
        episodic_store: EpisodicStore | None = None,
    ) -> None: ...
    
    def ingest(self, trace: ExecutionTrace) -> None:
        """
        - Record tool co-occurrences from the trace
        - Weight by outcome (success boosts, failure penalizes)
        - Store as episodic memory for future routing context
        """
        ...

Trace format

The ExecutionTrace type should be compatible with ChainWeaver's ObservedTrace (#11) and ExecutionResult:

@dataclass
class ExecutionTrace:
    trace_id: str
    steps: list[TraceStep]       # tool_name, success, duration_ms
    overall_success: bool
    source: str                  # "chainweaver", "manual", etc.
    timestamp: datetime

Scoring integration

# In Router, after ingesting traces:
# Tools appearing in successful chains get a routing score boost
# Tools appearing in failed chains get a routing score penalty
# Boost/penalty is configurable and decays over time

Acceptance Criteria

• TraceIngestor protocol in protocols.py
• ChainWeaverTraceIngestor implementation in src/contextweaver/adapters/ or src/contextweaver/store/
• Ingests execution traces and updates co-occurrence data ([routing] Tool co-occurrence tracking for relationship-aware routing #156)
• Success/failure weighting: successful traces boost scores, failed traces penalize
• Configurable boost/penalty factors and temporal decay
• ExecutionTrace dataclass compatible with ChainWeaver's ObservedTrace shape
• Unit tests with synthetic traces (successful chain, failed chain, mixed, empty)
• to_dict() / from_dict() on ExecutionTrace
• No dependency on ChainWeaver package (pure contract-based integration)

Dependencies

• Benefits from [routing] Tool co-occurrence tracking for relationship-aware routing #156 — CoOccurrenceTracker as the primary storage backend
• Benefits from [routing] Add EngineRegistry with pluggable Retriever, Reranker, and ClusteringEngine protocols #47 — could register as an engine for scoring signals
• Requires ChainWeaver [adapters] Add ingest_mcp_result() happy-path API for MCP artifact persistence #11 (trace capture) to have traces to ingest
• Related: ChainWeaver [eval] Add routing and context evaluation harness with gold-standard datasets #12 (determinism scoring — produces the quality signal this ingests)

Notes

• This is an optional integration module — contextweaver works without it. When ChainWeaver traces are available, routing gets smarter over time.
• The temporal decay prevents stale trace data from dominating: traces from 30 days ago matter less than traces from today.
• Consider a batch import mode for historical traces: ingest_batch(traces: list[ExecutionTrace]) for bootstrapping from recorded sessions.