What the agent does
The agent reads the changed conversations API behavior and locates its current tests before proposing new ones. In chatwoot/chatwoot, app/controllers/api/v1/accounts/conversations_controller.rb includes listing, creating, updating and deleting conversations as well as status and transcript actions. The matching file is spec/controllers/api/v1/accounts/conversations_controller_spec.rb. Despite its directory name, that file declares type: :request, so the agent follows the actual test style rather than adding isolated controller examples based on the folder name.
Existing examples show how account and inbox membership affect requests. They create accounts, users, conversations and messages with factories, authenticate with create_new_auth_token, and inspect both response status and payload. The agent compares those assertions with the PR diff to identify a distinct uncovered case. A changed assignment rule might need a disallowed target, while a changed conversation response might need an assertion on its JSON fields. Repeating the existing unauthenticated request example does not cover a new permission branch.
It reproduces the backend test environment from the repository. .ruby-version and Gemfile specify Ruby 3.4.4, and Gemfile names Rails 7.2.3.1. The backend job in .github/workflows/run_foss_spec.yml uses a pgvector PostgreSQL service and Redis, installs dependencies, creates the database and loads the schema before running RSpec. The agent prepares disposable equivalents for the selected application edition. It keeps that choice explicit rather than assuming Community and enterprise-only code share an identical test surface.
The agent writes narrowly scoped request examples, runs bundle exec rspec spec/controllers/api/v1/accounts/conversations_controller_spec.rb, then runs bundle exec rspec for the wider suite when the environment supports it. Tests should exercise the real request, authorization and database behavior rather than stubbing the controller method under examination. Application code stays unchanged. A failing assertion that reveals a defect in the PR is reported to its author. The agent does not rewrite that assertion to make the defective implementation appear correct.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "This pull request changes the conversations API. Read its diff, the existing Rails request specs and test environment. Find new or changed behavior without coverage and add focused RSpec examples beside the existing specs, using the real request and database paths. Do not change application code or replace the behavior under test with stubs. Prepare disposable PostgreSQL and Redis services as required. Run the affected spec file and bundle exec rspec, reporting focused and full-suite results separately. Push passing test additions to the authorized pull request branch and comment with what each test covers. Report implementation defects and blocked checks honestly.",
"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 deliverable is a test-only update on the original PR branch, with examples tied to its conversation API changes. The summary states whether the tests exercise successful requests, refusal cases, payload changes or persisted state. It records which application edition and services were used, names the focused RSpec command, and separates that result from the wider suite. A skipped or blocked full run is not described as a complete pass.
Reviewers check that the added examples create the right account and inbox relationships, use the intended user's credentials and assert the changed behavior rather than incidental factory values. They also inspect for accidental production edits or unrelated frontend changes. The session result links the work back to the pull request, and the transcript preserves setup and test output for investigation if CI disagrees.
Run it on every Rails pull request
A webhook handler you control can dispatch one request when a GitHub pull request opens. Supply the PR URL as the repository resource and identify its intended behavior in the prompt; the API can clone an accessible open PR branch. Validate the event and authorize that branch before permitting test commits. Filter the agent's own updates so adding a spec does not create an endless sequence of test-writing sessions.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Running the conversations suite can involve PostgreSQL extensions, Redis, Ruby gems and application setup beyond the code visible in the diff. Rush places that environment in a separate cloud sandbox. An agent can reproduce the request spec without taking over the developer's running Rails server or loading test records into their current database.
The same API call can serve each eligible PR without forcing every author to repeat the setup locally. Each run retains its own command output and answer, allowing reviewers to distinguish a missing database extension from a genuine authorization regression. That evidence matters more than a coverage percentage that does not identify what changed.
Frequently asked questions
Will it add controller specs or request specs?
It follows the repository's declared spec type and existing patterns. In the inspected app, the conversations file lives under spec/controllers but declares type: :request. The agent should exercise requests through that setup instead of choosing a different style solely because of the path.
Does it understand account and inbox permissions?
The task requires reading the authorization path and existing membership setup for each changed behavior. New cases should distinguish the acting user, account and inbox instead of authenticating every request as an unrestricted user. The reviewer still checks that the tested rule matches the PR's intended permission contract.
Will it edit Rails code to fix a failure it finds?
No, this is a test-only task. A failure caused by the proposed implementation becomes a reported defect, with the request and output that expose it. The PR author decides whether to fix the code or clarify the intended behavior.
What if the full RSpec suite cannot finish?
The report names the focused specs that ran and the wider checks that did not. It includes the environment failure or other limit rather than treating a targeted pass as a full-suite result. You can send a follow-up to the session after its turn finishes if more setup or a narrower scope is needed.