|
1 | 1 | # AGENTS.md |
2 | 2 |
|
3 | | -The following rules apply to coding agent collaboration and delivery workflows in this repository. |
| 3 | +The following rules apply to coding agent collaboration in this repository. These complement the general [CONTRIBUTING.md](CONTRIBUTING.md) workflow. |
4 | 4 |
|
5 | 5 | ## 1. Core Principles |
6 | 6 |
|
7 | | -- Move tasks forward under secure and traceable conditions, while avoiding unnecessary process blockers. |
8 | | -- Stay consistent with the existing repository structure, implementation style, and engineering conventions. |
| 7 | +- Move tasks forward under secure and traceable conditions. |
| 8 | +- Adhere to the existing repository structure and engineering conventions. |
9 | 9 |
|
10 | | -## 2. Git Workflow |
| 10 | +## 2. Collaboration Workflow |
11 | 11 |
|
12 | | -- Do not commit or push directly to protected branches: `main` / `master` / `release/*`. |
13 | | -- Each development task should be implemented on an independent branch, preferably cut from the latest mainline. |
14 | | -- Prefer `git fetch` + `git merge --ff-only` to sync mainline and avoid implicit merges. |
15 | | -- It is allowed to push development branches to remote branches with the same name for collaboration and backup. |
16 | | -- Do not rewrite shared history: no `git push --force`, `git push --force-with-lease`, or arbitrary `rebase`. |
17 | | -- Commit only files related to the current task; do not clean up or roll back unrelated local changes. |
| 12 | +- Follow the Git, Issue, and PR workflow defined in [CONTRIBUTING.md](CONTRIBUTING.md). |
| 13 | +- Use `gh` CLI for all issue/PR operations (reading, writing, and comments). Do not edit through the web UI. |
| 14 | +- Create a new tracking issue for any development task that does not already have one. |
| 15 | +- Link the issue explicitly in PR descriptions (e.g., `Closes #xx`). |
| 16 | +- Keep status updates synchronized to the relevant issue/PR to avoid duplicate manual work. |
18 | 17 |
|
19 | | -## 3. Issue and PR Collaboration |
| 18 | +## 3. Tooling and Text Conventions |
20 | 19 |
|
21 | | -- Before starting a development task, check whether a related open issue already exists (for example, `gh issue list --state open`). |
22 | | -- If no related issue exists, create a new issue for tracking. The issue should include background, reproduction steps, expected vs. actual behavior, acceptance criteria, and a `git rev-parse HEAD` snapshot. |
23 | | -- Only collaboration-process documentation changes (such as `AGENTS.md`) can be modified directly without creating an additional issue. |
24 | | -- Recommended issue title prefixes: `[feat]`, `[bug]`, `[docs]`, `[ops]`, `[chore]`. |
25 | | -- If a commit serves a specific issue, include the corresponding `#issue` in the commit message. |
26 | | -- PRs are recommended to be created as Draft by default, and should explicitly indicate linkage in the description (for example, `Closes #xx` / `Relates to #xx`). |
27 | | -- When key progress, solution changes, or new risks appear, sync updates to the corresponding issue/PR in time and avoid duplicate comments. |
| 20 | +- **Language**: Use Simplified Chinese for issues, PRs, and comments. Technical terms may remain in English. |
| 21 | +- **PR Body**: For multi-line bodies, write to a temporary file first and pass it via `gh pr create --body-file`. |
| 22 | +- **References**: Use `#123` for same-repo references; use full URLs for cross-repo links. |
28 | 23 |
|
29 | | -## 4. Tooling and Text Conventions |
| 24 | +## 4. Regression and Validation |
30 | 25 |
|
31 | | -- Use `gh` CLI to read and write issues/PRs; do not edit through the web UI manually. |
32 | | -- Use Simplified Chinese for issues, PRs, and comments; technical terms may remain in English. |
33 | | -- For multi-line bodies, write to a temporary file first and pass it with `--body-file`; do not concatenate `\\n` in `--body`. |
34 | | -- Use `#123` for same-repo references (auto-linking); use full URLs for cross-repo references. |
| 26 | +- Use the primary validation entrypoint for all changes: |
| 27 | + ```bash |
| 28 | + ./scripts/doctor.sh |
| 29 | + ``` |
| 30 | +- If `pre-commit` (via `doctor.sh`) auto-fixes files, review the changes before committing. |
| 31 | +- For documentation-only changes, you may skip tests but must self-check all commands and paths. |
| 32 | +- If environment limits prevent full validation, explicitly report what was skipped and why. |
35 | 33 |
|
36 | | -## 5. Regression and Validation |
| 34 | +## 5. Security and Configuration |
37 | 35 |
|
38 | | -- Choose regression strategy based on change type. Default baseline: |
39 | | - - `uv run pre-commit run --all-files` |
40 | | - - `uv run pytest` |
41 | | -- If `pre-commit` auto-fixes files (such as `ruff --fix`), review the changes before committing. |
42 | | -- For shell/deployment script changes, in addition to baseline checks, run at least `bash -n` for syntax validation on modified scripts. |
43 | | -- For documentation-only changes, tests may be skipped, but commands and path examples must be self-checked for usability. |
44 | | -- `uv sync --all-extras` is required only for first-time setup or dependency changes; it is not mandatory for every change. |
45 | | -- If any validation cannot be completed due to environment limits, explicitly state the skipped item and reason in the report. |
46 | | - |
47 | | -## 6. Security and Configuration |
48 | | - |
49 | | -- Never commit keys, tokens, credentials, or other sensitive information (including `.env` content). |
50 | | -- Logs and debug output must not leak access tokens or private data. |
51 | | -- Changes related to deployment, authentication, or secret injection must include synchronized documentation updates and minimal acceptance steps. |
| 36 | +- **Secrets**: Never commit keys, tokens, or `.env` content. |
| 37 | +- **Logs**: Ensure debug output does not leak access tokens. |
| 38 | +- **Documentation**: Synchronize documentation updates for all deployment or auth-related changes. |
0 commit comments