Merge pull request #1897 from tdamsma/claude/flag-tests-round-3

plan: findings for WR-594 (no operation reaches its branch) and WR-468 (the 1001 is #1021; the flag regresses a boss that WR-499 rounds)

plan/findings/general--flag-reachability-wr468-extended-rail-end-not-reached--addendum-2026-10-31-the-1001-is-wr499.md

@@ -0,0 +1,22 @@
+# General: WR-468 addendum: the overhanging boss's 1001 is the Nx1 corner of #1021 (WR-499), and with WR-499 on the WR-468 flag makes one round fail (2026-10-31)
+
+Updates: plan/findings/general--flag-reachability-wr468-extended-rail-end-not-reached.md
+
+- **Where the 1001 arises (origin/main 6a2e8c68f, instrumented build, `FilletSession` error info):**
+  - Rounding only the boss's concave base arc on the block's top (two edges, split at the cylinder's seam) with the default flags fails in `SmFilletNx1Corner`: error code 3, corner `NByOne`, "Fillet Corner Error: Corner Edge Computation Failure", at the arc's end vertex on the wall.
+  - That is tangency-labs/solidcore#1021: the overhang's rim continues the arc tangentially with the opposite convexity, and `MakeCornerTopology` takes it as the corner's side edge. #1021 names SolidCraft rig fillets/4174 and 4369, the latter being WR-468's own trigger.
+  - Selecting all three arcs at z = 10 (the convex rim under the overhang as well) fails under every flag combination tried, so the finding's earlier runs measured that, not WR-468.
+- **Pinned C++ (v1.0.1, the prebuilt `bin/cpp` libraries, a standalone `SM_API` probe):** `SmApiCreateBox(0,0,0; 30,60,10)`, `SmApiCreateCylinder` boss (height 10 on the top), `SmApiBooleanUnion`, then `SmApiFilletEdges` on the same arcs.
+  - It returns 1001 for every overhanging variant ((4, 33) r 5, (3, 30) r 5, (2, 30) r 6, (1, 30) r 5), with either edge selection.
+  - The control boss at (10, 30), fully on the block, gives 1000 and 18814.775309974. The port's default gives 18814.775309973586.
+  - So the 1001 is upstream behaviour, not a port divergence.
+- **Fork fix:** tangency-labs/smlib@420e47d (WR-499), in the port as `fillet_nx1_opposite_continuation_side_edge` with `fillet_nx1_tangent_side_edge` (WR-457). Open issue tangency-labs/solidcore#1410 reports the same topology (a plate-cylinder union overhanging the plate's side, 1001 on the pinned C++).
+- **With WR-499 and WR-457 on** (top arc only), the rounds succeed and WR-468's guard is reached:
+
+  | boss, round | WR-499 + WR-457 | + `fillet_through_extended_rail_end` |
+  |---|---|---|
+  | (4, 33) r 5, R 2 | Ok, 18807.824471783373 | **1001**, error code 4 "Fillet Surface Computation Failure" on the filleted edge |
+  | (2, 30) r 6, R 1.5 | Ok, 19142.548432299573 | Ok, identical volume |
+  | (0, 30) r 5, R 2 (axis on the wall) | Ok, 18800.086736685844 | Ok, identical volume |
+
+- **Answer:** WR-468 does not wait on a missing fork fix: it needs WR-499 (and WR-457) on, as the fork had them when 4369 was fixed. A WR-468 test must turn those on. No geometry found yet shows WR-468's intended effect (the round completing where it otherwise fails). The one that diverges goes the other way: on the (4, 33) boss, with the extra through knot, a round that WR-499 alone completes fails with 1001. That is a candidate defect in the opt-in WR-468 path (the port's or the fork's; the fork's C++ is not available to compare), worth its own issue before WR-468 stays in the SolidCraft preset.

plan/findings/general--flag-round3-wr594-no-operation-reaches-the-meeting-rails.md

@@ -0,0 +1,9 @@
+# General: WR-594 `fillet_rails_meet_at_one_end_point`: no fillet operation, and no curved-centre rails, reach the meeting-rails fix (2026-10-31)
+
+- **Flag:** `Kernel::fixes.fillet_rails_meet_at_one_end_point` (WR-594, fork tangency-labs/smlib@5fdefb9, merged as #1817; preset off).
+- **Audit:** class B-unit. Only `tests/wr_594_rails_meet_at_one_end_point.rs` reaches the guard, calling `CircularCrossSectionFsg::create_surface_from_curves` directly on line rails. The fork's measurable is one end point: the rails' ends and the surface's end corners bit-identical, an exact pole.
+- **Operations tried (origin/main 6a2e8c68f, instrumented build, flag on and off):**
+  - A T joint of equal cylinders (a vertical cylinder r on a horizontal one r along x, united; r = 10 with R 2 and R 1, r = 5 with R 1). The faces are tangent where the joint's edges meet, so a round there would close to a point. All fail with 1001 before the solver: error code 4 "Fillet Surface Computation Failure" on the joint edge, the same either way. The guard is not reached.
+  - A cylinder boss r 5 on a 40 x 30 x 10 block, its side tangent to the block's front face, base arc rounded R 2 and R 1: 1001 at an `NByTwo` corner, either way, guard not reached.
+- **The #1817 review's lead:** the difftest `blend.fillet_standard_solver_p1` "rails meet at the start" fixtures (`crates/difftest/src/units/blend_fillet_standard_solver_p1.rs`, `rng.below(12) == 1`) are the same helper with generated rails, not a B-rep operation. Built that way on a curved centre (a cubic bending in z, rails the centre moved 2 along y and 2 along z, rail 2's end control point put `6.5e-12` off rail 1's), the guard is reached, but `create_skinned_surface` fails with 1001 with the flag on and off, with the degenerate section at either end. Only the straight (line) rails of the existing test build a surface. Arc rails (a quarter circle r 10 with rails r 12 at z = 0 and r 10 at z = 2, one end control point moved) fail the same way.
+- **Consequence:** the existing helper test stays the only one that pins the measurable. A real-operation test waits on a fillet whose round closes to a point at an edge end and gets past the corner and surface set-up first: the fork's SolidCraft test-peg part (a two-round sequence, not public), which #1817 itself found failing earlier in the port, with WR-457 and WR-593 on.