What the agent does
The agent converts a small Linear issue into a Rust change with explicit acceptance criteria. In lldap/lldap, Cargo.toml:2–9 lists the workspace members and sets default-members = ["server"]. That detail changes the verification plan: cargo test at the root does not mean every workspace member was tested. rust-toolchain.toml:2 pins channel = "1.91.0", matching Cargo.toml:19's rust-version. The agent reads both files before diagnosing a compiler error or deciding which package checks establish the ticket.
It traces transport code into the crates that own protocol behavior. server/src/ldap_server.rs:10 imports lldap_ldap::{LdapHandler, LdapInfo}, and lines 85–90 construct a LdapHandler around AccessControlledBackendHandler. The implementation boundary is therefore not just the server file named in a traceback. crates/ldap/src/handler.rs:59–64 stores user_info and the access-controlled backend; lines 114–120 handle an unbound caller with InsufficentAccessRights. A ticket must preserve those caller distinctions while changing the requested LDAP response.
For GraphQL work, server/src/graphql_server.rs:14–15 imports the context and schema from lldap_graphql_server. crates/graphql-server/src/api.rs:11–14 defines a Context with handler and validation_result, and lines 35–56 choose admin, readonly, writable or readable handlers through that validation. The agent follows the affected query or mutation rather than adding an authorization shortcut at the HTTP boundary. Tests should exercise the real permission path with controlled data, including a denied identity when the ticket touches directory visibility or modification.
The agent makes a focused change and runs cargo test, then explicitly tests the affected crates with cargo test -p lldap_ldap -p lldap_graphql_server when both are implicated. Those package names come from crates/ldap/Cargo.toml:2 and crates/graphql-server/Cargo.toml:2. A broader workspace command belongs in the report only if it actually ran. The resulting PR links the Linear issue and states the tested scope. Your integration supplies the ticket and comments through its own Linear connection, then posts the returned PR URL; the displayed body grants no tracker tools.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Implement the scoped Linear issue whose URL, description, comments and acceptance criteria the caller appends below in this Rust directory service. Require the issue context before editing. Read Cargo.toml, rust-toolchain.toml, the LDAP and GraphQL server adapters, and their owning workspace crates. Preserve bound/unbound and role-based access behavior. Add regression tests that exercise the real affected protocol and permission path with controlled data. Run cargo test, then explicitly run tests for each changed crate, including cargo test -p lldap_ldap -p lldap_graphql_server if both are affected; do not present default-member testing as whole-workspace coverage. Report exact commands and failures. Open a pull request linking the Linear issue and return its URL for the caller to comment there. Do not merge, deploy or contact a production directory.",
"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 result is a PR connecting the ticket's directory behavior to its implementation and regression coverage. A protocol change shows the input operation, expected response and caller permissions. A GraphQL change explains the resolver and access-controlled backend path it affects. The patch avoids turning a small acceptance-criteria change into a reorganization of the workspace or a new directory access layer.
The reviewer checks the command list against the changed crates. A passing root cargo test is useful server evidence, but the declared default-members setting prevents it from proving all LDAP and GraphQL crate tests ran. Review also includes denied callers, unchanged transport behavior and any schema implications. Compiler, native dependency or test setup failures appear in the verification summary with their actual output. The session returns the PR link for caller-side issue commenting, without asserting any public LLDAP change has been made.
Run it on every Linear directory ticket labeled agent
Have your Linear webhook integration select approved directory-service tickets and retrieve their current descriptions and comments through its own authorized connection. Append the bounded context and repository mapping to input before calling POST /o/{org}/sessions. The quickstart notes that a built-in Linear sign-in cannot yet be named on a session, so this example explicitly uses caller-supplied tracker context.
Deduplicate notifications for the same issue revision and keep permission changes behind maintainer triage. When a run returns a PR, your handler comments the URL on the ticket using its existing authorization. If the result instead describes missing acceptance criteria or failed validation, surface that result without moving the issue to done. Human review decides whether the directory behavior is safe to merge.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
LDAP and GraphQL changes benefit from an isolated checkout, pinned Rust tools and controlled directory data. Rush gives the agent a cloud sandbox for that work, keeping temporary users, protocol fixtures and build dependencies away from an engineer's active directory setup. The task can test refused identities without connecting to a production identity service.
Independent tickets can run separately within the key's concurrency allowance, each with its own build output and transcript. Reviewers can inspect whether the agent tested the server default member, the LDAP crate, the GraphQL crate or an actual workspace-wide command. That command-level proof prevents a familiar Rust workspace mistake from becoming a misleading 'all tests pass' summary.
Frequently asked questions
Does cargo test cover every LLDAP crate?
The inspected root manifest selects server as its default member. The agent must explicitly test affected non-default crates or run an appropriate workspace-wide command. The PR states which scope actually ran.
Can it change LDAP and GraphQL for the same ticket?
Yes, when the acceptance criteria require the behavior through both interfaces. The agent traces their shared access-controlled backend before editing. A single-interface issue should not expand into unrelated protocol work.
Will it test against my organization's directory?
The request excludes production directory access. Use controlled fixtures and disposable state for the regression. If a production-only condition cannot be reproduced safely, the agent records that verification limit.
Can the agent comment on Linear from this request?
This body grants no Linear tools, so the caller handles that comment. It reads the session result and posts the returned PR URL through its authorized integration. Ticket text in input is context, not a credential grant.