Episode 14: an agent reads the WAF blocks, a script beats it, a human merges

ops-readonly gets two read-only questions, waf_blocked and waf_rule_info. The
rule ids per blocked request are in CrowdSec's alerts, not in its log, and
alerts need machine credentials that can also write, so waf-export.py runs on
the host and the container gets one more read-only mount.

Workflow G lets a local 3B model draft CRS route exclusions as a Forgejo issue.
The model never writes rule syntax, a code node checks every field against the
tool output, the only write permission is an issue in one repo, trusted sources
live in the workflow and the trigger needs a token.

waf-propose.py does the same without a model: 5 of 5 false positives, no
exclusion for an attack, 0.03 s. The model proposed an exclusion for nearly
every attack it saw. Numbers and the traps we hit are in HARDENING.md.

README.md

@@ -253,6 +253,15 @@ AppSec WAF inside Caddy. Install notes and the traps we measured are in
 **[crowdsec/](crowdsec/)**. Note the Caddy image now needs the key
 `CROWDSEC_BOUNCER_KEY` in `.env`.
 
+Episode 14 asks who should write the WAF exclusions the CRS needs. A local 3B
+model reads the blocked requests and drafts them as an issue; a human merges.
+Measured against twenty lines of Python on the same data, the script wins:
+5 of 5 false positives and no exclusion for an attack, where the model proposed
+an exclusion for nearly every attack it saw. What decides it is the one field
+in a blocked request that the sender cannot forge, the source address. The
+tool, the script and workflow G are in **[ops-readonly/](ops-readonly/)** and
+**[automation/](automation/)**, the reasoning in HARDENING.md.
+
 ---
 
 MIT — do whatever. If it saved you money, a YouTube subscription is the price: