[pmoust]

Grants the edge agent's ClusterRole get/list/watch on batch cronjobs, scheduling.k8s.io priorityclasses, rbac.authorization.k8s.io roles/clusterroles/rolebindings/clusterrolebindings, and crd.projectcalico.org ippools/bgppeers/ipamconfigs, for the informers in NOFireAI/edge#157. A rule for a CRD the cluster does not have is harmless.

values.yaml is unchanged: the new kinds stay opt-in through config.kube.resources. The standalone manifests.yaml and its check script are updated to match the template.

helm lint and tests/render/run.sh (66 passed) pass locally. The new helm unittest cases in tests/rbac_test.yaml were not run locally; CI is their first run.

Refs NOFireAI/edge#157

[pmoust]

@claude-fleet review

[claude-fleet]

Review task queued.

Task: 9412eafc-085f-41a5-b686-58321b7178a8
Commit: 667d33e
Model: claude-opus-5 (effort medium)
Executor: pmoust-mbp
Status: done. Review posted.

[claude-fleet]

Verified the change against the rendered template, the standalone manifest and the tests; both new test layers bind to the rules they claim to cover.

Findings:

• nit, templates/rbac.yaml:24 — new kinds get RBAC but no documented value names; examples/production-values.yaml still claims "all available resources"

Verified:

• The new rules are identical in template and standalone manifest, so the two do not drift — templates/rbac.yaml:18-32, manifests.yaml:88-102
• values.yaml is unchanged and the kinds stay opt-in: config.kube.resources is passed through verbatim with no allowed-set check and no values.schema.json in the chart — templates/configmap.yaml:21-26, values.yaml:193-209
• Granting read on RBAC objects is not a new trust boundary here: the ClusterRole already grants get/list/watch on secrets cluster-wide — templates/rbac.yaml:10
• jq -e ... | index(...) in the new manifest checks is sound even when the kind is the first element (jq treats 0 as truthy; only false/null exit non-zero) — tests/manifests/check.sh:26-33
• contains with a whole rule map matches the rule exactly, so a verb or resource drop fails the assert — confirmed by the revert run below

Checks run:

• helm unittest -f tests/rbac_test.yaml -f tests/examples_test.yaml . → 2 suites, 4 tests passed (installed the plugin locally; these are the cases the description says were never run)
• tests/manifests/check.sh → 10 ok, exit 0
• Reverted resources: ["jobs", "cronjobs"] to ["jobs"] in both templates/rbac.yaml:19 and manifests.yaml:89 → rbac_test.yaml case "lets the default ClusterRole read the CronJob, PriorityClass, RBAC and Calico kinds" fails and check.sh reports FAIL: ClusterRole reads cronjobs; files restored, tree clean

Smaller things:

• The header comment of tests/manifests/check.sh:2-4 still describes only "the ClusterRole can read endpoints"; it now checks four more kinds.
• tests/e2e/kind.sh:72-86 still asserts only the endpoints informer, so nothing in e2e exercises the new kinds end to end. Reasonable, since values.yaml does not enable them.
• Calico resources are granted only under crd.projectcalico.org. If the informer in edge#157 reads through the aggregated projectcalico.org group (Tigera-operator installs expose that as the user-facing group), these rules do not cover it.

Not checked:

• The informers in NOFireAI/edge#157: the resource strings the agent expects in config.kube.resources for these kinds, and which API group its Calico client uses. Not reachable from this repo.
• tests/render/run.sh and helm lint (CI runs them; values.yaml and the rendered config.json are unchanged by this diff).

Not checked:

• NOFireAI/edge#157: the resource strings the informers expect in config.kube.resources, and the API group its Calico client reads (crd.projectcalico.org vs the aggregated projectcalico.org)
• helm lint and tests/render/run.sh (CI covers them; values.yaml and the rendered config.json are unchanged by this diff)

Task 9412eafc-085f-41a5-b686-58321b7178a8 on pmoust-mbp, model claude-opus-5, effort medium.

[pmoust]

@claude-fleet review

[claude-fleet]

Review task queued.

Task: dc6c81b5-f10c-4798-ba16-8f8ce17e5c10
Commit: 22d8a72
Model: claude-opus-5 (effort medium)
Executor: rp1
Status: done. Review posted.

[claude-fleet]

Previous round at 667d33e: 1 finding.

