library-backend-adoption-evallisted

## When to use When a new library emerges as a candidate to replace an existing backend. Especially valuable when: - The current backend has caused recurring operational pain - The replacement inverts a known architectural weakness (e.g., source-of-truth inversion) - Benchmarks exist but scale validation does not ## Steps 1. **Prior art check** — search MemPalace for any prior analysis of the candidate library or migration topic. 2. **Fetch the discussion** — use `gh` CLI to pull the PR, issue, or community discussion. Prefer `gh` over WebFetch for GitHub URLs. 3. **Read the migration/handoff doc** — if a migration guide exists, read it and flag where it is more aggressive than the implementation (e.g., "opt-in" PR vs. "make it default" doc). 4. **Review implementation quality** — read the actual PR code, not just the description. 5. **Structure the analysis with these sections:** - **What this is** — one paragraph: what the library does, its source-of-truth model, and any traction signal (stars, age, adoption). - **Why the architecture matters for our specific situation** — connect the library's design to the *specific failure mode* of the current backend. Name the pain it would have prevented. - **The numbers — honest assessment** — table with: metric | claim | credibility. Rate credibility as high/medium-high/medium/low. Flag where benchmark conditions differ from your scale. - **What's unproven / risky right now** — numbered list. Include: library age,