An automated pipeline that builds and audits websites will, sooner or later, produce a bad one. What you do next decides whether you have a product or a hobby. Our rule: fix the loop, not the output.
The temptation
A build stalls. You open the files, fix the three things that are wrong, and ship it. It feels efficient. It also means the pipeline learned nothing, and the next build with the same weakness stalls the same way, except now you are the pipeline.
A real case
One build dead-ended at 84% on our coherence check, short of the threshold, and could not improve itself. Rather than edit the site, we asked why the loop could not repair it. Three causes turned up.
- No repair step. The loop detected the problem but had nothing that acted on the judge’s findings. We added a repair pass that feeds those findings back to the builder.
- Switches left off. Some environment settings that disable the self-healing steps had been left on from earlier debugging, so the repair code never ran. We removed them and now check the running process, not the config file, when a loop does not fire.
- The judge was reading the wrong thing. It scored from the source rather than the rendered pages, so it flagged problems a visitor would never see. We changed it to judge what the browser actually renders.
With those three changes the same build recovered on its own and reached 97% coherence, signed off. We did not touch its files.
The rule, and its cost
If you fix the output, you fixed one site. If you fix the loop, you fixed every site that has the same weakness.
The cost is time up front: finding the root cause takes longer than patching the symptom, and you have to resist shipping the patch. The payoff is that the failure stops recurring, and the pipeline’s record gets better with every fix instead of staying flat.