The second version of the project looks narrower and smarter.

After the first market-facing phase stalled out, the evidence does not suggest I gave up on the whole idea. It suggests I came back to it with a different product shape, a different notebook runtime, and a stronger bias toward operational coherence.

That second phase is where jar candles show up, marimo takes over from Jupyter, and the project starts looking less like “keep refining the same pillar candle forever” and more like a partial reboot.

Context

The pivot is visible in the notes pretty clearly.

By 2026-02-28, I had written:

Goal: Jar candle

That is a big shift.

A jar candle changes a lot of the constraints:

• the product reads differently
• the container takes over some of the structural burden
• the mountain form becomes an inserted object or adapted internal geometry
• packaging and giftability shift too

At roughly the same time, the software stack was also changing under my feet.

So naturally, instead of one pivot, I got two at once.

Excellent project management. No notes.

Problem

The first-generation stack had become powerful, but also heavy and shaped around Jupyter-era assumptions.

The project now needed:

• a narrower, more viable product direction
• a map interaction layer that fit the newer runtime
• a mesh viewer that was lighter than the full CAD stack where possible
• a CAD viewer bridge that could survive outside the old notebook host model
• higher-level CAD integration that matched the new viewer path
• better operational structure around repeated geometry work

That is not a tiny refactor. That is a second-generation tooling project.

Investigation

The supporting repos tell this story really well.

cad-viewer-widget fork

This is the heavy viewer-bridge migration work.

The branch-local commits from master..HEAD show a focused sequence:

• 9c0de77 (2026-04-14 09:40 -07:00) — nix dev env
• 92d953c (2026-04-14 10:12 -07:00) — Set up migration for marimo
• milestone commits through a working OCC bottle example
• cleanup, serializer fixes, interaction refactor, lifecycle fixes, path/build fixes

This looks like the grunt work of getting a CAD widget out of Jupyter-specific hosting and into a marimo-compatible anywidget-ish world.

jupyter-cadquery fork

This is the higher-level integration layer being pulled toward marimo-cadquery:

• scaffolding
• working CAD viewer path
• example fixes
• explicit rename toward marimo-cadquery

That tells me the migration was not only about low-level widget glue. It was also about preserving a useful end-user CAD workflow on top of the new bridge.

marimo-leaflet

This fills the missing map/region editing role:

• rectangle workflow
• GeoJSON handoff
• referrer fixes
• hillshade later on

This is a pretty good example of doing the narrow useful thing instead of rebuilding a giant GIS app for no reason.

marimo-mesh-viewer

This one is delightfully focused.

It appears to exist because sometimes a full CAD viewer is too much, and I just need a lightweight way to render triangle meshes in marimo without carrying the whole cathedral around.

jupyter-gis and wax-cam

Meanwhile the main repos are migrating too:

• jupyter-gis switches toward marimo in April 2026
• wax-cam gets a marimo refactor and later disk-caching / Operations.py work in early May 2026

And then there is the lovely note on 2026-04-29:

Migrated ui_save_geojson to marimo-leaflet, migrated ui_show_mesh to marimo-mesh-viewer

That line is fantastic because it ties the notes to the adjunct repos directly. It is not abstract architecture theorizing. It is evidence of the actual pieces being moved.

The product pivot is happening too

At the same time, the Dropbox evidence shows the product itself changing:

• later pours move into jar-related work
• mold entries become jar-sized or Bachelor/Hood jar variants
• notes talk about metal sizing and jar dimensions
• 2026-05-01 says “Ok. It’s working” and mentions a spoked candle sliced in Elegoo
• 2026-05-02 records a failed silicone-on-resin result and storefront actions on Wix and Etsy
• 2026-05-13 mentions wanting to build a wax injector

That last one, plus the giant WaxPump/ directory in Dropbox, suggests that the second-generation project is not just “new candle shape.” It is also “how do I make the production mechanics less goofy?”

What changed

This phase changes three important things at once.

1. The product gets narrower

Jar candles appear to be a more grounded second target than a fully standalone mountain pillar as the flagship form.

2. The toolchain gets rebuilt around marimo

Instead of dragging old Jupyter assumptions forever, the project starts making purpose-built replacements:

• map widget
• mesh viewer
• viewer bridge
• CAD integration branch

3. Operations become more explicit

This is where Operations.py and disk caching land in wax-cam:

• 404af0a (2026-05-05 23:16 -07:00) — operations strategy
• 556ecae / 832888f / 1e93b54 — memoization, timing, disk caching

That is not cosmetic. It suggests the second-generation system cares a lot about keeping iteration under control.

Results

I do not think the evidence shows a final, stable endpoint yet.

What it does show is real momentum in a more focused direction:

• jar candle geometry exists
• the marimo migration is no longer hypothetical
• adjunct repos are doing actual work, not just collecting TODOs
• storefront actions are happening again
• production mechanics are being revisited

That is enough to say the second act is real.

Trade-offs

Doing a product pivot and a runtime migration at the same time is, objectively, a little feral.

But I can also see the logic.

If the goal is to build the next version of the project rather than preserve the previous one forever, then sometimes it makes sense to absorb the disruption once and rebuild around the direction I actually want.

More work up front, less inherited fuss later.

At least that is the dream.

What this actually enabled

This phase seems to enable a more coherent next version of the project:

• more focused product form
• cleaner runtime foundation
• purpose-built map and mesh tools
• higher-level CAD integration aligned with the new stack
• more serious caching / operations thinking
• renewed commercialization activity, but hopefully with better judgment about where and how the thing should be sold

Where this leaves the project

The evidence does not give me a perfect ending.

What it gives me is something more believable:

• a first version that learned a lot
• a market contact that clarified what was not working
• and a second version that came back sharper, more constrained, and technically cleaner in the places that mattered most

Honestly, that is a pretty good result.

The first version proved the idea had something in it. The second version looks like the one trying to become practical.