Self-healing without human approval

On August 22, JobLander's repair agent shipped a fix for an analytics error. The change passed CI and AI review. On August 23, Check My App found the error again. The dispatcher picked up the new report and made another repair.

That sequence is the reason I built a loop. A failed AI fix must be able to become the next repair task without waiting for me to approve another attempt.

The implementation is public. It runs in JobLander, and I have also deployed the approach in Securify. The case below is from JobLander.

What the first repair missed

The browser was sending page-view events to /api/analytics/track for visitors who weren't signed in. The endpoint required authentication and returned HTTP 401.

The agent first added a client-side guard to skip requests when there was no user. The AI reviewer spotted a problem: during page startup, even a signed-in user's identity might not have loaded yet. The guard would drop their events too.

The agent changed the guard to wait until authentication had finished loading before skipping anonymous requests. That preserved signed-in users' events, but also let anonymous requests through during loading. The server still rejected them.

The next day's browser check found those 401 responses and created a new ticket. This time the dispatcher changed the server route to accept anonymous page-view events, while keeping authentication requirements for protected event types. The second repair merged on August 23. A subsequent Check My App run recorded the error as absent in production on August 25.

Incident records: JOB-902 / PR #280, JOB-905 / PR #281, and Check My App run #74. These are internal application records; the repair-loop repository linked above is public.

Where human approval is removed

The normal repair path is:

Production signal → ticket → agent investigation → patch
→ CI and AI review → automatic merge and deployment
→ continued production monitoring → next ticket if needed

CI and review remain. My approval is not a required step. The agent has a narrow remit: investigate a reported production defect and restore existing behavior, or establish that the report isn't a bug.

An AI-written change goes back under the same monitoring as any other change. The first attempt doesn't have to be the last opportunity to fix the problem. This depends on the monitor seeing the remaining failure; repeating a blind check won't help.

Using the repository

Start with the dispatcher rules: they describe ticket selection, investigation, review, and auto-merge. The README maps the output watcher, error monitor, dispatcher, and external watchdog.

The wiring still contains JobLander-specific services, repositories, and credentials configuration. Adapting it requires supplying your own detector, target repositories, and tool access. It is a reference implementation to inspect and adapt, not a plug-and-play installation.