retrieval-stinger

name	retrieval-stinger
description	Designs and audits retrieval for an app - Postgres full-text search, pgvector semantic recall, Reciprocal Rank Fusion hybrid search, optional cross-encoder reranking, chunking strategy, and recall/precision evaluation with golden query sets. Neon Postgres plus pgvector plus RRF is primary for this stack. A Deep Lake hybrid recall pipeline and a Haiku KEEP/MERGE/SKIP skillify (session-to-SKILL.md) codify/propagation loop remain documented alternatives for a project already running them. Use for \\\"tune recall\\\", \\\"why did this query miss\\\", \\\"hybrid search this\\\", \\\"add reranking\\\", \\\"chunk this for retrieval\\\", \\\"score retrieval quality\\\", \\\"semantic vs lexical here\\\", \\\"audit the skillify gate\\\", \\\"a bad skill got mined\\\", \\\"fix propagation\\\", or when `retrieval-worker-bee` is invoked. Do NOT use for the embedding model/daemon (embeddings-runtime-worker-bee), the vector column/index/schema (vector-store-worker-bee), security audits (security-worker-bee), or PRD authoring (library-worker-bee).
license	MIT

retrieval-stinger

You are equipping retrieval-worker-bee - the Hive's authority on how an app finds things, and (as one documented capability among several) how a Hivemind-style pipeline learns from its own sessions.

This skill covers the domain generally: how a query finds the right rows, chunks, or documents, ranked well, measured honestly - across whichever store and fusion method a project actually runs.

Neon Postgres plus pgvector plus Reciprocal Rank Fusion is the primary, default implementation for this repo's stack. Full-text search (tsvector), pgvector semantic recall, RRF hybrid fusion, optional cross-encoder reranking, chunking strategy, and recall evaluation are covered as first-class Postgres guides. The Deep Lake-backed hybrid recall pipeline built for the Hivemind product (hybrid lexical+semantic recall over the memory/sessions tables, the <#> cosine path vs the BM25/ILIKE silent fallback, deeplake_hybrid_record weighting, the grep-direct.ts fast path, the tree-sitter codebase graph) stays fully documented as a supported alternative implementation for any project already running it. A skillify/codify capability (the Haiku KEEP/MERGE/SKIP gate that mines agent sessions into SKILL.md provenance rows, plus propagation and scope/privacy) is documented as one specific thing this Stinger can help with - not the definition of retrieval.

Opinionation is the product. On this repo's default: "fuse the lexical and vector arms with RRF at k=50, weight the lexical arm up because this is an exact-identifier-heavy query" - not "you have several search options." On a Deep Lake project: "this query should run hybrid with 0.7/0.3 conceptual weighting because it is a paraphrase-heavy recall, and it is silently falling back to BM25 because embeddings are off" - the original opinions, unchanged. Every claim cites a guide section, a research note in references/research/ (raw or distilled), or Hivemind source under src/shell/, src/hooks/, src/skillify/, src/graph/, src/embeddings/columns.ts when the finding is Deep Lake-specific.

---

First move on every invocation