Previous finding	Classification	Cited line
templates/rbac.yaml:24 (nit): The permissions land but nothing tells an operator how to turn the kinds on. values.yaml:193-209 lists every currently supported entry of config.kube.resources and gains no entry for the new kinds (commented or otherwise), and examples/production-values.yaml:52-68 still says "# Monitor all available resources" above a list that no longer is one. Failure: an operator who wants CronJob graphing has no discoverable string to add, and copying the production example now silently omits four kinds whose RBAC is granted; the example's comment is a false claim about the list under it, the same staleness fixed for endpoints in 0ca8e42. Evidence: values.yaml:193-209, examples/production-values.yaml:52-68, templates/configmap.yaml:21-26 (the list is passed through verbatim, so any name is accepted and nothing validates a typo). Fix: add the four names as commented entries in values.yaml and either extend the production example or reword its comment.	fixed	values.yaml:210

Approve: previous nit fixed, one new nit.

Findings:

• nit, values.yaml:210-211 — "adding a name here is enough" is false for the three Calico kinds

Verified:

• Previous round's finding is fixed: values.yaml:210-220 adds the nine opt-in names as commented entries, and examples/production-values.yaml:52-53 replaces "Monitor all available resources" with a comment that names the opt-in kinds as excluded.
• "the production example monitors the default kinds": the example's list (examples/production-values.yaml:55-70) and the chart default (values.yaml:194-209) are the same 16 names, differing only in order.
• "the standalone manifests.yaml is updated to match the template": the rule blocks are byte-identical (diff of manifests.yaml:79-102 against templates/rbac.yaml:9-32).
• Each name in the new commented list has a matching grant: cronjobs (templates/rbac.yaml:18-20), priorityclasses (:24-26), the four RBAC kinds (:27-29), calico{ippools,bgppeers,ipamconfigs} against ippools/bgppeers/ipamconfigs (:30-32).
• config.kube.resources is passed through verbatim with no name validation — templates/configmap.yaml:21-26.
• The new tests/rbac_test.yaml:16-44 contains blocks match the template's rule maps exactly, including resource order ([jobs, cronjobs], [roles, clusterroles, rolebindings, clusterrolebindings], [ippools, bgppeers, ipamconfigs]); the suite's templates: is only templates/rbac.yaml, so the bare documentSelector resolves.
• The four new check.sh assertions (tests/manifests/check.sh:27-34) select on the exact apiGroups arrays present in manifests.yaml:89-101.

Checks run:

• diff of the manifests.yaml and templates/rbac.yaml rule blocks → identical
• git diff 667d33e..HEAD → only examples/production-values.yaml, tests/manifests/check.sh, values.yaml

Smaller things:

• tests/manifests/check.sh:2-3 still says the embedded config.json "watches the informers the chart does", while line 22 asserts it must not contain services, which is in the chart default (values.yaml:209). Pre-existing wording, but the PR rewrote that header.

Not checked:

• Whether the informer names (cronjobs, priorityclasses, roles, …, calicoippools, calicobgppeers, calicoipamconfigs) are the strings the agent accepts: NOFireAI/edge#157 is not reachable from here, and nothing in this repo validates them.
• helm lint, tests/render/run.sh and helm unittest — helm and yq are not installed in this workspace, so the new unittest cases are still unrun outside CI.

Not checked:

