Skip to content

Hand build mode the step you were watching - #6

Merged
thebuilder merged 2 commits into
mainfrom
feat/build-mode-state-persistence-e5eaf9
Aug 27, 2026
Merged

thebuilder merged 2 commits into
mainfrom
feat/build-mode-state-persistence-e5eaf9

Conversation

@thebuilder

Copy link
Copy Markdown
Owner

Watching a model to step thirty and pressing Build put you on an empty floor at step one. Both flows share a step in the URL, and build mode ignored it and read only the saved build, so the one gesture that means "I want to do this part myself" threw away the part you had just found.

The rule

Entering a build weighs two claims about how far in you are, the saved build and the step on screen, and the further one wins:

you are the save says you get
watching step 30, no save - step 31, thirty steps built
watching step 3, save at 200 200 step 201, the save's pile restored
opening ?flow=build from the gallery 40% in where you left off, as before
watching the finished model - the last step, not a finished build

Scrubbing back to look at something never discards a build that had already reached step two hundred. The watched step stops one short of the end, because playing a model through and then pressing build is a normal way to arrive here, and a finished model with nothing left to do is a dead end.

What it took

Starting at a step nobody placed by hand needs two things to follow it:

  • BuildSession.restore fills in every step before the one it starts at. That was already the rule per bag; this is the same argument one level finer, since a step cannot be left until every slot in it is filled.
  • LiveWorld.pour skips bricks the build already holds, so beginning partway into a bag does not tip out pieces that are standing in the model. Every brick still takes its turn of the random draw, so the rest land exactly where a full pour would have put them.

The parts list

It opens on Step in build mode and back on All in watch. Build mode asks one question, "what am I looking for now", and that is the panel that answers it.

For it to answer correctly the step has to reach React, so entering a build reports its step upward when it differs from the URL. That also makes the resume notice precise: "Picked your build up at step N" now appears only when picking the build up actually moved you, rather than on every deep link into a build.

Verifying

Driven in a real browser rather than the in-app pane, which freezes requestAnimationFrame:

  • Gatehouse watched to step 7, then Build: step 7 / 24, 23 / 128 placed, 105 on the floor, parts panel on Step showing the 8x Brick 1x1 it needs.
  • A save at step 7 beat a scrub back to step 2, with the pile restored where the save left it.
  • The car watched to its last step handed back step 8 / 8 with the wheels and roof on the floor, not a finished model.
  • "Start over" resets to step 1 and the parts panel follows.

513 tests pass (pnpm test), tsc --noEmit and ultracite check are clean, and next build succeeds.

Watching a model to step thirty and pressing build put you on an empty floor
at step one. The two flows share a step in the URL and build mode ignored it,
reading only the saved build, so the one gesture that means "I want to do this
part myself" threw away the part you had just found.

Entering a build now weighs two claims about how far in you are, the saved
build and the step on screen, and the further one wins. Watching thirty steps
hands you step thirty-one with those thirty already in the model; scrubbing
back to look at something does not quietly discard a build that had reached
step two hundred. The watched step stops one short of the end, because playing
a model through and then pressing build is a normal way to arrive here and a
finished model with nothing left to do is a dead end.

Starting at a step nobody placed by hand needs two things to follow. A
BuildSession restored to a step fills in every step before it, which was
already the rule per bag and is the same argument one level finer: a step
cannot be left until every slot in it is filled. And a pour skips the bricks
the build already holds, so beginning partway into a bag does not tip out
pieces that are standing in the model; every brick still takes its turn of the
random draw, so the rest land where a full pour would have put them.

The parts list opens on Step in build mode and back on All in watch, since
build mode asks one question and that is the panel that answers it. For it to
answer correctly the step has to reach React, so entering a build reports its
step upward when it differs from the URL. That also makes the resume notice
precise: it now appears only when picking a build up actually moved you, rather
than on every deep link into a build.
@vercel

vercel Bot commented Aug 27, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
ldraw-builder Ready Ready Preview Aug 27, 2026 12:43pm

Deciding where a build begins is its own question, and folding it into a
method that also creates a world, seeds a session, opens a bag and frames a
camera pushed that method past the cognitive complexity the audit allows.
It now returns the four things the start is: which step, which slots inside
it are filled, whether there is a pile to put back, and whether any of that
is worth announcing. No behaviour changes.
@thebuilder
thebuilder marked this pull request as ready for review August 27, 2026 12:52
@thebuilder
thebuilder merged commit 81ecafc into main Aug 27, 2026
3 checks passed

This branch was successfully deployed

1 active deployment
Preview — 41af1ab5 Deployed Aug 27, 2026 by vercel[bot]
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