Files
ukmesh/docs/pathing.md
T
Ben 21224a0525 Refactor backend, map, and worker boundaries
- split backend API into route/service/repository boundaries across stats, owner, and pathing\n- extract shared API bootstrap and helper modules\n- reduce MapLibreMap into smaller frontend map modules with extracted builders, config, popup UI, and types\n- continue worker modularization by extracting RF terrain/tile helpers alongside RF config and loss helpers\n- add repo-local architecture, DB lifecycle, link model, pathing, frontend map, and contributing docs\n\nThis is the verified refactor checkpoint: backend and frontend builds passed, worker syntax checks passed, affected containers were rebuilt, and /healthz is OK.
2026-03-20 17:45:47 +00:00

1.0 KiB

Pathing

Purpose

Pathing resolves packet routes into higher-confidence purple segments and lower-confidence red segments.

Main layers

  • backend/src/path-beta/
    • resolver implementation
    • worker pool
    • geometry helpers
    • fallback logic
  • backend/src/pathing/
    • service/repository orchestration for API-facing pathing endpoints

Evidence priorities

In practice the resolver should rank evidence roughly like this:

  • physically plausible link support
  • multibyte path evidence
  • radio-neighbour evidence
  • weaker observational hints

API ownership

  • backend/src/api/routes/pathing.ts
    • thin HTTP wrapper
  • backend/src/pathing/pathingService.ts
    • cache and resolver orchestration
  • backend/src/pathing/pathingRepository.ts
    • DB-backed path history and learning queries

Contributor rule

If a path looks wrong, first determine whether the issue is:

  • evidence weighting
  • physical graph quality
  • ambiguous short-hash matching
  • cache reuse

Do not debug purple/red rendering as if it were a frontend-only problem.