Skip to content

fix: black fascia, FAT progress restore, and persistent multi-RCB selection - #274

Merged
masarray merged 8 commits into
mainfrom
fix/black-fascia-fat-progress-restore
Sep 8, 2026
Merged

masarray merged 8 commits into
mainfrom
fix/black-fascia-fat-progress-restore

Conversation

@masarray

@masarray masarray commented Sep 8, 2026 •

Copy link
Copy Markdown
Owner

Summary

  • replace the runtime IED fascia transcription with Assets/black-fascia-ied.svg
  • keep three high-visibility runtime LEDs aligned with SVG metadata intent (LED1, LED2, LED3)
  • Engineering LEDs follow IsMonitoring: LIVE = bright green, first Stop = red even if MMS association is retained
  • FAT cards keep the equivalent IsLiveConnected state
  • fix Engineering -> FAT local progress continuation for the same SCL content
  • preserve fail-closed evidence restoration using IEC 61850 point configuration matching
  • fix Legacy SAS multi-RCB checkbox selection being lost when the WPF DataGrid virtualizes/recycles rows during scrolling

FAT progress restore

  • SCL continuation can match by normalized source-content SHA-256 when filename/staged source identity changes
  • compatible ARSAS-FAT-SCL-1.x snapshots can restore across non-semantic schema revisions
  • exact TestPointId remains first priority
  • fallback continuation requires a unique IEC/configuration match
  • workbook/package source matching remains strict
  • ambiguous candidates are not restored

RCB selection virtualization

  • RcbExportRow.IsSelected remains the durable selection authority
  • virtualization-generated Checked/Unchecked events are prevented from reaching the stale single-select XAML handlers
  • click, checkbox, Space and Shift-range behavior stays on the existing P1 multi-select path
  • virtualization remains enabled; no visual checkbox/container state is persisted

Exact combined candidate

Head: 7508d303a96baa947e17a16d2f319414e79e8042

Validation:

  • Build ARSAS #2187 — SUCCESS
  • full regression suite — SUCCESS
  • portable publish — SUCCESS
  • portable smoke test — SUCCESS
  • Validate IO List Testing #1049 — SUCCESS
  • Validate SV evidence bundles #1273 — SUCCESS

Diff audit against main base c424314ab1b1e6c6003a2b4e93a07d78c9d570d0: 10 files only; no ARIEC engine pin, protocol stack, GOOSE/SMV runtime, command/control backend, release metadata, or unrelated UX files changed.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 834419def8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +181 to +182
if (match != null)
return null;

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Preserve continuation after repeated source renames

When identical SCL bytes are first opened as file A and then reopened as file B, the cross-identity restore leaves A's snapshot in place while persistence creates a new snapshot for B. Reopening the same bytes under a third filename makes this scan find both snapshots and return null, so FAT opens a fresh workspace and fails to restore the operator's progress. Migrate or retire the consumed snapshot, or recognize snapshots belonging to the same continuation lineage rather than treating the duplicates created by this flow as ambiguous.

Useful? React with 👍 / 👎.

@masarray masarray changed the title fix: use black IED fascia and restore FAT progress across Engineering fix: black fascia, FAT progress restore, and persistent multi-RCB selection Sep 8, 2026
@masarray
masarray merged commit 8b07144 into main Sep 8, 2026
3 checks passed
masarray added a commit that referenced this pull request Sep 8, 2026
Release metadata only. Runtime content is the field-accepted mainline from PR #274. PR #277 passed Build ARSAS #2191 and Windows installer validation #721 before merge.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant