Maintaining
Maintaining keeps a codebase healthy after it ships. It sweeps the linked repository for dependency and vulnerability problems, records what it finds, and can turn a finding into a pull request.
Vitality
Section titled “Vitality”The top of the page is a rollup: how many findings are open, how they break down by severity, when the last sweep ran and whether it succeeded.
It answers one question, which is the right one to lead with: is this codebase healthy, and when did we last actually check?
The second half matters as much as the first. A clean board from a sweep that last ran months ago is not evidence of anything.
Sweeps run themselves
Section titled “Sweeps run themselves”A sweep clones the repository and scans it. You do not have to ask for one.
Taiga sweeps a project when either of two things is true:
- Your code changed. A push to the linked repository marks the project as due, so a sweep follows the work rather than a calendar.
- Enough time has passed. Every project is swept periodically even when nothing changed, because the other half of a finding is the advisory database, and that moves on its own. A dependency you have not touched can become a vulnerability overnight.
Projects are enrolled automatically once they have a linked repository. There is nothing to switch on.
Every sweep is kept, so the record shows both what is wrong now and when it was last checked.
Findings
Section titled “Findings”Findings are grouped by package rather than listed one per line. One outdated dependency causing six problems is one thing to decide about, not six.
Each finding has a severity, and you can filter to one.
Three things to do with a finding:
| Action | When |
|---|---|
| Resolve | It is dealt with. |
| Ignore | It is not applicable to you, or you accept it. Ignored findings are kept and reviewable, not deleted. |
| Remediate | You want the fix built. |
Acting on a finding is member-level, not an administrator task. Whoever notices the problem can deal with it.
The most urgent findings are fixed without being asked
Section titled “The most urgent findings are fixed without being asked”Taiga does not wait for you on the findings that matter most. A finding in the top severity bands is remediated automatically: an agent produces the fix on a branch and opens a pull request.
This is bounded on purpose, so it cannot flood you or make a decision you would not have made:
- Only the most urgent severities. Lower-severity findings wait for you to ask.
- Only minor and patch upgrades. A major version bump is a breaking change and stays yours to decide.
- A cap on how many are opened per project per day, and a cooldown before the same package is attempted again.
Everything else on the board is remediated when you choose to.
Remediation is always a normal build
Section titled “Remediation is always a normal build”Automatic or requested, a remediation is a build like any other. An agent produces the fix on a branch and opens a pull request, and you review and merge it.
There is no path where a dependency fix goes straight in. A patch that updates a dependency is a change to your code, and it gets the same review as one you asked for. Automatic remediation decides what to propose, never what to merge.
That also means everything in when an agent gets it wrong applies here: the run can break, stop on an ambiguity, or produce a fix you disagree with.
What this is not
Section titled “What this is not”It is not a gate. A sweep follows a push rather than blocking it, so a vulnerable dependency can reach your default branch and be found shortly afterward. If you need something to fail the commit, that belongs in your own pipeline.
It also reads the repository, not the running system. It can tell you a dependency is vulnerable; it cannot tell you whether the vulnerable path is reachable in production.