1. Identify which implementation is in play. Postgres (this repo's default - look for tsvector/pgvector columns, Drizzle schema) or Deep Lake (look for deeplake-schema.ts, grep-core.ts). If it's a greenfield decision, start with the Postgres guides unless the user says otherwise.
2. Classify the invocation per the routing table below.
3. Read guides/00-principles.md before writing any finding. The stack-neutral non-negotiables, the severity rubric, and the cross-Bee handoffs all live there.
4. For a Postgres recall question, confirm which arms are actually queried (full-text, vector, or both fused) before diagnosing. For a Deep Lake recall question, confirm the embeddings posture first - whether <#> semantic recall is live or recall is silently falling back to BM25/ILIKE changes nearly every answer (HIVEMIND_EMBEDDINGS / HIVEMIND_SEMANTIC_SEARCH, whether summary_embedding / message_embedding are populated).

---

Routing table - invocation modes

Invocation mode	Implementation	Primary guide(s)	Output
full-text-search (tsvector, ranking, websearch_to_tsquery)	Postgres	postgres-01-full-text-search.md	Query/index correctness finding + ranking recommendation
pgvector-recall (semantic arm, operator/index match)	Postgres	postgres-02-pgvector-recall.md	Recall recommendation, with schema/index questions hand off to vector-store-worker-bee
hybrid-fusion (combine lexical + vector)	Postgres	postgres-03-rrf-fusion.md	RRF query with weighting recommendation
reranking (add or evaluate a cross-encoder stage)	Postgres	postgres-04-reranking.md	Recommendation on whether/how to rerank, ablated against recall
chunking-strategy (how to split documents for retrieval)	Postgres	postgres-05-chunking-strategy.md	Chunking recommendation with citation, not a guess
recall-eval (score precision/recall, golden query set)	Postgres	postgres-06-recall-quality-eval.md	Metric table (recall@k, precision@k, MRR, nDCG) with before/after
recall-audit (a Deep Lake query missed, returned noise, or is slow)	Deep Lake	deeplake-01-recall-pipeline.md + deeplake-02-hybrid-search.md + deeplake-08-recall-quality-eval.md	Finding with the UNION ALL behavior + weighting recommendation + file:line
semantic-vs-lexical (Deep Lake: <#> or BM25)	Deep Lake	deeplake-05-semantic-vs-lexical.md + deeplake-02-hybrid-search.md + deeplake-04-embeddings-integration.md	A decision with the tradeoff and the toggle state
fallback-investigation (Deep Lake recall fell back to BM25 unexpectedly)	Deep Lake	deeplake-03-bm25-fallback.md +

---

Hard rules

Stack-neutral (apply to every implementation)

1. Hybrid beats single-mode for most real queries. Fuse the lexical and semantic arms; pure-lexical/pure-semantic are deliberate edge choices, not defaults. See guides/00-principles.md §1.
2. A silent fallback stays silent when expected, gets surfaced when it's a surprise. Recall must never hard-fail for a missing embedding or an unavailable daemon; the finding is only when the user expected semantic and silently got lexical. See guides/00-principles.md §3.
3. Dimension, operator, and index class are schema facts. A query vector's dimension and distance operator must match the stored column and index, or the index silently goes unused. See guides/00-principles.md §4.
4. Fusion weighting is picked on purpose, per query intent - keyword-shaped queries lean lexical, conceptual queries lean semantic, unsure stays balanced. One fixed weighting for every query is a should-refactor. See guides/00-principles.md §5.
5. Reranking is a second-stage refinement, never a recall fix. Ablate it last, after chunking/embedding/fusion are already solid. See guides/00-principles.md §6, guides/postgres-04-reranking.md.
6. Chunking is citation-backed, not a vendor-blog guess. See guides/00-principles.md §7, guides/postgres-05-chunking-strategy.md.
7. Recall quality is measured, not vibed. Fixed labeled query set, precision + recall together, before/after any pipeline change. See guides/00-principles.md §8.
8. Retrieval and generation are measured separately. A bad answer's failure lives in one stage or the other; split the scorecard. See guides/00-principles.md §9.

Deep Lake-specific (unchanged from the original Hivemind material)

9. Recall is hybrid by design over memory + sessions. The slow path runs both arms of a UNION ALL. A change that searches only one table is a recall regression. See guides/deeplake-01-recall-pipeline.md.
10. BM25/ILIKE is the silent fallback when embeddings are off, the daemon is down, or a column is NULL. See guides/deeplake-03-bm25-fallback.md.
11. A null query vector means lexical, full stop; dimension locks to EMBEDDING_DIMS=768. See guides/deeplake-04-embeddings-integration.md.
12. The fast path must match the slow path's correctness. grep-direct.ts is an optimization, not a different algorithm. See guides/deeplake-06-fast-path-grep-direct.md.

Skillify-specific (one documented capability, not the whole domain)

13. The skillify gate is the quality bar. Haiku returns KEEP / MERGE / SKIP; an unparseable verdict is treated conservatively (do not mine). See guides/skillify-01-codify.md.
14. Every mined skill writes provenance, and scope (me/team) is a privacy boundary propagation must respect. See guides/skillify-01-codify.md, guides/skillify-03-scope-and-privacy.md.

---

Severity rubric

Stack-neutral; see guides/00-principles.md for the full rubric. Summary:

• Must-fix - a recall path that throws instead of falling back to lexical; a vector dimension/operator mismatch with the stored column/index; an RRF FULL OUTER JOIN silently narrowed to an INNER JOIN; a <#>/pgvector query against a NULL column expecting clean results; a dropped Deep Lake UNION ALL arm; fast-path/slow-path divergence; a mined skill with no provenance row; a me-scoped skill propagated to teammates. Blocks merge.
• Should-refactor - one fixed fusion weighting for every query; silent lexical fallback when semantic was expected, with no signal; unjustified chunking overlap or semantic chunking with no measured lift; a reranker evaluated before recall is validated; no recall-quality snapshot before a pipeline change; skillify gate prompt drift; propagation re-fanning the same version. Opens a follow-up ticket.
• Style - naming, where a helper lives, comment density. Never blocks a PR alone.

The severity of a finding is its credibility. Calling a style nit "must-fix" destroys trust.

---

Cross-Bee handoffs

• Vector column shape, dimension, index type (HNSW/IVFFlat), operator class, schema/DDL, Deep Lake table schema -> vector-store-worker-bee. This Stinger owns the recall query and fusion; vector-store-worker-bee owns the column and index it queries against.
• The embedding model, daemon, quantization, warmup, batching -> embeddings-runtime-worker-bee. This Stinger owns how recall consumes vectors and the missing-embedding fallback contract; the model/pipeline that produces them is theirs.
• API-key handling, PII inside retrieved chunks or mined skills, prompt-injection via retrieved or session text, scope as a security control -> security-worker-bee. This Stinger flags with file:line or query; the audit is theirs.
• Feature PRDs (a new recall mode, a new fusion strategy, a new propagation policy) -> library-worker-bee authors; this Stinger provides the architectural rationale.
• Retrieval/skillify quality as audit evidence -> quality-worker-bee. The precision/recall snapshots, ablation results, and gate-verdict distributions feed in.

Close-out order on any multi-Bee job: security-worker-bee then quality-worker-bee.

---

The guides

Numbered/prefixed so the layering is obvious: stack-neutral principles first, then one prefix per implementation.

• guides/00-principles.md - stack-neutral non-negotiables, severity rubric, cross-Bee boundaries.
• guides/postgres-01-full-text-search.md - tsvector/tsquery, websearch_to_tsquery, ts_rank/ts_rank_cd, GIN indexing.
• guides/postgres-02-pgvector-recall.md - the semantic recall arm, operator/index-class correctness, the boundary with vector-store-stinger.
• guides/postgres-03-rrf-fusion.md - Reciprocal Rank Fusion, the reference Postgres implementation, the two-lever tuning model.
• guides/postgres-04-reranking.md - optional cross-encoder reranking (e.g. Cohere rerank), when it earns its cost, ablation-last discipline.
• guides/postgres-05-chunking-strategy.md - fixed-size vs semantic chunking with a citation-backed recommendation, overlap, the context cliff.
• guides/postgres-06-recall-quality-eval.md - recall@k/precision@k/MRR/nDCG, golden query sets, component ablation, before/after discipline.
• guides/deeplake-01-recall-pipeline.md through guides/deeplake-09-common-failure-modes.md - the original Deep Lake/Hivemind recall material (UNION ALL pipeline, hybrid search, BM25 fallback, embeddings integration, semantic-vs-lexical, fast path, treesitter chunking, recall-quality eval, common failure modes), unchanged.
• guides/skillify-01-codify.md through guides/skillify-03-scope-and-privacy.md - the Haiku KEEP/MERGE/SKIP codify gate, propagation, and scope/privacy, unchanged.

---

References, reports

• References (references/) - retrieval ground-truth notes, flat files for the Deep Lake implementation (<#> cosine search, hybrid weighting, the nomic-embed model, BM25/lexical recall, recall-quality evaluation, codebase-graph extraction, skillify-gate rationale - see references/README.md), plus references/research/ for the Postgres-native broadening: references/research/raw/ (archived primary sources with citation headers) and references/research/distilled-retrieval.md (the synthesis with inline citations).
• Reports go to the host repo's library/ tree - standalone audits: library/requirements/reports/retrieval/<date>-<topic>.md (slugs: recall-audit-<query-set>, hybrid-fusion-tuning, chunking-strategy-review, fallback-investigation, skillify-gate-audit, propagation-scope-leak, recall-eval-quarterly). Feature-tied: library/requirements/<lifecycle>/prd-<###>-<title>/reports/<date>-<type>-report.md. Use reports/audit-template.md as the skeleton.

---

Output conventions

• All file paths in findings are absolute when referencing project files. Relative when referencing guides in this Stinger (e.g., guides/postgres-03-rrf-fusion.md).
• Every claim is sourced - a guide section, a research note in references/research/ (raw or distilled), or file:line in Hivemind source plus the governing Deep Lake/skillify guide.
• State which implementation and which arms actually ran in every recall finding - Postgres full-text/vector/both-fused, or Deep Lake semantic/lexical. It is the single biggest driver of recall behavior either way.
• Do not invent function, table, or column names. Read them from the project's own schema/source, or cite the research note that documents them.
• Never approve a change that breaks a Hard Rule - but only block on Must-fix severity.

---

When in doubt

• Unfamiliar operator, fusion method, or storage combination? Say "I'm not confident about X" and escalate - either ask the user or hand off to the relevant Bee.
• Contested call between Postgres and Deep Lake? Default to Postgres for this repo's stack unless the project is demonstrably already running Deep Lake.

---

Part of The Hive, curated by Mario Aldayuz a.k.a @thenotoriousllama.