Fork divergence map: which of these would you like upstreamed?

[jphein]

Hi all — jphein here (techempower-org/mempalace fork; you may know us from #1377, RFC 001 #743, and the open RFC 002 work in #1484).

We just completed a full re-sync through da5a48c (213 commits — the remote MCP server, graph auto-population, facets, and date filters all composed cleanly with our fork-ahead work, which was fun to see). While doing it we built a complete, diff-verified map of every way the fork currently diverges: How the fork diverges today.

The question: several of these run in production for us (411K-drawer palace, postgres + pgvector + Apache AGE) and look portable. Rather than guessing which you'd want, we'd like you to pick — for anything that fits your direction, we'll cut small, focused PRs against develop with tests, one change per PR.

Candidates, roughly by expected general value

1. Multi-label tags — TF-IDF auto-extraction on write (3–8 tags/drawer, length/count caps) + $contains_all / $contains_any array filters implemented for both the chroma path (scalar-metadata workaround: predicate strip + Python post-filter with over-fetch) and SQL backends, surfaced through add_drawer / list_drawers / update_drawer / search. Fully tested.
2. Recency decay + rating feedback — Weibull-style recency weighting in ranking, plus a bounded mempalace_rate_memory MCP tool that feeds a rating signal back into search ordering. Both opt-in.
3. Write-quality pieces — write_sanitizer (control-char/surrogate/size hygiene at the write boundary), novelty tagging on mine (marks near-duplicates against a recent window so consumers can rank or filter them), and a room-taxonomy validator that warns on non-canonical rooms instead of letting taxonomies silently fragment.
4. Miner --workers — parallel file read/chunk/route with strictly serialized writes; substantially faster cold mines on multi-core boxes with no concurrency exposure on the write side.
5. Retrieval eval harnesses — the fusion A/B, cross-encoder rerank eval, and chunking-ablation scripts we used to make retrieval decisions (our labeled A/B is why we default to convex fusion over RRF, matching your default). Useful to anyone benchmarking against their own corpus — which, per the good methodology conversation in Benchmark methodology review + complementary approach from agentmemory #747, beats trusting anyone's published numbers.
6. ORT thread cap for the ONNX embedder — bounds intra_op_num_threads so a background mine doesn't pin every core (the Background mempalace mine pins 400–500 % CPU — ORT intra_op pool ignores OMP env vars #1068 failure mode), with a lazy-download fix so the cap isn't silently bypassed on first run.
7. Apache AGE knowledge-graph backend + LLM triple extraction — a full production KG: AGE-backed graph store, write-through triple extraction (local LLM), canonical vocab + predicate normalization, backfill workers. This one's bigger and architecturally opinionated — but if feat(kg): pluggable knowledge-graph storage backend (BaseKGStore) #1903 (BaseKGStore) lands, our AGE store becomes a natural first external implementation of that interface, which would validate the plug point with a real second backend.
8. Postgres backend experience report — we run backends/postgres.py (RFC 001 contract, psycopg3) in production alongside your newer backends/pgvector.py. Happy to write up operational lessons (HNSW at 400K+ rows, statement timeouts, migration tooling) and help converge the two rather than carrying parallel implementations forever.

Already open, if useful context

#1484 (RFC 002 OpenCode adapter), #1508 (symbol_header_prefix), #1382 (Windows benchmark encoding), #1378 (CLOSET_RANK_BOOSTS hoist), #1086/#1087/#1094 (export / purge / None-metadata). We'll rebase any of these on request — and are equally happy to close whichever no longer fit.

No expectations — the fork composes fine either way, and the re-sync cost is manageable. But the overlap between your recent direction (graph auto-population, facets, remote server) and our production stack keeps growing, so it felt like the right time to ask what's worth converging. Tell us which numbers interest you and we'll start with the smallest.