[Interop, gated] ContextWeaver + provider-native tool search/deferred loading

Summary

Keep a thin, tested interop path between ContextWeaver's controlled capability surface and provider-native tool search/deferred loading only if comparative evidence shows the combination is useful.

This issue is intentionally gated by #445. Provider-native tool search addresses a large part of the runtime tool-bloat problem, so ContextWeaver should not build provider-specific export complexity merely to preserve a routing story that native mechanisms already solve adequately.

Product rationale

The promising composition is:

heterogeneous sources
→ ContextWeaver normalize/analyse/evaluate/compile
→ bounded or policy-approved capability surface
→ provider-native deferred loading / tool search
→ host executes

In this model:

• ContextWeaver owns reproducibility, identity/ambiguity analysis, evaluation, provenance, drift and optional deterministic pre-bounding;
• the provider owns late-binding/tool-search behavior inside its model/runtime;
• the host still owns execution, credentials and side effects.

This is complementary positioning, not an attempt to replace provider-native search.

Decision gate

Do not implement a broad provider-specific exporter until #445 produces evidence for at least one of:

• ContextWeaver + native tool search improves task success/selection/argument correctness over native search alone;
• pre-bounding the candidate surface materially improves false-exclusion/ambiguity behavior or operational predictability;
• adopters need the same evaluated surface to feed multiple providers and this exporter removes meaningful integration friction;
• the combination preserves ContextWeaver's reproducibility/provenance guarantees in a way users value.

If #445 shows native tool search alone is sufficient for target users, close or reduce this issue to documentation explaining the simpler choice.

Minimal scope if the gate passes

1. Implement the thinnest pure exporter/adaptor needed to map an evaluated/bounded ContextWeaver surface into the provider's supported deferred-loading/tool-search shape.
2. Keep provider semantics isolated under adapters/integration code; do not leak provider fields into core capability contracts.
3. Preserve deterministic output for the same bundle/configuration.
4. Add golden fixtures against the provider's documented current wire shape.
5. Document three modes:
   • provider-native search alone;
   • ContextWeaver controlled surface alone;
   • ContextWeaver + provider-native search.
6. Link to #445 results and state which mode won/lost under which scenarios.

Explicit non-goals

• adding provider-specific behavior to ChoiceCard/core routing contracts;
• reimplementing provider-native semantic search;
• maintaining long-tail provider adapters without adopter demand;
• implying that ContextWeaver is required when native search is sufficient.

Acceptance criteria

Before implementation:

• #445 contains comparative evidence supporting a combined path or a concrete adopter blocker documents the need.

If implementation proceeds:

• exporter/adaptor is pure, thin and isolated;
• golden fixtures cover supported current provider wire shape;
• docs compare native-only, ContextWeaver-only and combined modes honestly;
• benchmark rerun measures the combined path;
• no core provider lock-in is introduced;
• unsupported/changed provider behavior fails explicitly rather than silently.

Related

• #758 — product thesis/go-kill gates;
• #445 — required comparative evidence;
• #433 — neutral landscape/when-not-to-use;
• #434 — product demo;
• #651 — adapter lifecycle/support policy.

Start by reading #445 and its comparative evidence, then review the related product and adapter-policy issues #758, #433, #434, and #651. The first outcome is a decision on whether the gate passes; if it does, define the thinnest isolated exporter with deterministic output, golden fixtures, honest mode documentation, and an updated benchmark.