Maintenance agents

Let three small checks look after a project while nobody is looking, covering old dependencies, security advisories and a command of your own. Each one opens a draft ticket for what it finds.

Maintenance agents look after a project while nobody is looking. On a schedule, or when you press Run Now, each agent checks one thing about the project and opens a ticket for what it finds. The ticket is a draft you approve. Then the normal pipeline fixes it: the same plan, implement, review and checks as any other ticket.

The agents themselves are plain jobs. They make no model call, so a run costs nothing. The tickets they open cost money when they run, and they count against your budgets like any ticket. Maintenance works on every plan.

The three agents

All of them are off until you switch them on, on the Maintenance page of the project (in the project's side menu).

Agent	What it checks	What it opens
Outdated dependencies	Packages with a newer release (npm and pip)	One ticket for all patch and minor updates of an ecosystem, plus one ticket per major update
Security advisories	Known security advisories that affect your dependencies	One ticket per advisory
Custom checks	A command you choose, such as a lint or audit command	One ticket while the command fails

Outdated dependencies

It looks for package.json (npm) and for requirements*.txt, pyproject.toml or setup.py (pip) in the repository's top folder and one folder below it.

The patch and minor updates of one ecosystem go in a single ticket, with the packages listed.
Each major update gets its own ticket, because a major version can break your code.
A run opens at most 3 tickets by default. You can change that.
While one of an ecosystem's maintenance tickets is not finished (shipped, failed or cancelled), the agent opens nothing new for that ecosystem.

For pip, the agent keeps only the packages your project declares. A project that declares no packages the agent can read, for example one with only a setup.py, is skipped, and the run's notes say so.

Security advisories

It runs npm audit and, when pip-audit is installed, a pip-audit check on each of the project's requirements*.txt files. When pip-audit is not installed, the run says so in its notes and carries on. That is not an error.

Each advisory at or above your minimum severity (high by default) becomes one ticket, with its package, its identifier, its severity and what fixes it. The most serious come first.
A run opens at most 5 tickets by default.
If you cancel an advisory's ticket, it is not opened again. Cancelling is how you say "this does not apply to us".

The advisory databases are reached through the same allowed hosts as your build and test commands. If a database is not on the list, the run reports that it could not run.

Custom checks

A custom check is a name and one command, for example npm run lint. The command runs in the repository, inside the same sandbox as your other check commands. When it exits with an error, or runs longer than its time limit, a ticket opens with the exit code and the end of its output.

The command runs as a single program with arguments, not through a shell, so pipes, &&, ; and redirects do not work. The settings refuse a command that uses them. Put several steps in a script in your repository and run the script.
A check opens one ticket while it keeps failing. While that ticket is open, nothing more opens.
If a program is not installed on the machine, the run fails with that message and no ticket opens.
You can set up to 5 checks.

When a finding was filed before

A finding that already has a ticket does not open another one, and the run says so in its notes.

The earlier ticket is	A finding that comes back
Open	Is covered by it. Nothing opens.
Cancelled	Is never opened again.
Failed	Is held back for four schedule intervals, then filed again.
Shipped	Is held back for one schedule interval, then filed again as a new ticket.

A shipped fix that did not hold is therefore reopened, not ignored for good.

Approval

Each agent has its own approval setting:

Manual (the default): the tickets are drafts, and nothing runs until you move them to Ready.
Auto: tickets go straight to Ready and Autopilot picks them up. Use this only where you trust the agent's tickets to be fixed without a look first.

Every ticket carries the label maintenance and the agent's kind (dependencies, advisories or custom).

When a run happens

On a schedule. Daily or weekly per agent, or off. The schedule needs a running worker, which the install starts for you.
By hand. Press Run Now on the Maintenance page. An agent has at most one run queued or running per project.
It never gets in the way of a ticket. If a ticket is running in the project, the run is skipped, says so, and tries again 15 minutes later. It never stops a ticket.
Stop. Stop ends a running command at once, with everything it started.
Budget and license. A run is skipped while the project's budget is paused, because the tickets it would open could not run anyway. Like every start of work, runs need a license that allows new work.

The page shows each agent with its last run, when it is due next and how many maintenance tickets are still open.

What the agents can see

A run fetches your repository the way a ticket does and runs its commands without any secret: the same restricted environment, the same sandbox and the same allowed hosts as your check commands.

What a command prints is stored in the ticket it opens, with secret values masked. A custom check's output goes only in its ticket.

From a terminal

reqursor-dev maintenance status --project <id>
reqursor-dev maintenance run dependencies --project <id> --wait
reqursor-dev maintenance runs --project <id>

The agents are named dependencies, advisories and custom:<name>. See Command line for how to run a command on your install.

Branch strategy & AutopilotHow Autopilot picks up approved tickets.
NotificationsGet told when something needs your attention.