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
42 lines
1.7 KiB
Markdown
42 lines
1.7 KiB
Markdown
# Autonomous Build Charter
|
|
|
|
## Mission
|
|
Codex must build GeoIntel Kempen as a production-shaped GeoAI Workbench, not as a demo-only UI. Every implementation pass must produce working, testable, API-driven behavior.
|
|
|
|
## Frozen Product Identity
|
|
GeoIntel is a GeoAI Workbench for the Kempen focused on raster/vector processing, AI detection, segmentation, QA/QC against reference data, and geospatial exports.
|
|
|
|
## Allowed Autonomy
|
|
Codex may improve:
|
|
- internal code organization when it keeps documented contracts intact;
|
|
- UI microcopy and layout when it improves clarity;
|
|
- validation and error messages;
|
|
- tests, fixtures, logging, and developer tooling;
|
|
- performance optimizations that do not alter outputs;
|
|
- accessibility and keyboard navigation;
|
|
- extra helper utilities that support documented workflows.
|
|
|
|
## Not Allowed Without Explicit User Approval
|
|
Codex must not:
|
|
- replace FastAPI, React, TypeScript, PostgreSQL/PostGIS, or Python GIS stack;
|
|
- introduce a different product direction such as a generic chatbot or CRUD dashboard;
|
|
- remove GRB/QA/QC as a first-class concept;
|
|
- make LiDAR, training studio, or MLOps part of V1 core;
|
|
- hardcode fake results while presenting them as real processing;
|
|
- break existing documented API contracts;
|
|
- silently change geometry formats or CRS assumptions;
|
|
- ignore tests because a dependency is missing.
|
|
|
|
## Output Expectations Per Pass
|
|
Every Codex pass must end with:
|
|
1. changed files list;
|
|
2. completed tasks;
|
|
3. skipped tasks with reason;
|
|
4. commands run;
|
|
5. test results;
|
|
6. known limitations;
|
|
7. next recommended pass.
|
|
|
|
## Quality Principle
|
|
If a feature cannot be fully implemented in the pass, Codex must implement the durable skeleton plus honest status handling, not a fake success path.
|