[knipknap]

Upgrades the raygeo dependency from 1.68.0 to 1.73.0 and makes the rayforge-side changes the releases call for.

Release notes reviewed (1.69.0 – 1.73.0)

• 1.69.0 — exact line-and-arc toolpaths: offset_exact, profile passes that walk exact line-and-arc boundaries and emit arcs as arcs, plan_profile, ProfileRampSpec, step_over validation (plan layer), plunge feed.
• 1.69.1 — profile passes cut each ring exactly once (the closing move and the backward walk over-ran boundaries).
• 1.69.2 — core resume strategy for step-overs near the tool diameter; convergence counts only reachable material; profile stubs advertise plunge_feed_rate.
• 1.70.0 — max_entry_angle_deg entry-angle option, rest resume strategy, hostile-input guards in generate_helix_3d/generate_spiral_3d.
• 1.71.0 — entry spiral machines the whole seed disk; the ramp entry seeds its actual swath at tool width (RampSpec gains tool_radius) and keeps clear of islands; wall margin reaches the island clearance.
• 1.72.0 — cut_direction and TravelMode (SafeZ) options for clearing; descents into material carry the plunge feed; erosion pass for stranded slivers; canonical for_tool spec constructors.
• 1.73.0 — conventional (CW) clearing completes end to end; the wrong-side safehold returns RaygeoError::WrongSideCut instead of panicking; resume candidates are validated against the tool-centre envelope.

Changes

• Dependency bump (pixi.toml, requirements.txt, debian/requirements-bundle.txt, pixi.lock).
• RampEntryStep now passes its real tool radius to RampSpec (1.71.0 API): the ramp seeds its cleared area with the swath its floor-level tail machined at tool width; the previous code relied on the raygeo default of 3.0 mm, which is wrong for any tool that is not 6 mm wide. Pinned by a new test.
• Regenerated the vendored raygeo API docs from the v1.73.0 tag (no content changes — they were already current).

Behavior changes to be aware of

All changes below are raygeo's intended new defaults; every new planner option (cut_direction, travel_mode, max_entry_angle_deg, the for_tool constructors) defaults to the previous behavior, and no API rayforge uses changed in a breaking way.

• Descents into material are cutting moves now. The adaptive clearing entry descent and same-XY re-entries, and the profile pass's entry descent, were rapid-classified travels before and are now cutting moves at the plunge feed — falling back to the cut feed when no plunge feed is set. Rayforge's pipeline path (ComputePayload) carries no plunge feed field yet, so descents run at the cut feed; slower than the old rapids, but also no longer plunging into full depth at rapid rate. Forwarding the steps' configured Plunge Rate needs a ComputePayload field in raygeo — follow-up material. Inter-step aggregate links keep rapid plunges (rayforge's step groups have a single input each, so no links fire today).
• Profile inner/outer output can contain arcs (ARC_TO) even for polygon-only input: the exact offsetter rolls tangent arcs at corners that open away from the offset side. Downstream consumers were verified: the Grbl G-code encoder, the Ruida encoder, the preview converters and the simulator all handle arcs.
• Adaptive clearing coverage improves (entry crescent, core resume, erosion pass), so computed toolpaths and time estimates shift slightly.

Verification

• pixi run lint green.
• pixi run test: 7934 passed.
• pixi run uitest: 1258 passed.
• Manual end-to-end run of the CNC chain (adaptive clearing → profile inner, state-threaded, island pocket geometry) through the real raygeo pipeline: both assemblers produce sane output, no warnings.

[github-actions]

🤖 Estimated LLM implementation cost

Replayed each of the 2 commits in this pull request and counted the code lines each commit added or rewrote:

Commit	Message	Lines (add/rewrite)	Est. output tokens	Est. output cost
5d1ced00	deps: bump raygeo to 1.73.0	3 / 3	60	$0.0009
91f7582d	fix(cnc): pass the ramp step's tool radius to the ramp spec	28 / 0	280	$0.0042
Total		34	340	$0.0051

Added lines by language: Python 28, Plain Text 2, TOML 1

Full estimate

Component	Est. tokens	Est. cost
Code emission (34 add/rewrite lines)	340	$0.0051
Context input (reading touched files)	7,419	$0.0223
Conversation replay (≈15× output)	5,100	$0.0153
Prompting (pull request description)	706	$0.0021
Lower bound (output only)	340	$0.0051
Best estimate	13,565	$0.0448

Cost model: ≈10 tokens per code line at $15/Mtok output and $3/Mtok input (assuming heavy prompt caching); input ≈ 15× output for conversation replay; a review round ≈ 42,000 tokens; a failed CI run ≈ 21,000 tokens; file reads capped at 20 kB each.

Active window from first commit to merge: <1 day.

⚠️ Caveat: the lower bound covers only the tokens for emitting the code. The best estimate adds modeled overhead for exploration, conversation replay, review and debug turns, but real sessions vary by tool and task — treat it as an order-of-magnitude figure. Human engineering time is not included.