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>
hermes_code_demo.sh run crashed before it did anything, with a JSON traceback
pointing at the parser rather than the cause. Jenkins tree selectors use square
brackets; this curl build treats them as glob metacharacters and declines to
send the request, so the body came back empty and json.load reported column 1.
Encoded, and an empty body now says which job and which Jenkins rather than
raising from inside the parser. The crash was harmless as crashes go - it
happened before the defect was seeded, so nothing was pushed - but it happened
at the exact moment a demo starts.
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>
One script with a 'fixture' and a 'code' subcommand meant the wrong subcommand
was always one word away, in front of an audience, with different blast radii
behind each: the triage demo touches only a ConfigMap, the code demo pushes to
a repository and deletes issues. Those should not share a command line.
Each demo is now its own driver with the same five verbs - monitor, reset,
preflight, run, status - so knowing one teaches the other. What they genuinely
share (credentials, Jenkins access, the tick reader, the lab-wide preflight
checks) moved to hermes_demo_lib.sh rather than being duplicated, because the
reason to split was clarity at the command line, not two copies of the same
helper drifting apart.
Each reset now covers only its own demo. The triage reset no longer reaches
into a Gitea repository it never writes to, and the code reset owns the
repository cleanup entirely.
The credentials file is now hermes_demo.env since both read it; the old
hermes_triage_demo.env is still sourced as a fallback so a filled-in file
keeps working, and both names stay git-ignored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The scripts said "flow chart" while the artifact the audience is following
has a name. Telling a room to follow along on the flow chart and then handing
them something titled Test Automation Diagram makes them hunt for the match.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The code demo seeds its defect by pushing to master, and the fix only lands if
someone merges the pull request - which, by design, nobody does during a demo.
So master stays broken, and reset only printed "revert it before demoing"
while leaving it that way. The second run of the day then aborted on "defect
already present" before anything started.
Reset now reverts it on master. The substitution is anchored so it cannot
match an already-correct divisor, which keeps reset idempotent: running it on
a healthy repository changes nothing rather than corrupting the file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The chart draws the human path as a dead end for the automation. It now has a
second output - a remediation Hermes proposes but cannot request - and the
arrow has to terminate at a person rather than at the action registry, or the
drawing would imply the model can grow its own capabilities.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The diagnosis dump was clipped at 16 lines, which was already tight and now
truncates the stored outcome once a suggested remediation is present - the
audience would see the JSON cut off mid-object at exactly the moment the
interesting field appears.
Also says what that field means when it shows up, since a proposal is easy to
misread as something Ariadne is about to do. It is inert: no gate reads it.
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>
