# M6 — Codex Autonomy Pack

## Purpose

M6 converts the GeoIntel repository from an implementation-ready specification into a self-driving build package for Codex. The goal is not to remove engineering judgment. The goal is to remove preventable manual decisions while leaving Codex enough bounded freedom to improve implementation details.

Codex must be able to:

1. audit the repository,
2. derive the next build pass,
3. implement one coherent vertical slice,
4. run the relevant tests,
5. update docs and changelog,
6. produce a handoff summary,
7. stop safely when blocked instead of guessing.

## Autonomy principle

Codex may improve the implementation when it improves maintainability, correctness, testability, performance, or UX while staying inside the frozen product direction.

Codex must not change:

- the product positioning: GeoAI Workbench for the Kempen;
- the backend-first architecture;
- FastAPI, React, TypeScript, PostGIS as core stack;
- GRB as official reference layer for QA/QC;
- data -> processing -> model -> geospatial output -> QA -> export as the core workflow;
- V1 scope boundaries;
- safety rules around external services, licensing, and generated outputs.

## Build autonomy levels

### Level 0 — No autonomy

Used for scope, product direction, data licensing, security boundaries, and architecture decisions already frozen in ADRs.

### Level 1 — Controlled autonomy

Used for internal code organization, helper functions, small UX improvements, tests, fixtures, naming consistency, and documentation improvements.

### Level 2 — Engineering autonomy

Used for improving implementation quality where the docs define goals but not exact code. Examples: better validation, better error messages, safer geometry handling, cleaner service boundaries.

### Level 3 — Proposal only

Used for new modules, new external dependencies, new providers, model changes, new data sources, or changed workflows. Codex may document a proposal but must not implement without explicit approval.

## Required Codex behavior

Each pass must start by reading:

1. `AGENTS.md`
2. `docs/CODEX_MASTER_PROMPT.md`
3. `docs/V1_SCOPE_FREEZE.md`
4. `docs/REPOSITORY_CONVENTIONS.md`
5. the pass-specific prompt in `prompts/codex/`
6. `docs/M6_AUTONOMY_BOUNDARIES.md`
7. `docs/M6_QUALITY_GATES.md`

Each pass must end with:

1. tests run or a precise explanation why not;
2. changed files list;
3. completion status against acceptance criteria;
4. known limitations;
5. next recommended pass;
6. no hidden TODOs in code unless documented in `docs/IMPLEMENTATION_BACKLOG.md`.

## Output discipline

Codex must keep implementation output small enough to review. A pass should build one coherent vertical slice, not ten half-finished modules.

Preferred pass size:

- 5 to 25 files changed;
- one backend service plus related schemas/tests; or
- one frontend route plus related API client/store/tests; or
- one full vertical slice when small enough.

## Non-negotiable stop conditions

Codex must stop and report instead of guessing when:

- a data license is unclear;
- a required external URL/API is unknown;
- a migration could destroy data;
- a dependency introduces GPU/CUDA assumptions without CPU fallback;
- a security boundary would be weakened;
- a design conflicts with frozen docs;
- test failures cannot be isolated.

## M6 deliverables

This pack adds:

- autonomy boundaries;
- strict-but-flexible improvement rules;
- pass prompts from audit to V1 completion;
- self-review checklist;
- failure recovery playbook;
- gap registry;
- final handoff template;
- issue templates;
- CI expectations;
- Codex build command reference;
- next-day execution checklist.