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>
Two bugs, both visible in a single demo transcript.
The stage memory was one shared set cleared whenever the incident changed. A
ten-minute window routinely holds two incidents - the build just pushed and
the one before it - so they wiped each other's progress and every stage
reprinted on every poll, forever. Memory is now per incident, and the monitor
follows one incident at a time: --incident pins an exact id, --filter matches
a substring, and otherwise the newest wins, which is what someone who just
triggered a build wants.
Worse: the diagnosis panel read the newest diagnosis in the whole table, not
the one for the incident on screen. During a code-demo run it displayed
ananke/249 - a different service, a different failure - directly beneath the
heading naming this incident. Showing an unrelated answer is worse than
showing nothing, because nothing about it looks wrong.
It is now scoped to the incident and reads both event types, since the code
path records a code_proposal rather than a diagnosis - which is why nothing
matched and the fallback took over. There is no fallback any more: an incident
with no recorded run says so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
