Field note /
Windows-only failure on a Unicode request
A real portfolio request failed only on Windows, because of its Unicode text. Node wrote UTF-8, but Python read it as Windows-1252. Test requests with escaped ASCII had missed the bug.
How the finding changed
Belief
Two test requests with equivalent JSON, under the same size limits, would exercise the same request path.
Evidence
Synthetic and ASCII-escaped probes passed, request sizes were far under the documented limits, and the local request builder looked healthy.
Contradiction
The real portfolio request still failed before reaching the provider. Reproducing the exact UTF-8 bytes showed Python reading child-process input as Windows CP1252, which changed Unicode text before the request was built.
Correction
Read the raw input bytes, decode them as UTF-8 on purpose, then parse the JSON. Treat the bytes actually sent as part of the evidence, separate from whether two JSON documents mean the same thing.
Current claim boundary
After the fix, one operator-run real-portfolio execution of the final acceptance check reached a deterministic pass, a semantic pass, an operational ok, resolved jev-1.13.0, and the result is advice only. That shows the tested end-to-end path. It does not show semantic calibration, factual truth, repeatability or fitness as a release gate.
Evidence
- UTF-8 bridge fix and offline subprocess probe (private repository)Private
- Live acceptance runbook (private repository)Private