fix(ci): remove a gate that could not fail on the bug but could on correct output

Fourteenth review: APPROVE, 0 blocking and 0 important for the second round
running. Both minors are claims of mine that do not survive checking.

The buffer note I added last round said the two thread_local StringBuffers must
stay separate or the value would overwrite the key. That is wrong: RawValue copies
into the output stream before returning, so they are never live at the same time.
The reviewer merged them and got byte-identical output across 20,000 random nested
documents on both the compact and pretty paths. The note now says the duplication
is removable and gives the real (weaker) reason to keep it.

Gate 14d was worse than useless and is gone. Its exponent check read repr() of the
parsed float, and repr(1.23457e+06) is "1234570.0" — no "e" — so that branch could
never fire. Its "exactly six significant digits" check would have failed on
perfectly correct output above one second: 1000.01, 1000.02, and 448 more within
the first five seconds. A check that cannot detect the defect but can fail on
correct output is worse than no check at all.

I tried a third framing before removing it — compare digit CAPACITY across
engines, which is timing-independent and sound in principle — and it cannot
discriminate either, because the available bench operator peaks near 4 ms, four
significant digits, where %g and shortest-round-trip are identical. Reaching six
digits needs a deliberately multi-second operator.

So the honest outcome is recorded rather than papered over: all three attempts and
why each failed are written where test 14d used to be, so nobody spends a fourth,
and the property stays pinned by test_json.cpp's "trace duration magnitudes match
Go" at the magnitudes no channel here can reach. Not every property can be gated
cross-engine; saying so beats leaving a check that is permanently green or that
cries wolf.

348 Java tests, 250 C++ cases, lint, codegen-check, cross-validate 55/55,
differential-fuzz 1000/1000.

Author: Liam0205

llmdoc/reference/json-key-order-parity.md

@@ -109,6 +109,13 @@ RapidJSON 的 `Key()`，而 `Key()` 的转义表**是有** `b`/`f` 的——所
 故意跑过 1 秒的算子，对校验套件太慢。改由 `test_json.cpp` 的
 "trace duration magnitudes match Go" 直接钉格式化函数本身。
 
+**这条属性尝试过三种通道级检查，全部失败，脚本里记了原因以免第四次尝试**：比数值不行（是计时）；
+比形状不行（指数分支读的是 `repr()` 解析后的 float，`repr(1.23457e+06)` 是 `1234570.0` 不含 `e`，
+永远不触发；而「恰好 6 位有效数字」分支会对**正确**输出误报——1 秒到 5 秒之间就有 450 个这样的值）；
+比跨引擎的「有效数字容量」原理上成立，但手头最慢的 bench 算子只到 4 ms 即 4 位有效数字，
+`%g` 与最短往返在那个量级根本无从区分。**结论：不是所有属性都能在跨引擎通道上钉住，
+承认这一点比留一个恒绿或会误报的检查更好。**
+
 纪律：**同一个字符串属性（转义、排序、数字拼写）在一个运行时里出现第二份实现时，第一反应应该是
 合并，而不是把规则抄一遍。** 抄一遍等于把「两处必须同步」这个约束交给未来的人记住，而本任务连续
 两轮证明了没人记得住。

pine-cpp/src/config/json_writer.hpp

