03f5fbf599
The sweep opens a pull request only when everything lines up: mapped repository, file inside the write allowlist, and a change expressible as one anchored snippet. Most of this instance's backlog fails the last of those - the bulk of it is cognitive-complexity refactors - so those findings produced nothing at all. That is backwards. A finding nobody can patch automatically is precisely the one a maintainer has to do by hand, which is when knowing the intended fix is worth the most. Such findings now become an issue carrying the finding, links to both the SonarQube entry and the Hermes run, and the code Hermes believes would resolve it. A declined pull request falls through to the same path rather than ending the attempt. Not a patch, and the issue says so: nothing here is anchored, validated against the file, or pushed. That is what lets a suggestion describe work too large or too diffuse for the patcher, which is the whole point of the path. Deduped on the rule through the existing issue marker, so one root cause yields one issue however many files it spans. Off by default: it writes to real repositories, so an operator turns it on deliberately. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ariadne
Ariadne is the Atlas admin and account automation service.
It sits behind the portal and handles the jobs that are annoying or risky to do by hand: approving access, syncing account state, rotating service passwords, cleaning stale Kubernetes work, checking platform health, and keeping a few service integrations lined up.
How it works
Ariadne is a FastAPI service with a small scheduler. It talks to Keycloak, Vault, Mailu, Nextcloud, Wger, Firefly, Jenkins, Metis, Kubernetes, and a few Atlas-specific services through focused adapters under ariadne/services/.
The API is split between admin routes, account self-service routes, internal event hooks, and Prometheus metrics. Background jobs store run history in the Ariadne database so failures can be inspected later instead of vanishing into logs.
The following are notes for future Brad.
Bring-up dependencies
Ariadne needs:
- Kubernetes API, service DNS, and Ariadne's service account/RBAC
- the Ariadne database, plus the portal database if portal/account sync is enabled
- Vault or the Kubernetes secrets that Vault normally feeds it
- Keycloak/OIDC, because auth and profile sync assume it exists
- ingress/proxy plumbing if humans are going to use it through the portal
- the services for whatever jobs are enabled: Mailu, Nextcloud, Vaultwarden, Wger, Firefly, Jenkins, Metis, OpenSearch, and the comms/game-mode pieces
It can start before every integration is perfect, but the matching scheduled jobs will fail or no-op until their service is actually alive. In a total bring-up, wait for storage, Flux, Postgres, Vault, Keycloak, and ingress first. Afterwards Ariadne becomes useful glue.
Useful routes:
GET /healthGET /metricsGET /api/admin/cluster/statePOST /api/admin/access/requests/{username}/approvePOST /api/account/mailu/rotatePOST /api/account/wger/resetPOST /api/account/firefly/resetPOST /events
Development
python -m pytest
ruff check .
Most runtime behavior is configured through environment variables in ariadne/settings.py. Service-specific logic is in the small adapter modules; ariadne/app.py is focused on request flow and task orchestration.