Round lat/lon in executor JSON output to avoid IEEE-754 float noise

[kiki830621]

Chain pre-flight: diagnosis bypassed

• At: 2026-05-29T06:27:26Z by /idd-all-chain
• User choice: proceed anyway despite no separate diagnosis comment
• Rationale: issue body already contains root cause (raw Double → JSONSerialization 17-sig-digit rendering) + fix strategy (round to 6 dp) + the 4 affected executors. Spec is not vague; the chain's internal idd-diagnose has a concrete target.

---

Problem

Original text (from test-coverage session, 2026-05-28):
「executor 把 lat/lon 用 raw Double 丟給 JSONSerialization，25.04 會渲染成 25.039999999999999（IEEE-754 noise），影響所有吐座標的 executor（bus/bike/traffic/parking）。對 LLM 消費無害（它會 round），但不乾淨。真要修是在 executor 把座標 round 到 ~6 位小數（≈0.1m，遠夠交通用）。已在 d49eecb commit message + 測試註解記錄，留待未來 polish。」

Geo-emitting executors build their output dictionaries with raw Double
latitude/longitude values and hand them to JSONSerialization. Because
25.04 is not exactly representable in IEEE-754 binary64, the serializer
emits the full 17-significant-digit form 25.039999999999999 rather than
the clean 25.04 the source TDX data implies.

Confirmed empirically during the test-coverage work (commit d49eecb):

JSONSerialization.data(withJSONObject: ["lat": 25.04, "lon": 121.56])
=> {"lat":25.039999999999999,"lon":121.56}

(Note 121.56 happens to render cleanly — representability is value-dependent,
so the noise appears unpredictably across coordinates.)

Type

refactor (output is numerically correct, just not clean — no functional bug)

Expected

Coordinate fields in tool output render at a sane precision, e.g.
"lat":25.04, with no 17-digit float tail.

Actual

Coordinates render with IEEE-754 noise, e.g. "lat":25.039999999999999,
whenever the value is not exactly representable in binary64.

Affected executors

Every executor that emits lat / lon (or nested position) from a
RailPosition-shaped Double pair:

• bus_status_positions — BusLivePosition.busPosition
• bike_search_stations / bike_stations_nearby — station StationPosition
• traffic_cctv — CCTV Position
• parking_list_lots — CarParkPosition

Impact

Cosmetic. An LLM consuming the JSON rounds it when presenting to the user,
so end-user-visible behavior is unaffected. The noise is just ugly in the
raw tool output and in any logging / debugging that inspects it.

Suggested fix

Round coordinates to ~6 decimal places (about 0.1 m, far finer than any
transit use needs) before they enter the output dictionary. Options:

1. A small helper roundCoord(_ d: Double) -> Double { (d * 1e6).rounded() / 1e6 }
   applied at each dict["lat"] = ... / dict["lon"] = ... site.
2. A shared output-assembly helper that all geo-emitting executors call,
   centralizing the rounding in one place.

Option 2 is preferable if the rounding is the only shared concern; option 1
if a shared helper would be over-abstraction for four call sites.

Provenance

Documented in commit d49eecb (executor test coverage) message + the
testBusStatusPositionsAssemblesPositions test note, which asserts on the
stable leading digits ("lat":25.0) precisely because of this noise.

[kiki830621]

Diagnosis

Root cause — the issue's proposed fix does not work (empirically verified)

The issue proposed rounding lat/lon to ~6 decimals ((d * 1e6).rounded() / 1e6). A standalone Swift probe shows that fix is a no-op:

• 25.04 has no exact IEEE-754 Double representation; the nearest representable value is 25.039999999999999….
• roundCoord(25.04) lands back on the same bit pattern → the Double is unchanged → JSONSerialization still emits 25.039999999999999.

The noise is not a property of the coordinate value — it is a property of the serialization layer. JSONSerialization formats every Double with up to 17 significant digits. This affects every non-exact Double in every tool's output (coordinates, speeds 88.5, fares, distances), not just lat/lon.

Scope is wider than the issue framed

All 7 modules serialize via a jsonResult(_:) helper calling JSONSerialization.data(withJSONObject:), plus 2 inline sites in RailTools. A per-site coordinate patch would also miss any coordinates riding inside rail_search_stations matches and similar — the bug lives below the call sites.

Correct fix — recursive shortest-round-trippable sanitizer

• Double.description yields the shortest round-trippable string (Swift built-in).
• NSDecimalNumber(string:) lets JSONSerialization emit the clean form (25.04) while preserving the exact numeric value.

Proven safe via probe:

• Round-trip exact: parsed-back Double bit-identical to input (25.04, -121.5654, 0.1, …).
• Int/Bool untouched: case let d as Double does not match native Int/Bool in [String: Any] (NSNumber objCType: Bool stays c, Int stays q).
• inf/nan: passed through unchanged → JSONSerialization rejects them exactly as today (no regression).
• Only behavioral change: integer-valued doubles render 25 instead of 25.0 (identical JSON number, round-trips to 25.0).

Implementation strategy

1. New Sources/CheTransportMCP/Tools/JSONSanitize.swift — JSONSanitize.clean(_:) recursive sanitizer.
2. Route all 9 serialization sites (7 jsonResult + 2 inline RailTools) through it.
3. TDD: flip testBusStatusPositionsAssemblesPositions to assert clean "lat":25.04; add focused JSONSanitizeTests.

