From a055af08734379555ca025d90babfc5a04ecff85 Mon Sep 17 00:00:00 2001 From: Gunju Kim Date: Tue, 24 Mar 2026 18:07:53 +0000 Subject: [PATCH 1/2] Add pre-push verification and cross-surface update conventions Address recurring review feedback: agents should run make verify/test before pushing (not just after), and should update all related surfaces when changing user-facing guidance. Co-Authored-By: Claude Opus 4.6 --- AGENTS.md | 1 + self-development/agentconfig.yaml | 1 + self-development/kelos-pr-responder.yaml | 2 +- self-development/kelos-workers.yaml | 11 ++++++----- 4 files changed, 9 insertions(+), 6 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 19ab801a..750d6655 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -8,6 +8,7 @@ - **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). +- **Consistent guidance across surfaces.** When changing user-facing guidance or instructions, search for all surfaces that reference the same topic (docs, CLI output, templates, code comments) and update them together. ## 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 b08f63a8..237ec424 100644 --- a/self-development/agentconfig.yaml +++ b/self-development/agentconfig.yaml @@ -30,4 +30,5 @@ 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 + - When changing user-facing guidance or instructions, search for all surfaces that reference the same topic (docs, CLI output, templates, code comments) and update them together - 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 38a2cfd8..4feb9e2e 100644 --- a/self-development/kelos-pr-responder.yaml +++ b/self-development/kelos-pr-responder.yaml @@ -84,7 +84,7 @@ spec: - 2. Read ALL comments on the linked issue referenced by the PR body. First determine the linked issue number from the PR body, then run `gh issue view --comments`. If `KELOS_UPSTREAM_REPO` is set, use `--repo "$KELOS_UPSTREAM_REPO"`. - 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}}. + - 5. Run `make verify` and `make test`. Fix any failures. Then 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, 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. 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. diff --git a/self-development/kelos-workers.yaml b/self-development/kelos-workers.yaml index 5dd37b83..e70ae2aa 100644 --- a/self-development/kelos-workers.yaml +++ b/self-development/kelos-workers.yaml @@ -103,7 +103,7 @@ spec: - Also read ALL comments on the linked issue (gh issue view {{.Number}} --comments), not just the PR. - 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}}. + - 5a. Run `make verify` and `make test`. Fix any failures. Then 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, 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. 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. @@ -115,10 +115,11 @@ spec: - Search the codebase for existing constants, types, and patterns before creating new ones. Do not duplicate definitions. - 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, 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. 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. + - 4b. Run `make verify` and `make test`. Fix any failures and update your commit before pushing. + - 5b. Push your branch to origin kelos-task-{{.Number}}. + - 6b. 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. + - 7b. 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. + - 8b. 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: From c8451fe621f6b9c8596d77a684a1f5255867994a Mon Sep 17 00:00:00 2001 From: Gunju Kim Date: Wed, 25 Mar 2026 18:07:18 +0000 Subject: [PATCH 2/2] Add provider-agnostic API and idiomatic Helm conventions Based on review feedback from recent PRs: - PR #785: reviewer required generic `none` credential type instead of AWS-specific `bedrock`, establishing provider-agnostic API design - PR #783: multiple review rounds corrected flat string Helm values to idiomatic nested dictionaries (controller.resources.requests|limits) Co-Authored-By: Claude Opus 4.6 --- AGENTS.md | 2 ++ self-development/agentconfig.yaml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 750d6655..e309bccd 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -9,6 +9,8 @@ - **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). - **Consistent guidance across surfaces.** When changing user-facing guidance or instructions, search for all surfaces that reference the same topic (docs, CLI output, templates, code comments) and update them together. +- **Provider-agnostic API design.** When adding CRD fields or API types, prefer generic, provider-agnostic abstractions over provider-specific ones (e.g., a generic `none` credential type instead of `bedrock`). Provider-specific details should be handled through existing generic mechanisms like `PodOverrides.Env` rather than dedicated fields. +- **Idiomatic Helm values.** Use nested dictionary structures in `values.yaml` (e.g., `controller.resources.requests.cpu`) instead of flat string-based parameters. Values that represent structured data should be proper YAML dictionaries, not strings. ## 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 237ec424..e3728352 100644 --- a/self-development/agentconfig.yaml +++ b/self-development/agentconfig.yaml @@ -32,3 +32,5 @@ spec: - When making structural changes (adding new files, configs, or components), update related documentation (especially README files) to stay in sync - When changing user-facing guidance or instructions, search for all surfaces that reference the same topic (docs, CLI output, templates, code comments) and update them together - Kubernetes resource comparison: use semantic `.Equal()` or `.Cmp()` methods for `resource.Quantity` comparisons, not `reflect.DeepEqual` + - Provider-agnostic API design: when adding CRD fields or API types, prefer generic abstractions over provider-specific ones (e.g., `none` credential type instead of `bedrock`); use existing generic mechanisms like `PodOverrides.Env` for provider-specific details + - Idiomatic Helm values: use nested dictionary structures in `values.yaml` (e.g., `controller.resources.requests.cpu`) instead of flat string-based parameters; structured data should be proper YAML dictionaries, not strings