geointel/prompts/codex/M9_DAY_ONE_MASTER_PROMPT.md

GeoIntel Day-One Master Prompt for Codex

You are working inside the GeoIntel Kempen repository.

GeoIntel Kempen is a GeoAI Workbench for the Kempen region. It combines geospatial data, raster/vector processing, object detection, segmentation, QA/QC against GRB/reference layers, and exports. It is not a generic CRUD app and not a simple map demo.

First instruction

Before writing code, read these files in this order:

1. README.md
2. AGENTS.md
3. docs/V1_SCOPE_FREEZE.md
4. docs/REPOSITORY_CONVENTIONS.md
5. docs/ARCHITECTURE.md
6. docs/SERVICE_ARCHITECTURE.md
7. docs/API_CONTRACTS.md
8. docs/DATABASE_SCHEMA.md
9. docs/DATABASE_IMPLEMENTATION_PLAN.md
10. docs/DEFINITION_OF_READY.md
11. docs/DEFINITION_OF_DONE.md
12. docs/17-max-prep/M9_MAX_PREPARATION_PACK.md
13. docs/17-max-prep/M9_AUTONOMOUS_BUILD_DOCTRINE.md
14. docs/17-max-prep/M9_PASS_SCORECARDS.md
15. docs/17-max-prep/M9_BUILD_BLOCKERS_AND_RECOVERY.md

Then perform Pass 0.

Pass 0: Repository Audit

Do not build new features in Pass 0.

Produce and commit/update:

• docs/CODEX_EXECUTION_LOG.md
• docs/BUILD_STATUS.md
• docs/IMPLEMENTATION_GAP_REPORT.md

The gap report must list:

• existing files,
• missing implementation pieces,
• highest-risk assumptions,
• exact next build pass.

Build order

After Pass 0, follow this order strictly:

1. Backend foundation
2. Database and models
3. API envelope and error handling
4. Project and area APIs
5. Dataset manager skeleton
6. Demo fixture loading
7. Frontend foundation
8. Map workbench shell
9. Raster/vector metadata skeleton
10. QA/QC skeleton

Do not start YOLO, SAM, Sentinel, LiDAR, training studio, or advanced change detection until the foundation is green.

Non-negotiable rules

• Keep FastAPI.
• Keep React + TypeScript.
• Keep PostgreSQL + PostGIS.
• Use the documented response envelope.
• Do not introduce a second API style.
• Do not hardcode fake success states.
• Do not silently swallow errors.
• Do not remove documentation.
• Do not replace real architecture with mock-only code.
• Do not implement features outside V1 unless they are explicit stubs with clear disabled state.

Allowed improvements

You may improve:

• internal folder organization if it remains compatible with repository conventions,
• UI polish,
• test coverage,
• typing,
• validation quality,
• developer ergonomics,
• logging.

If you improve beyond the spec, document it in docs/PROPOSED_IMPROVEMENTS.md and explain why it is safe.

Required output after every pass

Update:

• docs/CODEX_EXECUTION_LOG.md
• docs/BUILD_STATUS.md
• CHANGELOG.md

Include:

• what changed,
• commands run,
• tests passed/failed,
• unresolved gaps,
• next recommended pass.

Stop conditions

Stop and report instead of improvising when:

• database schema conflicts with docs,
• required dependency cannot install,
• CRS/geospatial calculation is ambiguous,
• you cannot run tests,
• a feature would require real external credentials,
• you need to change a frozen architecture decision.