Sister observation (NOT in scope here): the 7 jsonResult helpers are byte-identical — a DRY follow-up could centralize them. Noted, not chained.

[kiki830621]

Chain verified — PR #2 open

/idd-all-chain #1 complete. Single-root chain, 0 spawned issues.

Cluster branch	idd/chain-1-round-lat-lon-in-executor-json-output-to
PR	#2 — Refs #1, not auto-closing
Commit	JSONSanitize.clean + 8 wired serialization sites + tests
Tests	111 GREEN (2 keychain-skipped, 0 failures) — RED→GREEN bus + JSONSanitizeTests + bike cross-module guard

Verified via exhaustive direct + empirical checks (round-trip exactness across the full Double domain, completeness sweep, Int/Bool/Float/NSNumber safety). The independent 6-AI verify fleet was blocked by a transient server-side rate limit on subagent spawns — re-runnable via /idd-verify #1 or /code-review ultra when it clears.

Chain stops at verified — run /idd-close #1 after reviewing PR #2.

[kiki830621]

Independent verify completed (throttle cleared)

The 6-AI fleet that was earlier rate-limited has now run: 2 independent adversarial reviewers (correctness/regression + completeness/requirement), each built the package and ran empirical probes. Both PASS — no blockers or majors.

Minors surfaced and fixed in 1ea4430 (PR #2):

• testRoundTripIsBitExact → testRoundTripIsNumericallyExact, value set expanded to the adversarial magnitudes (1e-7, 1e300, greatestFiniteMagnitude, -0.0) so committed evidence matches the claims.
• JSONSanitize doc: -0.0 sign caveat + NSDecimal exponent-ceiling fallback documented.
• PR body: all 4 raw-TDX-passthrough exempt sites disclosed (3 RailTools + maritime), not just maritime.

Still stopping at verified — run /idd-close #1 after reviewing PR #2.

[kiki830621]

PR #2 merged

Reviewed and merged (rebased onto main as 695c0ef). The fix is live on main; CI was green (test + shell jobs). #1 left OPEN for a documented close — run /idd-close #1 to write the closing summary.

[kiki830621]

Closing Summary

Problem

Tool JSON output rendered non-exact Double values with IEEE-754 noise — e.g. coordinate 25.04 emitted as 25.039999999999999. Affected every geo-emitting executor (bus positions, bike stations, traffic CCTV, parking lots) plus any other non-exact Double (speeds, fares).

Root Cause

Not the coordinate values — JSONSerialization formats every Double with up to 17 significant digits. The issue's original proposal (round to 6 dp) was a no-op: 25.04 has no exact IEEE-754 representation, so rounding lands on the same bit pattern and the formatter still emits 17 digits. The noise lives in the serialization layer and affects every non-exact Double, not just lat/lon.

Solution

New JSONSanitize.clean(_:) (Sources/CheTransportMCP/Tools/JSONSanitize.swift) recursively rewrites every Double to NSDecimalNumber(string: d.description) — the shortest string that round-trips bit-exactly — wired into all 8 sites that re-serialize codebase-built dicts (6 jsonResult helpers + 2 inline RailTools sites). The 4 raw-TDX-passthrough sites are intentionally left untouched (they forward upstream bytes verbatim, introducing no noise of ours).

Verification

• TDD RED→GREEN: flipped testBusStatusPositionsAssemblesPositions to assert clean "lat":25.04.
• New JSONSanitizeTests: numerically-exact round-trip across 13 adversarial values (incl. 1e-7, 1e300, Double.greatestFiniteMagnitude, -0.0), Int/Bool preservation, recursion, non-finite, strings/null.
• Cross-module no-noise guard added to bike nearby.
• Full suite GREEN: 111 tests, 2 keychain-skipped, 0 failures. CI green (test + shell).
• Two independent adversarial reviewers (correctness + completeness lenses) PASS — no blockers/majors; minors addressed pre-merge.

Changes

• 695c0ef — fix: emit shortest-round-trippable JSON numbers to remove float noise (merged via PR chain: fix IEEE-754 float noise in tool JSON output (#1) #2, rebased onto main)

Closing Follow-ups Filed

• Centralize the 6 identical jsonResult helpers #3 — Centralize the 6 identical jsonResult helpers (P3 refactor, out of scope here)

Distribution Sync

• Detected: plugin + mcp (GitHub binary release + marketplace plugin)
• Choice: deferred — release batched with next substantive change (cosmetic fix, no urgency)
• Pending command: /mcp-tools:mcp-deploy → /plugin-tools:plugin-update che-transport-mcp
• At: 2026-05-29T12:40:46Z

[kiki830621]

Update — release shipped (not deferred after all)

The closing summary above recorded distribution sync as deferred, but the release was cut in the same session:

• Binary: v0.2.3 — universal (arm64 + x86_64), Developer ID signed + Apple notarized (Accepted), raw CheTransportMCP asset attached for the wrapper.
• Plugin: shell bumped to 0.2.4 / binaryVersion 0.2.3 (019c607); self-marketplace synced; installed plugin updated 0.2.3 → 0.2.4.

Users get the float-noise fix after a Claude Code restart (wrapper sees binaryVersion 0.2.3 ≠ local sidecar 0.2.2 → re-downloads the v0.2.3 binary).