CreaCaptcha

B-I4: the auto-refresh cron slot is only ever scheduled when BOTH firewall_trust_cloudflare AND firewall_cloudflare_auto_refresh are on (creationell_captcha_sync_cloudflare_cron(), cloudflare-proxies.php:173-176) — reading firewall_cloudflare_auto_refresh alone made this check report a permanent error on a healthy install whose proxy mode is off but whose two dependent fields are still frozen true by the settings requires-rewrite (they are simply gated, not broken). Mirrors the exact condition sync_cloudflare_cron() uses, and downgrades the "gated" case to warn — the field not taking effect is expected, not a defect.

W1-9: checks 14 and 15 used to read $settings['interceptor_paths']/ ['interceptor_actions'] directly. That is not what the interceptor itself decides on — a site using the documented creationell_captcha_protect_path() developer API only ever touches these filters, never the settings option, so the raw read was blind to filter-added guards (false "uncovered"/"ok, no exclusion problem") and equally blind to a filter that REMOVES a settings entry.

Public and static so the filter wiring itself — not just what the downstream checks do with the result — can be exercised directly in tests/test-cli-doctor-checks.php.

B-I5: fehlendes GD lässt should_issue_code_challenge() (code-challenge.php:31-33) die Zusatzstufe grundsätzlich nie auslösen — die PoW-Stufe bleibt unverändert aktiv, nichts fällt aus. Working degradation statt Ausfall, also warn statt error (siehe Check 16).

B-M22: signature and key-signature each resolve independently — a site can set one wp-config constant and rely on the stored option for the other. Missing either one leaves the engine unable to sign/verify challenges, so error (not warn) is correct here, matching the error-Regel in Check 16's comment.

Fixes two bugs found for this check (Bündel 5 / W1-10, W1-15):

• B-I6/W1-10: the previous loop set $covered = true on the FIRST matching probe and broke — an existence quantor answering "is ANY request under this pattern protected?" where the check's own claim ("jeder Inject-Pfad hat ein Gegenstück") requires a universal quantor. neutralising_excludes() right above already gets this direction correct for its own probes; this method aligns with it: ALL probes from probe_paths() must be covered.
• W1-15: matching only [rawurldecode($probe), $probe] covers the "inject pattern written percent-encoded" direction but not the reverse ("inject pattern written decoded, guard pattern written percent-encoded") — rawurldecode() on an already-decoded string is a no-op, so the guard's percent-encoded spelling was never produced to compare against. Building a third candidate — the probe percent-re-encoded segment-by-segment (preserving /) — covers that direction too, matching what a real browser sends over the wire for a non-ASCII path.

Public and static — like Interceptor::match_path() — so the three fixed constellations (Erst-Treffer, beide Kodierungsrichtungen) can be exercised directly in tests/test-cli-doctor-checks.php without bootstrapping the whole WP-CLI command.

B-I7: reading protect_wc_login raw ignored the kill switch and the protect_woocommerce master toggle — a value frozen true by the settings requires-rewrite from a time when Woo protection was on kept reporting "ok" long after protect_woocommerce was switched off, hiding the exact IN-7 gap (My-Account login unprotected) this check exists to surface. creationell_captcha_wc_login_active() is the single source of truth the render/verify hooks themselves use.

Die Substanz des B-I7-Fixes ist die QUELLE des dritten Arguments: creationell_captcha_wc_login_active() statt des rohen Toggles $settings['protect_wc_login']. Genau diese Wahl lag inline in run() und war deshalb von keiner Suite bewacht — login_coverage_check() selbst bekommt den Wert ja fertig gereicht. Als eigener Helfer ist der eingefrorene Fall (protect_wc_login = true bei ausgeschaltetem Master protect_woocommerce, AF-1) direkt pruefbar.

creationell_captcha_normalize_ip() (helpers.php) kanonisiert bewusst nur einzelne Adressen, nie CIDR-Bereiche — ein Umrechnen der Präfixlänge könnte eine Trusted-Proxy-Zeile stillschweigend verbreitern. Ein vor 1.1.0 in mapped Notation eingetragener Bereich (::ffff:203.0.113.0/120) trifft seit 1.1.0 deshalb nicht mehr; dieser Check macht das sichtbar statt es still wirkungslos werden zu lassen.

Zwei unabhängige Signale, weil ein wp-Aufruf über die CLI-SAPI normalerweise KEINE echte HTTP-Verbindung hat: $_SERVER['REMOTE_ADDR'] ist unter WP-CLI meist gar nicht gesetzt, ein Live-Treffer also nur bei ungewöhnlichen Aufrufkontexten möglich. Das Event-Log ist die verlässlichere Quelle: da creationell_captcha_get_client_ip() seit 1.1.0 jede IP kanonisiert, BEVOR sie geloggt wird, kann eine ::ffff:-Adresse im Log nur aus der Zeit VOR dem Update stammen — ein direkter, installationsspezifischer Nachweis, dass dieser Server REMOTE_ADDR mindestens zeitweise mapped ausliefert.

Probing with concrete sample paths derived from the positive patterns (rather than comparing pattern strings) uses the real matcher, so the answer is exactly the runtime behaviour.

