[denelson1-dot]

Ports unit blend.fillet_solver_p3 (SmFilletSolver.cpp part 3) into blend::fillet_solver::p3:

Rust	Upstream
FilletSolver::step_solve	SmFilletSolver::StepSolve
FilletSolver::split_and_trim_fillet_surface	SmFilletSolver::SplitAndTrimFilletSurface
FilletSolver::process_full_roll_over	SmFilletSolver::ProcessFullRollOver
FilletSolver::other_fillet_corner	SmFilletSolver::GetOtherFilletCorner
find_fillet_tsect_pnt	sm_FindFilletTsectPnt
refine_rail_curve_classification	sm_RefineRailCurveClassification
calc_rail_x_edge	sm_CalcRailXEdge

Status: partial. It cannot merge before its dependencies.

Dependencies (not re-ported)

This branch builds on #147 (blend.fillet_geom_p1, head b396cdd3, now on main through #156) and merges the head branch of the open dependency PR #192 (blend.fillet_solver_p1, head e6f4d026; main carries its older head a88c62af through #256), per AGENTS.md §4. #192 now carries its own reconciliation with main's offset surface, so its files are taken as they are. With both PRs merged in, the affected difftests have 0 failures.

Changes outside the unit

• FilletSolverOps gains solver_type (GetSolverType, pure virtual upstream) and constant_distance (the SmConstantDistanceFS::GetDistance read in SmFindClippedRadiusEFO). The custom solvers' GetSolverType override is UNPORTED(blend.fillet_standard_solver_p1).
• FilletBrep::set_vertex_point is now public.
• blend.fillet_intersector: main's UNPORTED(blend.fillet_solver_p3) StepSolve back-edge is wired. FilletSolverOps::step_solve is now required, and ConstantRadiusAssistedFs calls FilletSolver::step_solve with itself as the solver, so its own overrides are kept. Of the intersector's 120 cases deferred here, 59 now pass and 61 deferred one level deeper at blend.fillet_standard_solver_p1; with the overrides below wired, the intersector is at 1286 cases, 967 passed, 0 failed, 319 deferred.
• The constant-radius solver's FilletSolverOps overrides (GetJacobianSize, SetupOffsetValues, OffsetRadiiCanChange, LoadJacobian, GetType) call blend.fillet_standard_solver_p1 (port: blend.fillet_standard_solver_p1 #168). port: blend.fillet_solver_p1 #192 wires these too, and its version is the one merged here. This unit adds GetSolverType, which is SM_FS_CONST_RADIUS: one Rust type stands for both SmConstantRadiusFS and SmConstantRadiusAssistedFS, and the intersector shim builds a SmConstantRadiusFS. With SM_FS_CONST_RADIUS_ASSISTED, a clipped step would take the assisted branch, which the C++ doesn't. The custom solvers derived from SmConstantRadiusAssistedFS (SmEiffelTowerFS, SmSecantConstantRadiusFS) inherit its GetSolverType, SM_FS_CONST_RADIUS_ASSISTED. The intersector runner writes its Delta / Values points back, since upstream fills them by reference. The intersector's 94 _standard_solver_p1 deferrals: 33 pass, 59 defer at _standard_solver_p2 (LoadInitialValues) and 2 at _p4.
• PointOnPlaneSolve is a FilletSolverOps hook, because it is virtual upstream and SmConstantRadiusAssistedFS overrides it. Its default is the base's stub (blend.fillet_solver_p2). The variable-radius GetOriginalCurve and constant-distance GetDistance stubs are marked justified: those solvers don't implement FilletSolverOps yet (see plan/findings.md).
• FilletSolver::step_solve writes its three flags to a StepSolveOutcome the caller passes in, so a failure keeps what was set before it (upstream's SmFilletIntersector reads bClipped / bBoundaryHit after a failed solve). The shim and runner compare the flags after a failed solve too.

Stubs

Calls into units that are not ported yet go through UNPORTED stubs:

• blend.fillet_solver_p2: PointOnPlaneSolve, RailEdgeuseIntersect, GetFilletCorner, CreateCliffRollOverSideFG
• blend.fillet_geom_p5: MakeFilletEdge, TrimCliffRails
• blend.fillet_standard_solver_p1: the SmVariableRadiusFS cast, and GetDistance by default

Difftest

Every library solver belongs to an unported unit, so the shim derives a deterministic SmFilletSolver and the runner mirrors it. The shim's LoadJacobian solves the offset/offset intersection; the shim also lets the test set the solver type, use one extra unknown, or make LoadInitialValues fail.

StepSolve cases step along floor/wall fillets at 20–160° and scales from 1e-3 to 1e3, on flat and bumped B-splines. They cover:

• steps inside the domain and steps across a boundary (both the iso-curve intersection and the constant-distance clipped radius solve)
• steps that start on a boundary
• zero, tiny and reversed steps
• extended domains
• offsets on the wrong side

PARTIAL blend.fillet_solver_p3 cases=400 passed=378 failed=0 deferred=22 max_rel_err=1.8011683050692552e-15 with_values=378 no_values=0 blocked_by=blend.fillet_solver_p2(22)
SENSITIVE blend.fillet_solver_p3 perturbed=378 detected=378 unperturbed=0 deferred=22
FUZZ-PASS blend.fillet_solver_p3 cases=1500 rejected=354 malformed=640 ran=506 differs=0 crashes=0 panics=0 timeouts=0
PARTIAL blend.fillet_solver_p1 cases=346 passed=339 failed=0 deferred=7
PARTIAL blend.fillet_geom_p1 cases=480 passed=446 failed=0 deferred=21 rejected=13
PARTIAL blend.fillet_custom_solver cases=448 passed=401 failed=0 deferred=47
PARTIAL blend.fillet_intersector cases=1286 passed=967 failed=0 deferred=319
--green (local x86_64, at 858ad270): 239 units, 119 passed, 120 partial, 0 failed

With main's topology.face_p3, #147's clone_for_evaluation (the caches keep the surface's owner, as upstream's pointer does) moves 46 topology.face_p3 cases (the Endcap intersect fixtures) from pass to deferred at main's existing surface.surface_cache_p2 stub for SmTol::GetZoneTol3d on an opaque handle; main alone passes them. No failures; the regenerated reports are committed (146ecdd6).

With allow_ext = true, results on degenerate inputs (radius 0 or 1e-12, coincident surfaces) are not bit-identical; with allow_ext = false everything agrees bit for bit. The difference is in surface.offset_surface's extension path, not in StepSolve; plan/findings.md records it with a reproducer as a follow-up for that unit.

Local verification: fmt and workspace clippy (with and without cpp) are clean, cargo test -p solidcore passes (1598 tests, 12 of them new for this unit), and wasm32-unknown-unknown check passes.

The other six routines are covered by kernel tests only. On every path a native fixture can build, they reach blend.fillet_solver_p2 or fillet-geometry stubs. When p2 lands they should get difftest cases. Details are in plan/findings.md.

Checklist (§4 step 5)

• Default arguments match upstream: IsConvexRadialSector(10) passes bOptStepOff = FALSE and dTolDeg = 0; SmOffsetSurface uses SM_SS_UNKNOWN.
• No parameter is dropped.
• Every branch is ported, including the variable-radius, constant-distance and constant-radius-assisted branches of StepSolve, and SM_BT_NONE's early break.
• Statuses are honoured: SE statuses are ignored, Unported always propagates, and the effect of SetMin/Intersect failures is reproduced.
• The FFI guard rejects only the variable-radius solver type (an invalid cast in the shim), malformed blocks, a tolerance ≤ 0 and unordered domains.
• Recursion: none.
• Upstream index defects are recorded as UB-204 and UB-205.

Also noted for #208: its ProcessRollOver passes opt_step_off = true to is_convex_radial_sector, but upstream uses the default FALSE.

🤖 Generated with Claude Code

[bherbruck]

Thanks for this port. I reviewed head b419ae4a against SmFilletSolver.cpp. The port is faithful and every gate I ran passed, so only one small formatting item stands in the way.

What passed

• cargo fmt --check, clippy -D warnings (plain and with --features solidcore-ffi/cpp,difftest/cpp), cargo test -p solidcore (1399 passed, 0 failed) and the wasm32 check.
• --unit blend.fillet_solver_p3 gives the same result as your PR description. The green set gives 212 units, 113 passed, 99 partial, 0 failed. It was run in two batches because one run hit my local time limit.
• git merge-tree against origin/main (b6b6f7dd) is clean. Main has no UNPORTED(blend.fillet_solver_p3) stubs left to wire.
• I ran 157 extra adversarial StepSolve cases against the C++ as a local fixture: 150 passed bit-identical (max_rel_err 0), 7 deferred at PointOnPlaneSolve, 0 failed, and there were no crashes or rejections. They cover:
  • every accepted solver type, including SurfSurf and CurveBased, which the generator does not pick;
  • real SmPlane bases, both planes or mixed with a B-spline;
  • parallel and coincident surfaces;
  • radius 0, negative and 1e-12; orientations 0, -1 and 2;
  • point-sized and line-sized domains; current points outside the domain; extended domains with and without allow_ext;
  • steps of ±1e300, 1e-300, -0.0 and a denormal; tolerances of 1e3, 1e-15 and 1e-300;
  • scales of 1e-6, 1e6 and 1e9;
  • constant-distance targets of 0, negative, 1e6 and 1e-12;
  • zero, huge and tiny tangents;
  • the extra unknown combined with init_fail for each solver type;
  • starts on a boundary or 1e-13 inside it; a corner clip; degree-3/2 patches; angles of 20° and 170°.
• Faithfulness checks that held up:
  • StepSolve: both clip tests, the rdStep vs dStepSize use, the SetupOffsetValues status being ignored, sUV written back from the EFO, the retry with an adjusting plane, and the SM_MAX_USER_DOUBLES guard.
  • SplitAndTrimFilletSurface: the bFound1/2 cross-setting and SM_BT_NONE's i > 0 break.
  • sm_RefineRailCurveClassification: the reversed ii loop and the SE on RailEdgeuseIntersect and the drops.
  • sm_CalcRailXEdge: the nine guesses.
  • ProcessFullRollOver: IsConvexRadialSector(10) defaults, the loop walk and SetDataSize.
  • Unitize's SM_ERR_INVALID_INPUT (1007) matches the Rust InvalidInput mapping.
• The FFI guard rejects only the variable-radius cast (undefined in the shim), a tolerance ≤ 0, unordered domains and malformed blocks.
• UNPORTED stubs in p3.rs target only blend.fillet_solver_p2, blend.fillet_geom_p5 and blend.fillet_standard_solver_p1. All three are todo on main and tagged with the right owners.

PARTIAL blend.fillet_solver_p3 cases=400 passed=378 failed=0 deferred=22 max_rel_err=1.8011683050692552e-15 with_values=378 no_values=0 blocked_by=blend.fillet_solver_p2(22)
PARTIAL blend.fillet_solver_p3 cases=157 passed=150 failed=0 deferred=7 max_rel_err=0e0 with_values=150 no_values=0 blocked_by=blend.fillet_solver_p2(7)   # extra adversarial fixture (local only)
PARTIAL blend.fillet_solver_p1 cases=333 passed=280 failed=0 deferred=53
PARTIAL blend.fillet_geom_p1 cases=461 passed=429 failed=0 deferred=19 rejected=13
PARTIAL blend.fillet_custom_solver cases=448 passed=401 failed=0 deferred=47
--green: 212 units, 113 passed, 99 partial, 0 failed

Must-fix

1. rustfmt on the include!d unit files. cargo fmt does not reach these files, so CI misses them, but rustfmt --edition 2021 --check reports diffs in both new files:

   • crates/difftest/src/units/blend_fillet_solver_p3.rs: lines 23, 330, 339, 390, 437, 453, 466, 537 and 563 (long use lists, the OffsetSurface::new match arm, next_ud);
   • crates/solidcore-ffi/src/units/blend_fillet_solver_p3.rs:73 (the variable-radius bad(..) message).

   Fix: run rustfmt --edition 2021 on both files and commit the result.

Should-fix (short)

• The branch carries an older copy of #147. #147's current head (b396cdd3) has since wired the UNPORTED(topology.brep_p1) stubs in fillet_geom/p1.rs, and topology.brep_p1 is now partial on main. A trial merge of b396cdd3 into this branch conflicts in crates/solidcore/src/surface/surface/p4.rs. Re-merging the latest #147 head before you mark this ready would keep the dependency stack in sync.
• Optional: one or two SrfIn::Plane bases in the generator would keep the analytic offset path compared in the committed cases. My plane cases all passed.

🤖 Generated with Claude Code

[denelson1-dot]

Thanks for the thorough review and the adversarial fixture.

Must-fix: done. 382c6f00 runs rustfmt --edition 2021 (with the repo's rustfmt.toml) on crates/difftest/src/units/blend_fillet_solver_p3.rs and crates/solidcore-ffi/src/units/blend_fillet_solver_p3.rs; both pass rustfmt --check now. (blend_fillet_custom_solver.rs in both crates also has rustfmt diffs, but those files come from main, so I left them out of this PR.)

Should-fix: done. I merged both dependency heads again:

• port: blend.fillet_geom_p1 #147 at b396cdd3 (bc9cf8f3). The surface/surface/p4.rs conflict was the query.face_p2 caller note; both sides list the same callers, so I took port: blend.fillet_geom_p1 #147's wording.
• port: blend.fillet_solver_p1 #192 at a88c62af (20602f17), because it had moved too (round 3, the setup_offset_extension hook). The plan/findings.md conflict: port: blend.fillet_solver_p1 #192's revised fillet_solver_p1 sections replace this branch's older copy.
• Main is merged again, at 28cd7d9a. b2babe17 updates the notes for the new dependency figures. Since then 65aa93f9 merges main through 5387f70c (port: topology.brep_p10 #130 topology.brep_p10; a plan/findings.md append conflict, both kept). At that head: clippy (plain and cpp), 1420 tests, wasm and the four fillet difftests pass with the same figures.

Gates at 0ad12c90 (x86_64): cargo fmt --check, rustfmt on both p3 unit files, clippy -D warnings (plain and with solidcore-ffi/cpp,difftest/cpp), cargo test -p solidcore (1414 passed) and the wasm32 check all pass. --green: 214 units, 114 passed, 100 partial, 0 failed. blend.fillet_solver_p3 is unchanged at 378/0/22. With the new heads, fillet_solver_p1 is 303 passed / 40 deferred and fillet_geom_p1 is 446/21.

Optional SrfIn::Plane bases: not in this push. I can add one or two plane bases to the generator here, or leave that for a follow-up. Your plane cases all passed.

[tangency-monitor]

Thanks for the round-3 changes, @denelson1-dot. I reviewed head 85cfe04c (it moved from ff0f701b while I worked; the only change is the #283 main merge). p3.rs's StepSolve change is right, and the intersector now reaches it. One thing has changed since my last review: blend.fillet_standard_solver_p1 (#168) is now on main as partial, and this branch has merged it. That turns the deferral we expected into stubs that can be wired, so there is one more round of work below.

Earlier items

• Must-fix (wire UNPORTED(blend.fillet_solver_p3) in the intersector): fixed. FilletSolver::step_solve now writes the flags to a caller's StepSolveOutcome and keeps them on an error. ConstantRadiusAssistedFs::step_solve (fillet_intersector.rs:496) passes self as the solver and copies the flags back, as SmFilletIntersector.cpp:427-436 reads them. The runner and shim now compare the three flags after a failed solve. The new kernel test covers this too.
• Should-fix (findings entry for allow_ext): done, with a reproducer.
• Nit (#212's UNPORTED(blend.fillet_solver_p3) stubs): still open on #212; whichever PR lands second wires them.

What passed

• cargo fmt --all --check, rustfmt --edition 2021 --check on the p3/p1 runner and FFI unit files and the intersector runner, clippy -D warnings (plain and with --features solidcore-ffi/cpp,difftest/cpp), cargo test -p solidcore (1515 passed, 0 failed) and the wasm32 check.
• git merge-tree against origin/main (3132491e) is clean.
• Extra cases against the C++, no crashes, panics or timeouts:
  • --seeds 3000 on blend.fillet_solver_p3: 2849 passed, 151 deferred (PointOnPlaneSolve), 0 failed, max_rel_err 4.4e-15.
  • --fuzz 2000 on blend.fillet_solver_p3: 487 rejected, 652 ran, 0 differs.
  • --fuzz 600 on blend.fillet_intersector: 119 rejected, 183 ran, 0 differs.
• A local trial of the must-fix below. I wired the overrides and fixed the runner's write-back in my worktree only (nothing was pushed). After that, blend.fillet_intersector gave 967 passed, 0 failed, 319 deferred (now 934/0/352). All 94 blend.fillet_standard_solver_p1 deferrals go away, and every compared next (StepSolve) case is bit-identical.

PARTIAL blend.fillet_solver_p3 cases=400 passed=378 failed=0 deferred=22 max_rel_err=1.8011683050692552e-15 with_values=378 no_values=0 blocked_by=blend.fillet_solver_p2(22)
PARTIAL blend.fillet_solver_p3 cases=3000 passed=2849 failed=0 deferred=151 max_rel_err=4.369504743270105e-15 blocked_by=blend.fillet_solver_p2(151)   # --seeds 3000 (local)
PARTIAL blend.fillet_intersector cases=1286 passed=934 failed=0 deferred=352 max_rel_err=0e0 blocked_by=blend.fillet_solver_p2(37),blend.fillet_solver_p4(59),blend.fillet_standard_solver_p1(94),curve.crv_on_surf(162)
PARTIAL blend.fillet_intersector cases=1286 passed=967 failed=0 deferred=319 max_rel_err=0e0 blocked_by=blend.fillet_solver_p2(37),blend.fillet_solver_p4(61),blend.fillet_standard_solver_p2(59),curve.crv_on_surf(162)   # local trial of the must-fix
PARTIAL blend.fillet_solver_p1 cases=346 passed=339 failed=0 deferred=7 max_rel_err=0e0
PARTIAL blend.fillet_custom_solver cases=448 passed=401 failed=0 deferred=47 max_rel_err=0e0
PARTIAL blend.fillet_geom_p1 cases=480 passed=446 failed=0 deferred=21 rejected=13
PARTIAL blend.fillet_geom_p2 cases=350 passed=219 failed=0 deferred=131
PARTIAL blend.fillet_standard_solver_p1 cases=3839 passed=3786 failed=0 deferred=42 rejected=11
PARTIAL offset.offset_geometry_creation cases=861 passed=428 failed=0 deferred=433
FUZZ-PASS blend.fillet_solver_p3 cases=2000 rejected=487 malformed=861 ran=652 differs=0 crashes=0 panics=0 timeouts=0
FUZZ-PASS blend.fillet_intersector cases=600 rejected=119 malformed=298 ran=183 differs=0 crashes=0 panics=0 timeouts=0
difftest: 232 unit(s), 114 passed, 118 partial, 0 failed   # --green

Must-fix

1. Wire the ConstantRadiusAssistedFs overrides to blend.fillet_standard_solver_p1, and add the missing solver_type. impl FilletSolverOps for ConstantRadiusAssistedFs (crates/solidcore/src/blend/fillet_custom_solver.rs:1703, merged in from #192) has these stubs:

   • UNPORTED(blend.fillet_standard_solver_p1) for GetJacobianSize (:1714), SetupOffsetValues (:1724), OffsetRadiiCanChange (:1738), GetType (:1748) and LoadJacobian (:1768).

   That unit is now partial on main, and all five exist as inherent methods or constants in blend/fillet_standard_solver/p1.rs (setup_offset_values :595, load_jacobian :640, jacobian_size :579, offset_radii_can_change :573, CONSTANT_RADIUS_ASSISTED_FS_TYPE :173). Today 94 intersector cases defer on them (AGENTS.md section 5, item 9). The same impl also has no solver_type override, so it falls through to the trait default FilletSolverType::Unknown. That contradicts its doc comment at :1702 ("none falls through to the base"). Upstream GetSolverType returns SM_FS_CONST_RADIUS (SmFilletStandardSolver.h:58) or SM_FS_CONST_RADIUS_ASSISTED (:112), and StepSolve branches on it (p3.rs:404). It is masked only while SetupOffsetValues is a stub. Fix:

   • Delegate each override to the inherent method, as #285 does for the macro solvers. For example, ConstantRadiusAssistedFs::setup_offset_values(self, tsect) writes *pOffsetDist. load_jacobian maps JacobianLoad onto (rail_index, [surface1, surface2], &mut [surf1_offset, surf2_offset], x) and copies the offsets back.
   • Add fn solver_type that returns the type of the class the C++ side builds. The intersector shim builds a real SmConstantRadiusFS (blend_fillet_intersector.rs FFI header), so that is ConstRadius there. When I tried ConstRadiusAssisted, one next case went down the assisted branch and differed from the C++.
   • Runner: crates/difftest/src/units/blend_fillet_intersector.rs:575-597 (Delta) and :598-615 (Values) compute into clones of the arena points and never write them back. Upstream fills rTsectPnt / rDeltaPnt by reference (SmFilletIntersector.cpp:87-134), so once SetupOffsetValues runs, 33 delta cases fail on the point record (for example gen0047: values.rec[24]: cpp=2 rust=0). After the call, write pa / pb back with fi.base.base.point_mut(id(*a))?, whatever the status, since C++ writes in place before any SER.

   With those three changes the intersector gives 967/0/319 locally (the line above). Then update the blend.fillet_intersector notes in plan/modules.toml. If you would rather this land in #192 first and be merged here, that works too. Either way, this branch should not carry the stubs once it is ready.

Should-fix (short)

• p3.rs:222 and :514 call a free PointOnPlaneSolve stub tagged blend.fillet_solver_p2 (SmFilletSolver::PointOnPlaneSolve). Upstream it is virtual (SmFilletSolver.h:258), and SmConstantRadiusAssistedFS overrides it (SmFilletStandardSolver.h:123, unit blend.fillet_standard_solver_p2). This is the solver StepSolve reaches it on. A FilletSolverOps::point_on_plane_solve hook would keep the override reachable, so that porting the base in p2 does not quietly run the base for an assisted solver. For now the stub is fine; only the dispatch matters.
• p3.rs:450: UNPORTED(blend.fillet_standard_solver_p1): SmVariableRadiusFS::GetOriginalCurve now names a partial unit. CurveBasedFs::original_curve exists there, but FilletSolverOps has no way to reach it. Either add a small hook (an original_curve() that is InvalidInput by default), or retag the stub with a note that it needs that glue, so the stale-stub audit does not count it as wire-now.

🤖 Generated with Claude Code

[tangency-monitor]

Thanks for round 4, @denelson1-dot. I reviewed head 07f39394. The earlier must-fix is done, and the overrides behave as intended against the C++. One small item is left, below.

Earlier items

• Must-fix (wire ConstantRadiusAssistedFs's overrides to blend.fillet_standard_solver_p1, add solver_type, write the runner's Delta / Values points back): fixed in 0487f538. jacobian_size, setup_offset_values (including *pOffsetDist), offset_radii_can_change, type_code and load_jacobian (offsets copied back on an error too) delegate to the #168 ports. solver_type is ConstRadius, which matches the SmConstantRadiusFS the shim builds. The runner writes pa / pb back before st(o, r). The intersector is at 967 / 0 / 319, the same as my local trial.
• Should-fix (PointOnPlaneSolve dispatch): done. FilletSolverOps::point_on_plane_solve is a hook, and both StepSolve and sm_FindFilletTsectPnt go through it.
• Should-fix (GetOriginalCurve stub at p3.rs:446): done. It now has a justification, with a findings entry explaining that CurveBasedFs is not on the trait yet.

What passed

• cargo fmt --all --check, and rustfmt --edition 2021 --check on the p3/p1 runner and FFI unit files, the intersector runner and the standard_solver_p1 runner.
• clippy -D warnings, both plain and with --features solidcore-ffi/cpp,difftest/cpp.
• cargo test -p solidcore (1534 passed, 0 failed) and the wasm32 check.
• git merge-tree against origin/main (bb137d7d) is clean.
• About 5,600 extra cases against the C++, with no crashes, panics or timeouts:
  • --seeds 3000 on p3: 2849 passed, 0 failed.
  • --fuzz 2000 on p3: 0 differs.
  • --fuzz 600 on the intersector: 0 differs.

PARTIAL blend.fillet_solver_p3 cases=400 passed=378 failed=0 deferred=22 max_rel_err=1.8011683050692552e-15 with_values=378 no_values=0 blocked_by=blend.fillet_solver_p2(22)
PARTIAL blend.fillet_solver_p3 cases=3000 passed=2849 failed=0 deferred=151 max_rel_err=4.369504743270105e-15 blocked_by=blend.fillet_solver_p2(151)   # --seeds 3000 (local)
PARTIAL blend.fillet_intersector cases=1286 passed=967 failed=0 deferred=319 max_rel_err=0e0 blocked_by=blend.fillet_solver_p2(37),blend.fillet_solver_p4(61),blend.fillet_standard_solver_p2(59),curve.crv_on_surf(162)
PARTIAL blend.fillet_solver_p1 cases=346 passed=339 failed=0 deferred=7 max_rel_err=0e0
PARTIAL blend.fillet_standard_solver_p1 cases=3839 passed=3786 failed=0 deferred=42 rejected=11
PARTIAL blend.fillet_custom_solver cases=448 passed=401 failed=0 deferred=47 max_rel_err=0e0
PARTIAL blend.fillet_geom_p1 cases=480 passed=446 failed=0 deferred=21 rejected=13
PARTIAL blend.fillet_geom_p2 cases=350 passed=219 failed=0 deferred=131
PARTIAL offset.offset_geometry_creation cases=861 passed=431 failed=0 deferred=430
FUZZ-PASS blend.fillet_solver_p3 cases=2000 rejected=487 malformed=861 ran=652 differs=0 crashes=0 panics=0 timeouts=0
FUZZ-PASS blend.fillet_intersector cases=600 rejected=119 malformed=298 ran=183 differs=0 crashes=0 panics=0 timeouts=0
difftest: 234 unit(s), 114 passed, 120 partial, 0 failed   # --green

Must-fix

1. crates/solidcore/src/blend/fillet_custom_solver.rs:1629-1637: return the type instead of stubbing it. The fillet_solver_ops! macro (used for EiffelTowerFs and SecantConstantRadiusFs) has a solver_type override that returns UNPORTED(blend.fillet_standard_solver_p1): SmConstantRadiusAssistedFS::GetSolverType. This branch adds that stub; it is not on main. blend.fillet_standard_solver_p1 is partial on main, and the upstream body is one inline line: return SM_FS_CONST_RADIUS_ASSISTED; (SmFilletStandardSolver.h:112). Both classes inherit it, because SmEiffelTowerFS and SmSecantConstantRadiusFS derive from SmConstantRadiusAssistedFS and do not override it (SmFilletCustomSolver.h:27, :105). That makes this a stub into a ported unit (AGENTS.md section 4, step 5, item 9). It would also send StepSolve (p3.rs:400) to an error where upstream takes the assisted branch.
   • Fix: fn solver_type(&self) -> Result<FilletSolverType> { Ok(FilletSolverType::ConstRadiusAssisted) }, and update the doc comment.
   • I tried this locally. cargo test -p solidcore still passes (1534), and blend.fillet_custom_solver (401/0/47), blend.fillet_solver_p3 (378/0/22) and blend.fillet_intersector (967/0/319) do not change. No compared path reaches this method today, so it is a one-line change with nothing to re-baseline.

Note (not blocking)

• #192 has moved to f676c2e8 since the e6f4d026 you merged, and git merge-tree of that head with this branch now conflicts. Whichever of the two lands second will need to resolve it. No action is needed here unless you want to pick it up now.

🤖 Generated with Claude Code

[tangency-monitor]

Thanks for round 5, @denelson1-dot. I reviewed head 4c94deee. The one must-fix from my last review is fixed, and everything passes again after the two main merges. This is reviewed and good to merge once CI is green. CI on this head has already passed.

Earlier item

• Must-fix (fillet_solver_ops!'s solver_type was a stub into blend.fillet_standard_solver_p1): fixed in 3e8cc11f. It now returns FilletSolverType::ConstRadiusAssisted, which is the inherited SmConstantRadiusAssistedFS::GetSolverType (SmFilletStandardSolver.h:112), and the doc comment and file-header row are updated. The only PR-side changes since 07f39394 are that commit and the two upstream/main merges (8890f8ac, 4c94deee). I checked the PR's own diff before and after; the rest is merge context.

What passed

• cargo fmt --all --check, and rustfmt --edition 2021 --check on the p3/p1 runner and FFI unit files, the intersector runner and the standard_solver_p1 runner.
• clippy -D warnings, both plain and with --features solidcore-ffi/cpp,difftest/cpp.
• cargo test -p solidcore (1565 passed, 0 failed) and the wasm32 check.
• git merge-tree against origin/main (7b57d8de) is clean.
• Every stub this PR adds names a unit that is todo on main. The two that name blend.fillet_standard_solver_p1 (GetDistance, GetOriginalCurve) are the justified ones with findings entries from earlier rounds.
• About 5,600 extra cases against the C++, with no crashes, panics or timeouts:
  • --seeds 3000 on p3: 2849 passed, 0 failed.
  • --fuzz 2000 on p3: 0 differs.
  • --fuzz 600 on the intersector: 0 differs.

PARTIAL blend.fillet_solver_p3 cases=400 passed=378 failed=0 deferred=22 max_rel_err=1.8011683050692552e-15 with_values=378 no_values=0 blocked_by=blend.fillet_solver_p2(22)
PARTIAL blend.fillet_solver_p3 cases=3000 passed=2849 failed=0 deferred=151 max_rel_err=4.369504743270105e-15 blocked_by=blend.fillet_solver_p2(151)   # --seeds 3000 (local)
PARTIAL blend.fillet_intersector cases=1286 passed=967 failed=0 deferred=319 max_rel_err=0e0
PARTIAL blend.fillet_solver_p1 cases=346 passed=339 failed=0 deferred=7 max_rel_err=0e0
PARTIAL blend.fillet_standard_solver_p1 cases=3839 passed=3786 failed=0 deferred=42 rejected=11
PARTIAL blend.fillet_custom_solver cases=448 passed=401 failed=0 deferred=47 max_rel_err=0e0
PARTIAL blend.fillet_geom_p1 cases=480 passed=446 failed=0 deferred=21 rejected=13
PARTIAL blend.fillet_geom_p2 cases=350 passed=219 failed=0 deferred=131
PARTIAL blend.fillet_executive_p2 cases=274 passed=249 failed=0 deferred=25
PARTIAL offset.offset_geometry_creation cases=874 passed=575 failed=0 deferred=299
FUZZ-PASS blend.fillet_solver_p3 cases=2000 rejected=487 malformed=861 ran=652 differs=0 crashes=0 panics=0 timeouts=0
FUZZ-PASS blend.fillet_intersector cases=600 rejected=119 malformed=298 ran=183 differs=0 crashes=0 panics=0 timeouts=0
difftest: 237 unit(s), 116 passed, 121 partial, 0 failed   # --green

Nit (not blocking, can be a follow-up)

• crates/solidcore/src/blend/fillet_executive/p3.rs:799-808 (it came from main through port: blend.fillet_executive_p2 #267/port: blend.fillet_executive_p3 #244): the default ExecutiveAccess::solver_other_corner is still UNPORTED(blend.fillet_solver_p3): SmFilletSolver::GetOtherFilletCorner. It can't call FilletSolver::other_fillet_corner because the hook only gets opaque O handles, so it can't be wired here. Once this PR lands, though, the tag names a ported unit. other_fillet_corner itself bottoms out in GetFilletCorner, so retag it to UNPORTED(blend.fillet_solver_p2): SmFilletSolver::GetFilletCorner (or add a justified: note) and update the "waiting for blend.fillet_solver_p3" doc line.

🤖 Generated with Claude Code