Where to rehearse a patch before anybody reads it

ruleset_feeds.cve_url points an installation at its own channel document, from
engine 3.2.7. It replaces the published channel rather than adding to it: the
channel owns its ruleset source, a fetch clears that source before rebuilding
it, and two feeds claiming it would delete each other's rules on alternating
ticks.

So a new patch can be published to your own document, run as log against your
own traffic for as long as it takes to trust, and only then proposed here.
Until now there was nowhere to do that.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N5fpE6Gu4W6JoFMXyb7t7r

CVE-CHANNEL.md

@@ -13,6 +13,27 @@ Engine 3.0.47 and later fetch it hourly from:
 
     https://git.artica.center/Andre/edgeguard-owasp-feed/raw/branch/main/cve.json
 
+## Rehearsing a rule before it reaches anybody
+
+Since engine 3.2.7 an installation can point the channel at its own document:
+
+```json
+{ "ruleset_feeds": { "enabled": true, "cve_url": "https://your.host/cve.json" } }
+```
+
+It **replaces** the published channel rather than adding to it, because the
+channel owns its ruleset source: a fetch clears that source before rebuilding
+it, which is what makes a rule withdrawable, and two feeds claiming it would
+delete each other's rules on alternating ticks. `rulesets_url` does the same
+for the CRS mirror. Leave both empty for the published documents, which is the
+right default — an installation that sets nothing gets the patches we publish.
+
+So the sequence for a new patch is: publish it to your own document, let it run
+as `log` against your own traffic for as long as it takes to trust, and only
+then propose it here. Until this existed there was nowhere to do that, and
+every publish was a decision taken on every customer's behalf with no
+rehearsal.
+
 ## When a rule belongs here, and when it does not
 
 This document reaches every customer's agents from one hardcoded URL, so a