AGENTS.md

1# AGENTS.md
2 
3This file provides guidance to agents working in this repository.
4 
5## Purpose and Precedence
6 
7- MUST means required.
8- SHOULD means recommended unless there is a concrete reason to deviate.
9- MAY means optional.
10- Root `AGENTS.md` defines repository-wide defaults. If a deeper path later adds a more specific `AGENTS.md`, the deeper file SHOULD be treated as higher precedence for that subtree.
11 
12## Non-negotiables
13 
141. Correctness first. TiDB is a distributed SQL database; seemingly small changes can alter SQL semantics, consistency, or cluster behavior.
152. No speculative behavior. Do not invent APIs, defaults, protocol behavior, or test workflows.
163. Keep diffs minimal. Avoid unrelated refactors, broad renames, or formatting-only churn unless explicitly requested.
174. Leave verifiable evidence. Run targeted checks and report exact commands.
185. Respect generated code artifacts. Do not hand-edit generated code outputs; regenerate from source inputs.
19 
20## Agent Interaction Overrides (Repo-Local)
21 
22- For short non-code questions about definitions, acronyms, symbols, errors, or other potentially repository-specific terms, agents MUST search the active repository and read the closest authoritative local definition before answering, lead with the repository-specific meaning, and use general knowledge only when local evidence is absent or the user explicitly requests broader context.
23 
24## ExecPlans
25 
26When writing complex features or significant refactors, use an ExecPlan from design to implementation.
27 
28- Definition and format: `PLANS.md` at repository root.
29- Requirement: keep the ExecPlan updated as a living document while implementation progresses.
30- Scope: use this for multi-step work where losing context would risk correctness or incomplete validation.
31 
32## Quick Decision Matrix
33 
34| Task | Required action |
35| --- | --- |
36| Added/moved/renamed/removed Go files, changed the import section of an existing Go file, added a new top-level Go test function matching `func TestXxx(t *testing.T)` in an existing `*_test.go` file, changed Bazel files, updated Bazel test targets, or changed `go.mod`/`go.sum` | MUST run `make bazel_prepare` and include resulting Bazel metadata changes in the PR (for example `BUILD.bazel`, `**/*.bazel`, and `**/*.bzl`). |
37| Running package unit tests | SHOULD run targeted tests and avoid full-package runs unless needed (see `docs/agents/testing-flow.md` -> `Unit tests`). |
38| Unit tests in a package that uses failpoints | MUST enable failpoints before tests and disable afterward (see `docs/agents/testing-flow.md` -> `Failpoint decision for unit tests`). |
39| Recording integration tests | MUST use the recording command in `docs/agents/testing-flow.md` -> `Integration tests` (not `-record`; `-record` is for unit-test suites that explicitly support it). |
40| RealTiKV tests | MUST start playground in background, run tests, then clean up playground/data (see `docs/agents/testing-flow.md` -> `RealTiKV tests`). |
41| Bug fix | MUST add a regression test and verify it fails before fix and passes after fix. |
42| Fmt-only PR | MUST NOT run costly `realtikvtest`; local compilation is enough. |
43| During local coding iterations (not claiming completion) | SHOULD use the `WIP` verification profile from `.agents/skills/tidb-verify-profile` to run only scoped checks. |
44| Claiming task completion / PR readiness | MUST use the `Ready` verification profile from `.agents/skills/tidb-verify-profile`; if there are code changes, this includes `make lint`. `Ready` is mandatory before making final-status claims such as "fixed", "done", "all tests pass", "ready for review", or "ready for PR". |
45| Creating or updating a GitHub issue | SHOULD use `.agents/skills/tidb-issue-metadata-guard` to preserve issue templates and label hygiene. |
46| Creating a PR or editing PR metadata | SHOULD use `.agents/skills/tidb-pr-metadata-guard` to preserve PR templates, title scope, and bot-parsed checklist sections. |
47| Before finishing | SHOULD self-review diff quality before finishing. |
48| Expensive optional sweeps (for example `make bazel_lint_changed`, broad package runs) | MUST run only when required by change scope, CI reproduction, or explicit user request. |
49 
50### Skills
51 
52- Repository-level skills are maintained under `.agents/skills` (relative to the repository root / current working directory).
53- Keep skill content and references together under each skill folder (for example: `.agents/skills/<skill>/SKILL.md` and `.agents/skills/<skill>/references/`).
54- `.github/skills` is kept only as a migration note path and should not be used as the primary location for new skill updates.
55- Policy belongs in `AGENTS.md`; detailed command playbooks SHOULD live in `docs/agents/*`, and skills SHOULD provide entrypoint workflows that reference those playbooks.
56- Operational testing/build skills are indexed in `.agents/skills/README.md` to avoid duplicated lists drifting in multiple docs.
57 
58## Pre-flight Checklist
59 
601. Restate the task goal and acceptance criteria.
612. Locate the owning subsystem and the closest existing tests (`Repository Map`, `Task -> Validation Matrix`). If the target package has `doc.go`, agents MUST read that package-level doc first before diving into implementation files.
623. Decide prerequisites before running tests/build (`docs/agents/testing-flow.md` -> `Failpoint decision for unit tests`; `AGENTS.md` -> `Build Flow` -> `When make bazel_prepare is required`).
634. Pick the smallest valid validation set and prepare final reporting items (`Agent Output Contract`).
645. If `AGENTS.md` or docs under `docs/agents/` changed, follow the checklist in `docs/agents/agents-review-guide.md` before finishing.
65 
66## Repository Map (Entry Points)
67 
68- Detailed subsystem path mapping and test surfaces live in `docs/agents/architecture-index.md` (source of truth).
69- Update policy: when module/path mapping changes, update `docs/agents/architecture-index.md` first; update this section only when top-level entry points change.
70- `/pkg/planner/`: planner and optimization entrypoint.
71- `/pkg/executor/`, `/pkg/expression/`: SQL execution and expression evaluation.
72- `/pkg/session/`, `/pkg/sessionctx/`: session lifecycle and runtime statement context.
73- `/pkg/ddl/`, `/pkg/infoschema/`, `/pkg/meta/`: schema and metadata management.
74- `/pkg/store/`, `/pkg/kv/`: storage and distributed query interfaces.
75- `/pkg/statistics/`: statistics and estimation behavior entrypoint.
76- `/pkg/parser/`: SQL grammar and AST.
77- `/tests/integrationtest/`, `/tests/realtikvtest/`: SQL integration and real TiKV test surfaces.
78- `/cmd/tidb-server/`: TiDB server entrypoint.
79 
80## Notes
81 
82- Follow `docs/agents/notes-guide.md`.
83- DDL module-only rules (applies to changes under `pkg/ddl/` and `docs/agents/ddl/`):
84  - MUST: Before making/reviewing any DDL changes in the DDL module, read `docs/agents/ddl/README.md` first and use it as the default map of the execution framework.
85  - Debugging: You MAY reference `docs/agents/ddl/*`, but you MUST NOT treat it as authoritative. Treat it as hypotheses until verified in code/tests (avoid hallucination/outdated assumptions).
86  - Doc drift: If implementation and `docs/agents/ddl/*` differ, you MUST update the docs to match reality and call it out in the PR/issue. Do not defer.
87 
88## Build Flow
89 
90### When `make bazel_prepare` is required
91 
92Run `make bazel_prepare` before building when any of the following is true:
93 
94- New workspace or fresh clone.
95- Bazel-related files changed (for example `WORKSPACE`, `DEPS.bzl`, `BUILD.bazel`, `MODULE.bazel`, `MODULE.bazel.lock`).
96- Any Go source file is added/removed/renamed/moved in the PR.
97- The import section changed in any existing Go source file (including `*_test.go`).
98- A code change adds a new top-level Go test function matching `func TestXxx(t *testing.T)` in an existing `*_test.go` file.
99- Go module dependencies changed (for example `go.mod`, `go.sum`), including adding third-party dependencies.
100- Bazel test targets were updated (for example `shard_count` changed, test `srcs` list edited, or `tests/realtikvtest/**/BUILD.bazel` modified).
101- Local Bazel dependency/toolchain errors occurred.
102 
103For an operational decision checklist, use `.agents/skills/tidb-bazel-prepare-gate`.
104 
105Recommended local build flow:
106 
107```bash
108# Conditional step: run only when required by this section or `.agents/skills/tidb-bazel-prepare-gate`.
109make bazel_prepare
110```
111 
112```bash
113# Then continue with normal local build steps.
114make bazel_bin
115make gogenerate   # optional: regenerate generated code
116go mod tidy       # optional: if go.mod/go.sum changed
117git fetch origin --prune
118```
119 
120`make bazel_lint_changed` is intentionally excluded from the default local flow because it can be slow and resource-intensive on local macOS environments. Agents MUST NOT run `make bazel_lint_changed` unless the user explicitly requests it.
121 
122## Task -> Validation Matrix
123 
124Use the smallest set that still proves correctness.
125Command details for package, integration-test, and RealTiKV surfaces live in `docs/agents/testing-flow.md`.
126 
127| Change scope | Minimum validation |
128| --- | --- |
129| `pkg/planner/**` rules or logical/physical plans | Targeted planner unit tests and update rule testdata when needed |
130| `pkg/executor/**` SQL behavior | Targeted unit test plus relevant integration test (`tests/integrationtest`) |
131| `pkg/expression/**` builtins or type inference | Targeted expression unit tests with edge-case coverage |
132| `pkg/session/**` / variables / protocol behavior | Targeted package tests plus SQL integration tests for user-visible behavior |
133| `pkg/ddl/**` schema changes | DDL-focused unit/integration tests and compatibility impact checks |
134| `pkg/store/**` / `pkg/kv/**` storage behavior | Targeted unit tests; use realtikv tests if behavior depends on real TiKV |
135| Parser files (`pkg/parser/**`) | Parser-specific Make targets (`make parser`, `make parser_yacc`, `make parser_fmt`, `make parser_unit_test`) and related unit tests |
136| `tests/integrationtest/t/**` changed | Record and verify regenerated result correctness (see `docs/agents/testing-flow.md` -> `Integration tests`) |
137| `tests/realtikvtest/**` changed | Start playground, run scoped tests, then mandatory cleanup (see `docs/agents/testing-flow.md` -> `RealTiKV tests`) |
138 
139## Testing Policy
140 
141- Detailed command playbooks live in `docs/agents/testing-flow.md`.
142- Select required test surfaces first (`Task -> Validation Matrix`), then run scoped commands from the playbook.
143- Use `.agents/skills/tidb-verify-profile` to pick a validation profile (`WIP` / `Ready` / `Heavy`). `Ready` is required before any final-status claim; trigger phrases are defined in `Quick Decision Matrix`.
144- All other testing rules (failpoints, integration recording, RealTiKV lifecycle, regression tests) are stated once in `Quick Decision Matrix` above; do not duplicate them here.
145 
146## Code Style Guide
147 
148### Go and backend code
149 
150- Because TiDB is a complex system, code SHOULD remain maintainable for future readers with basic TiDB familiarity, including readers who are not experts in the specific subsystem/feature.
151- Follow existing package-local conventions first and keep style consistent with nearby files.
152- Code SHOULD be self-documenting through clear naming and structure.
153  - Example: when implementing a well-known algorithm, naming SHOULD be clear enough to make the approach recognizable; if naming alone may not make intent obvious, add a brief comment.
154- Keep changes focused; avoid unrelated refactors, renames, or moves in the same PR.
155- Keep error handling actionable and contextual; avoid silently swallowing errors.
156- For new source files (for example `*.go`), include the standard TiDB license header (copyright + Apache 2.0) by copying from a nearby file and updating year if needed.
157- Comments SHOULD explain non-obvious intent, constraints, invariants, concurrency guarantees, SQL/compatibility contracts, or important performance trade-offs, and SHOULD NOT restate what the code already makes clear.
158- Keep exported-symbol doc comments, and prefer semantic constraints over name restatement.
159 
160### Tests and testdata
161 
162- Prefer extending existing test suites and fixtures over creating new scaffolding.
163- Keep test changes minimal and deterministic; avoid broad golden/testdata churn unless required.
164- When recording outputs, verify changed result files before reporting completion.
165 
166### Docs and command snippets
167 
168- Commands in docs SHOULD be copy-pasteable from repository root unless explicitly scoped.
169- Use explicit placeholders such as `<package_name>`, `<TestName>`, and `<dir>`.
170- Documentation updates SHOULD keep terminology, policy wording, and command conventions consistent across related docs.
171- Keep guidance executable and concrete; avoid ambiguous phrasing.
172 
173## Agent Output Contract
174 
175When finishing a task, report:
176 
1771. Files changed.
1782. Validation profile used (`WIP`, `Ready`, or `Heavy`) and why.
1793. Risks: correctness, compatibility, performance.
1804. Exact commands run for validation.
1815. What was not verified locally.
182