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>
Maps workspace_storage_exhausted to the reclaim action, so a build that failed
on a full workspace volume is remediated rather than escalated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The three categories now appear in the deployment next to the action
allowlist, and the monitor prints both at the policy gate so the difference is
visible during a demo rather than asserted: two ids Ariadne may execute on its
own authority, three categories it may only ask Hermes to propose a patch for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Several stages assumed the fixture job. On a code-demo run they would have
read the fixture ConfigMap, which is unrelated to that job, and asserted that
a field changing from unhealthy to healthy was the repair - flatly false when
the outcome is a pull request. The route stage would also have claimed the
source-proposal branch was not taken during the run that takes it.
The stages now branch on the job: the route explains that a source fix is not
a registered action and so takes the proposal branch; the response points at
the pull request recorded on the incident; and the verify stage says the
branch build validates the proposal and that nothing merges without a human
whatever it reports.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gitea wedged at 2073Mi against a 2Gi limit: its API stopped answering even on
its own loopback, and the repeated SSH LoginGraceTime drops in its log were
starvation symptoms rather than a separate fault. Raised to 3Gi.
The reset command's Gitea calls had no --max-time, so a slow service became an
indefinite hang with no output - the script appeared frozen after 'clearing
bstein/hermes-code-demo'. They now fail after 25 seconds and say so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Five corrections to how the monitor explains itself, plus code-demo support.
The authorization is now described as what it is: a match between an action
Ariadne already has code to perform, an action id Hermes is permitted to
request, and the action Hermes actually recommended. Hermes cannot add to that
registry, and the recommendation proceeds only because it names something
already in it. The editorial line about pull requests is gone.
The repair now reads as a change rather than a value: the field said unhealthy
when the build failed and says healthy because Ariadne just patched it.
The rebuild stage says plainly that the operational branch is complete and
that neither the human-required response nor the optional source proposal is
entered, rather than leaving the reader to infer it from silence.
Inspectable outputs states that on the chart it is the 'records and artifacts'
edge out of the whole response box, not out of one branch - every path ends
there. The layout makes it look like it belongs to the proposal path alone.
follows hermes-code-demo, which takes the proposal branch: the
stages now read as a patch proposal and a pull request instead of being
mislabelled an escalation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The bundle stage printed the job allowlist, which says nothing about what was
actually sent. It now samples the bundle itself, rebuilt with the same
collector Ariadne used - durable, because a finished build's console does not
change - and trimmed hard, since the point is to show what each source
contributes rather than to reprint it:
jenkins.console_failures : 1 region(s), truncated=False
| ERROR: Demo fixture check failed for incident hermes-triage-demo/34
jenkins.failed_tests : 0
log_evidence.records : 35 from OpenSearch kube-*
| [jenkins] Using /home/jenkins/agent/remoting as a remoting work directory
The diagnosis now also carries run_id and run_seconds, so the run can be
opened in the Hermes dashboard to see the prompt it was given and every tool
call it made - the request, not just the answer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The detection stage read the fixture ConfigMap, which is a live value. Every
stage describes a moment that has passed, and by the time detection is
narrated the repair has already run - so it printed 'healthy' and implied the
fixture had never failed, contradicting the premise of the whole run. Replay
made it certain rather than occasional.
It now prints the incident's recorded state changes, which stay true
afterwards:
21:48:03 detected {result: FAILURE, ...}
21:48:18 diagnosed {classification: known_demo_fixture_failure, ...}
21:48:18 repairing {action: repair_demo_fixture}
21:48:18 awaiting_rebuild {repair: configmap_patch, ...}
21:49:03 resolved {resolved_by_build: 35}
The fixture read stays on the response stage, where healthy is the point.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Hermes stage proved only that a pod was running, when the substantive
evidence is the JSON Hermes returned; it now reads that from the audit trail,
so classification, confidence and requested action are on screen. The policy
gates stage never showed the verdict it was describing; authorized and
authorize_reason now appear with it.
The chart paths were paraphrases. They are now the node labels from
mermaid/TestAutomation.mmd verbatim - Response check, Scoped repair guard,
Action authorizer, Action registry, Scoped ConfigMap repair, Action result -
so a line on screen can be found on the diagram. The checklist carries them too.
The Optional source proposal branch was silently absent rather than explained.
The route stage now states it was not taken and why: a fixture repair is an
operational action, and source fixes are not actions at all.
Also widened the log window and its timeout; the fetch occasionally exceeded
25s and dropped a poll.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It read only the newest tick from a --tail=400 window. Ariadne now emits
roughly two hundred lines per tick, so that window held about two ticks, and a
step that lasted a single tick - the repair, most importantly - vanished if a
poll landed after it. Build 30 was triaged, repaired and resolved correctly
while the monitor printed nothing at all.
The window is now time-based, and every tick inside it is replayed rather than
just the last. mark() was already idempotent, so replaying is safe and the
monitor recovers stages it was not running for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The fixture check waited on the Job's .status.succeeded/.status.failed. The
kubelet records a container's exit code the instant it stops, but the Job
controller reconciles those fields on its own schedule: observed at 2m24s,
4m27s and 34m on this cluster for identical work. During that window the pod
had already exited 1 and the build sat printing 'Will try again after 13 sec',
looking hung long after the test had finished, which is unusable in a demo.
Polling the pod's terminated exitCode removes the controller from the path
entirely. The Job is still used, so the evidence shape is unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An audience watching a dashboard has to take the result on trust. Watching
kubectl run against the cluster and reading the raw answer is the difference
between a demonstration and an assertion, so every read is now printed before
it runs and its output shown beneath.
Each stage also names the service UI worth looking at when something changes
there: the Jenkins job as the build goes red and again when the rebuild starts
on its own, the Hermes dashboard as the agent run appears, the Grafana triage
panels and the filed issues at the end.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
