trails-cool/trails
1
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trails/openspec/specs/brouter-integration/spec.md
Ullrich Schäfer e530492753
Archive phase-1-mvp, sync specs to main 
All 85 tasks complete. Archive change to openspec/changes/archive/ and
sync 9 capability specs to openspec/specs/ for future reference.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-25 02:55:28 +01:00

2.8 KiB
Raw Blame History

ADDED Requirements

Requirement: Route computation from waypoints

The Planner SHALL compute a route between ordered waypoints by calling the BRouter HTTP API and returning the result as GeoJSON.

Scenario: Compute route with two waypoints

  • WHEN the routing host submits two waypoints (start, end) with profile "trekking"
  • THEN the BRouter API returns a GeoJSON route within 2 seconds

Scenario: Compute route with via points

  • WHEN the routing host submits three or more waypoints
  • THEN the BRouter API returns a route passing through all waypoints in order

Requirement: Routing host election

The Planner SHALL elect one participant per session as the "routing host" who is responsible for sending waypoint changes to BRouter. Only the host SHALL make BRouter API calls.

Scenario: Initial host assignment

  • WHEN a session is created
  • THEN the session creator is assigned as the routing host via Yjs awareness state

Scenario: Host failover

  • WHEN the current routing host disconnects
  • THEN the longest-connected remaining participant becomes the new host within 5 seconds

Requirement: Route broadcast

The routing host SHALL store computed route results in the Yjs document so that all participants receive route updates automatically.

Scenario: Route update propagation

  • WHEN the routing host receives a new route from BRouter
  • THEN the route GeoJSON is stored in a Y.Map field and all participants see the updated route on their maps

Requirement: Profile selection

The Planner SHALL support selecting a routing profile that determines how BRouter computes the route.

Scenario: Switch routing profile

  • WHEN a user changes the routing profile from "trekking" to "shortest"
  • THEN the profile change syncs via Yjs and the routing host recomputes the route

Requirement: BRouter API proxy

The Planner backend SHALL proxy all BRouter API calls. Clients SHALL NOT communicate with BRouter directly.

Scenario: Proxied route request

  • WHEN the routing host client requests a route computation
  • THEN the Planner backend forwards the request to BRouter, applies rate limiting, and returns the response

Requirement: Rate limiting

The Planner backend SHALL rate limit BRouter API calls to prevent abuse.

Scenario: Rate limit exceeded

  • WHEN a session exceeds 60 route computations per hour
  • THEN subsequent requests receive a 429 response with a Retry-After header

Requirement: BRouter Docker deployment

BRouter SHALL run as a separate Docker container with Germany RD5 segments mounted as a volume.

Scenario: BRouter container starts

  • WHEN the Docker Compose stack starts
  • THEN the BRouter container is reachable at its internal HTTP port and can compute routes using the mounted RD5 segments