107 lines
3.4 KiB
Markdown
107 lines
3.4 KiB
Markdown
# BUILD SUCCESS DEFINITION — Sprint 1 / First Codex Run
|
|
|
|
This document defines the exact point at which Codex must stop expanding scope and consider the first implementation run successful.
|
|
|
|
## Purpose
|
|
|
|
The first build is not successful because many features exist. It is successful when the foundation is stable, testable and ready for the next module.
|
|
|
|
## Sprint 1 success statement
|
|
|
|
Sprint 1 is successful when GeoIntel can run locally with a backend, frontend, database and a minimal geospatial dataset workflow.
|
|
|
|
The vertical slice is:
|
|
|
|
```text
|
|
Project
|
|
-> Area
|
|
-> Dataset upload/registration
|
|
-> Metadata extraction
|
|
-> PostGIS persistence
|
|
-> Minimal map display
|
|
-> GeoJSON export
|
|
```
|
|
|
|
## Required backend success criteria
|
|
|
|
- FastAPI application starts without import errors.
|
|
- `/health` returns a successful response.
|
|
- `/docs` or OpenAPI schema is available in development.
|
|
- Database configuration is loaded from environment variables.
|
|
- PostgreSQL connection is verified by a health or readiness check.
|
|
- PostGIS extension is created or verified by migration/bootstrap logic.
|
|
- Project CRUD works through API endpoints.
|
|
- Area CRUD works with valid GeoJSON polygon input.
|
|
- Dataset registration or upload works for at least GeoJSON.
|
|
- Dataset metadata is extracted and persisted.
|
|
- API responses use the canonical response envelope.
|
|
- Errors use the canonical error format.
|
|
|
|
## Required database success criteria
|
|
|
|
- Alembic or equivalent migration path exists.
|
|
- Core tables exist:
|
|
- `projects`
|
|
- `areas`
|
|
- `datasets`
|
|
- `dataset_versions` or documented equivalent
|
|
- `analysis_runs` placeholder/table if needed for future compatibility
|
|
- `exports` placeholder/table if needed for future compatibility
|
|
- Geometry columns use PostGIS types.
|
|
- CRS/SRID rules follow `docs/specs/GIS_STANDARDS.md`.
|
|
- Demo seed data can be loaded or fixtures can be used in tests.
|
|
|
|
## Required frontend success criteria
|
|
|
|
- React/Vite application starts.
|
|
- Main layout is visible.
|
|
- MapLibre map renders.
|
|
- Project list/detail state exists.
|
|
- Dataset upload/registration UI exists for the Sprint 1 dataset type.
|
|
- Area display or drawing/import flow exists in minimal form.
|
|
- API client uses configured backend base URL.
|
|
- Loading, empty and error states exist for the implemented pages.
|
|
|
|
## Required storage success criteria
|
|
|
|
- Uploaded/registered dataset files are stored under a controlled storage path.
|
|
- Storage paths are not hardcoded to a developer machine.
|
|
- Metadata in the database references stored files where applicable.
|
|
- Generated exports go to a controlled exports folder.
|
|
|
|
## Required testing success criteria
|
|
|
|
At minimum:
|
|
|
|
- Backend import smoke test passes.
|
|
- Health endpoint test passes.
|
|
- Database connection/migration smoke test passes or has a documented fallback if no DB is available in CI.
|
|
- GeoJSON fixture validation passes.
|
|
- Frontend build or typecheck passes.
|
|
- `make readiness` passes.
|
|
|
|
## Explicitly not required for Sprint 1
|
|
|
|
Do not block Sprint 1 on:
|
|
|
|
- YOLO inference.
|
|
- SAM inference.
|
|
- Sentinel download automation.
|
|
- GRB live WFS integration.
|
|
- LiDAR processing.
|
|
- Training Studio.
|
|
- AI Copilot.
|
|
- Advanced reporting.
|
|
- Multi-user authentication.
|
|
- Production deployment.
|
|
|
|
## Stop condition
|
|
|
|
When all Sprint 1 success criteria are met, Codex must stop feature expansion and produce:
|
|
|
|
- changelog entry;
|
|
- commands run;
|
|
- test results;
|
|
- known limitations;
|
|
- next pass recommendation.
|