review-envoy-gateway-pr

# Envoy Gateway PR Review Skill ## Inputs - GitHub PR URL (e.g. review PR: https://github.com/envoyproxy/gateway/pull/8237), or - A local diff between commits (e.g. review change: git diff 4927877a HEAD) ## Output - Lead with findings ordered by severity. - Include exact file and line references. - Separate required fixes from optional follow-ups. - If there are no findings, say that clearly and mention residual test or release-note risk. ## Review - Check API changes, implementation changes, feature coverage, and release notes as applicable. - Keep findings concise and actionable, with file references when possible. ## Checklist ### API changes - Make sure changes under `api/` align with https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md - Make sure changes under `api/` are consistent with existing API patterns in the Gateway API project: https://github.com/kubernetes-sigs/gateway-api/tree/main/apis - Make sure changes under `api/` are consistent with existing API patterns in this project. - Try to reuse existing types. - Keep naming consistent with this project. - Try to add kubebuilder and CEL validations to catch errors. - Make sure API validations are tested in `/test/cel-validation`. - Check backward compatibility for API shape, CRD schema, defaults, versioned structs, and upgrade behavior. - If a PR mixes API and implementation changes, say whether it should be split into separate PRs. ### Implementation changes - For changes under `internal/gatewayapi`, check that user-visible errors are surfaced in status. - For changes under `internal/gatewayapi`, check that status conditions follow the conventions in the Gateway API spec: https://gateway-api.sigs.k8s.io/geps/gep-1364/index.html - For changes under `internal/gatewayapi`, check that `internal/gatewayapi/testdata` has coverage. - For changes under `internal/xds/translator`, check that `internal/xds/translator/testdata` has coverage. ### Feature coverage - For new user-facing features, check that `test/e2e` has coverage. - For bug fixes, check that `test/e2e` has coverage if the bug is in user-facing code or has user-facing impact. ### Release notes Release notes should be added as a new fragment file under `release-notes/current/<section>/<pr-number>-<slug>.md` (see `release-notes/current/README.md`) for any of the following changes. One change per file; the section directory determines the category. - Bug fixes should be noted as "bug fix" (`bug_fixes/`) and include a brief description of the issue and the fix. - New features should be noted as "new feature" and include a brief description of the feature. - Any breaking changes should be noted as "breaking change" and include a clear description of the change and its impact on users. - Any change to generated Envoy config (xDS) that moves, removes, or modifies existing config content would break EnvoyPatchPolicies and Extension Servers, so it should be noted as a breaking change. Additions to generated xDS config do not need to be called out. - Existing API changes should be noted. - Existing behavior changes should be noted.