What the agent does
The agent reads the Linear ticket as a concrete change to a Spring MVC flow. In spring-projects/spring-petclinic, pom.xml:8 selects Spring Boot 4.1.0 and line 19 sets java.version to 17. The agent uses the repository's Maven wrapper rather than assuming a global Maven installation. It identifies whether the issue concerns owner search, owner editing or booking a pet visit, then turns the supplied acceptance criteria into an observable request, form response or persisted change.
For owner behavior, it follows src/main/java/org/springframework/samples/petclinic/owner/OwnerController.java. Lines 94–107 accept page and Owner inputs, normalize lastName with strip() and call findPaginatedForOwnersLastName. Lines 108–114 redirect invalid pages, while lines 116–129 distinguish no results, a single owner and the owner list. A search ticket must say which of these outcomes changes. The agent should extend that existing flow instead of adding a parallel controller or replacing the application's MVC pages with a new API.
For visit behavior, it reads VisitController in the same package and the corresponding JUnit tests. VisitController.java:64–74 loads the owner and confirms that the pet belongs to that owner. Lines 98–111 validate the visit, reject dates that are not after today, save the owner and redirect. src/test/java/org/springframework/samples/petclinic/owner/VisitControllerTests.java:97–106 checks the non-future date error through MockMvc. The agent preserves relationship checks and form validation while reproducing the ticket's exact input.
The test plan separates MVC assertions from persistence evidence. VisitControllerTests.java:44 uses @WebMvcTest(VisitController.class), and lines 56–57 provide a mocked OwnerRepository, so that class alone cannot prove a database write. The agent adds real persistence coverage when the issue requires it, using isolated test state; src/main/resources/application.properties:2 declares database=h2. It runs focused JUnit checks and ./mvnw test, records the outputs and opens a PR linked to the supplied Linear issue. The caller supplies comments through its own Linear connection and handles posting the returned PR URL.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Implement the scoped Linear issue supplied below in this Spring Boot application's owner or visit flow. The caller must append its issue URL, description, relevant comments and acceptance criteria; this request grants no Linear tools. Read the Maven configuration, owner and visit controllers, validation and existing JUnit tests. Reproduce the requested behavior through the real MVC path, preserving owner/pet relationships, form binding and denied or invalid cases. Add database-backed coverage with disposable state if persistence changes; do not claim a mocked repository proves a write. Run focused JUnit checks and ./mvnw test, and record exact results and setup failures. Open a pull request linking the issue and return its URL so the caller can comment it on Linear. Do not merge, deploy or access production records.",
"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 pull request connects the ticket to a specific owner or visit interaction and includes the regression that establishes its expected behavior. Its description explains any controller, validation, template or persistence change that is actually needed. For a visit ticket, review includes the owner's pet relationship and invalid form submission as well as the successful redirect. For search, it includes the relevant empty, single-result or paginated outcome rather than only a service-level return value.
The maintainer sees focused test results and the complete ./mvnw test result separately. The PR identifies whether evidence comes from a MVC slice or a real database-backed flow. An unavailable JDK, wrapper download problem or failing suite stays explicit. Your Linear integration comments the returned PR link using its own account access; this page describes the deliverable and does not invent a completed PetClinic run or a pre-existing issue.
Run it on every Linear controller ticket labeled agent
Your webhook handler filters the approved Linear label and maps the ticket to the Spring Boot repository. It reads the current description and comments through its authorized Linear connection and appends that snapshot to the session input. The quickstart currently says built-in Linear sign-ins cannot yet be named on sessions, so the example body relies on the caller to supply tracker context rather than implying hidden account access.
Start one session for the accepted issue revision and deduplicate repeated webhook deliveries. Read the resulting PR URL from the session or process the API key's completion webhook, then post the link back through your integration. Keep issue closure, production deployment and merging outside this label-driven implementation request. A ticket with unclear date or search semantics should return its missing requirements before code changes begin.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
A Spring MVC change often needs a clean JDK environment, Maven dependencies and isolated database state before its actual patch can be judged. Rush gives the task a cloud sandbox for those commands, keeping wrapper downloads and test data away from an engineer's active local application. The ticket's expected user interaction stays attached to the returned change.
Independent owner and visit tickets can run separately within the API key's concurrency allowance. The transcript retains Maven commands and their output, letting the reviewer inspect which test class ran and whether the broader suite succeeded. That record makes a meaningful distinction between a controller assertion and a demonstrated persistence change. The PR supplies the proposed result; the evidence shows how far verification reached.
Frequently asked questions
Will the agent replace existing MVC controllers with REST endpoints?
The task extends the current owner or visit flow unless the issue explicitly asks for a different interface. It preserves form views and redirects where they are part of the accepted behavior. A parallel endpoint would enlarge the scope and require separate justification.
Does MockMvc prove that the visit was saved?
MockMvc verifies the request and MVC response, but the existing visit test supplies a mocked repository. A persistence change needs additional coverage against a real isolated database. The PR should label those forms of evidence separately.
How are date-sensitive booking rules handled?
The agent reads the controller's current comparison with LocalDate.now() and reproduces the ticket's specified boundary. It checks invalid submissions as well as the accepted case. Unstated timezone or booking-policy changes should not be invented.
Who comments the result on the Linear issue?
The caller's Linear integration posts the returned PR URL. The request itself contains no connection grant. This keeps issue reads and comments explicit while the agent works from the supplied ticket snapshot.