feat(examples): add optional Adanos sentiment enrichment example

✨ Feature Summary

Would you accept a small, optional example showing how to enrich financial research with time-bounded Adanos sentiment observations alongside QuantMind's existing knowledge artifacts?

Disclosure: I work on Adanos, a commercial market sentiment API. I would contribute and maintain the example. This is a scope discussion before implementation, as requested by CONTRIBUTING.md.

🎯 Motivation

An article or paper and the market discussion around it provide different kinds of evidence. A research workflow could retrieve financial knowledge through QuantMind and consult a separately attributed sentiment snapshot for the same asset and period, without interpreting sentiment as a trading recommendation or as the article's own content.

📋 Detailed Description

The proposed example would fetch a bounded response using the user's API key and keep the asset, source, requested period, retrieval time, and available provenance with the observations. It would distinguish observation time from retrieval time and would not claim historical point-in-time availability that the upstream response cannot establish.

Adanos data must remain distinguishable from original news documents and QuantMind-extracted knowledge. Aggregated scores would not be converted into fabricated articles, original-source citations, or complete news coverage. The supported source and operation for the first example would be agreed with you rather than introducing a broad endpoint wrapper.

🔧 Proposed Implementation

Start with one focused example using existing QuantMind operations and the existing HTTP dependency. No provider registry, agent runtime, mandatory SDK dependency, or changes to the default news collector.

I read the news design's exclusion of authenticated feeds from the current scope. This proposal deliberately asks whether an opt-in example outside collect_news is welcome; it does not assume that boundary should change. The example-versus-core discussion in #52 is also relevant here.

API Design

No new public QuantMind API is proposed. The example would compose existing components, with the final input/output shape agreed before code is written.

Configuration

An optional ADANOS_API_KEY supplied through the environment, used only when explicitly running the example. Documentation would identify the service as commercial and state the chosen operation's plan requirements and limits. No credentials or live customer responses would be committed.

🎨 User Experience

A researcher explicitly runs the example for an asset and bounded period, sees the QuantMind research output and separately attributed sentiment evidence, and can distinguish unavailable data from a neutral sentiment result. Authentication, entitlement, and rate-limit errors would be reported without exposing credentials or silently substituting another source.

📊 Use Cases

1. Compare retrieved company research with separately attributed market-discussion sentiment for a specified period.
2. Preserve a dated sentiment response alongside a research artifact for later inspection, without presenting it as a point-in-time backtest guarantee.

🔗 Related Issues

• #52: discussion of a focused example versus built-in functionality.
• #100: source-explicit collection and the separation of collection from semantic extraction.
• Adanos API reference and OpenAPI contract.
• No existing Adanos issue or PR found in the repository search.

Implementation Considerations

If this direction is welcome, I would include mocked success/failure coverage, focused usage documentation, and run the repository verification harness. Any applicable bounded live smoke check and credential handling would follow the existing component workflow; ordinary CI would remain network-free. Which research use case/source would you prefer for the first example, or would you prefer this to live in our own repository instead?

Breaking Changes

• This feature would introduce breaking changes
• This feature is backward compatible

Dependencies

• Requires new dependencies
• Uses existing dependencies only

---

Checklist

• I have searched existing issues to avoid duplicates
• I have provided a clear and detailed description
• I have explained the motivation and use cases
• I have considered the implementation approach
• I have thought about potential breaking changes

Start by reading CONTRIBUTING.md, the news design around collect_news, and the example-versus-core discussion in #52. Before implementation, confirm whether an opt-in Adanos example belongs in this repository and agree on its first supported operation and input/output shape. Done would include mocked success and failure coverage, focused usage documentation, credential-safe handling, and the repository verification harness passing.