• Whether the informer names in values.yaml:212-220 match the strings the edge agent accepts (NOFireAI/edge#157 not reachable from this workspace)
• helm lint, tests/render/run.sh and helm unittest: helm and yq are not installed here, so tests/rbac_test.yaml remains unrun outside CI
• tests/e2e: not read; the new kinds are opt-in and not enabled by default

Task dc6c81b5-f10c-4798-ba16-8f8ce17e5c10 on rp1, model claude-opus-5, effort medium.

[pmoust]

@claude-fleet review

[claude-fleet]

Review task queued.

Task: 2218d519-e94e-4ee8-be9f-87cbcb544366
Commit: d6dc3e8
Model: claude-opus-5 (effort medium)
Executor: rp2
Status: done. Review posted.

[claude-fleet]

Previous round at 22d8a72: 2 findings.

Previous finding	Classification	Cited line
values.yaml:210 (nit): The permissions land but nothing tells an operator how to turn the kinds on. values.yaml:193-209 lists every currently supported entry of config.kube.resources and gains no entry for the new kinds (commented or otherwise), and examples/production-values.yaml:52-68 still says "# Monitor all available resources" above a list that no longer is one. Failure: an operator who wants CronJob graphing has no discoverable string to add, and copying the production example now silently omits four kinds whose RBAC is granted; the example's comment is a false claim about the list under it, the same staleness fixed for endpoints in 0ca8e42. Evidence: values.yaml:193-209, examples/production-values.yaml:52-68, templates/configmap.yaml:21-26 (the list is passed through verbatim, so any name is accepted and nothing validates a typo). Fix: add the four names as commented entries in values.yaml and either extend the production example or reword its comment.	fixed	values.yaml:214
values.yaml:211 (nit): The comment tells the operator that "adding a name here is enough" for all nine kinds, which does not hold for the three Calico entries. Failure: an operator on a cluster without Calico uncomments calicoippools and gets an informer for a CRD that is not installed; the RBAC rule is present (templates/rbac.yaml:30-32) but the API group is not served, so the failure surfaces at runtime rather than at install. The chart cannot catch it either: templates/configmap.yaml:21-26 passes the list through verbatim with no validation. Evidence: values.yaml:210-220; templates/rbac.yaml:30-32; templates/configmap.yaml:21-26. Fix: note on the Calico lines that they also require the crd.projectcalico.org CRDs to be installed.	fixed	values.yaml:211

No longer carried to the next round, settled in rounds 2 and 3:

• values.yaml:210 (nit): The permissions land but nothing tells an operator how to turn the kinds on. values.yaml:193-209 lists every currently supported entry of config.kube.resources and gains no entry for the new kinds (commented or otherwise), and examples/production-values.yaml:52-68 still says "# Monitor all available resources" above a list that no longer is one. Failure: an operator who wants CronJob graphing has no discoverable string to add, and copying the production example now silently omits four kinds whose RBAC is granted; the example's comment is a false claim about the list under it, the same staleness fixed for endpoints in 0ca8e42. Evidence: values.yaml:193-209, examples/production-values.yaml:52-68, templates/configmap.yaml:21-26 (the list is passed through verbatim, so any name is accepted and nothing validates a typo). Fix: add the four names as commented entries in values.yaml and either extend the production example or reword its comment.

Approve: the previous round's two nits are fixed and the diff holds up; one new nit.

Findings:

• nit, examples/production-values.yaml:53 — the opt-in enumeration drops priorityclasses

Verified:

• templates/rbac.yaml:18-32 grants get/list/watch on exactly the kinds the description names; verbs are read-only, so no RBAC escalation path (reading roles/clusterroles needs no escalate/bind).
• The standalone manifest matches the template: manifests.yaml:86-104 ClusterRole rules parse equal, rule for rule, to templates/rbac.yaml:8-32 defaults (compared both parsed lists; 8 rules, identical).
• values.yaml keeps the kinds opt-in: the nine new entries at values.yaml:214-222 are commented, so templates/configmap.yaml:21-26 renders the same kube.resources as before.
• New check.sh header claim is true: manifests.yaml:150-167 lists k8services and endpoints, has no services, while the chart default at values.yaml:209 does have services — the check at tests/manifests/check.sh:23 is what forced the wording.
• One ClusterRole rule per apiGroup in manifests.yaml, so each new select(.apiGroups == [...]) in tests/manifests/check.sh:28-35 matches exactly one rule, and every index lookup lands on a present element.
• Production example claim "the default resource kinds": examples/production-values.yaml:54-70 is the same 16-element set as values.yaml:194-209, reordered.
• README has no resource-kind list, so nothing there went stale.

Checks run:

• Parsed manifests.yaml and templates/rbac.yaml and compared the ClusterRole rule lists → equal.
• Replayed the four new check.sh assertions against manifests.yaml → all pass.
• tests/manifests/check.sh itself → cannot run, yq: command not found.

Smaller things:

• The Calico rule uses crd.projectcalico.org only. A cluster where the agent reads Calico through the aggregated API server (projectcalico.org/v3) would not be covered. Consistent with the crd.projectcalico.org/v1 wording in values.yaml:212, so this is a question for edge#157, not the chart.
• tests/manifests/check.sh:19 runs yq outside check(), so a missing/failing yq aborts before any check reports. Pre-existing, off-diff.

Not checked:

• Whether the edge agent accepts the resource names cronjobs, priorityclasses, roles, clusterroles, rolebindings, clusterrolebindings, calicoippools, calicobgppeers, calicoipamconfigs — NOFireAI/edge#157 is not reachable here, and templates/configmap.yaml:21-26 passes the list through unvalidated.
• The values.yaml:212-213 claim that the agent skips a Calico kind when the CRDs are absent — agent-side behavior, not in this repo.
• tests/rbac_test.yaml under helm unittest, and helm lint / tests/render/run.sh: no helm, helm-unittest or yq binary in this workspace. CI is the first run, as the description says.
• The pull request's merge base: this clone is grafted so git merge-base origin/main HEAD resolves to HEAD; reviewed git diff origin/main HEAD (6 files) instead, and git diff 22d8a72..HEAD after fetching that commit.

Task 2218d519-e94e-4ee8-be9f-87cbcb544366 on rp2, model claude-opus-5, effort medium.