trails/openspec/changes/phase-1-mvp/specs/brouter-integration/spec.md at 40e541fcce502ee6fe2d2d6519dada6d67bd2828

Ullrich Schäfer da2f3c04ba

Add OpenSpec phase-1-mvp change with full specifications

OpenSpec initialized with Claude Code integration. Created phase-1-mvp
change with all artifacts:

- proposal.md: 9 new capabilities covering Planner, Journal, and infrastructure
- design.md: 8 technical decisions with alternatives considered
- specs/: 9 capability specs with testable WHEN/THEN scenarios
  - planner-session, brouter-integration, map-display
  - journal-auth, route-management, planner-journal-handoff
  - activity-feed, shared-packages, infrastructure
- tasks.md: 11 task groups, 74 implementation tasks

Ready for implementation via /opsx:apply

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-03-22 11:35:21 +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

2.8 KiB Raw Blame History