Found by the review of PR #242 (Phase 2, code search).
AIPipeline.generateSupportResponse now retrieves over docs and source. generateStreamingResponse still calls searchDocs only.
So the same question answered on the streaming path gets docs-only retrieval, while the prompt it runs under (GROUNDING_RULES, updated in #242) tells the model that source code may be present and that documentation silence is not evidence a feature is missing. The model is invited to reason about evidence the streaming path never fetched.
Latent rather than live: nothing in production reaches it. handlers/ai-response.ts and apps/web/src/app/api/qa/route.ts both call generateSupportResponse. But it will silently regress the #242 fix the moment anyone streams, and "no production caller" is exactly why the streaming path has drifted before — see #237 (no empty-response guard, raw provider error yielded as content) and #146 (streaming still reads the pre-#143 groundedness signal).
Three issues now describe the same underlying thing: generateStreamingResponse is a second copy of the pipeline that nobody exercises. Worth deciding whether to bring it to parity or delete it until there is a caller, rather than fixing each divergence as it is spotted.
Found by the review of PR #242 (Phase 2, code search).
AIPipeline.generateSupportResponsenow retrieves over docs and source.generateStreamingResponsestill callssearchDocsonly.So the same question answered on the streaming path gets docs-only retrieval, while the prompt it runs under (
GROUNDING_RULES, updated in #242) tells the model that source code may be present and that documentation silence is not evidence a feature is missing. The model is invited to reason about evidence the streaming path never fetched.Latent rather than live: nothing in production reaches it.
handlers/ai-response.tsandapps/web/src/app/api/qa/route.tsboth callgenerateSupportResponse. But it will silently regress the #242 fix the moment anyone streams, and "no production caller" is exactly why the streaming path has drifted before — see #237 (no empty-response guard, raw provider error yielded as content) and #146 (streaming still reads the pre-#143 groundedness signal).Three issues now describe the same underlying thing:
generateStreamingResponseis a second copy of the pipeline that nobody exercises. Worth deciding whether to bring it to parity or delete it until there is a caller, rather than fixing each divergence as it is spotted.