Borrowing a solver instead of rewriting the rules — NOVEMADE

A browser demo normally reimplements just enough of the product to look right. That is fine until the interesting part of the product is a rule that is easy to describe and hard to get right — at which point the rewrite quietly ships a worse version of the thing being advertised.

Glow Garden is exactly that case. Its rule reads like a puzzle cliché: one firefly per row, per column, per coloured region, none touching. But the game does not check placements against those rules. It asks a solver whether the board can still be completed, and refuses the tap if it cannot. That means a placement can be legal in isolation and still be rejected, which is what makes the game feel fair instead of arbitrary — and it is precisely the subtlety a rewrite would have flattened.

So instead of rewriting, the rule core was copied out of the app unchanged, its hash recorded, and a typed boundary put in front of it so the build breaks if the original ever drifts. The same approach then worked for Veyra’s stencil function.

Findings so far.

The part worth copying is rarely the part that looks complicated. It is the part where a plausible reimplementation would be subtly wrong and nobody would notice.

Vendoring needs a boundary, not just a copy. A hand-written typed surface in front of the borrowed code is what turns "it drifted" from a silent behaviour change into a failed build.

It only works where the logic is already pure. Both pieces that transplanted cleanly had no imports and no framework underneath them, which is a property you get by writing them that way, not by wishing for it later.

A fixed board still needs the real generator’s guarantee. The demo board was searched for with the app’s own solver until one with exactly one solution appeared, rather than hand-drawn and hoped over.

Findings so far.

See it working