You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Also compile examples or packaging modules (e.g. `packages/clickhouse-jdbc-all`) when a change affects examples, packaging, public APIs, or other user-facing behavior — running the touched module's tests alone isn't enough.
42
+
43
+
Run benchmarks under `clickhouse-benchmark` when a change touches a performance-sensitive path (see
44
+
`docs/ai-review.md`); this is optional and only worth doing when performance is actually in question.
45
+
32
46
Avoid broad dependency, formatting, or unrelated cleanup churn unless required by the task.
33
47
34
48
## Editing expectations
@@ -37,10 +51,40 @@ Avoid broad dependency, formatting, or unrelated cleanup churn unless required b
37
51
- Read nearby code and follow existing local patterns before introducing new abstractions.
38
52
- Prefer focused tests near the affected module over repo-wide runs.
39
53
54
+
## Scope discipline
55
+
56
+
- One logical change per commit/PR: a feature, a bug fix, a refactor, or a doc update. Don't mix.
57
+
- Implement the smallest change that solves the problem. Defer polish, extra configuration, and
58
+
optimization to follow-ups rather than expanding scope.
59
+
- Flag it if a change is growing large: ~400 LOC starts to hurt reviewability, 800+ LOC needs to be
60
+
split into smaller changes.
61
+
62
+
## Testing expectations
63
+
64
+
- Add negative tests when a change affects validation, error handling, parsing, serialization, or
65
+
compatibility-sensitive behavior. The test should prove the failure path produces the correct
66
+
result/exception, not just that the original bug no longer reproduces.
67
+
- Don't pad coverage: add a test only when it covers a distinct scenario, edge case, module, type,
68
+
format, or failure mode. Avoid duplicating existing coverage.
69
+
- Favor scenario coverage (boundary values, invalid input, nullable/nested interactions) over raw
70
+
coverage percentage.
71
+
- Keep tests compact, readable, and focused on the scenario being verified. Reduce duplication in test setup and assertions so a reviewer can quickly see what behavior is being tested.
72
+
73
+
## Closeout checklist
74
+
75
+
- Run the affected module's tests locally (see "Setup and test commands") before treating a change as done. Don't hand off a change with failing or unrun tests.
76
+
- Update `CHANGELOG.md` for user-facing changes: what the problem was, how it was fixed, and a link to the issue.
77
+
- Update `docs/features.md` when a `client-v2` or `jdbc-v2` feature is added, removed, or its behavior intentionally changes.
78
+
- In the final summary: state compatibility impact explicitly, describe any user-visible behavior
79
+
change, and link the related issue (note that one should be created if it's missing).
80
+
40
81
## Review expectations
41
82
42
83
For review requests, follow `docs/ai-review.md` as the shared review standard across AI agents.
43
84
85
+
Before treating implementation work as done, self-review your own diff against `docs/ai-review.md` —
86
+
not only when a review is explicitly requested.
87
+
44
88
## Optional nested AGENTS.md
45
89
46
90
If a module develops its own conventions, add a nested `AGENTS.md` inside that module.
0 commit comments