Feedback #92: recall_search missed the decision-records design doc for a highly on-topic query; returned generic daemon-handoff scratchpads instead

Merged to master by flower-orchestrator (daemon 29). Merge commit a0ae3aa (worker commit e34558dd, branch flower/194-recall-search-relevance). Full suite green on MAIN: 1026 tests / 1024 passed / 2 skipped / 0 failed (incl. live-Meili fail-closed tests). DIAGNOSTIC FINDING (both leading hypotheses DISPROVEN via read-only investigation on MAIN's real corpus): the `decision-records-design-doc.md` is a PHANTOM SOURCE — it doesn't exist anywhere in the corpus (not a flower/Solo scratchpad, not a RepoDoc [0/319], not on disk). Its §5.2 content lives ONLY inside session segments (the epic-#95 design-loop conversation) — which is why segments ABOUT it rank ~0.79 but no discrete "doc" chunk exists to rank #1. This is a CAPTURE GAP, not a ranking bug. Archived-exclusion hypothesis also disproven: archived scratchpads ARE fully chunked/embedded/searchable (code has no archived predicate; 106/125 archived pads have chunks — regression-guarded in EmbedChunksTest). SHIPPED (the one confirmed, conservative, in-scope defect): the fail-OPEN scope leak behind #186's cross-project bleed. When scope=project/worktree and the ref didn't resolve, both search paths silently widened to an unfiltered all-projects, includes-non-searchable query. Now fails CLOSED (Meili project_id=-1 / keyword no-match) with an explanatory notice; resolved + global scopes unchanged. NO speculative ranking change ("don't ship blind" — and it wouldn't surface a phantom doc anyway). ⚠️ FOLLOW-UP (operator/successor): the acceptance criterion "doc surfaces in top hits" is NOT yet meetable — the doc must first be CAPTURED (commit it under /docs → RepoDoc pipeline #45, or re-create it as a Solo scratchpad). Recommend a small follow-up brief. Deferred ranking ideas (down-weight giant handoff scratchpads, mergeHits score normalization) documented on the branch but not shipped.

DIAGNOSIS (read-only against MAIN's real corpus) + FIX. Branch flower/194-recall-search-relevance @ e34558dd (off master). php artisan test GREEN (1004 passed / 1 pre-existing skip / 0 fail, 6477 assertions, MEILISEARCH_KEY=LARAVEL-HERD); pint clean. === DIAGNOSIS: the brief's leading hypotheses were BOTH wrong; the real cause is a COVERAGE gap of a different kind === 1) The design doc is a PHANTOM SOURCE — absent from the ENTIRE corpus. - No flower scratchpad IS the doc: content-search of scratchpads for `decision-records-design-doc`, `parent_answer_id`, `decision_answers`, `Decision Records` only returns pads that *reference* it (triage log 333, refine handoffs 364/386, "Feedback #83 fix-spec" 380). None contains the §5.2 design content. - No RepoDoc IS the doc: repo_docs LIKE the doc = [] (319 repo_docs exist, none matches). - Not a Solo scratchpad either: scratchpad_list(project 49, "decision records design") → only the fix-spec + handoffs. There is NO `decision-records-design-doc` scratchpad in Solo project 49. - Not on disk: find over ~/Documents/code for *decision-records-design*/*decision-records* → nothing. => The doc's content lives ONLY inside session_segments (the design-loop conversation for epic #95), which is exactly why the refiner saw segments ABOUT it rank ~0.79 but no discrete "doc" chunk. There is nothing to rank #1 because the doc was never captured as a durable flower source. 2) The "archived → excluded" hypothesis (a) is DISPROVEN. Archived scratchpads are fully chunked/embedded/indexed as searchable — confirmed in code (ingest pulls `--include-archived`; EmbedChunks::reconcileScratchpadChunks has ONLY a project_id predicate, no archived filter; `archived` is written as chunk text/tag metadata, and is_searchable is gated by project.is_searchable, NOT archived) AND in data (106 of 125 archived scratchpads have chunks). So the brief's "keep finalized design docs searchable even when archived" coverage fix is already satisfied — nothing to change there. I added a REGRESSION test to lock this in. 3) Cause classification: NOT (a) archived-exclusion, NOT a ranking problem for the doc (it can't be out-ranked; it isn't indexed). It's (b)-adjacent: the artifact was never captured as an ingestable source. This is a CAPTURE gap, bigger than a search-relevance tweak, overlapping #45 (index /docs markdown — shipped) and #174 (ingest health). See "FOR THE ORCHESTRATOR" below. === WHAT I FIXED (the one confirmed, conservative, in-scope code defect): cross-project scope bleed = FAIL-OPEN scoping === Confirmed reachable latent bug matching #186's symptom (lounge docs outranking flower docs for a flower-scoped query): when scope=project/worktree but the ref doesn't resolve to an id (typo/unknown, or scope=project with no project ref), normalizeSearchFilters leaves project_id/worktree_id null and searchable_only=false → MeiliSearchService::buildFilter added NO scope clause AND no is_searchable clause (that lives only in the global branch), and DatabaseSearchService::applyScope added no constraint → the "scoped" search silently widened to an UNFILTERED, ALL-PROJECTS, includes-non-searchable query. Fix (fail-closed, both paths): an explicit project/worktree scope whose target doesn't resolve now matches NOTHING (Meili: impossible `project_id = -1`; keyword: `1 = 0`) instead of everything. RecallService::search returns a `notice` so an empty payload reads as "scope not found", not "no matches". Resolved scopes + global scope are byte-for-byte unchanged (all prior scope tests still pass). This is the "verify project scoping actually filters cross-project bleed" ask. I did NOT ship a speculative ranking change (down-weight handoffs / boost design docs) — it wouldn't surface a phantom doc and the brief says don't ship blind. Tests added: (1) MeiliSearchServiceScopeFilterTest — buildFilter fail-closed contract via reflection (always green, no live Meili); (2) RecallServiceTest — keyword-path project scope fails closed with NO cross-project bleed + positive control + notice, worktree scope fails closed; (3) SearchServiceTest — live-Meili project/worktree fail-closed (ran, not skipped — Meili reachable in worktree); (4) EmbedChunksTest — archived scratchpad still chunked+embedded+searchable (guards the coverage intent against a future archived-exclusion). === REGRESSION QUERIES FOR THE ORCHESTRATOR TO RUN ON MAIN (real index) === A) Cross-project bleed fix (should PASS now): - recall_search(query="decision follow-up chains decision_answers parent_answer_id §5.2", scope=project, project="does-not-exist-typo") → expect 0 hits + a `notice` ("did not resolve"); MUST NOT return lounge/other-project docs. - recall_search(query="decision_answers parent_answer_id", scope=project, project="flower", sources=[scratchpad,doc]) → every hit MUST be project_id=16 (flower); NO cross-project bleed. B) The original acceptance criterion "design doc surfaces in top hits" is currently UNMEETABLE by search code alone — the doc is not in the corpus. To make it pass, the doc must first be CAPTURED (see below), then re-embedded; only then re-run the feedback #92 query (`decision follow-up chains decision_answers parent_answer_id threaded UI §5.2`, flower-scoped) and the #83 query (flower decision-affordance design craft). === FOR THE ORCHESTRATOR — decision needed (out of scope for this conservative fix) === The design doc for epic #95 was produced by a design-loop and never persisted as a durable flower source. To make it recall-searchable, pick a capture path: (i) commit it as a repo markdown doc under flower's /docs so it rides the RepoDoc→doc pipeline (#45, already shipped) — cleanest + durable; or (ii) re-create it as a Solo scratchpad in project 49 (it'll be ingested, archived or not). Then flower:embed on MAIN. This likely warrants its own brief; recommend adjusting #194's acceptance to (a) the cross-project-bleed fix shipped here + (b) a capture follow-up, since no ranking/scoping change can surface an unindexed doc. Optional deferred RANKING ideas (NOT shipped, need real-index A/B — do not ship blind): down-weight huge high-churn daemon HANDOFF scratchpads and/or normalize the keyword-vs-Meili score scales in MeiliBackedSearchService::mergeHits (0..1 Meili score is currently merged unnormalized with an unbounded keyword score in project-scope-with-touches).

## Problem recall_search fails to surface the flower `decision-records-design-doc.md` (finalized design doc; §5.2 = decision follow-up chains / `decision_answers` / `parent_answer_id`) even for queries containing its exact terms. Reported twice — feedback #92 (this brief) + feedback #83 (merged #186). Reproduced live 2026-07-04. ## Evidence (flower-refine reproduction — see refinement event) - `sources=[scratchpad,doc]` replay → only daemon HANDOFF scratchpads; doc absent. - broad replay (all sources) → doc scratchpad still absent, though session-segments ABOUT it rank ~0.79. - #186 clues: doc "likely archived"; cross-project bleed (lounge docs outranking flower docs for a flower-scoped query). ## Diagnostic-first (do BEFORE any ranking change) 1. **Locate**: find the `decision-records-design-doc.md` Solo scratchpad — confirm it exists, get its id, and whether it is ARCHIVED (scratchpad_list/find). 2. **Index state**: is that scratchpad a flower chunkable that is chunked + embedded + present in Meili? Query chunks / chunk_embeddings for it; check ingest_state; check whether ARCHIVED scratchpads are excluded from the chunk pipeline. This definitively separates coverage-gap vs ranking. 3. **Classify the cause**: - (a) not indexed because ARCHIVED → policy call: finalized design docs should stay searchable (index archived scratchpads with a recency/active penalty rather than dropping them). - (b) not indexed due to ingest backlog / pipeline gap → converges with ingest-health #174 + doc-indexing #45; ensure it gets ingested. - (c) indexed but out-ranked → genuine ranking problem (below). ## Fix (branch on diagnosis; keep conservative — search ranking is subtle, do NOT ship blind) - COVERAGE: ensure finalized design-doc scratchpads are indexed/searchable (don't silently drop archived; and/or promote design/spec docs). - RANKING: (i) high-churn giant daemon HANDOFF scratchpads dominate scratchpad-scoped recall over specifically-matching design docs — consider down-weighting huge/high-churn handoff scratchpads or boosting design/spec docs on strong keyword match; (ii) CROSS-PROJECT BLEED (#186) — a project-scoped query returned out-of-project lounge docs; verify project scoping actually filters/penalizes cross-project hits. - Regression: the exact feedback #92 query (`decision_answers parent_answer_id §5.2`) and #83 query (decision-affordance design craft), scoped to flower, must surface the design doc in the top hits. ## Acceptance - Diagnosis documented (coverage vs ranking, with the doc's actual index/archive state). - Design doc surfaces in the top hits for both feedback queries, flower-scoped. - No cross-project bleed for a project-scoped query (regression). - `php artisan test` green + pint. `Brief: #194` trailer. ## Provenance feedback #92 (flower-w122-followup) → operator note (ingest-backlog vs ranking hypotheses + replay method) → flower-refine live reproduction + consolidation of #186/feedback #83 (flower-119; "likely archived" + cross-project-bleed clues). Existing ops fix-spec context: Solo scratchpad 1072 (flower scratchpad 380) / Solo todo 706 (flower todo 386). Related: #45 (index /docs markdown — shipped), #174 (ingest health), #68 (orphan-chunk prune).

Refine grounding + live reproduction (flower-refine, 2026-07-04). CONSOLIDATION: merged #186 (feedback #83, from the #119 worker) into this brief — same defect (recall_search fails to surface `decision-records-design-doc.md`), reported from two sessions. This brief now carries feedback #83 + #92. REPRODUCED NOW (not a since-resolved transient): - Exact replay — recall_search(q="decision follow-up chains decision_answers parent_answer_id threaded UI §5.2", scope=project:flower, sources=[scratchpad,doc], limit 8) → ALL 8 hits are daemon reset/orchestrator HANDOFF scratchpads (score ~0.69-0.71); the design doc is ABSENT. Matches feedback #92 exactly. - Broad unrestricted replay (all sources) → the design-doc SCRATCHPAD still does not appear, yet session_segments ABOUT the doc rank well (~0.79). Topic IS in-corpus; the doc scratchpad chunk itself is not surfacing. DIAGNOSIS — likely BOTH operator hypotheses, weighted to coverage: 1. COVERAGE GAP (primary): the design-doc scratchpad chunk isn't surfacing at all. #186's clue: the doc is "LIKELY ARCHIVED" → archived scratchpads may be excluded from / deprioritized in the chunk pipeline. Also possible: not chunked/embedded (ingest backlog per operator's note) or a scratchpad-ingest gap. DEFINITIVE test = the doc's actual index/archive state. 2. RANKING (secondary): huge high-churn daemon HANDOFF scratchpads dominate scratchpad-scoped recall; and #186 saw CROSS-PROJECT BLEED (lounge /authors docs outranking in-project flower docs for a flower-scoped query). Even once indexed, these may still crowd it. The operator's "replay after backlog resolves" is moot as a wait-gate — the miss reproduces live; the definitive diagnostic (index/archive state of the doc) can and should run now.

I wasn't involved at the time of this happening (operator) but I know that there _was_ an issue/currently an issue with the ingest being backlogged and I wonder if that wasn't at play here. But I also think it's worth exploring if the handoff documents should be ranking above spec documents - once we get the queue/embed backlog resolved I wonder if we can replay the tool calls the session that reported this feedback and see what the results are like and if it was due to missing session/spec/ingest in the index or the results really are dominated by handoff docs.

Feedback #92 Authority: AUTONOMOUS Funnel: B - autonomous brief Gate: this bug/MCP/Sentry feedback may be planned without operator approval. Kind: mcp_issue Source: flower-w122-followup Summary: recall_search missed the decision-records design doc for a highly on-topic query; returned generic daemon-handoff scratchpads instead Detail: While grounding for Brief #122 (PR-6 follow-up chains) I ran recall_search(query="decision follow-up chains decision_answers parent_answer_id threaded UI §5.2", scope=project, project=flower, sources=[scratchpad,doc], limit=6). Every top hit was a daemon reset/orchestrator HANDOFF scratchpad; none contained the §5.2 follow-up design. The brief spec explicitly references scratchpad `decision-records-design-doc.md` (the finalized craft doc with the §5.2 follow-up section) — that's the doc I'd expect to rank #1 for those exact terms (decision_answers, parent_answer_id), but it didn't appear in the top 6. Not blocking (recall_brief(95) carried the full synthesized spec incl. §5.2, which was excellent), but the ranking surfaced high-churn handoff notes over the specifically-matching design doc. Possible causes to consider: handoff scratchpads dominating on recency/frequency, or the design doc not being indexed/searchable. Positive counter-note: recall_brief(122)+recall_brief(95) were a clean win — full spec, parent epic, dependency chain, and all operator Q&A in one shot. Context JSON: { "tool": "recall_search", "limit": 6, "query": "decision follow-up chains decision_answers parent_answer_id threaded UI \u00a75.2", "scope": "project", "project": "flower", "sources": [ "scratchpad", "doc" ], "expected": "decision-records-design-doc.md \u00a75.2", "observed": "daemon reset/orchestrator handoff scratchpads" }