fix: black fascia, FAT progress restore, and persistent multi-RCB selection - #274
Conversation
There was a problem hiding this comment.
💡 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".
| if (match != null) | ||
| return null; |
There was a problem hiding this comment.
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 👍 / 👎.
Summary
Assets/black-fascia-ied.svgLED1,LED2,LED3)IsMonitoring: LIVE = bright green, first Stop = red even if MMS association is retainedIsLiveConnectedstateFAT progress restore
ARSAS-FAT-SCL-1.xsnapshots can restore across non-semantic schema revisionsRCB selection virtualization
RcbExportRow.IsSelectedremains the durable selection authorityExact combined candidate
Head:
7508d303a96baa947e17a16d2f319414e79e8042Validation:
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.