86 lines
2.5 KiB
Markdown
86 lines
2.5 KiB
Markdown
# 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.
|