No description

malice 8b59284158 decouple: read wiki_index.db directly in navi-places (drop /api/wiki-enrich HTTP) ... PR-A of decouple #4-READ. navi-places now reads its own wiki_index.db directly (NAVI_WIKI_INDEX_DB) instead of HTTP-calling recon's /api/wiki-enrich — same pattern it already uses for place_cache.db. The 2.1GB DB was copied to /var/lib/navi-backend/wiki_index.db out-of-band (5,061,763 rows verified). - NEW services/navi_places/wiki_index.py: verbatim port of recon's lookup_wiki_index + _get_wiki_index_db, reading NAVI_WIKI_INDEX_DB, mirroring place_cache.py's db_path()/lazy-conn/reset() pattern. Returns the same {wiki_summary, wiki_population, wiki_url, wikivoyage_url} shape /api/wiki-enrich did, so it's a drop-in for the HTTP client. - place_detail.py: _enrich_with_wiki_via_http -> _enrich_with_wiki_index; call wiki_index.lookup() instead of wiki_client.enrich_via_recon(); docstrings. - app.py: wiki_index.reset() per worker/test (alongside place_cache.reset_cache()). - admin.py: drop the recon-wiki-enrich dependency probe; add NAVI_WIKI_INDEX_DB env + a read-only filesystem entry. (recon-wiki-rewrite probe kept — separate decouple.) - DELETE wiki_client.py (fully replaced). - test_place.py: convert the wiki test from a monkeypatched HTTP client to a hermetic tmp wiki_index.db. Internal localhost migration — no nginx/edge involvement. recon's /api/wiki-enrich stays live until PR-B (deploy PR-A first so nothing calls the route after removal). Co-authored-by: Matt Johnson <mj@k7zvx.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-05-23 19:17:53 -06:00
backend	decouple: read wiki_index.db directly in navi-places (drop /api/wiki-enrich HTTP)	2026-05-23 19:17:53 -06:00