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>
Both demos went quiet for up to a minute between the build turning red and
the monitor reacting, because Ariadne's tick is on cron. The scripts now run
that tick immediately over the pod's own loopback - nothing exposed outside
the cluster - and print what it saw, so the pause becomes a visible step
rather than dead air.
Falls back to silence rather than failure: if the request does not land the
scheduler still picks the build up within the minute, which is exactly the
old behaviour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wait_for_build slept before its first poll, so a build that had already
finished still bought a full interval of silence. On stage that reads as the
script having missed the result - the build goes red in Jenkins and the
terminal sits there. Polling first and sleeping after removes it entirely: a
finished build now returns in under a second, measured.
The interval drops from ten seconds to three for the same reason. The wait is
dead air in front of an audience and a Jenkins status read is cheap. The
budget is now expressed in seconds rather than poll counts, so shortening the
interval does not silently shorten the timeout.
This is only the script's own latency. Ariadne's autotriage cron is * * * * *,
so an incident still takes up to a minute to appear after a build fails, and
no amount of polling here changes that.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The run tab said a defect was seeded and then moved on. The audience had to
take on trust both that a change was made and that the diagnosis Hermes
produced two minutes later actually matched it. Printing the diff first closes
that gap: they watch the wrong line go in, then watch a model find the same
line without being told where it is.
Placed before the commit rather than after the push because this is the only
moment in the demo where a human changes any code, and it is worth being seen
as such. The short sha follows the push so the commit on screen can be matched
to the one Jenkins builds.
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 Hermes stage is where the demo claims a model made the call. It showed the
stored JSON and named the run id, which asks the audience to take the rest on
trust. It now prints the console link for that exact run, so the claim can be
opened on screen instead of described.
Same route the pull request links to, so following either lands on the same
page.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
