Ayuriel/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: simplify AGENTS validation policy

Browse Source
This commit is contained in:
Tak Hoffman 2026-03-19 10:34:04 -05:00
parent e1b5ffadca
commit 5a41229a6d
No known key found for this signature in database
1 changed files with 2 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
AGENTS.md
View File

@ -76,27 +76,8 @@
- Scoped tests prove the change itself. `pnpm test` remains the default `main` landing bar; scoped tests do not replace full-suite gates by default.
- Hard gate: if the change can affect build output, packaging, lazy-loading/module boundaries, or published surfaces, `pnpm build` MUST be run and MUST pass before pushing `main`.
- Default rule: do not commit or push with failing format, lint, type, build, or required test checks when those failures are caused by the change or plausibly related to the touched surface.
## Judgment / Exception Handling
- Use judgment for narrowly scoped changes when unrelated failures already exist on latest `origin/main`.
- Before using that judgment, explicitly separate:
- failures caused by the change
- failures reproducible on current `origin/main`
- failures that are clearly unrelated to the touched surface
- Scoped exceptions are allowed only when all of the following are true:
- the diff is narrowly scoped and low blast radius
- the failing checks touch unrelated surfaces
- the failures are reproducible on current `origin/main` or are otherwise clearly pre-existing
- you explicitly explain that conclusion to Tak
- Even when using a scoped exception, narrowly scoped tests are still required as direct proof of the change unless no meaningful scoped test exists.
- Do not claim full gate compliance when using a scoped exception. State which checks are failing and why they appear unrelated.
- When using judgment because full-suite failures are unrelated or already failing on latest `origin/main`, report both:
- which scoped tests you ran as direct proof of the change
- which full-suite failures you are setting aside and why they appear unrelated
- If the branch contains only the intended scoped change and the remaining failures are demonstrably unrelated or already failing on latest `origin/main`, report that clearly and ask for a push/waiver decision instead of silently broadening scope into unrelated fixes.
- If Tak explicitly authorizes landing despite unrelated failing gates, treat that as an informed override. Do not keep repairing unrelated areas unless Tak explicitly asks for that broader work.
- Do not use judgment as a blanket bypass. If the change could plausibly affect the failing area, treat the failure as in-scope until proven otherwise. Do not use “scoped tests passed” as permission to ignore plausibly related failures.
- For narrowly scoped changes, if unrelated failures already exist on latest `origin/main`, state that clearly, report the scoped tests you ran, and ask before broadening scope into unrelated fixes or landing despite those failures.
- Do not use scoped tests as permission to ignore plausibly related failures.
## Coding Style & Naming Conventions