📄 packages/analysis/src/common/filter/filter-path.ts:106-114
In classifyFilePathInternal the final two branches both return { status: 'OUT_OF_SCOPE' }:

if (mainClassification === 'OUT_OF_SCOPE' || testClassification === 'OUT_OF_SCOPE') {
  return { status: 'OUT_OF_SCOPE' };
}
return { status: 'OUT_OF_SCOPE' };

The explicit conditional is dead because the unconditional fallthrough returns the same value. This is harmless functionally but suggests an intended distinction (e.g. NO_MATCH vs OUT_OF_SCOPE) that was collapsed and may confuse future maintainers. Consider removing the conditional, or, if NO_MATCH was meant to be surfaced distinctly to observability, modeling it explicitly.

📄 packages/analysis/src/file-stores/generated-sources.ts:357-371 📄 packages/analysis/src/file-stores/generated-sources.ts:261 📄 packages/analysis/src/file-stores/generated-sources.ts:281-287
In the per-file loop of buildGeneratedSourceObservability, the final else branch (file classified MAIN/TEST, not tagged, and present in requestedFilePaths) counts the file as excluded. This branch is effectively unreachable: familyByFile (taggedFamilyByFile) is derived from filterAnalyzableGeneratedFiles(derivedFamilyByFile, analyzableFiles), which tags every resolved file that is present in analyzableFiles. So any resolved file that is in requestedFilePaths is already tagged and hits the first continue branch. When analyzableFiles is undefined, requestedFilePaths is undefined and every resolved file is tagged as well. The dead branch is harmless but obscures the intended classification logic; consider removing it or adding a clarifying comment about why an in-scope, requested, untagged file is treated as excluded.

📄 packages/analysis/src/file-stores/generated-sources.ts:262-269 📄 packages/analysis/src/file-stores/generated-sources.ts:444-457
refreshFilteredState calls logGeneratedSourceObservability, which emits an INFO line for the summary plus one INFO line per generated-source family. refreshFilteredState runs on each request-files-key change (from isInitialized) and during postProcess. In long-lived SonarLint sessions where generated-source state is re-derived on filesystem events / repeated analyses, this re-emits the same INFO lines on every refresh, producing log noise for projects that use code generators. Consider logging the summary at DEBUG, or only logging when the computed telemetry actually changes from the previously logged value.

📄 packages/analysis/src/file-stores/generated-sources.ts:533-541 📄 packages/analysis/src/file-stores/generated-sources.ts:270
createGeneratedSourceObservabilityLogKey serializes the entire observability object on every postProcess/refreshFilteredState call. Note families[].excludedPaths and families[].outOfScopePaths hold all matching paths (sampling only happens later in formatSamplePaths), so for large projects with many generated outputs this stringifies large arrays purely to compute a dedup key. Since this runs once per refresh (not in a hot per-file loop) the impact is bounded, but a cheaper key (e.g. derived from the telemetry counts plus a hash of path lengths) would avoid the full serialization.

📄 packages/analysis/src/file-stores/generated-sources.ts:224-232 📄 packages/analysis/src/file-stores/generated-sources.ts:136-143 📄 packages/analysis/src/file-stores/generated-sources.ts:80 📄 packages/analysis/src/file-stores/generated-sources.ts:270-274
clearDerivedState() resets observabilityTelemetry to empty but does not reset the new lastLoggedObservabilityKey, and neither does clearCache(). After a cache invalidation (config change, relevant fs event), if a re-derivation produces observability identical to the last logged one, the dedup check at L271 will suppress the log even though the derived state was just rebuilt. This is inconsistent with the surrounding reset logic. If suppression across invalidations is intentional, that's fine; otherwise reset the key in clearDerivedState() so a fresh analysis re-logs.