What the agent does
The agent reads both input declarations and their consumers. In terraform-aws-modules/terraform-aws-s3-bucket, variables.tf declares nullable acl, a typed lifecycle_rule list and object_ownership with the default BucketOwnerEnforced. Its ownership description names BucketOwnerPreferred and ObjectWriter as the other valid values. versions.tf requires Terraform >= 1.5.7 and AWS provider >= 6.44. The task adds validation to those existing variables without quietly raising the module's minimum Terraform version.
Compatibility requires more than an enum list. main.tf treats the string "null" specially for ACL input, while a real null also means no canned ACL. examples/acl/main.tf demonstrates private with BucketOwnerPreferred and an ownership-control toggle. The agent distinguishes supported inputs from misspellings, retains documented omission behavior and checks the selected provider's allowed bucket ACLs. It does not reject existing valid callers simply because a shorter validation expression overlooks the module's current handling.
For lifecycle rules, main.tf prefers enabled when present and otherwise normalizes status; it also supports both days and noncurrent_days for noncurrent-version settings. The agent defines which invalid combinations the issue wants rejected, including contradictory expiration fields or malformed transition settings, while preserving accepted shapes. Validation messages name the offending variable and the allowed form. Null optional attributes and an empty rule list receive explicit tests rather than being passed to expressions that fail before the intended diagnostic.
The existing .pre-commit-config.yaml already includes Terraform formatting, documentation and validation checks. The agent adds native plan-oriented tests with expected variable failures and valid examples, choosing a test-capable runtime without changing consumer compatibility by accident. It runs terraform init -backend=false, terraform fmt -check, terraform validate and terraform test. Provider-mocked tests can check inputs without creating buckets; any test that needs AWS access must be identified separately and must not use production credentials.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A Linear issue labeled agent asks for validation blocks on the S3 bucket module's acl, lifecycle_rule and object_ownership variables, with clear diagnostics for invalid values. Read variables.tf, main.tf, versions.tf and existing examples before editing. Preserve documented valid forms, null/default behavior and the existing ACL string-null compatibility unless the issue explicitly authorizes its removal. Check the provider contract for allowed values and define precise lifecycle constraints without changing unrelated inputs. Add native Terraform tests with valid cases and expect_failures for the relevant variables, using plan-only/provider-mocked execution where appropriate and no production AWS access. Keep the module's declared consumer compatibility intact; explain the test runtime requirements. Run terraform init -backend=false, terraform fmt -check, terraform validate and terraform test. Open a pull request linking the supplied Linear issue with real command output and any untested provider behavior.",
"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
The PR contains validation blocks on existing variables, tests that assert the intended diagnostics, and documentation changes where accepted forms need clarification. It shows examples of rejected values alongside valid defaults and legacy supported forms. The description separates input validation from provider behavior and names the Terraform runtime used for tests. It does not claim that a provider-mocked plan contacted AWS or created a bucket.
Before merging, a reviewer checks that valid example configurations still pass and that negative tests fail for the variable under test rather than missing credentials or a syntax error. The reviewer pays particular attention to nulls, optional lifecycle attributes and ownership settings when ownership management is disabled. A validation patch can break callers without changing a resource block, so the PR explains every intentional tightening and leaves unrelated policy changes out.
Run it on every Linear issue labelled terraform-validation
Your Linear receiver sends one request per approved validation issue, copying its body and URL into input and naming the module repository in resources. Include the compatibility policy and the variables in scope, not a production state file or cloud keys. Send an Idempotency-Key for the issue revision when calling the sessions API. An updated issue that deliberately changes the accepted input contract should start a new request rather than reuse the earlier body.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
Input validation needs repeated invalid plans as well as successful ones. Rush gives the agent a separate sandbox for provider initialization, test fixtures and command output, keeping that work away from your laptop's active Terraform directory and backend configuration. The request limits execution to validation and tests, so writing better diagnostics does not require applying infrastructure or touching production state.
You can investigate validation gaps in several modules concurrently, each with a separate repository clone and PR. The session transcript records which commands produced each diagnostic, making it possible to distinguish a tested error message from one that only looks helpful in HCL. A follow-up after the turn ends can narrow a compatibility concern while retaining the agent's existing module context.
Frequently asked questions
Will it reject null and omitted values?
The inspected acl input is nullable and lifecycle rules default to an empty list. Those cases need positive tests before adding stricter conditions. The prompt also calls out the ACL string-null handling in main.tf, which should not disappear as an accidental side effect.
Can variable checks replace AWS provider validation?
They can reject known invalid input shapes earlier and provide a clearer message. Provider and service constraints still matter, especially when values are unknown until planning or depend on remote resources. The PR must say which contract each check establishes.
Does terraform test create real buckets?
That depends on the test configuration, so the request explicitly asks for plan-only or provider-mocked input tests. Inspect the run commands and provider setup in the PR. Any test requiring real AWS access must be identified and separately authorized rather than hidden behind the test command.
Will this increase the minimum Terraform version?
The module currently declares >= 1.5.7 in versions.tf. The task preserves consumer compatibility and makes any newer test-runtime requirement explicit. A validation expression that needs a higher consumer version requires a deliberate issue decision, not an unexplained version bump.