Merge pull request #594 from MDA2AV/update-json-rulez

sneaky

Author: MDA2AV

site/content/docs/test-profiles/h1/isolated/json-compressed/implementation.md

@@ -1,7 +1,7 @@
 ---
 title: Implementation Guidelines
 ---
-{{< type-rules production="Must use the framework standard JSON serialization and the framework or engine's built-in response compression (middleware, filter, or equivalent). No pre-compressed caches, no bypassing the response pipeline." tuned="May use alternative JSON libraries, tuned compression libraries, or framework-specific optimizations as long as the output is valid gzip or brotli." engine="No specific rules." >}}
+{{< type-rules production="Must use the framework standard JSON serialization and the framework or engine's built-in response compression (middleware, filter, or equivalent). No pre-compressed caches, no bypassing the response pipeline." tuned="May use alternative JSON libraries, tuned compression libraries, and framework-specific optimizations as long as the output is valid gzip or brotli. The JSON body must still be serialized and compressed per request — pre-computed / pre-serialized / pre-compressed response caches are not allowed on either type; they defeat the serialization and compression workload the profile exists to measure." engine="No specific rules." >}}
 
 The JSON Compressed profile is the same workload as [JSON Processing](../json-processing/implementation/) with one difference: the client sends `Accept-Encoding: gzip, br` and the server must return a compressed response with a matching `Content-Encoding` header.
 

site/content/docs/test-profiles/h1/isolated/json-processing/implementation.md

@@ -1,7 +1,7 @@
 ---
 title: Implementation Guidelines
 ---
-{{< type-rules production="Must use the framework standard JSON serialization. No pre-serialized caches, no custom serializers, no bypassing the framework response pipeline." tuned="May use alternative JSON libraries (simd-json, sonic-json), pre-computed responses, or framework-specific optimizations." engine="No specific rules." >}}
+{{< type-rules production="Must use the framework standard JSON serialization. No pre-serialized caches, no custom serializers, no bypassing the framework response pipeline." tuned="May use alternative JSON libraries (simd-json, sonic-json) and framework-specific optimizations. The JSON body must still be serialized per request from live data — pre-computed / pre-serialized response caches or response-lookup tables are not allowed on either type; they short-circuit the serialization workload the profile exists to measure." engine="No specific rules." >}}
 
 
 The JSON Processing profile measures how efficiently a framework handles a typical real-world API workload: loading data, computing derived fields, and serializing a JSON response.

site/content/docs/test-profiles/h1/isolated/json-tls/implementation.md

@@ -1,7 +1,7 @@
 ---
 title: Implementation Guidelines
 ---
-{{< type-rules production="Must use the framework standard JSON serialization and a standard TLS stack (OpenSSL, BoringSSL, rustls, SChannel, JDK JSSE, etc.). No pre-serialized caches, no bypassing the framework response pipeline, no TLS session-ticket shortcuts that skip real handshakes." tuned="May use alternative JSON libraries, pre-computed responses, tuned TLS providers, and framework-specific optimizations." engine="No specific rules." >}}
+{{< type-rules production="Must use the framework standard JSON serialization and a standard TLS stack (OpenSSL, BoringSSL, rustls, SChannel, JDK JSSE, etc.). No pre-serialized caches, no bypassing the framework response pipeline, no TLS session-ticket shortcuts that skip real handshakes." tuned="May use alternative JSON libraries, tuned TLS providers, and framework-specific optimizations. The JSON body must still be serialized per request from live data — pre-computed / pre-serialized response caches are not allowed on either type; they short-circuit the serialization workload the profile exists to measure." engine="No specific rules." >}}
 
 The JSON over TLS profile is the [JSON Processing](../json-processing/implementation/) workload transported over HTTP/1.1 + TLS on a dedicated port. It measures how much of a framework's plaintext JSON throughput survives encryption.
 

site/content/docs/test-profiles/h1/workload/api-16/implementation.md

@@ -1,7 +1,7 @@
 ---
 title: Implementation Guidelines
 ---
-{{< type-rules production="All endpoint implementations must follow their respective production rules. No endpoint-specific optimizations that would not be used in production." tuned="May optimize each endpoint independently. Pre-computed responses, custom serializers, and non-default configurations allowed." engine="No specific rules." >}}
+{{< type-rules production="All endpoint implementations must follow their respective production rules. No endpoint-specific optimizations that would not be used in production." tuned="May optimize each endpoint independently. Custom serializers and non-default configurations allowed. Pre-computed / pre-serialized JSON response caches are not allowed on either type — the JSON slice of this workload must still be serialized per request from live data." engine="No specific rules." >}}
 
 The API-16 profile is identical to [API-4](../../api-4/implementation) but with the server constrained to **16 CPUs and 32 GB memory** instead of 4 CPUs and 16 GB. This measures how well the framework scales with more available resources.
 

site/content/docs/test-profiles/h1/workload/api-4/implementation.md

@@ -1,7 +1,7 @@
 ---
 title: Implementation Guidelines
 ---
-{{< type-rules production="All endpoint implementations must follow their respective production rules. No endpoint-specific optimizations that would not be used in production." tuned="May optimize each endpoint independently. Pre-computed responses, custom serializers, and non-default configurations allowed." engine="No specific rules." >}}
+{{< type-rules production="All endpoint implementations must follow their respective production rules. No endpoint-specific optimizations that would not be used in production." tuned="May optimize each endpoint independently. Custom serializers and non-default configurations allowed. Pre-computed / pre-serialized JSON response caches are not allowed on either type — the JSON slice of this workload must still be serialized per request from live data." engine="No specific rules." >}}
 
 The API-4 profile runs a multi-endpoint workload with the server container constrained to **4 CPUs and 16 GB memory**. Only baseline, JSON, and async database endpoints are tested. The load generator uses 64 threads and 256 connections.