91 lines
2.2 KiB
Markdown
91 lines
2.2 KiB
Markdown
# M6 Autonomy Boundaries
|
|
|
|
## Codex may change without asking
|
|
|
|
Codex may freely improve:
|
|
|
|
- internal service decomposition when public contracts remain compatible;
|
|
- helper functions and utility modules;
|
|
- validation functions;
|
|
- error messages;
|
|
- unit tests;
|
|
- smoke tests;
|
|
- docs that clarify existing decisions;
|
|
- small UI layout improvements that follow the design system;
|
|
- fixtures that support documented demo cases;
|
|
- logging details that follow observability guidance;
|
|
- type names if the change is applied consistently;
|
|
- generated API clients if contracts remain stable.
|
|
|
|
## Codex may change only with explicit rationale in the handoff
|
|
|
|
Codex may adjust:
|
|
|
|
- exact internal table indexes;
|
|
- pagination defaults;
|
|
- threshold defaults for demo inference;
|
|
- frontend component split;
|
|
- worker retry counts;
|
|
- cache invalidation strategy;
|
|
- validation strictness;
|
|
- local development scripts.
|
|
|
|
Every such change must include:
|
|
|
|
- what changed;
|
|
- why it improves the project;
|
|
- which contract remains unchanged;
|
|
- whether docs were updated.
|
|
|
|
## Codex must not change without approval
|
|
|
|
Codex must not change:
|
|
|
|
- core stack;
|
|
- V1 module list;
|
|
- product positioning;
|
|
- GRB reference role;
|
|
- geospatial CRS strategy;
|
|
- API route prefixes once implemented;
|
|
- database primary key strategy;
|
|
- storage root layout;
|
|
- security assumptions;
|
|
- license assumptions;
|
|
- model class catalog unless documented as proposal;
|
|
- public export formats;
|
|
- Docker service names;
|
|
- environment variable names once introduced.
|
|
|
|
## Codex may add proposal documents
|
|
|
|
When Codex sees a meaningful improvement outside scope, it may create a proposal in:
|
|
|
|
`rfc/RFC-next-<topic>.md`
|
|
|
|
The proposal must contain:
|
|
|
|
- problem;
|
|
- proposed change;
|
|
- affected modules;
|
|
- benefits;
|
|
- risks;
|
|
- migration effort;
|
|
- recommendation.
|
|
|
|
It must not implement that proposal in the same pass unless it is inside the allowed autonomy boundaries.
|
|
|
|
## Interpretation rule
|
|
|
|
When the docs disagree, Codex must apply this priority order:
|
|
|
|
1. `V1_SCOPE_FREEZE.md`
|
|
2. ADRs
|
|
3. `M6_AUTONOMY_BOUNDARIES.md`
|
|
4. API contracts
|
|
5. database contracts
|
|
6. module contracts
|
|
7. UI specs
|
|
8. roadmap / backlog
|
|
|
|
When still ambiguous, Codex must choose the smallest implementation that preserves future extensibility and document the assumption.
|