Files
geointel/prompts/codex/final/DAY_1_MASTER_PROMPT.md
Jens faeb58ef6d
GeoIntel release gates / Compile, test, contracts and builds (push) Successful in 1m49s
GeoIntel release gates / Python and npm vulnerability policy (push) Successful in 21s
GeoIntel release gates / Production AI image, SBOM and container scan (push) Successful in 5m39s
GeoIntel release gates / Deploy exact gated revision to Unraid (push) Failing after 58m43s
Initial public release
2026-08-31 21:56:53 +02:00

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.