geointel/prompts/codex/final/DAY_1_MASTER_PROMPT.md

Day 1 Master Prompt for Codex

You are implementing GeoIntel Kempen.

GeoIntel is a GeoAI Workbench for the Belgian Kempen. It is not a generic dashboard, chatbot, reporting tool, or QGIS clone. The core pipeline is:

data → processing → geospatial output → QA/QC → export

Mandatory reading

Before coding, read in this order:

1. CODEX_START.md
2. docs/00-start/START_HERE.md
3. docs/20-run-readiness/RUN_READINESS_FINAL.md
4. docs/20-run-readiness/PASS_SEQUENCE_FINAL.md
5. docs/governance/GEOINTEL_CONSTITUTION.md
6. docs/governance/ARCHITECTURE_INVARIANTS.md
7. docs/governance/FORBIDDEN_DECISIONS.md
8. docs/specs/CANONICAL_DOMAIN_MODELS.md
9. docs/specs/STATE_MACHINES.md
10. docs/workflows/GOLDEN_PATHS.md

Your first objective

Start with Pass 0 and Pass 1 only unless explicitly instructed otherwise.

Do not begin with YOLO/SAM, LiDAR, Sentinel automation, dashboards, chat, reports, MLOps, or QGIS plugins.

Pass 0

Audit the repo, confirm the canonical start path, run available smoke scripts, and prepare the implementation workspace.

Pass 1

Create the backend FastAPI foundation with health endpoint, response envelope, settings structure, router structure, and import/smoke tests.

Non-negotiable rules

• Use FastAPI for backend.
• Use React + TypeScript for frontend.
• Use PostgreSQL + PostGIS as the target database.
• Use Redis + RQ for async jobs when job processing is introduced.
• Preserve the canonical response envelope.
• Preserve state machine names.
• Do not introduce unapproved dependencies without documenting why.
• Do not hardcode demo-only paths into production logic.
• Do not hide incomplete work with TODO comments as a substitute for implementation.
• Do not change architecture invariants.

Allowed improvements

You may improve:

• file organization within documented conventions;
• type safety;
• tests;
• error handling;
• developer experience;
• documentation clarity;
• small helper abstractions;
• UI consistency when frontend work begins.

Required output after each pass

Report:

Pass:
Scope completed:
Files changed:
Commands run:
Tests passed:
Tests failed:
Golden paths affected:
Architecture invariants touched:
Known limitations:
Next pass:

Day 1 success target

At minimum, Day 1 should produce a backend that imports, has health/status endpoints, has a documented config structure, and has a clear path toward domain/database implementation.

A strong Day 1 may also include initial database models and project/area APIs, but only if Pass 1 is stable.