Matt 0b5e15e2b9 fix: continue the plane depth count through model geometry ...

A construction plane built from model geometry resolves each of its sides
through the document again. That hop restarted the recursion depth at 0, so a
plane that is its own side never exceeded depth 1 and the 32-level cap never
fired: a ~600-byte design file recursed until the stack overflowed and the
process aborted, which no panic guard can intercept.

Carry the depth on the construction context so the geometry arms continue the
caller's count instead of restarting it.

Fixes #143

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit 4bca1d49f27dfe9ef0140132746e1c7415daba8e)

2026-10-11 08:22:07 -07:00

..

corpus

Command ids are SolveCraft's own: 173 ids that were another product's internal command ids become dotted, lower-case ids (<area>.<thing>[.<variant>]: solid.extrude, sketch.rectangle.two_point, sheet.flange, joint.drive, ...), in the registry, toolbar, dialogs, shortcuts, palette, control channel, MCP, examples, scenarios and docs

2026-10-09 12:17:23 +00:00

design_corpus.rs

fix: continue the plane depth count through model geometry

2026-10-11 08:22:07 -07:00

fuzz_range.rs

fix: validate fuzz seed ranges without overflow

2026-10-11 00:41:49 +02:00

kill_mid_save.rs

Faster tests: hostile_params_never_panic shares its commands across threads (154 s to 20 s), the design-file fuzz test tries its seeded cases on all cores (21 s to 7.5 s), the kernel's tangent-primitive boolean test runs its three seeds at once, and the headless scenario harness skips the software viewport render it threw away every frame (scenarios 63 s to 26 s). kill_mid_save waits for the saver to reach a varying round instead of sleeping a fixed time, so it holds on a busy machine

2026-10-10 13:24:08 -04:00