# 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:

```text
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.