The cassandra pipelineJob had no trigger, so Gitea's notifyCommit
webhook found no matching job and pushes only built when started
manually. Poll every 5 minutes like lesavka/typhon so pushes build
within one poll cycle and the webhook race disappears.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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>
