doc #7

AGENTS.md

@@ -21,7 +21,7 @@ Use the single-context documentation layout. See [domain.md](file:///home/nessar
 - Extract reusable logic when it is duplicated or independently testable.
 - Avoid unrelated refactoring in feature or bug-fix merge requests.
 - Do not introduce a new dependency when the existing stack can reasonably solve the problem.
-- Preserve backward compatibility unless the issue explicitly requires a breaking change.
+- The application is not in production. Change development contracts and schemas directly when the domain model changes; update all callers and tests together instead of preserving backward compatibility.
 - Add or update tests for changed behavior.
 - Do not commit secrets, tokens, credentials, generated artifacts, or local environment files.
 - Update relevant domain documentation when behavior, architecture, or business rules change.
@@ -156,7 +156,7 @@ Use the single-context documentation layout. See [domain.md](file:///home/nessar
 - Follow the repository's existing REST conventions.
 - Use nouns for resource paths and standard HTTP methods.
 - Return appropriate HTTP status codes.
-- Keep request and response contracts stable.
+- Keep request and response contracts coherent with the current model; replace obsolete development contracts rather than adding compatibility layers.
 - Use explicit DTOs instead of generic maps.
 - Validate incoming requests with Jakarta Bean Validation.
 - Return consistent, structured error responses.
@@ -210,13 +210,12 @@ Use the single-context documentation layout. See [domain.md](file:///home/nessar
 - Test success, validation failure, authorization failure, and important edge cases.
 - Add regression tests for bug fixes.
 
-## Database migrations
+## Development data lifecycle
 
-- Create a migration for every schema or reference-data change.
-- Do not modify a migration that may already have been applied outside the local environment.
-- Ensure migrations are backward-compatible with the currently deployed application when rolling deployment is used.
-- Avoid destructive migrations without an explicit data-retention and rollback plan.
-- Include a safe data migration strategy when changing populated columns or constraints.
+- The application is not in production; development and test data are disposable and should be deleted or reseeded when the model changes.
+- Do not create data migrations, compatibility adapters, dual-read or dual-write paths, or legacy schema support.
+- Replace obsolete schemas, reference data, API contracts, and development documents directly, then update every caller and test in the same change.
+- Do not plan for rolling upgrades or backward-compatible deployment until an explicit project decision declares production data must be preserved.
 
 ## Before finishing