# Platform Architecture

## Goal

One frontend product with two sections:

- `/trips`
- `/fitness`

Separate backend services remain in place:

- `services/trips`
- `services/fitness`

The legacy frontends stay runnable during migration for fallback and comparison.

## Service Boundaries

- Trips backend remains independent.
- Fitness backend remains independent.
- Trips and Fitness keep separate SQLite databases.
- Platform frontend owns the shared shell and explicit API proxy layer.

## Proxy Contract

- `/api/trips/*` -> Trips backend
- `/api/fitness/*` -> Fitness backend

Frontend code should call these proxy paths, not raw backend URLs.

## Migration Order

1. Keep both legacy frontends alive.
2. Build platform shell.
3. Add explicit proxy/API clients.
4. Migrate one product area first.
5. Migrate the second area.
6. Retire legacy frontends only after full coverage.