What the agent does
The agent identifies the actual application and storage before starting a database. honojs/examples contains independent projects rather than one API with a shared backend. Its blog example uses Cloudflare KV: blog/src/model.ts accepts a KVNamespace, while blog/package.json supplies a Vitest test script and Cloudflare Workers test pool. That is a useful concrete Hono integration example, but it is not a PostgreSQL application. For your SQL-backed API, the agent instead starts the database and runs the migrations your repository declares; it never invents a database dependency for an app that uses KV.
It reads the outer application as well as the route module. In the blog, blog/src/api.ts defines post CRUD operations, but blog/src/index.ts mounts them under /api, installs Basic authentication for non-GET post requests and defines a JSON not-found response. Existing blog/src/api.test.ts imports the inner api module directly. That exercises route and storage behavior, but it bypasses middleware defined only on the outer app. New integration coverage should enter through the exported application to test the composed URLs and authentication path.
The agent builds cases from the handlers rather than assuming conventional responses. Creating a post without the required title or body returns 422. Reading an absent post returns 404, while updating or deleting an absent post returns an empty 204 response. blog/src/model.ts also distinguishes an invalid update from a missing record. Tests check status, body and persisted state through the real storage binding. They do not stub model functions or replace the request handler with a test implementation that merely reproduces its expected answers.
It follows blog/vitest.config.ts, including the Wrangler configuration path and isolatedStorage: false setting, and runs npm test from blog. The new cases establish their own records and cleanup rather than depending on a previous case's generated post ID. For a network-listening API, the task also starts its server and exercises HTTP against it; an in-runtime Workers request is labeled as such. The report states whether the checks used SQL, a local KV binding or another declared backend, with no claim that local Workers storage proves production KV behavior.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Write integration tests for every endpoint in the selected Hono API. Identify the app entry point, mounted routes, existing runner and actual storage backend before editing. For a SQL-backed app, start a disposable real database in the sandbox, run its migrations and start the API; do not replace the database with mocks. If the repository uses Workers KV instead, exercise its real local runtime binding and state that this is KV coverage, not SQL coverage. Test the outer app including auth middleware, successful requests, implemented validation errors, missing auth and not-found behavior. Reuse the runner, keep cases independent and do not change production behavior to fit assumed status codes. Run the suite and open a pull request with exact commands, results and remaining boundaries.",
"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 contains an integration suite and only the setup needed to run it with the project's actual backend. Its endpoint matrix names the mounted URL, method, authorization requirement and response cases. A SQL application includes database startup and migration instructions; a Workers application identifies its runtime bindings. The summary distinguishes an HTTP server test from an in-runtime app request so reviewers know which execution boundary was exercised.
Reviewers check that the tests import or start the outer app and therefore include middleware. They inspect whether test-created records survive the intended operations and whether cleanup makes failures reproducible in isolation. In the blog example, missing-record updates and deletes should keep their existing 204 contract rather than acquire invented 404 assertions. The session's tool output records what ran, and any unavailable database or runtime dependency appears as a blocked check.
Run it on every Hono route change
Your webhook receiver can dispatch this request when a PR changes routing, middleware or the storage model. Replace the repository resource with your accessible app or open PR URL, and identify the relevant subproject in input if the repository contains several examples. Use the session read or a completion webhook to collect the result. The dispatch policy belongs to your integration, not an extra field in the session body.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Hono applications can look similar at the handler level while requiring different runtimes underneath. Rush gives the agent a separate sandbox to prepare the actual database or Workers test environment without reconfiguring the developer's current setup. It can investigate a middleware gap and run storage-backed requests alongside the code changes rather than delivering unexecuted test text.
The captured execution record also makes claims about integration coverage inspectable. Reviewers can distinguish a request against the exported app from an isolated inner router, and a real local storage binding from a mocked model. Separate runs keep different APIs' database state and runtime configuration apart while returning a PR and a concrete account of what remains unproved.
Frequently asked questions
Does the official example use a real SQL database?
The inspected blog example uses Cloudflare KV, not SQL. Its existing tests run through the Workers Vitest pool with an environment binding. The agent should report that accurately and only start PostgreSQL or another SQL engine when your application actually declares it.
Why test the outer app instead of the route module?
Middleware and URL prefixes can live outside the module containing the endpoint handlers. The blog mounts its API and configures write authentication in src/index.ts, while its existing tests import src/api.ts. Entering through the outer app covers that composition instead of bypassing it.
Will every missing record return 404 in the tests?
The assertions follow the implemented contract and your stated requirements. In the inspected blog, a missing read returns 404, but a missing update or delete returns 204. If that behavior should change, the agent reports it as a product decision rather than silently changing production routes during test work.
Can it avoid mocking the database and Hono handlers?
Yes, that is the purpose of this task. It uses the actual application and its disposable database or local runtime storage, then verifies persisted effects through requests. If the backend cannot be prepared, the result names the missing dependency instead of substituting a mock and calling it an integration pass.