Most of the SonarQube backlog is refactors too diffuse for an anchored patch,
so without this the majority of what static analysis knows never reaches a
maintainer. Deduped on the rule like the pull requests, so one root cause
yields one issue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The sweep covered four projects because only four had a write allowlist.
ananke (Go, cmd/ and internal/), pegasus (Go backend, TS frontend) and
atlasbot (Python) all have SonarQube projects and mapped repositories; they
were excluded only for want of prefixes and suffixes, which are now set from
each repository's actual layout.
The per-sweep ceiling rises to seven, one per project. With rule-level dedupe
a project stops producing proposals once every rule it has is already under
review, so this is a ceiling rather than a rate - the backlog cannot become a
queue nobody drains.
The Hermes deployment annotation still advertised gpt-5.6-terra as primary.
The config has had claude-opus-5 as default and primary for some time, so the
annotation was telling operators the wrong thing about which model made a
decision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Only one pull request appeared because the sweep was scoped to one project at
one proposal per hour - a throttle I set deliberately while nothing had ever
run, not a limit of the mechanism. It has now run, so it widens to every
project whose job also has a write allowlist: ariadne, metis, soteria and
bstein-dev-home. The rest are left out because without allowed prefixes
nothing is patchable, and a sweep would spend a SonarQube call to discover it
has nowhere to write.
Still one proposal per project per hour. The backlog is 139 findings on
Ariadne alone; the constraint that matters is how many pull requests a person
will actually read, not how many the mechanism could open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The sweep's token was injected from kv/data/atlas/quality/sonarqube-oidc,
which the maintenance role cannot read. I granted that path on the live policy
and verified the read, but the grant was reverted by whatever manages Vault
policy, and the next rollout wedged: vault-agent-init retries a 403 forever, so
the pod never initializes and the Deployment cannot roll. The old replica kept
serving, which is the only reason this was not an outage.
A template block that depends on a grant outside this repository is the actual
defect. The token now lives beside Ariadne's other credentials in
kv/data/atlas/maintenance/ariadne-db - a path its role has always been able to
read - so no policy change is needed and nothing outside this repo can revoke
it. Existing keys at that path were merged, not replaced.
Guarded with an if, so a deployment whose secret predates the key renders an
empty value and starts normally instead of blocking on a missing field. The
sweep then reports an empty token and skips, which is the right failure: no
sweep is much better than no Ariadne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Static analysis findings never fail a build, so nothing has ever pulled them
into triage. There are 139 open on Ariadne alone, each already naming its
file, line and rule - better-located evidence than the console text the
code-repair flow usually mines.
Scoped deliberately narrow to start: one project, one proposal per hourly
sweep, and only findings SonarQube itself estimates at 20 minutes or less.
Effort is the filter rather than severity because it is the closest proxy for
the single anchored change the patch validator can actually check. The
64-open-proposal ceiling still applies on top, so the queue cannot grow while
nobody is draining it.
Hotspots are not in the type list and cannot be: SonarQube models them as
needing human review, this instance's quality gate fails on exactly that
condition, and an automation that resolved them would be marking them reviewed
without review.
The token comes from Vault. Ariadne's maintenance role was granted read on
kv/data/atlas/quality/sonarqube-oidc, which it did not previously have.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A build whose agent never started is a distinct failure from one that lost a
connection mid-run, and a plain retry queues behind the same stuck pods. The
remediation clears pods that have already succeeded or failed - Ariadne's
existing scheduled cleanup - and only then rebuilds.
Mapping jenkins_agent_provisioning_failure to it keeps the one-classification-
one-action rule: a diagnosis asking for this action under any other
classification is still refused before anything runs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