@@ -147,9 +147,16 @@ inline void write_go_string(rapidjson::StringBuffer& sb, const std::string& s) {
 // NOTE: write_json_value's string branch below repeats this same three-line
 // shape (clear a thread_local buffer, write_go_string into it, emit as
 // kStringType). That is boilerplate duplication, not a second copy of the
-// escaping RULES — those live only in write_go_string. The two buffers must stay
-// separate: a key and its value are both live within one write_json_value call,
-// so sharing one buffer would have the value overwrite the key.
+// escaping RULES — those live only in write_go_string.
+//
+// An earlier version of this note claimed the two buffers MUST stay separate
+// because a key and its value are both live in one write_json_value call. That
+// is wrong: RawValue copies into the output stream before returning, so the two
+// are never live at once, and merging them was measured to leave 20,000 random
+// nested documents byte-identical on both the compact and pretty paths. The
+// duplication is therefore removable, not load-bearing — the reason to leave it
+// is only that a shared buffer makes the lifetime harder to reason about, not
+// that sharing breaks.
 template <typename Writer>
 inline void write_go_key(Writer& w, const std::string& key) {
   thread_local rapidjson::StringBuffer key_buf;

scripts/cross-validate/06-server-http.sh

@@ -715,82 +715,29 @@ print(json.dumps([shape(x) for x in snaps]))"
     fail "server HTTP: trace input_snapshot key order divergence (Go=$snap_go, Java=$snap_java)"
   fi
 
-  # Test 14d: trace duration_ms NUMBER FORMAT. The value is timing and therefore
-  # not comparable, but its spelling is: Go marshals float64 with
-  # shortest-round-trip, so it never uses exponent notation in this range and
-  # never truncates to 6 significant digits. snprintf("%g") does both — 1234.567
-  # became 1234.57 and 1234567 became 1.23457e+06 — and no channel could see it,
-  # because every one of them strips duration_ms as timing. This checks the shape
-  # instead of the number, which is deterministic.
-  srv_total=$((srv_total + 1))
-  dur_shape_cmd="import json, re, sys
-d = json.loads(sys.stdin.read())
-bad = []
-for t in d.get('trace', []):
-    raw = t.get('duration_ms')
-    txt = repr(raw)
-    if 'e' in txt.lower():
-        bad.append('exponent notation: ' + txt)
-    digits = re.sub(r'[^0-9]', '', txt).lstrip('0')
-    if len(digits) == 6 and float(raw) >= 1000:
-        bad.append('suspiciously exactly 6 significant digits: ' + txt)
-print('ok' if not bad else '; '.join(bad))"
-  # Uses its own config with transform_bench_cpu so the duration is non-trivial.
+  # Test 14d intentionally does not exist.
   #
-  # Honest limit of this check: duration_ms has microsecond resolution (at most
-  # three decimals), so "%g" and shortest-round-trip only disagree once the value
-  # exceeds 1000 ms. A 400k-iteration bench operator measures about 4 ms, so this
-  # check confirms the shape is exponent-free and untruncated but does NOT go red
-  # against snprintf("%g") — verified by mutation. Making it discriminate would
-  # need a deliberately >1s operator, which is too slow for this suite. The
-  # formatter itself is pinned by test_json.cpp's
-  # "trace duration magnitudes match Go" case instead.
-  DUR_CONFIG="$WORK_DIR/dur_config.json"
-  python3 -c "
-import json
-cfg = {'pipeline_config': {'operators': {'slow': {'type_name': 'transform_bench_cpu',
-        'iterations': 400000, 'debug': True,
-        chr(36)+'metadata': {'item_input': [], 'item_output': []}}},
-       'pipeline_map': {'s': {'pipeline': ['slow']}}},
-       'pipeline_group': {'main': {'pipeline': ['s']}}}
-with open('$DUR_CONFIG', 'w') as f:
-    json.dump(cfg, f)
-"
-  DUR_GO_PORT=18031
-  DUR_JAVA_PORT=18032
-  DUR_CPP_PORT=18033
-  "$WORK_DIR/pineapple-server" -config "$DUR_CONFIG" -addr ":$DUR_GO_PORT" >/dev/null 2>&1 &
-  dur_go_pid=$!
-  java -cp "$JAVA_CP" -Dpine.config="$DUR_CONFIG" -Dpine.port=$DUR_JAVA_PORT page.liam.pine.PineServer >/dev/null 2>&1 &
-  dur_java_pid=$!
-  dur_cpp_pid=""
-  if [[ -n "${CPP_SERVER:-}" ]]; then
-    "$CPP_SERVER" -config "$DUR_CONFIG" -addr ":$DUR_CPP_PORT" >/dev/null 2>&1 &
-    dur_cpp_pid=$!
-  fi
-  srv_ready $DUR_GO_PORT || fail "server HTTP: 14d Go server not ready"
-  srv_ready $DUR_JAVA_PORT || fail "server HTTP: 14d Java server not ready"
-  DUR_REQ='{"common":{"_return_trace":true},"items":[{"id":"a"}]}'
-  go_dur=$(curl -s -X POST -H "Content-Type: application/json" -d "$DUR_REQ" "http://localhost:$DUR_GO_PORT/execute" | python3 -c "$dur_shape_cmd" || echo parse_error)
-  java_dur=$(curl -s -X POST -H "Content-Type: application/json" -d "$DUR_REQ" "http://localhost:$DUR_JAVA_PORT/execute" | python3 -c "$dur_shape_cmd" || echo parse_error)
-  if [[ "$go_dur" == "ok" && "$java_dur" == "ok" ]]; then
-    srv_pass=$((srv_pass + 1))
-    echo "    [14d] POST /execute (trace) → duration_ms number format Go and Java both shortest-round-trip"
-  else
-    fail "server HTTP: duration_ms number format (Go=$go_dur, Java=$java_dur)"
-  fi
-  if [[ -n "${CPP_SERVER:-}" ]] && $cpp_srv_ready; then
-    cpp_srv_total=$((cpp_srv_total + 1))
-    cpp_dur=$(curl -s -X POST -H "Content-Type: application/json" -d "$DUR_REQ" "http://localhost:$DUR_CPP_PORT/execute" | python3 -c "$dur_shape_cmd" || echo parse_error)
-    if [[ "$cpp_dur" == "ok" ]]; then
-      cpp_srv_pass=$((cpp_srv_pass + 1))
-      echo "    [14d] POST /execute (trace) → duration_ms number format Go vs C++ match"
-    else
-      fail "server HTTP: duration_ms number format C++ (=$cpp_dur)"
-    fi
-  fi
-  kill $dur_go_pid $dur_java_pid ${dur_cpp_pid:-} 2>/dev/null || true
-  wait $dur_go_pid $dur_java_pid ${dur_cpp_pid:-} 2>/dev/null || true
+  # trace[].duration_ms goes through go_format_json_number so its spelling matches
+  # Go's shortest-round-trip rather than snprintf("%g")'s six significant digits.
+  # Three attempts were made to gate that here, and all three failed for the same
+  # reason, which is worth recording so nobody spends a fourth:
+  #
+  #   1. Compare the value: impossible, it is timing.
+  #   2. Compare its shape (exponent present, digit count): the exponent branch
+  #      could never fire, because it inspected repr() of the PARSED float and
+  #      repr(1.23457e+06) is "1234570.0"; and the digit-count branch would have
+  #      failed on CORRECT output above one second (1000.01, 1000.02, and 448 more
+  #      in the first five seconds).
+  #   3. Compare digit CAPACITY across engines: sound in principle, but the
+  #      available bench operator peaks around 4 ms, i.e. four significant digits,
+  #      so %g and shortest-round-trip are indistinguishable there. Reaching six
+  #      digits needs a deliberately >1s operator, too slow for this suite.
+  #
+  # duration_ms carries at most three decimals (duration_us / 1000.0), so the
+  # divergence only appears once the integer part reaches four digits. The
+  # formatter is therefore pinned directly by test_json.cpp's "trace duration
+  # magnitudes match Go", which asserts 1234.567, 1000.001 and 1234567 — the
+  # magnitudes this channel cannot reach.
 
   # Test 15: Content-Type header parity across endpoints
   srv_total=$((srv_total + 1))