Add agent conventions from recent PR review feedback

AGENTS.md

@@ -3,8 +3,11 @@
 ## Rules for AI Assistants
 - **Use Makefile targets** instead of discovering build/test commands yourself.
 - **Keep changes minimal.** Do not refactor, reorganize, or 'improve' code beyond what was explicitly requested.
+- **Stay within scope.** Only modify what the task explicitly asks for. Do not make changes to files or components outside the stated scope, even if they seem related.
 - **For CI/release workflows**, always use existing Makefile targets rather than reimplementing build logic in YAML.
 - **Better tests.** Always try to add or improve tests(including integration, e2e) when modifying code.
+- **Use typed constants.** In Go tests, always use typed constants (e.g., `batchv1.PodFailurePolicyActionCount`) instead of string literals (e.g., `"Count"`). This ensures compile-time checking and consistency with production code.
+- **Keep docs in sync.** When modifying configuration or removing/adding features, update related documentation (e.g., README files) in the same PR.
 - **Logging conventions.** Start log messages with capital letters and do not end with punctuation.
 - **Commit messages.** Do not include PR links in commit messages.
 

self-development/agentconfig.yaml

@@ -19,6 +19,7 @@ spec:
     ## Standards
     - Do not create duplicate issues — check existing issues first with `gh issue list`
     - Keep changes minimal and focused
+    - Stay within the stated scope of the task — do not modify files or components outside what was explicitly requested
 
     ## Project Conventions
     - Use Makefile targets instead of discovering build/test commands yourself:
@@ -28,5 +29,7 @@ spec:
       - `make test-integration` — run integration tests
       - `make build` — build binary
     - Always try to add or improve tests when modifying code
+    - In Go tests, use typed constants (e.g., `batchv1.PodFailurePolicyActionCount`) instead of string literals
+    - When modifying configuration or features, update related documentation (e.g., README) in the same PR
     - Logging conventions: start log messages with capital letters and do not end with punctuation
     - Commit messages: do not include PR links in commit messages

self-development/kelos-config-update.yaml

@@ -85,4 +85,5 @@ spec:
       - Do not create a PR if no actionable changes are found — exit cleanly instead
       - Do not create duplicate issues — check existing issues first with `gh issue list`
       - Back every change with a specific reference to the PR review that motivated it
+      - When editing YAML files with `promptTemplate: |` (literal block scalars), ensure all content lines maintain the correct indentation level (typically 6 spaces for content inside a 4-space-indented key). Lines with insufficient indentation will exit the block scalar and break YAML parsing
   pollInterval: 1m

self-development/kelos-self-update.yaml

@@ -82,5 +82,6 @@ spec:
         - Strategic proposals, new use cases, integrations, CRD extensions → kelos-fake-strategist
         - Documentation, CLI UX, error messages → kelos-fake-user
         - Agent configuration based on PR reviews → kelos-config-update
+      - When editing or proposing changes to YAML files with `promptTemplate: |` (literal block scalars), ensure all content lines maintain the correct indentation level (typically 6 spaces for content inside a 4-space-indented key). Lines with insufficient indentation will exit the block scalar and break YAML parsing
       - If after review you find nothing actionable to improve, exit without creating an issue or PR. Not every run needs to produce output
   pollInterval: 1m