Skip to content

ai: batch agent validation #951

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ovitrif merged 2 commits into from
May 18, 2026
Merged

ai: batch agent validation #951

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3b0b243
docs: batch agent validation
ovitrif May 18, 2026
20579da
docs: narrow validation reruns
ovitrif May 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -161,9 +161,10 @@ suspend fun getData(): Result<Data> = 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 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
- USE single-line commit messages under 50 chars; use conventional commit messages template format: `feat: add something new`
Expand Down
Loading