[WAF-01] Create the executable ModSecurity and Coraza feature matrix

Objective

Inventory every stable directive, variable, action, transformation, operator, body processor, log format and writer, collection, API method, and selected integration from the pinned baselines in a machine-readable matrix.

Deliverables

• Implement the complete scoped behavior described above.
• Keep request-path work independent from UI, PostgreSQL, and blocking audit I/O.
• Use Zig 0.17-dev and dependencies pinned through Pantry; do not add Git submodules.
• Keep public APIs explicit about ownership, resource limits, errors, security policy, and compatibility.
• Add focused unit, integration, differential, fuzz, benchmark, and documentation coverage as applicable.

Acceptance criteria

• The scoped implementation and tests are merged on main in small conventional commits.
• Zig formatting, focused tests, and the relevant CI suite pass.
• Compatibility claims have executable evidence and no unexplained skips or silent fallbacks.
• Untrusted inputs have deterministic bounds; hot paths have benchmark evidence.
• Documentation and the machine-readable compatibility matrix are updated.

Relationships

• Parent: WAF-00

Blocked by

None

Blocks

None

Baselines

• ModSecurity 3.0.16
• Coraza 3.7.0
• OWASP CRS 4.28.0
• libinjection 4.0.0
• Zig 0.17-dev resolved and locked through Pantry

Initial executable matrix shipped in 09b5b96. The typed JSON matrix pins all baselines and rejects malformed rows, duplicate IDs, missing GitHub issue links, or implemented/verified claims without evidence. CI passed: https://github.com/zig-utils/zig-waf/actions/runs/29893842701. This issue remains open while the directive/action/transformation/operator inventory is expanded to the complete ModSecurity/Coraza stable union.

Complete. The matrix has two halves, both machine-readable, and neither can drift from the engine unnoticed.

Per-item inventory (63f461c) — zig build matrix emits every directive, transformation and alias, operator, variable, collection, audit format, and body processor the engine knows, generated from the same tables the engine dispatches on. That is the point rather than a convenience: a hand-maintained inventory drifts the moment someone adds a directive and forgets the list, and an inventory that disagrees with the engine is worse than none, because it is the document people check instead of reading the source. This one cannot disagree — if the engine gained an operator, the operator is in the file.

directives 86 · transformations 35 (+2 aliases) · operators 21 · variables 78
collections 37 · audit formats 4 · body processors 4

Directive rows carry per-baseline support including recognized_limited — the baseline parses it but does less than the name implies — which is the distinction a compatibility claim lives or dies on.

Area-level matrix — src/compatibility/features.json says what each area implements, with evidence files and the reasoning that is not derivable from a list: why signing is asymmetric for bundles and symmetric for webhooks, why parameters are bound as text rather than binary, why the SQLite backend is not a deployment target, why an uncollectable metric is omitted rather than zeroed. Kept current with every issue closed this session.

Executable against the baselines — the inventories are checked against the upstream sources themselves, not against a transcription:

• zig build test-transformation-inventory compares the typed registry with ModSecurity 3.0.16's seclang-scanner.ll and seclang-parser.yy and Coraza 3.7.0's transformations.go. Latest run: modsecurity_names=38 modsecurity_tokens=36 coraza_names=34 canonical=35 aliases=2 reset=1 mismatches=0.
• zig build test-directive-inventory does the same for directives.
• zig build test-plan-corpus and test-directive-corpus compile every CRS 4.28, ModSecurity, and Coraza configuration in the pinned checkouts, with files expected to fail declared and asserted rather than skipped (#38).

Both artifacts are generated and uploaded on every CI run, alongside the SBOM (#5).