release 1.4.1 status update

Author: ZeroBitsTech

CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 1.4.1
+
+- Clarified target maturity: optional network modules are now documented as stable enough for ESP32 deployments that validate against their real endpoint, while ESP8266 remains under active hardening.
+- Added transport readiness gating for `ZeroMqttPump`, matching the existing HTTP-side link probe and reducing futile broker connect attempts while Wi-Fi is still down.
+- Synced runtime metadata: runtime version is now `1.4.1` and ABI version is published consistently as `2` in the manifest.
+
 ## Unreleased
 
 - Added generic compare workloads for `EnvMonitor`, `TelemetryGateway`, and `IndustrialLoop`.

README.md

@@ -107,6 +107,12 @@ The optional network helpers are currently marked **BETA**:
 
 They are already useful and validated on desktop plus ESP32 hardware, but they are still under active tuning for footprint, retry behavior, and cross-board transport quirks. The core runtime is the stable layer; the network helpers should be treated as add-on modules that are ready for evaluation and controlled deployments.
 
+Current target maturity:
+
+- **ESP32:** stable enough for production-style evaluation and controlled deployments when validated against the real HTTP/MQTT endpoint you intend to ship with.
+- **ESP8266 / Wemos:** still BETA. Live delivery is real, but timing cost is still under active hardening.
+- **Other supported families:** compile-validated, but network helper maturity should still be treated as evaluation-grade until they receive the same live validation depth.
+
 Current best module tradeoff reference (ESP32, `LEAN_NET`, manual pattern vs module pattern):
 
 - RAM overhead: `+408 bytes`
@@ -117,6 +123,29 @@ Current best module tradeoff reference (ESP32, `LEAN_NET`, manual pattern vs mod
 
 In other words: the modules do cost memory, but the current tuned path keeps that cost bounded and pays it back with better transport throughput and less queue buildup under the same synthetic workload window.
 
+## ESP32 Network Status
+
+The current network helper stack is now strong enough on ESP32 to treat as a practical deployment target, not just a lab demo, as long as you still validate it against your own endpoint, payload size, and retry policy.
+
+Current accepted live compare reference on ESP32:
+
+- baseline:
+  - `sample_runs=47`
+  - `fast_avg_lag_us=112955`
+  - `fast_max_lag_us=1609577`
+  - `fast_miss=12`
+  - `http_rate=73`
+  - `mqtt_rate=73`
+- modules:
+  - `sample_runs=85`
+  - `fast_avg_lag_us=15857`
+  - `fast_max_lag_us=1047913`
+  - `fast_miss=5`
+  - `http_rate=66`
+  - `mqtt_rate=100`
+
+The important part is the shape of the tradeoff: timing improves materially, MQTT delivery becomes clean, and HTTP stays alive under the same live window. That is why the ESP32 path is now documented as stable enough, even though the global module label remains BETA until the ESP8266 path is cleaned up too.
+
 ## General-Purpose Validation Workloads
 
 To avoid overfitting the runtime to a single project, ZeroKernel now also ships with three reusable compare workloads:

docs/wiki/Beta-Modules.md

@@ -9,10 +9,17 @@ The following optional modules are currently marked **BETA**:
 
 They are already useful and validated on desktop plus ESP32 smoke tests, but they are not yet considered fully field-proven across all transport stacks and all board families.
 
+## Target maturity right now
+
+- **ESP32:** the current network stack is stable enough for production-style evaluation and controlled deployments when you validate against your real server or broker.
+- **ESP8266 / Wemos:** still BETA. Live transport works, but timing cost is still under active hardening.
+- **Other targets:** compile-supported, but network helpers should still be treated as validation targets until they see the same live-network coverage.
+
 ## What BETA Means Here
 
 - API shape is usable, but may still tighten as real-world patterns accumulate.
 - Performance and footprint are measured and improving, but still under active tuning.
+- ESP32 already has the strongest live-network validation. The BETA label mainly remains because the ESP8266 path is not yet clean enough to claim cross-board stability.
 - The modules are suitable for evaluation, prototypes, and controlled deployments.
 - For production, validate them against your actual transport stack and retry policy.
 

library.properties

@@ -1,5 +1,5 @@
 name=ZeroKernel
-version=1.4.0
+version=1.4.1
 author=ZeroBits
 maintainer=ZeroBits
 sentence=ZeroKernel by ZeroBits for deterministic embedded task orchestration.

src/core/KernelIdentity.cpp

@@ -9,7 +9,7 @@ const Kernel::Identity kKernelIdentity = {
     "ZeroBits",
     "Small Bits. Solid Systems.",
     "https://kernel.zerobits.tech",
-    "1.4.0"};
+    "1.4.1"};
 
 }  // namespace
 

zerokernel.manifest.json

@@ -2,8 +2,8 @@
   "kernel": "ZeroKernel",
   "vendor": "ZeroBits",
   "tagline": "Small Bits. Solid Systems.",
-  "runtime_version": "1.3.1",
-  "abi_version": 1,
+  "runtime_version": "1.4.1",
+  "abi_version": 2,
   "model": "Embedded Execution Runtime",
   "execution": {
     "scheduler": "cooperative",