What the agent does
The agent starts with the constraints that define a compatible upgrade. In an app like symfony/demo, composer.json requires PHP >=8.4, sets config.platform.php to 8.4.1, and gives Symfony Flex an extra.symfony.require value of 8.1.*. Those settings matter more than a headline about the newest Symfony release. The agent reads composer.lock alongside the manifest and records the installed baseline before asking Composer to resolve anything. It treats a change to the supported PHP or Symfony series as a separate decision.
It prepares the PHP environment from .github/workflows/tests.yaml, which installs Composer v2 and the intl, mbstring, pdo_sqlite and zip extensions. Then it installs the existing dependencies and runs vendor/bin/phpunit before updating them. phpunit.dist.xml sets APP_ENV to test and makes deprecations, notices and warnings failures. Its Doctrine test extension rolls database changes back between cases. The agent preserves those checks, so an upgrade cannot appear safe merely because the test configuration became more permissive.
Next it runs composer update within the existing constraints and examines the resulting dependency changes. The manifest's post-update-cmd invokes auto-scripts for cache clearing, asset installation, import maps and Sass, so successful dependency resolution is not the whole check. The agent reviews symfony.lock and any Flex-managed configuration changes alongside composer.lock. It tests smaller dependency groups when the combined update fails, retaining compatible changes and recording the specific package, command and failure behind each deferred group.
Finally it reruns vendor/bin/phpunit on the proposed final dependency set. Existing coverage in tests/Controller/BlogControllerTest.php includes the blog index, RSS output and posting a comment, while tests/Form/DataTransformer/TagArrayToStringTransformerTest.php identifies another behavior boundary worth preserving. The task asks the agent to follow the repository's existing coverage rather than invent test results. A failure before the update, an install failure and a new regression after the update are reported separately.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade the Symfony and Composer dependencies in this repository to the latest versions compatible with its existing PHP and Symfony constraints. Read composer.json, composer.lock, symfony.lock and the existing CI setup first. Establish a baseline with vendor/bin/phpunit, run composer update with Symfony Flex, inspect auto-script and configuration changes, and rerun the suite. Leave out dependency groups that introduce failures and explain the failing command and reason. Do not weaken tests or widen the supported PHP or Symfony series without approval. Open a pull request with one line per package bump, final check results and a list of deferred upgrades.",
"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 the updated Composer lockfile and any necessary manifest or Flex configuration edits. Its summary separates direct dependencies from transitive movement and lists the old and proposed versions for each bump. Deferred upgrades have a reason tied to observed output, such as a solver conflict, an auto-script failure or a failing PHPUnit case. An unchanged package is not described as upgraded.
Before merging, a reviewer checks that the PHP platform setting and Symfony series still match the deployment environment. They inspect unexpected configuration changes and confirm that PHPUnit ran against the final lockfile, not an earlier intermediate resolution. The session answer and transcript provide the commands and their output; a passing unit suite does not claim that production data migrations or browser behavior have been verified.
Run it on every weekly dependency review
A weekly job on your server can send this body to POST https://api.prix.dev/o/{org}/sessions using an API key. Install the Rush GitHub App on your repository first, then replace the example resource URL. Keep the schedule outside the request body. Read the resulting session to collect its answer and pull request, or configure the key's completion webhook to notify your dependency-review workflow.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
Composer updates can change the local vendor directory, regenerate cached files and run asset commands before a developer has reviewed the diff. Rush gives this work its own cloud sandbox. The agent can compare the original and proposed dependency sets without changing the PHP installation or working tree you are using for another task.
The useful output is a dependency decision with evidence. Rush's transcript connects tool calls to their results, so a reviewer can inspect why an upgrade was left out instead of receiving a lockfile with unexplained omissions. Separate apps can have separate sessions, allowing their different PHP constraints and test failures to be investigated without sharing one vendor directory.
Frequently asked questions
Will it move my app to a new Symfony major version?
This request keeps the existing compatibility constraints. For the inspected demo, composer.json explicitly names the Symfony series through extra.symfony.require. A major-version migration needs a different instruction and review of its application changes; the agent should not silently turn a weekly dependency update into that migration.
Does it update Symfony Flex configuration too?
The agent inspects Flex-related changes, including symfony.lock and configuration files changed by the update. It keeps necessary edits visible in the pull request rather than accepting generated changes without review. Existing cache and asset auto-scripts remain part of the verification.
What happens when the existing test suite already fails?
The baseline failure is reported before the upgrade is judged. The agent should not remove an assertion or relax the deprecation policy to produce a passing result. If it cannot establish whether the proposed versions are safe, the answer explains that limit instead of labeling the update verified.
Can it keep some updates when another package breaks?
Yes, the prompt asks for dependency groups that can be resolved and tested together. Composer may require related packages to move as a group, so excluding one package is not always independent. The final combined lockfile must pass the checks again, and the pull request explains which groups remain deferred.