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

[dgenio]

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 [Blocked until D1 evidence] D2/D3 comparative falsification vs native tool search #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:

• [Blocked until D1 evidence] D2/D3 comparative falsification vs native tool search #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

• Epic: Falsify ContextWeaver and earn the smallest surviving product #758 — product thesis/go-kill gates;
• [Blocked until D1 evidence] D2/D3 comparative falsification vs native tool search #445 — required comparative evidence;
• docs: Map capability discovery, tool search, gateways, and context compilation #433 — neutral landscape/when-not-to-use;
• docs/demo: Prove the reproducible capability-surface workflow end to end #434 — product demo;
• governance: Define adapter tiers, compatibility windows, conformance, and retirement #651 — adapter lifecycle/support policy.

[dgenio]

Backlog consolidation update: this issue is in the constrained-selection and provider-export cluster, anchored by #515 (constrain before) and #479 (validate after).\n\nDependencies\n- Depends on: #515\n- Related to: #479, #609, #620