What the agent does
The agent begins with replica counts in the target configuration, not a budget for every YAML file. In GoogleCloudPlatform/microservices-demo, kustomize/kustomization.yaml loads base and lists optional components. kustomize/base/frontend.yaml defines a Deployment with an app: frontend pod selector but omits replicas, while loadgenerator.yaml explicitly declares replicas: 1. The inspected base contains no Deployment explicitly scaled above one. The issue must therefore identify a scaled overlay, or the PR must explain that the base has no eligible workloads.
It follows the existing opt-in pattern in kustomize/components/network-policies/kustomization.yaml, whose kind is Component. The proposed disruption-budget component belongs alongside those components, with a README explaining how to enable it for the chosen overlay. Budget selectors come from the rendered Deployment pod selectors, not from Service names or an empty selector. The agent does not silently increase replica counts to make the issue appear implemented; scaling changes require their own stated acceptance criteria.
The tests render a configuration with the component enabled and another without it. For eligible workloads they compare each budget's selector to the intended Deployment and check the requested availability policy against its replica count. They also cover an explicitly single-replica configuration so an opt-in component cannot accidentally make routine maintenance impossible. The README states which scaling assumptions must remain true and distinguishes a voluntary-disruption policy from a guarantee against crashes or an unavailable application.
The repository already has scenario directories under kustomize/tests/, and .github/workflows/kustomize-build-ci.yaml builds the base and loops over those scenarios with kustomize build. The agent extends that pattern, runs kustomize build kustomize, renders the new scenarios, and validates the output with kubeconform -strict. Schema validation and selector assertions answer different questions. The task requests rendered-manifest checks, not permission to apply resources to a live cluster or drain a production node.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent requests an opt-in Kustomize component adding PodDisruptionBudgets for Deployments with more than one replica. Inspect the actual base and rendered target overlays first. The unmodified Online Boutique base does not identify a multi-replica deployment, so do not invent one or silently scale workloads: document the absence and require the issue's target overlay or explicit scaling scope before assigning production budgets. For eligible workloads, use their exact pod selectors and a reviewed availability policy. Add the component README, enabled/disabled rendering tests and checks for selectors and single-replica exclusions using the existing kustomize/tests pattern. Run kustomize build for the base and affected scenarios, then kubeconform -strict on rendered output. Do not apply to a cluster. Open a pull request linking the supplied Linear issue and report real validation results and any missing overlay information.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
For an issue with a defined scaled target, the result is a PR containing the optional component, budget resources, its README and rendering scenarios. It lists exactly which Deployments qualify and how the selector checks establish that each policy covers the intended pods. The default configuration stays unchanged unless the issue explicitly requests enabling the component. The PR separates schema-validation output from the assertions about replica eligibility.
For the unmodified demo base, an honest result identifies the missing scaled target rather than presenting arbitrary budgets as completed work. A reviewer checks the actual overlay, the desired minimum availability and the consequences of unhealthy pods before enabling anything. Rendered YAML can establish the proposed configuration, but cluster eviction behavior requires a separately authorized cluster test. Neither the page nor a successful schema check claims that a node drain has occurred.
Run it on every Linear issue labelled disruption-budget
Your Linear event handler reads the labelled issue and sends the repository, target overlay and availability requirements to the sessions API. Copy the issue text and link into input; the API body has no Kubernetes or Linear trigger option. Use one idempotency key per issue revision and inspect the returned session before requesting another policy change. A completion webhook on the API key can notify your receiver that the review material is ready.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Manifest work benefits from a clean render environment rather than a laptop's current Kubernetes context. Rush gives the agent a separate sandbox for Kustomize, schema downloads and selector checks. The prompt explicitly keeps it away from cluster mutation. Your local context remains untouched while the result records the exact commands used to turn an overlay into the YAML under review.
Several services or repositories can have independent policy reviews running at once, with a separate PR and transcript for each request. A reviewer can inspect why one overlay has eligible Deployments while another has none. The recorded output also exposes missing schemas or failed renders, so infrastructure changes arrive with specific evidence instead of a claim that adding a budget automatically improves availability.
Frequently asked questions
Why not add a budget to every Deployment in the demo?
The issue limits the change to workloads with more than one replica. The inspected base omits replica counts for most Deployments and explicitly sets the load generator to one. The agent must inspect a scaled target rather than invent qualifying workloads.
Will it change replica counts?
The request forbids an implicit scaling change. If the issue explicitly includes scaling, the PR must show that change and explain the availability assumptions it creates. Otherwise missing replica information is reported as a scope gap.
Does kubeconform prove the budgets are safe?
It checks the rendered resources against schemas, not whether a selector targets the right workload or a maintenance operation can finish. Separate assertions cover selectors and eligibility. Runtime eviction testing needs an authorized test cluster and its own recorded result.
Can I keep the component disabled by default?
Yes, the requested change follows the repository's optional-component structure. The README describes enabling it in a chosen Kustomization. Tests should show that the original base still renders without the new policies.