mirror of
https://github.com/ajisaacs/OpenNest.git
synced 2026-10-27 19:41:08 -04:00
ajandClaude Opus 5.5
07e7d7edcd
A part with about 1,700 holes (P241017-01) never planned: material capture paired every boundary with every other one and lead checks scanned every boundary per lead, so both hit the 1M native query limit and the plate fell back to an unverified best-effort plan. - Material capture sweeps boundary extents along X and queries only pairs the lead checks' per-pair clearance cannot skip, in the full scan's order. - Material with 64+ boundaries keeps a grid of boundary extents. Lead checks, contour-joint matching and replay's contour accounting query only nearby boundaries; ray parity reads only holes on the point's row. - Only native queries that run are charged to the budget; skipped far material no longer costs its full boundary count. - The search looks up chosen holes and route ranks instead of scanning. With that the plate plans Ready, but in 189 s: every step re-emitted and re-checked all holes already cut. On parts with 64+ contours a middle hole step now checks only the contour it adds, continuing the completed-contour state its prefix left (ReleasedContourState.Continue). It falls back to the full prefix whenever it cannot continue exactly, and the last contour still checks the whole part from before it. Isolated contour emission clones only the chosen contour. P241017-01 now plans Ready in 5.4 s with an identical route, expansions and rapid travel. Core and engine suites pass; the problem-nest corpus matches the unchanged commit's outcomes and expansions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>