1.3.0-beta3: operator-experience fixes from the rc2 production-soak Stepping back from rc to beta after the 1.3.0-rc2 install reached the actual PURGE code path for the first time on a Cloudflare- fronted Jelastic-managed LSWS Enterprise environment and surfaced operator-experience gaps that warranted a fresh soak window before re-claiming rc quality. What landed since 1.3.0-rc2 (commit f037d9b): - 442e93f: actionable error messages. Suggested URL in the no-host failure reason changed from https://your-site.example.com to http://localhost/ (the previous example sent operators behind any CDN into a 400 trap). HTTP non-2xx purge failures now surface operator-actionable reasons via the new formatNon2xxReason() helper, detecting Cloudflare's HTTP 400 + CF-Ray signature specifically and pointing operators at origin-direct purge_host alternatives. Same change applied to the settings form description and placeholder. - 88d4398: purger logging now routes through @logger.channel. lscache_purger via constructor injection. The channel was registered in services.yml since 1.0.0 but never used; the plugin defaulted to PurgerBase's framework channel. drush watchdog:show --type=lscache_purger now returns purge-warning entries instead of "Unrecognized message type". Messenger-surfaced failure reasons now apply to every failure path (no-host, HTTP non-2xx, transport error), not just the no-host case rc2 covered. - 89a1150: two new doc sections in docs/htaccess-gotchas.md. "LSWS-side PURGE handling" makes explicit that HTTP 200 from LSWS means "request accepted at the protocol level," not "entry evicted." On managed-LSWS environments (Jelastic, Cloudways) and on Enterprise installs with admin-port routing, the two can be distinct states. Documents the diagnostic, LSWS configuration requirements, and operator workarounds. "LSCache vs Drupal's dynamic_page_cache UNCACHEABLE hint" covers the case where the two cacheability signals disagree, documents how to opt out via response policy when needed. - 5593f00: ROADMAP records the rc2 -> beta3 step-back with the rationale and the deferred-to-1.3.1/1.4.x list (post-purge sentinel verification flag, everything-invalidation type, the operator-experience polish items). Pure operator-experience + docs scope. No API contract changes; the "HTTP 200 = SUCCEEDED" mapping is unchanged. Finding 7 (auth- served-as-anon variant) was canary-clean on rc2 across 81 controlled requests; treating that finding as resolved pending the invalidation-driven re-test once LSWS-side PURGE works in the test environment. Soak target ~5-7 days. If clean, promotes straight to rc3, then ~2-week soak, then 1.3.0 stable. If anything new surfaces, beta4 cycle.