From 3b0b24374fbea7dd8622f8c6530545e2734d193a Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Mon, 18 May 2026 16:07:41 +0200 Subject: [PATCH 1/2] docs: batch agent validation --- AGENTS.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index d3f6b9d22..183160d48 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -161,9 +161,9 @@ suspend fun getData(): Result = withContext(Dispatchers.IO) { ### Rules - USE coding rules from `.cursor/default.rules.mdc` -- ALWAYS run `./gradlew compileDevDebugKotlin` after code changes to verify code compiles -- ALWAYS run `./gradlew testDevDebugUnitTest` after code changes to verify tests succeed and fix accordingly -- ALWAYS run `./gradlew detekt` after code changes to check for new lint issues and fix accordingly +- For multi-step changes, stacked PR surgery, and review follow-up with several small edits, batch validation instead of running the full build/check suite after every edit. Run the relevant Gradle checks once the coherent change set is ready, before committing, updating a PR, or pushing. +- Still run `./gradlew compileDevDebugKotlin`, `./gradlew testDevDebugUnitTest`, and `./gradlew detekt` before the final PR update/push for code changes, and fix failures before pushing. +- Use narrower checks earlier only when they answer an immediate risk, e.g. a single unit test after touching focused business logic or a Kotlin compile after a risky refactor. - ALWAYS ask clarifying questions to ensure an optimal plan when encountering functional or technical uncertainties in requests - ALWAYS when fixing lint or test failures prefer to do the minimal amount of changes to fix the issues - USE single-line commit messages under 50 chars; use conventional commit messages template format: `feat: add something new` From 20579da7fab5b791120a706a3f57c6591617baae Mon Sep 17 00:00:00 2001 From: Ovi Trif Date: Mon, 18 May 2026 17:48:40 +0200 Subject: [PATCH 2/2] docs: narrow validation reruns --- AGENTS.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index 183160d48..3f34b1bdb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -161,8 +161,9 @@ suspend fun getData(): Result = withContext(Dispatchers.IO) { ### Rules - USE coding rules from `.cursor/default.rules.mdc` -- For multi-step changes, stacked PR surgery, and review follow-up with several small edits, batch validation instead of running the full build/check suite after every edit. Run the relevant Gradle checks once the coherent change set is ready, before committing, updating a PR, or pushing. +- For multi-step changes, stacked PR surgery, and review follow-up with several small edits, batch validation instead of running the full build/check suite after every edit. Run the relevant Gradle checks once the coherent change set is ready, before updating a PR or pushing. - Still run `./gradlew compileDevDebugKotlin`, `./gradlew testDevDebugUnitTest`, and `./gradlew detekt` before the final PR update/push for code changes, and fix failures before pushing. +- After fixing validation failures, rerun the narrowest useful check that proves the fix. If only test files changed, prefer the targeted test task and a test-focused lint/detekt check when the project tooling supports it; otherwise use the standard detekt task before pushing. - Use narrower checks earlier only when they answer an immediate risk, e.g. a single unit test after touching focused business logic or a Kotlin compile after a risky refactor. - ALWAYS ask clarifying questions to ensure an optimal plan when encountering functional or technical uncertainties in requests - ALWAYS when fixing lint or test failures prefer to do the minimal amount of changes to fix the issues