# Autonomy Boundaries for Codex

Codex should be proactive, but not uncontrolled.

## Green zone — Codex can decide

- function and class names when consistent with docs;
- internal helper extraction;
- validation improvements;
- error message clarity;
- test fixture additions;
- component decomposition;
- minor styling improvements;
- logging improvements;
- dependency pinning within the approved stack.

## Yellow zone — Codex can decide but must document

- replacing a library with an equivalent only if dependency installation fails and the replacement stays within the stack intent;
- changing endpoint internals while preserving contracts;
- adding new tables that support existing aggregates;
- adding background job scaffolding earlier than planned;
- improving storage folder structure while preserving published paths.

Must be documented in:

- `docs/CODEX_EXECUTION_LOG.md`;
- `CHANGELOG.md`;
- relevant ADR/RFC if architectural.

## Red zone — Codex must stop and ask

- changing FastAPI/React/PostGIS stack;
- removing GRB-centered QA/QC direction;
- turning the product into a generic GIS dashboard;
- removing AI pipeline readiness;
- changing V1 scope boundaries;
- adding authentication/multi-user as core V1;
- adding paid/cloud-only dependencies as mandatory;
- implementing real external downloads without source strategy and license notes;
- changing output formats away from GeoJSON/COCO/YOLO/masks without approval.

## Safe fallback principle

When a dependency, data source or model cannot be used yet, implement a controlled adapter interface and deterministic fixture-backed behavior. Mark it as a scaffold, not as production-complete.