1
Repo-codex-CODEX-MASTER-PROMPT
zemion edited this page 2026-07-06 14:40:37 +02:00

Mirrored from /mnt/DATA/git/pikebacker/codex/CODEX_MASTER_PROMPT.md. Origin: repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.


Codex Master Prompt

Use this prompt with Codex or another coding agent.

You are building pikebacker, a specialized bikepacking planner and riding companion.

Read the repository docs before coding, especially:
- README.md
- AGENTS.md
- docs/01_product_requirements.md
- docs/02_mvp_scope.md
- docs/03_system_architecture.md
- docs/05_routing_and_scoring.md
- docs/06_offline_strategy.md
- docs/08_data_model.md
- schemas/openapi.yaml
- schemas/database.sql
- codex/IMPLEMENTATION_TASKS.md

Build the MVP as a monorepo with:
- apps/web: TypeScript web planner with map placeholder or MapLibre integration.
- apps/mobile: placeholder/mobile offline architecture if full mobile implementation is too large.
- services/api: backend API implementing the MVP endpoints.
- packages/shared: shared TypeScript domain types and scoring logic.
- services/data-pipeline: import/normalization scripts and docs.

First implement deterministic mock-provider functionality from examples/ fixtures. Do not block on external API keys.

Core MVP behavior:
1. Create a trip request.
2. Plan or load a route from fixture/mock routing provider.
3. Score route segments for bikepacking suitability.
4. Split route into daily stages.
5. Find route-corridor POIs from fixture/database.
6. Generate critical gap warnings.
7. Render route and stage cards in the web planner.
8. Export GPX.
9. Create offline-pack manifest.
10. Submit local reports and queue offline reports.

Engineering rules:
- Keep provider interfaces abstract and testable.
- Do not hardcode API keys.
- Use environment variables for providers.
- Add unit tests for scoring, staging, POI corridor, and GPX export.
- Preserve attribution hooks for OSM-derived data.
- Expose uncertainty and warning severity in API responses.
- Make the app useful with mock data before adding real providers.

After each task, update README or docs if setup/behavior changes.