|
1 | | ---- |
2 | | -applyTo: "**" |
3 | | ---- |
| 1 | +______________________________________________________________________ |
| 2 | + |
| 3 | +## applyTo: "\*\*" |
4 | 4 |
|
5 | 5 | # ABACUS Governance Review Instructions |
6 | 6 |
|
7 | 7 | Apply these instructions when reviewing or changing ABACUS code: |
8 | 8 |
|
9 | | -- Use `AGENTS.md` and `docs/developers_guide/agent_governance.md` as the |
10 | | - authoritative project baseline. |
11 | | -- Keep review scope diff-oriented: new files, diff-added lines, new includes, |
12 | | - newly introduced symbols, and changed text files for line-ending checks. |
13 | | -- Do not treat untouched historical debt as a default blocker. Mention it only |
14 | | - when it affects the changed area, and label it as advisory. |
15 | | -- Flag PRs that increase `GlobalV`, `GlobalC`, or `PARAM` code references as |
16 | | - blocker-level governance issues. Flag migration-neutral added usage as a |
17 | | - warning that requires reason, scope, risk, and cleanup/follow-up rationale. |
18 | | - Prefer explicit dependencies or narrow local interfaces. |
19 | | -- Flag new default arguments in existing header interfaces. Prefer explicit |
20 | | - call-site updates, overloads, or a clearer configuration object. |
21 | | -- Review header include growth and `.hpp` propagation carefully. These are |
22 | | - usually warnings unless the PR records a narrow reason. |
23 | | -- Require LF line endings for text files. `.bat` and `.cmd` files are the CRLF |
24 | | - exceptions. |
25 | | -- Flag new `#pragma once` in header files as a blocker-level governance issue. |
26 | | - Require traditional `#ifndef`/`#define`/`#endif` include guards instead. |
27 | | -- For INPUT parameter behavior changes, require corresponding C++ `Input_Item` |
28 | | - metadata updates, or a clear no-update explanation in the PR. Do not require |
29 | | - generated YAML or Markdown documentation files to be committed. |
30 | | -- Check that new source files are linked through the relevant `CMakeLists.txt` |
31 | | - unless the PR explains generated or indirect inclusion. |
| 9 | +- Use `AGENTS.md` and `docs/developers_guide/agent_governance.md` as the authoritative project |
| 10 | + baseline. |
| 11 | +- Keep review scope diff-oriented: new files, diff-added lines, new includes, newly introduced |
| 12 | + symbols, and changed text files for line-ending checks. |
| 13 | +- Do not treat untouched historical debt as a default blocker. Mention it only when it affects the |
| 14 | + changed area, and label it as advisory. |
| 15 | +- Flag PRs that increase `GlobalV`, `GlobalC`, or `PARAM` code references as blocker-level |
| 16 | + governance issues. Flag migration-neutral added usage as a warning that requires reason, scope, |
| 17 | + risk, and cleanup/follow-up rationale. Prefer explicit dependencies or narrow local interfaces. |
| 18 | +- Flag new default arguments in existing header interfaces. Prefer explicit call-site updates, |
| 19 | + overloads, or a clearer configuration object. |
| 20 | +- Review header include growth and `.hpp` propagation carefully. These are usually warnings unless |
| 21 | + the PR records a narrow reason. |
| 22 | +- Require LF line endings for text files. `.bat` and `.cmd` files are the CRLF exceptions. |
| 23 | +- Flag new `#pragma once` in header files as a blocker-level governance issue. Require traditional |
| 24 | + `#ifndef`/`#define`/`#endif` include guards instead. |
| 25 | +- For INPUT parameter behavior changes, require corresponding C++ `Input_Item` metadata updates, or |
| 26 | + a clear no-update explanation in the PR. Do not require generated YAML or Markdown documentation |
| 27 | + files to be committed. |
| 28 | +- Check that new source files are linked through the relevant `CMakeLists.txt` unless the PR |
| 29 | + explains generated or indirect inclusion. |
32 | 30 | - Keep default C++ changes compatible with the repository C++11 baseline. |
33 | | -- Ask for focused tests or explicit test rationale for feature changes, bug |
34 | | - fixes, INPUT behavior changes, heterogeneous kernels, and core-module |
35 | | - refactors. |
36 | | -- Treat CI governance findings as deterministic evidence and semantic review |
37 | | - findings as advisory until maintainers approve them. |
| 31 | +- Ask for focused tests or explicit test rationale for feature changes, bug fixes, INPUT behavior |
| 32 | + changes, heterogeneous kernels, and core-module refactors. |
| 33 | +- Treat CI governance findings as deterministic evidence and semantic review findings as advisory |
| 34 | + until maintainers approve them. |
0 commit comments