docs: clarify tdd and delivery workflow

AGENTS.md

@@ -24,11 +24,13 @@ If code and docs diverge, update docs first or together with code.
 ## Workflow
 
 - Follow `Red -> Green -> Refactor -> Commit`.
-- Every feature uses its own branch: `feat/<feature-name>`.
+- Backend changes follow `TDD` strictly. Frontend layout, copy, and UX cleanup do not require strict `TDD`, but working frontend behavior should still be verified before commit.
+- Large features use their own branch: `feat/<feature-name>`.
 - Commits must be atomic.
 - Push periodically after one or more logically complete `RGR + commit` cycles.
 - Do not wait for the whole feature to be finished before pushing.
 - Delete merged feature branches both locally and in `origin`.
+- During the current refactoring and small-fix phase, changes are merged directly into `main` on GitHub without opening PRs by default.
 
 ## Language rules
 

docs/development-rules.md

@@ -59,18 +59,28 @@
 - `crank-mapping`
 - `crank-registry`
 - `crank-runtime`
+- `admin-api`
+- `mcp-server`
 - YAML import/export
 - versioning logic
+- любая backend-логика, меняющая доменный контракт, поведение runtime, storage, auth, execution или transport
 
 ### 5.2. Что допускается делать сначала каркасом, потом тестами
 
 - frontend layout;
+- frontend copy, UX cleanup и визуальная реструктуризация;
 - wiring приложений;
 - пустые `axum` handlers;
 - начальный scaffold `cargo workspace`.
 
 Но как только появляется логика, она должна переходить под тесты.
 
+Практическое правило проекта:
+
+- для backend `TDD` обязателен;
+- для frontend строгий `TDD` не требуется на уровне верстки, копирайта и UX-правок;
+- frontend-изменения все равно должны подтверждаться проверками, smoke-тестами или e2e там, где это уместно.
+
 ### 5.3. Правило минимального шага
 
 Нельзя писать сразу большую "умную" реализацию на сотни строк без промежуточных тестов.
@@ -179,7 +189,7 @@ git@github.com:bsodfather/crank.git
 Фиксируем такой workflow:
 
 - `main` - стабильная ветка;
-- каждая фича делается в отдельной ветке `feat/<feature-name>`.
+- крупные фичи делаются в отдельной ветке `feat/<feature-name>`;
 - после merge feature-ветка удаляется и в `origin`, и локально.
 
 Примеры:
@@ -215,7 +225,25 @@ git@github.com:bsodfather/crank.git
 - push делается после одного или нескольких логически связанных `RGR + commit`;
 - push должен оставлять ветку в консистентном состоянии.
 
-### 8.5. Merge cleanup
+### 8.5. Current delivery mode
+
+Для текущего этапа проекта фиксируется отдельное правило доставки:
+
+- рефакторинг;
+- небольшие исправления;
+- UX/copy cleanup;
+- documentation-driven remediation
+
+по умолчанию вливаются напрямую в `main` в GitHub без обязательного PR.
+
+PR остается допустимым, если:
+
+- изменение большое;
+- меняется публичный контракт;
+- нужен отдельный review gate;
+- работа идет рискованным или спорным срезом.
+
+### 8.6. Merge cleanup
 
 После merge в `main` обязательно: