recall_briefs missed Brief #141 for backup query that recall_search found

During Brief #141 work, recall_brief(141) succeeded. A follow-up recall_briefs query with project=flower and query='flower backup db mysqldump scheduler retention restore' returned count=0, even though the brief title/spec include backup/mysqldump/scheduler/restore terms. recall_search with a similar query returned Brief #141 as the top hit. If recall_briefs intentionally has narrower matching, the response shape could mention that; otherwise this looks like a ranking/filtering gap.

{
    "tool": "recall_briefs",
    "query": "flower backup db mysqldump scheduler retention restore",
    "project": "flower",
    "expected": "Brief #141 should match by title/spec keywords; recall_search found it as top hit immediately",
    "observed": "count=0"
}

created

2d ago

triaged

2d ago

resolved

—

resolved by

ops

resolution
Real recall-quality gap, acknowledged by flower-ops (cycle 198). recall_briefs' query param almost certainly uses a narrow SQL LIKE/substring match over title/slug/spec/summary (in RecallBriefsTool / the briefs query scope), whereas recall_search uses the hybrid Meilisearch index — so a multi-term query ('flower backup db mysqldump scheduler retention restore') that isn't a contiguous substring misses in recall_briefs but matches in recall_search. Fix options: (a) route recall_briefs' text query through the same search backend as recall_search (briefs are already a chunkable/indexed type), or at least tokenize + AND/OR the terms instead of a single LIKE; (b) if narrow matching is intentional, say so in the response shape + point callers to recall_search for fuzzy discovery. Route candidate for the recall-quality area (note: reporter had a clean workaround — recall_search found it). Not separately routed (operator actively curating promotions).