Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions docs/WORKBENCH_CURRENT_HANDOFF.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,17 @@
> **Primary strategy and ownership contract:** [WORKBENCH_ARSAS_GUI_SSOT_STRATEGY.md](WORKBENCH_ARSAS_GUI_SSOT_STRATEGY.md).
> **Scope:** installed native ARStack Workbench in apps/ied_simulator. Not a web app, WPF clone, or the separate ESP32-P4/SMV Studio track.

## P0 negotiated NameList wire pipeline — 2026-10-16 (WIB)

- **Actual main at integration:** `47f9966edc07d5ef391d149b0ac60bc259b5bd11` after [PR #197](https://github.com/masarray/arstack61850/pull/197), source head `88ba0419af3866938be7a69c57cdc6cea6c56457`. **13/13 exact-head workflows SUCCESS** including C++ GCC/Clang/MSVC, native IED Simulator Qt, Security and Evidence, SCL-assisted, MMS/RCB, interoperability, and Product Naming Guard. Automated review issue about strict GCC aggregate initialization was corrected and marked resolved. Post-merge `main` workflows were still active at the checkpoint; independently verify results on their actual SHA.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Retire the superseded “latest” checkpoint

When an engineer uses this handoff to resume work, the new integration record conflicts with the still-active section immediately below: line 9 identifies 47f9966e as the integrated main, while lines 18–24 still call aae37327 the “Latest accepted P0 checkpoint” and instruct readers to implement the negotiated pipeline that the new section says is already merged. Mark that older section as historical/superseded so the handoff does not direct follow-up work from stale state.

Useful? React with 👍 / 👎.

- **Implementation:** portable native C++ `MmsAssociationRuntime::exchange_confirmed_batch` sends whole confirmed P-DATA frames on one association owner, then receives through the existing authoritative receive primitive; exact invoke-ID correlation handles out-of-order responses, duplicates/unregistered IDs fail closed, and asynchronous InformationReport remains on the original bounded queue. Each complete send has a per-batch receipt even when later timeout/fault occurs. No concurrent `exchange_confirmed` threads, second decoder, worker pool, timers, or hidden MMS Write.
- **Safety contract:** strict positive decoded peer MMS Initiate-Response `maxOutstandingCalling` is a prerequisite for any batch window above 1. If unknown/tolerant, **fallback is serial** despite compatibility defaults. Effective GetNameList window = min(explicit request, verified peer calling window, internal hard cap 8). The batch call is synchronous and single-owner: it is not safe to invoke other receive/poll methods concurrently. Pagination on each chain stays sequential, bounded and fail-closed.
- **Discovery behavior:** independent per-domain NamedVariable and NamedVariableList chains are opt-in; existing Workbench/controller default remains serial to preserve field compatibility. Read-only bench CLI: `ariec61850_live_discover <ied-ip> --name-list-window 4` (range 1..8, default 1). Model/raw FC identity stays canonical; completed evidence only is published. Summary exposes completed confirmed-request wire budget and `nameListPeakOutstanding` without extra network traffic.
- **Regression evidence:** 48/48 CTest PASS on GCC and Clang. Focused tests verify VMD+two-domain model parity and equal six NameList sends between serial and four-chain operation; page continuation after the prior response; out-of-order invoke routing; interleaved InformationReport; bad continuation, rogue/duplicate IDs, over-window refusal, loss/timeout and reconnect/send-receipt semantics. No real IED timing speedup claimed from scripted transport.
- **Other observed CI issue (independent):** Workbench Release Hardening on `main bcbebc32` failed *before build* because Chocolatey/NSIS dependency download returned HTTP 503; Linux release-soak succeeded. Treat as packaging environment incident, not evidence of MMS/Qt regression. Re-verify installer separately.
- **Next highest-value work:** same-relay repeated serial/window=2/window=4 captures with SCL and model fingerprint, completeness, wire budget, `maxOutstandingCalling`, elapsed discovery latency, time-to-first-usable model, CPU/memory, reconnect and report/RCB behavior. Only after physical interoperability evidence consider exposing the opt-in to native Workbench. Long-term association-wide concurrent requester APIs still require an explicit shared lifecycle/receive-pump contract; the current batch API is intentionally single-owner.
- **Acceptance remaining:** exact post-merge `main` gates; physical IED and installed Windows Workbench bench runs; measurement of speedup; ESP32-P4 PTP/SV qualification is unrelated. Do not merge the separate Studio scope into the native Workbench.

## Latest accepted P0 checkpoint — 2026-10-16 (WIB)

- **Main HEAD after integration:** `aae37327d8e9c40314f4a86b6127a12d38248420` (merge of #187). This supersedes the older baseline in the historical section below; always re-query GitHub before further writes.
Expand Down
Loading