No description
  • JavaScript 96.9%
  • CSS 2.9%
  • HTML 0.2%
Find a file
malice 65911d320c decouple: move /api/wiki-rewrite logic from recon to navi-places
PR-A of decouple #4-REWRITE — the LAST navi→recon coupling. navi-places now
decides "is this wiki article in the local Kiwix mirror?" in-process instead of
HTTP-calling recon's /api/wiki-rewrite. Intra-process swap, no nginx changes.
Mirrors decouple #4-READ (which moved wiki_index.db reads the same way).

- NEW services/navi_places/wiki_rewrite.py: verbatim port of recon's
  lib/wiki_rewrite.py. Only adjustments: setup_logging -> stdlib logging;
  KIWIX_BASE -> NAVI_KIWIX_BASE_URL env; KIWIX_PUBLIC_BASE -> NAVI_KIWIX_PUBLIC_BASE
  env; cache DB -> NAVI_WIKI_CACHE_DB (default /var/lib/navi-backend/wiki_cache.db,
  auto-created); + a reset() to match the place_cache/wiki_index per-worker pattern.
  No logic changes — same classify, same lazy hourly catalog refresh, same HEAD
  timeout, same status values (local/public/original), same cache semantics.
- place_detail.py: _enrich_wiki_links_via_http -> _enrich_wiki_links; calls
  wiki_rewrite.rewrite_wiki_link(tag,value) (TUPLE) and unpacks it, replacing
  the dict-returning HTTP client. Import + docstrings updated.
- app.py: wiki_rewrite.reset() per worker/test (alongside place_cache/wiki_index).
- DELETE services/navi_places/wiki_rewrite_client.py (HTTP shim dead).
- tests: the 2 wiki-rewrite tests now monkeypatch the local
  wiki_rewrite.rewrite_wiki_link (tuple) instead of the deleted client.

Recon's endpoint stays live but unused until PR-B (safe co-existence).

Co-authored-by: Matt Johnson <mj@k7zvx.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-23 21:12:27 -06:00
backend decouple: move /api/wiki-rewrite logic from recon to navi-places 2026-05-23 21:12:27 -06:00