Verify a retrieved UI recommendation before reuse

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A React dialog fails to restore focus to its opener. Teaching C1 is style-pricing-palette mentioning React, while C2 ux-focus-return describes returning focus to an opener that still exists. Catalog items are candidates, not fixes established by a stack keyword.

Mechanism

Query one observable outcome in its semantic domain, then check category, identity, platform and mechanism. Retrieve stack detail separately when needed. Use bounded rewrites for missing matches, label fallback origin and persist verified guidance only. Inspect actual interaction after implementation.

Bad example

Choose/persist C1 solely for mentioning React, apply its palette and claim focus repaired without inspecting the opener or active element.

Good example

Search UX dialog keyboard focus and inspect C2's category, opener-return mechanism and platform fit. Reject palette-only C1. Query React detail separately if needed; failed bounded retry remains no verified match with labelled general fallback. After implementation close the dialog and inspect focus on the existing opener.

Why the change matters

Topic/stack relevance differs from behavioral relevance. Mechanism plus actual focus checks prevent irrelevant guidance becoming a durable fix claim, while fallback labels preserve evidence provenance.

Observable expectation

The illustrative record selects C2/rejects C1 with reasons; closing yields activeElement=existing opener. Empty catalogs retain no-verified-match/fallback states.

Source word/retry counts do not prove suitability. No React app is repaired here.

Limits

Removed openers need the project’s focus fallback; this fixture assumes an existing opener. Catalogs may be stale/wrong, and scope fit does not guarantee quality. Verify real behavior/accessibility.