diff --git a/AGENTS.md b/AGENTS.md index 3c7d869a..19ab801a 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -7,6 +7,7 @@ - **Better tests.** Always try to add or improve tests(including integration, e2e) when modifying code. - **Logging conventions.** Start log messages with capital letters and do not end with punctuation. - **Commit messages.** Do not include PR links in commit messages. +- **Kubernetes resource comparison.** Use semantic `.Equal()` or `.Cmp()` methods for `resource.Quantity` comparisons, not `reflect.DeepEqual` — structurally different Quantity values can be semantically identical (e.g., `1000m` vs `1` CPU). ## Key Makefile Targets - `make verify` — run all verification checks (lint, fmt, vet, etc.). diff --git a/self-development/agentconfig.yaml b/self-development/agentconfig.yaml index 657975a3..b08f63a8 100644 --- a/self-development/agentconfig.yaml +++ b/self-development/agentconfig.yaml @@ -30,3 +30,4 @@ spec: - Logging conventions: start log messages with capital letters and do not end with punctuation - Commit messages: do not include PR links in commit messages - When making structural changes (adding new files, configs, or components), update related documentation (especially README files) to stay in sync + - Kubernetes resource comparison: use semantic `.Equal()` or `.Cmp()` methods for `resource.Quantity` comparisons, not `reflect.DeepEqual` diff --git a/self-development/kelos-pr-responder.yaml b/self-development/kelos-pr-responder.yaml index c6b31759..38a2cfd8 100644 --- a/self-development/kelos-pr-responder.yaml +++ b/self-development/kelos-pr-responder.yaml @@ -85,9 +85,9 @@ spec: - 3. Read the existing diff (git diff main...HEAD) to understand what has already been done. Do NOT start over or rewrite from scratch. - 4. Make only the incremental changes needed to address review feedback or remaining issues. Preserve existing work. - 5. Commit and push your changes to origin {{.Branch}}. - - 6. /review the PR to verify your changes address the feedback. If changes are needed, make them, commit and push, then /review again. Repeat until the review passes. + - 6. /review the PR to verify your changes address the feedback. If changes are needed, make them, run `make verify` and `make test`, commit and push, then /review again. Repeat until the review passes. - 7. Update the PR title and description to reflect the final diff. The PR body MUST contain a standard closing keyword reference on its own line (e.g., `Fixes #123` or `Closes #123`). Do not embed the issue number in natural language. Ensure the PR has labels "generated-by-kelos" and "ok-to-test" (use `gh pr edit {{.Number}} --add-label generated-by-kelos --add-label ok-to-test` if missing). If `KELOS_UPSTREAM_REPO` is set, include `--repo "$KELOS_UPSTREAM_REPO"`. - - 8. Make sure the PR passes all CI tests. + - 8. After pushing, actively check CI status with `gh pr checks {{.Number}}` (if `KELOS_UPSTREAM_REPO` is set, add `--repo "$KELOS_UPSTREAM_REPO"`). If any checks fail, investigate the failures, fix them, commit and push, then check again. Do not request review until CI passes. Post-checklist: - If the PR is ready for human review, you need more information, or you cannot make progress, post a PR comment whose first line is `/kelos needs-input` and explain why below it. Maintainers can resume the PR later with `/kelos pick-up`. When all review feedback was already addressed in previous commits and no new comments require action, keep the explanation brief (e.g. "All review feedback was addressed in previous commits. Ready for re-review.") instead of repeating a full status breakdown. Never post duplicate or near-identical status messages. diff --git a/self-development/kelos-workers.yaml b/self-development/kelos-workers.yaml index 6f5f16f9..5dd37b83 100644 --- a/self-development/kelos-workers.yaml +++ b/self-development/kelos-workers.yaml @@ -104,9 +104,9 @@ spec: - 3a. Read the existing diff (git diff main...HEAD) to understand what has already been done. Do NOT start over or rewrite from scratch. - 4a. Make only the incremental changes needed to address review feedback or remaining issues. Preserve existing work. - 5a. Commit and push your changes to origin kelos-task-{{.Number}}. - - 6a. /review the PR to verify your changes address the feedback. If changes are needed, make them, commit and push, then /review again. Repeat until the review passes. + - 6a. /review the PR to verify your changes address the feedback. If changes are needed, make them, run `make verify` and `make test`, commit and push, then /review again. Repeat until the review passes. - 7a. Update the PR title and description to reflect the final diff. The PR body MUST contain a standard closing keyword reference on its own line (e.g., `Fixes #{{.Number}}` or `Closes #{{.Number}}`). Do not embed the issue number in natural language. Ensure the PR has labels "generated-by-kelos" and "ok-to-test" (use `gh pr edit {{.Number}} --add-label generated-by-kelos --add-label ok-to-test` if missing). - - 8a. Make sure the PR passes all CI tests. + - 8a. After pushing, actively check CI status with `gh pr checks`. If any checks fail, investigate the failures, fix them, commit and push, then check again. Do not request review until CI passes. If no PR exists: - 2b. Investigate the issue #{{.Number}}. @@ -116,9 +116,9 @@ spec: - Only implement what the issue explicitly asks for. If you discover related improvements, create separate issues for them. - 3b. Create a commit that fixes the issue. - 4b. Push your branch to origin kelos-task-{{.Number}}. - - 5b. Create a PR with labels "generated-by-kelos" and "ok-to-test" (use `gh pr create --label generated-by-kelos --label ok-to-test`), then /review it. If changes are needed, make them, commit and push, then /review again. Repeat until the review passes. + - 5b. Create a PR with labels "generated-by-kelos" and "ok-to-test" (use `gh pr create --label generated-by-kelos --label ok-to-test`), then /review it. If changes are needed, make them, run `make verify` and `make test`, commit and push, then /review again. Repeat until the review passes. - 6b. Update the PR title and description to reflect the final diff. The PR body MUST contain a standard closing keyword reference on its own line (e.g., `Fixes #{{.Number}}` or `Closes #{{.Number}}`). Do not embed the issue number in natural language. - - 7b. Make sure the PR passes all CI tests. + - 7b. After pushing, actively check CI status with `gh pr checks`. If any checks fail, investigate the failures, fix them, commit and push, then check again. Do not request review until CI passes. Post-checklist: - Post a `/kelos needs-input` comment on the issue (gh issue comment {{.Number}} --body "/kelos needs-input") and leave a comment for the reason if any of the following applies: