Hope is not a strategy

Okay, so I was reviewing a PR for faster.dev and noticed a repeating pattern of string limit html entity decode strip tags empty placeholder flags utf8 across the frontend code. This raised a red flag for me. On the backend, we use a rich text editor that outputs HTML, and while I'm not worried about "dangerously setting inner html" due to the admin area's protection, I was concerned about the redundant code.

I asked the Clanker (an LLM) to explain why this pattern exists, and it said it was to clean up HTML for excerpts where plain text is rendered. Makes sense. So, I had it create a macro called Clean Rich Text to encapsulate this logic and avoid repetition. I put this macro in the app service provider.

Centralizing the behavior is key, but how do I ensure the Clanker uses it consistently? Rules, skills, and agents.md are helpful, but not enough. I need to tighten the ratchet to prevent this issue from recurring. The LLM seems inclined to inline those functions (HTML decode, strip tags), as it's done it many times.

To make sure this specific problem never happens again, I added a test using Pest's Architectural Testing plugin that will fail in CI. The first test ensures that these functions are only used within the Clean Rich Text macro. If I need those functions elsewhere, I'll modify the test, but for now, it's locked down. A second test ensures entity decode is only used in the macro (except for where the macro is defined).

This makes it deterministic. I'm not relying on the LLM to remember, I've caught the mistake, fixed it, and have a test to prevent future occurrences. If it ever happens again, CI will fail. This is how I'm tightening the ratchet and keeping the codebase clean and maintainable.