From 890cda75ea8b41e9610c5d527fb000e420f6e37b Mon Sep 17 00:00:00 2001 From: Cristian Greco Date: Tue, 17 Feb 2026 10:57:41 +0000 Subject: [PATCH 1/4] Update AGENTS.md API type export guidance --- AGENTS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index a3659d985..ac200c8d2 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -8,6 +8,8 @@ It captures practical rules that prevent avoidable CI and PR churn. ## Development Expectations - If a public API changes, update the relevant docs in the same PR. +- If new types are made part of the public API, export them from the package's `index.ts` in the same PR. +- If new learnings or misunderstandings are discovered, propose an `AGENTS.md` update in the same PR. - Tests should verify observable behavior changes, not only internal/config state. - Example: for a security option, assert a real secure/insecure behavior difference. From ea6f67432b8e96ac55ad04e7fc65f4d00f18be49 Mon Sep 17 00:00:00 2001 From: Cristian Greco Date: Tue, 17 Feb 2026 10:59:13 +0000 Subject: [PATCH 2/4] Document broken hook fallback in AGENTS --- AGENTS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/AGENTS.md b/AGENTS.md index ac200c8d2..7f7ca55f7 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -22,6 +22,7 @@ It captures practical rules that prevent avoidable CI and PR churn. - Use specific commands and clear justifications. - Prefer narrow reruns rather than broad full-suite reruns when iterating. +- If local git hooks are broken or missing (for example, `.husky/_/husky.sh` not found), use `git commit --no-verify` only as a last resort and note the reason in the PR body. ## PR Process From 104daec473a9a840dc49e679687618e92a50f825 Mon Sep 17 00:00:00 2001 From: Cristian Greco Date: Tue, 17 Feb 2026 11:03:25 +0000 Subject: [PATCH 3/4] Move no-verify guidance into PR process step --- AGENTS.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 7f7ca55f7..e9c815547 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -22,7 +22,6 @@ It captures practical rules that prevent avoidable CI and PR churn. - Use specific commands and clear justifications. - Prefer narrow reruns rather than broad full-suite reruns when iterating. -- If local git hooks are broken or missing (for example, `.husky/_/husky.sh` not found), use `git commit --no-verify` only as a last resort and note the reason in the PR body. ## PR Process @@ -31,7 +30,7 @@ It captures practical rules that prevent avoidable CI and PR churn. 3. Implement scoped changes only. 4. Run required checks: `npm run format`, `npm run lint`, and targeted tests. 5. Verify git diff only contains intended files. -6. Commit with focused message(s). +6. Commit with focused message(s), using `git commit --no-verify`. 7. Push branch. 8. Open PR against `main` using a human-readable title (no `feat(...)` / `fix(...)` prefixes). 9. Add labels for both change type and semantic version impact. From a4c50514802694be528236e71395958229d847a1 Mon Sep 17 00:00:00 2001 From: Cristian Greco Date: Tue, 17 Feb 2026 13:20:06 +0000 Subject: [PATCH 4/4] Add explicit approval gates for discussion and issue comments --- AGENTS.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index e9c815547..07c1e3dac 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -29,12 +29,13 @@ It captures practical rules that prevent avoidable CI and PR churn. 2. Create a branch prefixed with `codex/`. 3. Implement scoped changes only. 4. Run required checks: `npm run format`, `npm run lint`, and targeted tests. -5. Verify git diff only contains intended files. +5. Verify git diff only contains intended files. If changes are still being discussed, share the diff and get user approval before committing or pushing. 6. Commit with focused message(s), using `git commit --no-verify`. -7. Push branch. +7. Push branch. Ask for explicit user permission before any force push. 8. Open PR against `main` using a human-readable title (no `feat(...)` / `fix(...)` prefixes). -9. Add labels for both change type and semantic version impact. -10. Ensure PR body includes: +9. Before posting any comment on GitHub issues or PRs, share the proposed message with the user and get explicit approval. +10. Add labels for both change type and semantic version impact. +11. Ensure PR body includes: - summary of changes - verification commands run - test results summary