[soulteary]

Publication

Released in v0.3.10, together with follow-up #24. A post-merge release audit found that missing verified angle feedback could add a successful latency sample; #24 corrects that case and protects dispatch-only L20 writes. The signed v0.3.9 tag remains unchanged and has no Release or binary publication. Final merged-source CI, complete A+ analysis, twelve-target acceptance and all 26 published asset checks passed; the full verification record is in #24.

Changes

Under the explicit Python policy, health could count wire stages as completed transactions, count report publications as polling feedback, and expose native totals without an active polling plan. This patch projects these statistics using the Python SDK's logical boundaries.

• Count completed reads and eligible feedback once per resolved query. Keep command-feedback policies distinct. Stopped plans report zero polling counters; equivalent plans preserve the measurement window and disabled optional queries retain completed counts.
• Record one successful logical transaction from first Session submission through completion, including send waiting and multi-stage execution. Partial stage success does not clear a failed logical chain. Retain the latest 2048 successful durations per device across close, reopen and recovery, using Python nearest-even percentile indices.
• Add force-field health with requested rates, resolved query rates, achieved rates and observed support. Optional PollingChannel::force_fields entries preserve field intent; shared queries use the fastest requested interval. L20Lite scalar categories retain independent queries. Invalid plans are rejected before replacement. Native policy rejects the new selector.

The added metrics store owns no transport or scheduler. All physical frames continue through the existing Session.

Compatibility

Existing C++ method signatures and Native defaults remain available. Public structures have appended fields: rebuild the SDK and downstream consumers with matching headers and libraries. Binary compatibility with older headers is not claimed. The minimum and paired transport remain v0.3.4 (0e190032d65ed0b315337b45b3779cf4f650ed68).

Reference Python source: 3a63e723b9a0046e9a60a58339b9f064ef5b70fd. This is the source used for comparison, not a claimed deployment-build SHA.

Validation

• 14 new offline cases / 130 assertions; all 10 local CTest groups passed. Coverage includes polling windows, feedback policies, shared force queries, descriptor support, invalid-plan preservation, multi-stage success/failure, queued sends, late completion, identity rejection and per-device history on a shared Session.
• 6144 latency-window updates matched an independent Python oracle and the reference SDK's actual RuntimeMetrics. 27 reference Python tests passed. Installed-package consumer and documentation/helper checks passed.
• CI: GCC Debug/Release, Windows x64 Debug/Release and ASan/UBSan.
• Prebuilt transport consumers: x86_64 and ARM64 with transport v0.3.4.
• Complete static analysis: downloaded report independently checked; A+, score 100, zero diagnostics; 619/619 formatting files and 362/362 units for each analyzer.
• Release acceptance: all twelve native Ubuntu/Windows targets and complete asset collection.

An initial ARM64 Debug run reached the aggregate communication process's 120-second deadline. Python-policy regressions now run in a separate bounded group: the original 1053 communication cases partition into 935 + 118 without omissions or duplicates. Acceptance budgets and assertions are unchanged. The final ARM64 Debug evidence records 104.51 seconds for comm and 14.89 seconds for python-policy-regressions, with all 19 offline acceptance entries passed. An initial local run also reproduced the previously recorded Native L20Lite polling restart race; the unchanged isolated case and subsequent complete runs passed.

Scope

No new physical-device acceptance is claimed. Adapter/driver and firmware combinations, physical timestamps, mixed CAN/FD topology, hardware timing/throughput and extended multi-device operation remain subject to separate hardware validation. O20, Python bindings and hand/arm integration are excluded. Tactile-stage scheduling, remaining identity metadata and automatic reconnect remain separate work.