What the agent does
The agent reads the expanded Rails route set as well as the route file. In rubygems/rubygems.org, config/routes.rb:12-26 nests versioned API namespaces, and lines 79-93 expose rubygems resources at the path gems, add a yank operation and nest owner and trusted-publisher routes. Format constraints matter: other declarations require JSON or YAML, while dependencies default to Marshal. The agent uses bin/rails routes when the app can boot, preserving method, path, format and controller action instead of guessing expansion from resource names.
Access requirements come from the callback chain and policies. app/controllers/api/v1/rubygems_controller.rb:5-9 authenticates most actions but exempts show and reverse_dependencies, adds user-key requirements and requires OTP verification for creation. In app/controllers/api/base_controller.rb:52-61, authenticate_with_api_key reads the Authorization header, looks up an unexpired hashed key and checks account state. The agent follows inherited callbacks, action-specific exceptions, scope checks and Pundit policy calls before describing a route as protected.
The inventory follows each action's accepted parameters and body type. rubygems_controller.rb:38 checks push scope, and lines 41-50 distinguish uploaded multipart gem data from the raw request body. A gem push cannot be described as a generic JSON POST. config/routes.rb:77 also declares an OPTIONS request for gem details; preflight success must not be confused with authorization to publish. Deprecated endpoints and compact-index paths receive their own sections so a report can explain the whole HTTP surface without treating every route as a versioned JSON API.
Before verification, the agent checks .ruby-version, Gemfile, Gemfile.lock and CONTRIBUTING.md. This example declares Rails ~> 8.1.3 in Gemfile:7, and the contribution guide names PostgreSQL, Memcached and OpenSearch as dependencies. It documents ./bin/setup and bin/rails s; Docker Compose starts supporting services rather than the Rails application itself. The agent prepares a disposable local setup, confirms database targets and probes anonymous requests without reaching the public gem host. Publication, yanking and webhook operations remain unverified unless their data and side effects are isolated.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Produce endpoints.md for the attached Rails repository. Expand the route set and inventory method/path/format, controller action and file:line, accepted parameters and body types, inherited before_action requirements, API-key scopes, roles, OTP and policy checks. Distinguish API namespaces, public metadata, preflight, deprecated routes and other HTTP surfaces. Boot only an isolated development instance with sandbox-owned services and data, then call each safely exercisable route without credentials. Record original status, redirects and content type; flag protected operations that succeed, not intended public reads. Mark unsafe or blocked probes unverified. Do not contact production, publish or yank real packages, send external webhooks, edit source, push or open a PR.",
"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
endpoints.md contains an expanded route table plus separate details for authentication, API-key scope, OTP and policy requirements. Each row cites its registration and the callback or action supporting its classification. The observed-response column records the exact local request shape and leaves unexecuted operations blank with an explanation. The report includes format constraints and raw-body operations, preventing a JSON-only client inventory from quietly dropping package publishing behavior.
A reviewer checks that callback exceptions apply to the right actions, that unauthenticated gem metadata remains classified as intentionally public and that a successful OPTIONS response says nothing about push permission. Mutation evidence must come from disposable local data, never the live package registry. The report is a file artifact returned by the session; it contains findings and reproduction notes without changing application code or opening an upstream pull request.
Run it on every Rails API change
Use your repository webhook or release script to send one request for the branch under review. Include changes to controllers, concerns and policies in the trigger criteria, because access can change while config/routes.rb stays untouched. Set an Idempotency-Key for the candidate revision and attach the repository branch through resources.
After the session finishes, your receiver can collect the report from the session read or react to the configured completion webhook. Compare authentication exceptions, formats and accepted parameters with the last inventory. Treat a new finding as review input; a scheduled report does not authorize package operations or policy edits.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
A Rails inventory needs the expanded router and the inherited controller behavior together. Rush gives the agent a sandbox for that investigation and a separate place to prepare supporting services. It avoids turning a developer's existing database, package storage or mail settings into the subject of a broad anonymous probe.
The trajectory preserves the route command, startup output and local requests behind the table. That lets a maintainer distinguish a verified response from a source-derived expectation or a service that never booted. Independent inventory requests can cover several Rails services within the API key's concurrency limit without mixing their database targets or report evidence.
Frequently asked questions
Can it trace authentication inherited from a base controller?
Yes, the task follows controller inheritance, concerns and callback exceptions. A base authentication method alone does not mean every action invokes it. The report cites the callback registration and the implementation that together determine access.
Will public gem metadata appear as an auth failure?
Public reads belong in the inventory but do not become vulnerabilities merely because they return success anonymously. The example explicitly exempts gem details and reverse dependencies from its authentication callback. The agent compares intent and response before flagging exposure.
What about routes outside the API namespace?
The report includes a separate section for other HTTP surfaces and identifies compact-index and deprecated endpoints. Format-constrained HTML routes stay distinct from JSON APIs. That keeps coverage broad without flattening different protocols into one misleading table.
Will it push a gem to test authentication?
Never to a public or production registry in this task. A local publishing probe needs disposable storage, accounts and isolated downstream behavior. Otherwise the route remains documented with its runtime check explicitly unverified.