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>
An audience following mermaid/TestAutomation.mmd needs to know which edge off
the route diamond was taken, which was the one thing the output left them to
infer. It now quotes the chart's own labels - authorized action, human
required, and the optional code path - and the docstring states where the
reporting is coarser than the diagram.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A rerun should start from nothing. DEMO_REPOS is the entire blast radius and
is deliberately explicit: a real service's issues are genuine triage records,
and clearing them to tidy a demo would destroy the evidence the system exists
to produce.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The resolving tick remains the newest one until another incident opens, so the
completed checklist reprinted on every poll.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
reset restores only what the demo itself creates: the fixture ConfigMap, the
demo repository's open repair pull requests and their branches. Real service
repositories are deliberately untouched - those issues are genuine triage
records, and deleting them to tidy a demo would destroy the evidence the
system exists to produce.
monitor streams the flow in the stages of mermaid/TestAutomation.mmd, so a
second terminal can be followed against the chart: Detect and gather, Hermes
analysis, Ariadne policy gates, Ariadne response, Inspectable outputs. Each
stage prints the evidence that moved it, since the claim the chart makes is
that every step is answerable from data rather than asserted. Read-only.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The allowlist is the outermost safety boundary - a job absent from it is never
touched, whatever fails - so it is worth reading at a glance rather than as a
comma-separated setting value echoed verbatim.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The script demanded JENKINS_USER and JENKINS_TOKEN in the environment and said
only 'set JENKINS_USER' when they were missing, which is not enough to act on.
It now sources scripts/ops/hermes_triage_demo.env, git-ignored so it can hold
real tokens, and names that file when credentials are absent. An example file
records what belongs in it.
The fixture command also still polled for a hermes-demo-repair-<build> Job.
That Job stopped existing when the repair became an in-process ConfigMap
patch, so the command would have waited its full 400 seconds and then reported
nothing. It now watches the fixture returning to healthy, which is what
actually happens.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
START-HERE.md is visible in the Hermes dashboard, so its wording is part of
what an operator sees. Describing the runbook as a five-minute demonstration
frames the automation as a set piece rather than as something that runs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ananke, pegasus and atlasbot were triaged but mapped to no repository, so
their failures could produce neither an issue nor a pull request. All three
exist on main and are non-empty. data-prepper is deliberately absent: it has
no repository under bstein.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The agent init container is appended by default, so init-config ran before
/vault/secrets existed and fell back to the Secret every time. The values were
identical, so the migration appeared to work while Vault was never actually
read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Claude subscription OAuth token was created as a manual kubectl Secret in
the interest of demo time, with migration to Vault agreed as follow-up. The
value now lives at kv/atlas/hermes/agent-tokens and is injected as a file.
The hermes role gains that path and binds the hermes-triage service account
the deployment actually runs as; it previously bound only hermes-vault. The
init container prefers the Vault file and falls back to the Secret, so this
can be rolled back by removing the annotations alone, and the Secret should be
deleted once Vault has been serving it for a while.
Vault was reachable all along without the operator credential: Ariadne already
holds a vault-admin Kubernetes auth role, which is how the value was written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The earlier probe fix addressed slow /health responses under load, but the
restarts continued with a different signature: connection refused rather than
timeout, meaning the app was not listening yet. Ariadne runs migrations and
builds its cron schedule before binding, which can outlast what liveness
allows from initialDelaySeconds, so the kubelet kept restarting a pod that
was merely still starting.
Add a startupProbe granting up to five minutes to come up, after which
liveness takes over unchanged. This is the case startupProbe exists for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
