feat: MobyDB + latlng spatial engine integration — provenance, fleet tracking, geofencing

[devin-ai-integration]

Summary

Integrates two external geospatial engines into FarmConnect:

MobyDB (GNS-Foundation/mobydb) — geospatial-native database where the primary key is a 3D spacetime address (H3 cell, GEP Epoch, Ed25519 pubkey). Used as the spatial provenance layer for field observations, supply chain traceability, and cryptographic verification via Merkle proofs.

latlng (tobilg/latlng) — real-time geospatial object engine with spatial indexing, geofencing, and webhook events. Used as the real-time tracking layer for fleet vehicles, cold chain units, distributor coverage, and IoT sensors.

Both engines use PostgreSQL as a fallback/mirror — the platform works fully without either engine running, and auto-upgrades to the engines when available.

Architecture

PostgreSQL  — relational data (users, orders, KYC, financial)
MobyDB      — spatial provenance (field obs, consignments, Merkle proofs)
latlng      — real-time tracking (fleet, cold chain, geofencing)
TigerBeetle — financial ledger

New files (13 changed, 3,186 insertions)

Layer	Files	Details
Clients	server/lib/mobydb-client.ts, server/lib/latlng-client.ts	HTTP clients with health checks, graceful fallback, singleton pattern
Schema	drizzle/schema-spatial-engines.ts	7 tables: provenance_records, provenance_epochs, provenance_keys, tracked_objects, tracking_history, geofence_zones, geofence_events, supply_chain_steps — all with indexes and FK constraints
Routers	server/routers/mobydb-router.ts (10 endpoints), server/routers/latlng-router.ts (12 endpoints)	Rate-limited, Kafka events, Zod validation
PWA Pages	4 new pages with SmartAlex teal design	Provenance Explorer, Fleet Tracker, Geofence Manager, Supply Chain Provenance
Navigation	CategoryHub.tsx, DashboardLayout.tsx, App.tsx	Routes + sidebar + category entries under "Spatial & Weather"

Key design decisions

• MobyDB client tries engine first, falls back to PostgreSQL LIKE on H3 prefix for proximity queries
• latlng client tries engine first, falls back to PostgreSQL Haversine distance for nearby()
• Provenance keys are auto-generated per user (Ed25519 hex) on first observation
• All Kafka events are fire-and-forget with null-safe producer checks
• Supply chain steps form a verified chain with optional Merkle proof links

Build: tsc 0 errors · 586 tests pass

Link to Devin session: https://app.devin.ai/sessions/87560355a8b7425392cbfab1aa9e89fa
Requested by: @munisp

[devin-ai-integration]

Original prompt from Patrick

https://drive.google.com/file/d/1xoRlAMbf0QPI9WGN9K11iXEDhsTCgf_0/view?usp=sharing
https://drive.google.com/file/d/1kpaWHhlZq1410zZdqm87cSkY8MNvMOLI/view?usp=sharing
Extract ALL the files and artifact. Analyse and perform the following
1)
1)how robust and integrated is postgres ?
2)how robust and integrated is tigerbeetle ?
3)how robust and integrated is redis ?
4)how robust and integrated is mojaloop ?
5) how robust and integrated is kafka ?
6)how robust and integrated is apisix ?
7)how robust and integrated is keycloak ?
8)how robust and integrated is openappsec ?
9)how robust and integrated is permify ?
10)how robust and integrated is opensearch ?
11) how robust and integrated is fluvio ?
12. How robust and integrated is dapr
2)implement all the gaps and recommendation
3)how do ensure and assess that features for example domain and business logic/rules/requirements are fully impemented and production ready and complete - can you thoroughly assess each files and features to determine there are ready for production

1. Database integration (replace in-memory with real Postgres)
2. Inter-service HTTP wiring with retries/circuit breakers
3. Security hardening (JWT everywhere, remove hardcoded creds, mTLS)
4. Integration tests for critical flows
5. Graceful shutdown, observability, alerting
6. inter-service grpc wiring with retries/circuit breakers

4)search for orphan, partially and generic scaffolded features across the platform - fully implement them end to end -generic CRUD-only patterns , modules with no domain logic, disconnected features, and incomplete implementations.

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

E2E Test Results: MobyDB + latlng Spatial Pages — 7/7 PASSED

Ran frontend locally (Vite dev server, client-only), tested all 4 new PWA pages end-to-end in browser with auth bypass.

Results

#	Test	Result
1	Provenance Explorer renders with hero, 5 tabs, 6 KPIs, WHERE/WHEN/WHO model	PASSED
2	Fleet Tracker renders with 5 collection cards, empty map, 3 stat cards	PASSED
3	Geofence Manager renders with 3 tabs, 7 zone type filters, empty state	PASSED
4	Supply Chain Provenance renders with 5 step cards, chain search, problem/solution split	PASSED
5	Sidebar shows all 4 new navigation entries under Spatial & Weather	PASSED
6	CategoryHub shows 4 NEW-badged cards (Provenance, Fleet, Geofence, Supply Chain)	PASSED
7	Tab switching on Provenance Explorer (Records → Verify) works correctly	PASSED

Build Verification

• tsc --noEmit: 0 errors
• npm test: 586 tests passed

Known Non-Blocking Issues

• sql.js WASM module throws RuntimeError: Aborted(both async and sync fetching of the wasm failed) — documented in testing skill, does not affect UI
• No backend running so tRPC queries show loading/empty states — expected for client-only testing

Devin session