Split out from review feedback on #744, which asked for this as a follow-up rather than part of that PR. find-api answers only from what a project already references, which is correct for "does my code compile against this" but leaves a real gap: a member that exists in a newer SDK reads as simply absent.
From the review:
This is a feature addition, not a defect in local-only lookup. An older project already has LanguageModel but lacks GenerateStructuredJsonResponseAsync; a newer SDK contains it.
Please allow discovery in a cached latest-stable Windows App SDK catalog, clearly separate from project references:
GenerateStructuredJsonResponseAsync
Project index (AI 1.8.53): no matching member
SDK catalog (Windows App SDK 2.4.0 / AI 2.4.4): found
The experiment acquired about 175 MB of selected SDK/API packages and produced a roughly 4.9 MB metadata cache. Make the initial download explicit and reuse the cache; do not modify the project or install a runtime. "Found in version X" must not imply a minimum version, compilation success, or device compatibility.
What this needs to get right
- Separate from project references. The catalog answer is a second section, never merged into the project index result. A reader must always be able to tell which one answered.
- Explicit first download. ~175 MB is not something to acquire silently behind a search. Ask, or require an opt-in verb.
- Reuse the cache. The ~4.9 MB metadata cache is the artifact that matters; the packages it was built from should not need to stay on disk.
- No project mutation. No package added, no restore triggered, no runtime installed.
- Careful wording. "Found in Windows App SDK 2.4.0" states where it was found. It must not be read as a minimum version, a guarantee the call compiles, or a claim about device compatibility.
Not in scope
Recognizing terms that appear nowhere in package information (for example "Phi Silica" or "LLM" when the metadata never uses them). An honest miss is better than an unrelated match.
Split out from review feedback on #744, which asked for this as a follow-up rather than part of that PR.
find-apianswers only from what a project already references, which is correct for "does my code compile against this" but leaves a real gap: a member that exists in a newer SDK reads as simply absent.From the review:
What this needs to get right
Not in scope
Recognizing terms that appear nowhere in package information (for example "Phi Silica" or "LLM" when the metadata never uses them). An honest miss is better than an unrelated match.