B-M23: public (like inject_pattern_covered() above) so Check 14's own matching — not just what the check does with the result — has a direct Ebene-2 test in tests/test-cli-doctor-checks.php. Before this, the ~300-line doctor addition from Modul 27 had no such coverage at all for the BK-15 exclusion logic; class-cli-list-command.php:339 makes the identical visibility argument for a comparable validation seam.

Two probes per pattern — * expanded to nothing and to a filler — so a narrow exclusion that only catches one of them is not mistaken for one that swallows the whole pattern.

B-M23: public for the same reason as neutralising_excludes() above.

The four values mirror the firewall_proxy_header select field's options in includes/settings.php (and creationell_captcha_get_client_ip()'s $header_map in includes/helpers.php) — kept in sync manually since this check must not depend on either of those files loading.

Nachlese N6, Befund 6. Analytics::run_scheduled_prune() und ensure_prune_schedule() steigen seit W3-2 beim Kill-Switch sofort aus. Für den kurzen Einsatz ist das richtig — Zeilen zu löschen ist die einzige zerstörende Hintergrundoperation dieses Plugins, und wer während eines Vorfalls CREATIONELL_CAPTCHA_DISABLE setzt, will den Zustand einfrieren, nicht die Beweise wegräumen lassen. Für eine Konstante, die länger steht als die Aufbewahrungsdauer, ist es eine offene Zusage: die Einstellung sagt „ältere Einträge werden entfernt", und es passiert nichts. Der Guard bleibt (dieselbe Entscheidung wie in W3-2), aber der Zustand wird gemeldet statt still zu bleiben.

wp creacaptcha log prune prüft den Kill-Switch NICHT und ist damit der Weg heraus, ohne die Konstante anzufassen — die Meldung nennt ihn.

Ruft den Sanitizer im PROGRAMMATIC-Kontext NUR zum Vergleichen auf und schreibt das Ergebnis nicht. Seit Welle 1 ist der Sanitizer seiteneffektfrei (der ensure_table()-Aufruf haengt an den update_option_/add_option_-Hooks, nicht mehr am Sanitizer), sonst waere dieser Aufruf aus einer rein lesenden Diagnose heraus unzulaessig.

Eigener Helfer aus demselben Grund wie secret_resolvable(): stand diese Zeile inline in run(), liess sich der Wertvergleich auf $sanitized = $stored zuruecknehmen, ohne dass eine Suite rot wurde — Check 9 haette dann strukturell nie eine Wertabweichung sehen koennen.

Bis zum Re-Review stand diese Disjunktion inline in run(); die Doctor-Suite ruft aber ausschliesslich die reinen Check-Funktionen mit bereits fertigen Argumenten auf, sodass eine Ruecknahme des Konstanten-Zweigs von KEINEM Test bemerkt wurde (Fehlerklasse 2: der Fix stimmt, der Beweis trifft den Pfad nicht). Als eigener Helfer ist die B-M22-Divergenz — Konstante gesetzt, Option leer — direkt und diskriminierend pruefbar.

Der Konstantenname kommt als Zeichenkette herein, damit ein Test beide Zweige im selben Prozess durchlaufen kann; constant() liest ihn erst nach dem defined()-Guard.

Bewusst NICHT ueber creationell_captcha_get_hmac_secret(): der Getter heilt eine fehlende Option durch Neuerzeugen und PERSISTIEREN — ein Schreibvorgang, den diese rein lesende Diagnose nie ausloesen darf (Vertrag „doctor liest ausschliesslich" im Klassen-Docblock).

Nachlese N2: schliesst die CLI-10-Grenze ("nur die Schluesselmenge"), seit der Sanitizer-Aufruf selbst kein DDL mehr ausloest (Welle 1). $sanitized ist der Aufrufer-seitige, rein lesende Sanitizer-Durchlauf ueber $stored (creationell_captcha_sanitize_settings($stored, CREATIONELL_CAPTCHA_SANITIZE_PROGRAMMATIC)) — diese Methode selbst ruft ihn nicht auf und bleibt dadurch ohne jede settings.php-Abhaengigkeit direkt testbar.

B-I5: Engine::algorithm_key() (class-engine.php:601-611) falls back to PBKDF2 silently and logs when ext-sodium is missing — challenges keep working. That is a working degradation, not the "cannot work" state error is reserved for (see the Check-16 comment below), so this is warn.

Two independent signals, checked in order of confidence:

1. $sig_resolvable false — no HMAC signature secret resolves (neither the wp-config constant nor the stored option), so mint_pass() cannot derive a token for ANY visitor. This is N1's suggested direct condition (creationell_captcha_derive_hmac_key(...) === ''), reformulated without calling the self-healing getter chain (see the __invoke() comment above this call) — error, because the site is durably unusable, matching the error-reservation rule from Check 16's comment.
2. $data — the event-log symptom (see below), for the other cause (headers_sent()), which cannot be observed directly from a WP-CLI process.

$data is null when the prerequisites for a meaningful measurement are not met (event log off, either log gate off, or the table missing) — reported as "not measurable", never as "ok" by absence of evidence. Below the attempt threshold the same applies: zero passes out of zero or a handful of attempts says nothing about whether the gate is passable at all.