v1.4.0

v1.4.0 (2026-10-09)

The websocket guard and the adapter lifecycle surface (guard-core-go v4.3.2 floor)

Added

• The websocket handshake guard (#25): GuardWebSocket(engine, r) runs the engine's websocket handshake checks over the upgrade request (identity resolution, the fail-secure unknown-address close, the ban probe, the is_ip_allowed verdict, the ws rate limit, and the penetration detection pass sharing the HTTP pipeline's suspicious counts). A nil result allows the upgrade; a non-nil reason closes it. A nil engine fails closed with the security-check-failed reason. WebSocketHTTPStatus maps a close reason onto the HTTP status an upgrade rejection carries (503 try-again-later, 403 policy violation). The ws request shim mirrors the reference _WebSocketGuardRequest: method WEBSOCKET, empty body, repeated headers joined with a comma, fresh request state.
• The adapter lifecycle surface (#26): the fastapi-guard middleware lifecycle ops (the FEATURE_MATRIX_GO adapter row's PARTIAL/MISSING entries) as explicit functions over the engine handle (the same seam as GuardWebSocket and AddStatusRoute): MarkInitialized (a warmed engine makes Initialize a no-op), GetInitializationStatus (the payload AddStatusRoute serves), Reset (the rate limiter's windows, redis and in-memory), AgentStats (enabled/degraded merged with the wired handler's stats), and RefreshCloudIPRanges (the redis-backed refresh at the configured TTL, the reference cloud_handler.refresh_async, or the in-memory refresh; no blocked providers is the reference's no-op early return).

Changed

• Raised the engine floor to github.com/rennf93/guard-core-go/v4 v4.3.2, the adapter-parity release. The v4.3.2 engine carries the ReDoS static-safety trio with the pattern_safety corpus going registry-free (94/94, 0 divergences), the sus-patterns runtime registry with the pattern_detected envelope and real dynamic-rules application, the custom_response_modifier response pass (Engine.ModifyResponse exposes it to this adapter for pass-through composition), the websocket guard surface GuardWebSocket drives with suspicious counts shared with the HTTP pipeline, the fifteen SecurityConfig knobs with the performance-monitor wiring (redis tuning, body_read_timeout under a slot budget, log_country_check_level, agent_strict + on_error, the pattern-validation cache path, the per-request scan budgets), and the lifecycle/state surface the functions above call (manager exports, GeoIPManager.IsInitialized, the cross-instance middleware state registry, the engine side of MarkInitialized/AgentStats). The floor also brings redis/go-redis/v9 v9.23.0 transitively, clearing the stdlib-adjacent x/sys exposure (the engine's x/sys v0.48.0); govulncheck stays clean. Everything else flows through the unchanged middleware surface.
• Post-transfer metadata sweep (e87d9c8): repo URLs, docs links, and ecosystem references point at the Guard-Core org, and the upstream-drift suite checks out Guard-Core/guard-core-go@master. Module paths, Go imports, and the CHANGELOG history line are deliberately unchanged.

v1.3.1

v1.3.1 (2026-10-07)

guard-core-go v4.3.1 floor (route-id ownership, the trusted-proxy XFF chain walk, agent enrichment)

Changed

• Raised the engine floor to github.com/rennf93/guard-core-go/v4 v4.3.1, the family-parity release. The v4.3.1 engine carries the route-id ownership contract from @HardMax71's report (guard-core #140, reference fix #141/#142): every decorated endpoint owns its route id and the engine's GetEndpointID prefers the request's GuardRouteID (then the runtime guard_endpoint_id extra, then METHOD:redacted-path), so behavioral usage/return counters key per route instead of collapsing onto METHOD:path; adapters that attach route ids to requests get per-route behavioral buckets with no adapter code. The floor also brings the trusted-proxy XFF chain walk (client identity resolves through X-Forwarded-For behind configured trusted proxies, depth-selected from the right with the right-to-left walk fallback, instead of keying bans, rate limits, geo rules and behavioral counters on the proxy IP), the agent enrichment tier (EnableEnrichment/AgentProjectID/OtelServiceName/OtelResourceAttributes), the composite/OTel/Logfire agent handlers with the AgentHandlerFunc adaptation seam, structured JSON logging (LogFormat/LogFile), and the cost-parity detection loop (literal prefilter, rune-API scans, fail-closed cost ceilings). Everything flows through the unchanged middleware surface.

Added

• The reference status route (#23, landed on master after the v1.3.0 tag without a changelog entry): AddStatusRoute(mux, engine, path) registers a GET handler serving the engine's initialization snapshot JSON (cloud_providers ready/last_refreshed/entries per provider, geo_ip null or the configured resolver's status, redis enabled plus a live O(1) probe with the failure string) at DefaultStatusPath (/_guard/status) by default, never mutating engine state - the fastapi-guard add_status_route + HandlerInitializer.get_initialization_status parity.

v1.3.0

---

guard-core-go v4.3.0 floor (the corpus-parity engine)

Changed

• Raised the engine floor to github.com/rennf93/guard-core-go/v4 v4.3.0, the corpus-parity release. The v4.3.0 engine is validated against the full conformance corpus: the pattern_safety, events and redis_interop suite kinds now run against the real engine alongside detect and pipeline (fail-closed baselines), the spec 12 observable event stream is ported (security event bus, metrics collector, dynamic-rules agent pipeline, the emission fidelity wave that closes the events surface to reference parity at 32 of 38 cases), plus the detection performance monitor, the security-headers Redis cache with the cross-worker sync contract, and the manager-level geo country verdict (GeoIPManager.CheckCountryAccess). Everything flows to the adapter through the unchanged middleware surface: agent integrations receive the new event stream via the existing handler hooks, and the engine-level changes require no adapter code. The module's go directive follows the engine to 1.26.0 (the engine's toolchain floor), and the CI matrix (ci.yml and release.yml), the example-app smoke images and the Makefile's GO_IMAGE move to go 1.26 with it, mirroring the engine's own go 1.26 floor wave (guard-core-go #36).
• Dependency bumps: the codeql-action suite to 4.38.2 (#17) and golang.org/x/text v0.41.0 to v0.42.0 via the engine module graph.

Added

• A hard 100% coverage gate wired into CI (#20): the adapter surface is fully covered (coverage_test.go drives the shim and middleware paths the pipeline exercises), and the gate (check_coverage.sh) fails closed on a missing or empty profile and refuses anything under 100% total.
• staticcheck joins the CI gates (#19) with the findings fixed ahead of the gate.
• The upstream-drift suite runs on go 1.26 (#18) to match engine master's toolchain floor, and the live-smoke workflow fronts the advanced app with an nginx edge so the smoke asserts through the real deployment shape (#19).
• The guard-core process baseline (#19): hygiene files (SECURITY, CONTRIBUTING, Code of Conduct, funding, issue and PR templates), dependabot, the labeler and scheduled lint.

---

v1.2.0

v1.2.0 (2026-09-27)

guard-core-go v4.2.0 floor (the parity engine)

Changed

• Raised the engine floor to github.com/rennf93/guard-core-go/v4 v4.2.0, replacing the master pseudo-version pin with the real parity tag. The v4.2.0 engine is the parity release validated against the shared conformance corpus (spec 4.1.0, 219 cases; pipeline gate 35 passed, 0 failed, 0 xfail, 0 config divergences) and carries everything the pseudo-version pin already exercised plus the full feature surface: behavior rules (global_behavior_rules, per-route BehaviorRules, Engine.ProcessResponse return rules), the IPInfo geo lifecycle with OnGeoEvent (country_blocked, geo_lookup_failed, decorator_violation), per-route detection exclusions and enable_suspicious_detection, Retry-After from the tripped rate-limit tier window, the corrected CORS response surface (Allow-Methods/Headers, 3600 Max-Age, wildcard plus credentials downgraded at policy resolution), and the reference-shape passive on_block hook payloads (empty trigger_info, null status_code, inline ip_security/deny dispatch). The intermediate master pin (v4.0.5-0.20260927055209) existed only to pick up the 4.1.0 passive on_block contract ahead of the tag; v4.2.0 supersedes it.

v1.1.0

Security headers on pass-through responses

Added

• Security headers on every pass-through response. The adapter applies the engine's ResponseHeaders() set in one loop before the handler writes, so clean responses carry the same default header set as blocked ones (mirroring the engine's process_response). Disabling SecurityHeaders restores the header-free pass, and config overrides plus custom headers flow through the adapter untouched.

v1.0.1

guard-core-go v4.1.0 floor bump

Changed

• Raised the engine floor to github.com/rennf93/guard-core-go/v4 v4.1.0. The engine now attaches its default security headers to blocked responses, and the adapter translates that header set verbatim alongside the verdict status and body. The floor also carries the engine's per-route IP allow/block lists, exempt_ips, geo country blocking, and CORS support.
• The suite now requires the engine's security headers on blocked responses. The TestMiddlewareBlocksBannedIPExactly lockstep window (headers optional while the adapter floor lagged the engine) is closed: a blocked response must carry exactly the engine's default security header set, verbatim, with nothing added and nothing stripped.

v1.0.0

First stable release (v1.0.0)

Added

• The first stable release of nethttp-guard, the net/http middleware adapter for the guard-core-go engine. It translates *http.Request into the guardcore request surface, runs the engine, and translates verdicts to exact HTTP responses. Works with the stdlib mux, chi, httprouter, gorilla, and anything speaking func(http.Handler) http.Handler.
• 17/17 security checks parity with guard-core 4.0.4, covering suspicious activity detection, penetration attempts, IP bans and allow lists, cloud provider detection, rate limiting, HTTPS enforcement, required headers, referrer policy, user agent filtering, and route-level configuration, with binary-noise gates on the detection engine.
• Fail-closed behavior on engine malfunctions: any engine error answers 500 instead of letting the request through. Detection covers at most the first MaxBodyBytes of the body (default 262144, tunable via nethttp.WithMaxBodyBytes); payloads beyond the bound are not scanned, and the full body still reaches your handler untouched.
• Route-level configuration via engine.Routes.Register plus nethttp.WithRouteID(ctx, id) on the request context, and a swappable fail-closed logger via nethttp.WithLogger(l).
• Documentation site (MkDocs: index and usage/configuration pages), simple and advanced example apps, and a dockerized live smoke workflow over the example apps.

Changed

• Migrated to the guard-core-go /v4 module path. The dependency is now github.com/rennf93/guard-core-go/v4 v4.0.4 and every import uses github.com/rennf93/guard-core-go/v4/guardcore. The previous github.com/rennf93/guard-core-go v0.1.0 pre-release is retired.
• Release engineering harmonized with guard-core-go: a dockerized Makefile (install, test, lint, clean, bump-version) and a stdlib-only .github/scripts/bump_version.py that scaffolds this changelog; the git tag is the version.
• Upstream drift guard, demo container publishing, and community workflows from the parity polish: a daily test run of the adapter suite against guard-core-go@master, a container-release workflow for the demo image, docs publishing to GitHub Pages, plus labeling, staleness, and greetings workflows.