Sync Repo-codex-IMPLEMENTATION-TASKS from project files
164
Repo-codex-IMPLEMENTATION-TASKS.-.md
Normal file
164
Repo-codex-IMPLEMENTATION-TASKS.-.md
Normal file
@@ -0,0 +1,164 @@
|
||||
<!-- codex-wiki-sync:c9375f025d2593058f6b617b -->
|
||||
|
||||
> Mirrored from `/mnt/DATA/git/pikebacker/codex/IMPLEMENTATION_TASKS.md`.
|
||||
> Origin: `repository`.
|
||||
> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.
|
||||
|
||||
---
|
||||
# Implementation Tasks for Codex
|
||||
|
||||
## Task 1 — Create monorepo scaffold
|
||||
|
||||
Create:
|
||||
|
||||
```text
|
||||
apps/web
|
||||
apps/mobile
|
||||
services/api
|
||||
services/data-pipeline
|
||||
packages/shared
|
||||
```
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- root package/workspace or equivalent created;
|
||||
- lint/test scripts documented;
|
||||
- shared domain types imported by web/API where applicable;
|
||||
- `.env.example` files created;
|
||||
- no API keys committed.
|
||||
|
||||
## Task 2 — Implement shared domain types and scoring
|
||||
|
||||
Implement TypeScript types from `schemas/domain_types.ts`.
|
||||
|
||||
Add pure functions:
|
||||
|
||||
- `scoreSegment(segment, profile)`;
|
||||
- `scoreRoute(route, profile)`;
|
||||
- `detectCriticalGaps(route, pois, thresholds)`;
|
||||
- `estimateHikeABikeRisk(segment, profile)`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- unit tests pass;
|
||||
- sample scoring fixture returns expected warnings;
|
||||
- profile thresholds are configurable.
|
||||
|
||||
## Task 3 — Backend API mock MVP
|
||||
|
||||
Implement endpoints from `schemas/openapi.yaml` with mock data:
|
||||
|
||||
- `POST /v1/routes/plan`,
|
||||
- `POST /v1/stages/plan`,
|
||||
- `GET /v1/routes/{id}/pois`,
|
||||
- `GET /v1/routes/{id}/gaps`,
|
||||
- `POST /v1/offline-packs`,
|
||||
- `GET /v1/routes/{id}/export?format=gpx`,
|
||||
- `POST /v1/reports`.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- returns deterministic responses from `examples/`;
|
||||
- API validation is implemented;
|
||||
- tests cover success and error cases.
|
||||
|
||||
## Task 4 — Stage planner
|
||||
|
||||
Implement stage splitting:
|
||||
|
||||
- respect min/max daily distance;
|
||||
- prefer endpoints near sleep options;
|
||||
- avoid long water/food gaps at stage end;
|
||||
- include Plan A/B endpoints;
|
||||
- generate warnings.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- 3-day and 5-day fixture routes produce plausible stages;
|
||||
- no stage exceeds hard constraints unless warning returned;
|
||||
- sleep candidates attached to each stage.
|
||||
|
||||
## Task 5 — Web planner UI
|
||||
|
||||
Build a web UI:
|
||||
|
||||
- trip request form;
|
||||
- map panel;
|
||||
- stage timeline;
|
||||
- POI filter toggles;
|
||||
- warnings panel;
|
||||
- export/offline buttons.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- user can submit sample trip and see route/stages;
|
||||
- route-corridor POIs shown/listed;
|
||||
- critical warnings visible;
|
||||
- GPX export downloads.
|
||||
|
||||
## Task 6 — GPX export
|
||||
|
||||
Generate valid GPX with:
|
||||
|
||||
- route geometry;
|
||||
- waypoints for stage endpoints;
|
||||
- optional POIs/course points;
|
||||
- metadata and attribution.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- validates as XML;
|
||||
- imports into common route viewers;
|
||||
- includes stage waypoints.
|
||||
|
||||
## Task 7 — Offline pack manifest
|
||||
|
||||
Implement offline manifest generation.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- includes route, stages, POIs, rules, exports, data versions;
|
||||
- marks unavailable layers clearly;
|
||||
- supports future tile pack file references.
|
||||
|
||||
## Task 8 — Data pipeline skeleton
|
||||
|
||||
Implement scripts/docs for:
|
||||
|
||||
- reading OSM PBF extract;
|
||||
- extracting POI categories;
|
||||
- normalizing tags;
|
||||
- inserting into PostGIS;
|
||||
- importing protected areas/rule cards later.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- one small sample extract/fixture works;
|
||||
- schema migrations documented;
|
||||
- source attribution stored.
|
||||
|
||||
## Task 9 — Provider adapters
|
||||
|
||||
Add adapters:
|
||||
|
||||
- mock routing provider;
|
||||
- openrouteservice provider placeholder;
|
||||
- GraphHopper/Valhalla adapter interfaces;
|
||||
- OSM POI provider.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- provider selected via environment/config;
|
||||
- mock provider is default;
|
||||
- external provider failures return actionable errors.
|
||||
|
||||
## Task 10 — Community reports
|
||||
|
||||
Implement structured report model and UI submission.
|
||||
|
||||
Acceptance criteria:
|
||||
|
||||
- reports typed and dated;
|
||||
- offline queue represented;
|
||||
- reports can attach to route meters/location;
|
||||
- moderation status supported.
|
||||
Reference in New Issue
Block a user