bsodfather/crank
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: clarify tdd and delivery workflow

Browse Source
This commit is contained in:
a.tolmachev
2026-04-12 01:56:49 +03:00
parent 6250a4c6d1
commit 53dd4be2dd
2 changed files with 33 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+3 -1
View File
@@ -24,11 +24,13 @@ If code and docs diverge, update docs first or together with code.
## Workflow ## Workflow
- Follow `Red -> Green -> Refactor -> Commit`. - 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. - Commits must be atomic.
- Push periodically after one or more logically complete `RGR + commit` cycles. - Push periodically after one or more logically complete `RGR + commit` cycles.
- Do not wait for the whole feature to be finished before pushing. - Do not wait for the whole feature to be finished before pushing.
- Delete merged feature branches both locally and in `origin`. - 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 ## Language rules
docs/development-rules.md
+30 -2
View File
@@ -59,18 +59,28 @@
- `crank-mapping` - `crank-mapping`
- `crank-registry` - `crank-registry`
- `crank-runtime` - `crank-runtime`
- `admin-api`
- `mcp-server`
- YAML import/export - YAML import/export
- versioning logic - versioning logic
- любая backend-логика, меняющая доменный контракт, поведение runtime, storage, auth, execution или transport
### 5.2. Что допускается делать сначала каркасом, потом тестами ### 5.2. Что допускается делать сначала каркасом, потом тестами
- frontend layout; - frontend layout;
- frontend copy, UX cleanup и визуальная реструктуризация;
- wiring приложений; - wiring приложений;
- пустые `axum` handlers; - пустые `axum` handlers;
- начальный scaffold `cargo workspace`. - начальный scaffold `cargo workspace`.
Но как только появляется логика, она должна переходить под тесты. Но как только появляется логика, она должна переходить под тесты.
Практическое правило проекта:
- для backend `TDD` обязателен;
- для frontend строгий `TDD` не требуется на уровне верстки, копирайта и UX-правок;
- frontend-изменения все равно должны подтверждаться проверками, smoke-тестами или e2e там, где это уместно.
### 5.3. Правило минимального шага ### 5.3. Правило минимального шага
Нельзя писать сразу большую "умную" реализацию на сотни строк без промежуточных тестов. Нельзя писать сразу большую "умную" реализацию на сотни строк без промежуточных тестов.
@@ -179,7 +189,7 @@ git@github.com:bsodfather/crank.git
Фиксируем такой workflow: Фиксируем такой workflow:
- `main` - стабильная ветка; - `main` - стабильная ветка;
- каждая фича делается в отдельной ветке `feat/<feature-name>`. - крупные фичи делаются в отдельной ветке `feat/<feature-name>`;
- после merge feature-ветка удаляется и в `origin`, и локально. - после merge feature-ветка удаляется и в `origin`, и локально.
Примеры: Примеры:
@@ -215,7 +225,25 @@ git@github.com:bsodfather/crank.git
- push делается после одного или нескольких логически связанных `RGR + commit`; - push делается после одного или нескольких логически связанных `RGR + commit`;
- push должен оставлять ветку в консистентном состоянии. - 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` обязательно: После merge в `main` обязательно: