Spixor

Read the Spixor post here: https://spixor.com/updates/27-bu...

Last week, we shared an update about the stability work behind Spixor s visual builder.
At that point, the big systems were starting to pass:
View restoration
Layers synchronization
Normal builder boot
Settings transaction ownership
History command ownership
This week, the work became more focused.
We are now deep inside one of the hardest parts of a visual builder: making Undo and Redo behave correctly after real user actions, delayed saves, and restore callbacks all happen close together.
The visible problem sounds simple:
You make two changes.
You press Undo.
The page visually restores correctly.
Redo should still be available.
But in one specific case, a delayed save callback arrived after Undo and was being interpreted as a brand-new history action.
That could clear the Redo stack.
The frustrating part is that the UI looked correct at first. The text restored. The right view was active. The correct page was targeted. But a late internal callback could still create an extra Settings Actions snapshot in history.
So we kept narrowing it down.
What is now confirmed:
Direct text Undo stability passes.
Consecutive actions pass.
Callback overlap no longer creates duplicates.
Terminal callback rejection still works.
UID-only snapshot noise is rejected.
Omitted page titles are handled correctly.
The restore-target registry is being populated.
The restore-target guard is being evaluated.
The issue is no longer which view is this? or which command owns this?
It is now a field-level comparison issue.
The latest browser validation showed something very specific:
HTML matched.
JavaScript matched.
The page title was correctly treated as omitted.
But CSS was still being treated as different.
That means the remaining bug is not broad Undo/Redo behavior anymore. It is about how a restore callback reports omitted CSS during history validation.
In plain English:
The builder restores the right content.
The history system sees the right restore target.
But one omitted field can still make the callback look like a real new change.
That is the kind of bug we do not want to hide under good enough.
The next fix is narrow:
Treat omitted CSS/JS in restore callbacks as omitted, not as intentional clears.
Keep real CSS edits and real CSS clears working.
Keep real text edits working.
Keep real title edits working.
Keep Undo/Redo exact.
Then rerun the isolated browser validation again.
Current status:
View restoration: passed
Layers synchronization: passed
Normal builder boot: passed
Settings transaction ownership: passed
Direct text Undo: passed
Consecutive actions: passed
Callback overlap: stable enough to continue
Restore-target diagnostics: working
Page title omission handling: passed
CSS omission handling: next validation target
Broader release: not yet
This is slow work, but it is the kind of slow work that makes a builder feel reliable.
Features are easy to show.
Trust is harder.
Undo, Redo, saving, and view isolation need to feel boring. That is the goal.
We are getting closer.

It is making every action feel predictable.

Over the past week, we have continued working on the stability update we shared earlier.