90 lines
2.9 KiB
Markdown
90 lines
2.9 KiB
Markdown
# M7 Implementation Control Layer
|
|
|
|
This layer exists to keep Codex productive without allowing it to improvise core architecture.
|
|
|
|
## Purpose
|
|
|
|
M7 adds strict execution control around the existing GeoIntel specifications. It defines how Codex should sequence work, how each pass should prove completion, which traps to avoid, and when it is allowed to improve the design.
|
|
|
|
## Operating Principle
|
|
|
|
Codex may improve implementation quality, developer experience, robustness, performance and UX clarity, but it may not silently change product direction, data model semantics, analysis definitions, geospatial meaning or API contracts.
|
|
|
|
## Build Priorities
|
|
|
|
1. Keep the vertical slice working at all times.
|
|
2. Build backend contracts before frontend polish.
|
|
3. Prefer small complete modules over broad incomplete scaffolding.
|
|
4. Every result must be reproducible from fixtures or documented sample data.
|
|
5. Every analysis output must retain source, parameters, units and assumptions.
|
|
6. Every geospatial geometry must carry CRS awareness.
|
|
7. Every long-running process must expose status, errors and recoverability.
|
|
|
|
## Mandatory Per-Pass Output
|
|
|
|
At the end of every Codex pass, update or create:
|
|
|
|
- `CHANGELOG.md`
|
|
- `docs/BUILD_STATUS.md`
|
|
- relevant TODO checkboxes
|
|
- test notes
|
|
- known limitations
|
|
- next recommended pass
|
|
|
|
If a pass changes API contracts, update `contracts/api/` and all affected frontend service calls.
|
|
|
|
If a pass changes database models, update migrations, schema docs and seed data.
|
|
|
|
If a pass changes analysis logic, update analysis specifications, tests and expected fixtures.
|
|
|
|
## Allowed Improvements
|
|
|
|
Codex may add:
|
|
|
|
- better validation
|
|
- better error messages
|
|
- safer defaults
|
|
- clearer UI states
|
|
- test fixtures
|
|
- helper utilities
|
|
- small performance improvements
|
|
- developer scripts
|
|
- documentation clarifications
|
|
|
|
Codex may not add without explicit approval:
|
|
|
|
- multi-user auth
|
|
- paid external services
|
|
- unrelated AI chat features
|
|
- unrelated dashboards
|
|
- LiDAR production implementation before V1 slice
|
|
- training studio before detection and QA/QC are stable
|
|
- new primary data sources that conflict with GRB-first strategy
|
|
|
|
## Stop Conditions
|
|
|
|
Codex must stop and report instead of continuing if:
|
|
|
|
- a core specification conflicts with another specification
|
|
- a required dependency cannot be installed
|
|
- tests fail for reasons that require product decision changes
|
|
- geospatial output cannot be tied to CRS or source metadata
|
|
- generated outputs would be misleading or scientifically invalid
|
|
|
|
## M7 Completion Target
|
|
|
|
The repository is ready for autonomous implementation when Codex can execute:
|
|
|
|
1. preflight checks
|
|
2. backend foundation
|
|
3. database foundation
|
|
4. dataset upload and metadata
|
|
5. map workspace
|
|
6. raster/vector preview
|
|
7. demo detection stub or real YOLO integration boundary
|
|
8. QA/QC fixture comparison
|
|
9. GeoJSON export
|
|
10. smoke tests
|
|
|
|
without needing manual architecture decisions.
|