Read the update on Spixor.com here: https://spixor.com/updates/31-bu...

In our previous update, we talked about gradually returning to a more consistent rhythm of visible Spixor updates.

Since then, we have continued working on the systems behind Spixor and that work has made something increasingly clear:

Read the update directly on the Spixor Website here: https://spixor.com/updates/30-th...

It has been a little quieter on the update side of Spixor over the past several weeks.

We re building something behind the scenes at Spixor. It s called Spixor Forge.

We have been quieter than usual for almost two weeks.

Development did not stop. We made a deliberate decision to pause smaller progress updates while changing the foundation underneath Spixor. Over time, parts of the public website and its visual experience grew through many separate improvements.

Last week, we shared that our next phase would focus on improving the public website, refreshing the Settings panel and making the Builder feel smoother and easier to use.

This week, most of our attention stayed on the first part of that plan: the Spixor website.

We have been rebuilding and polishing the homepage so it does a better job of showing what Spixor is, how the product feels and where we want to take it. A visual website builder should not be introduced through a website that feels static or unclear, so we are putting more care into the way the product is presented.

A large part of the work has gone into the overall visual experience:

Over the last phase, we spent a lot of time stabilizing the core builder experience. A big part of that work was focused on undo/redo, history handling, page switching, builder state consistency and several smaller bugs that could make the editing experience feel less reliable than we wanted.

Those fixes are important, because Spixor should feel safe to use before we keep adding more visible features.

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.

We recently found one of those bugs users may never fully see but immediately feel.

Under a very specific timing condition, an inactive view could wake up and create two internal generations during what should have been a single loading transaction.

The visible symptoms could be subtle: