docs(skills): roadmap — snapClip bed-flat volume pin resolved#1108
Conversation
…t analytic more accurate than reference NURBS loft)
There was a problem hiding this comment.
Pull request overview
Updates the roadmap skill documentation to record the resolution of the snapClip bed-flat volume “pin mismatch” investigation, clarifying that the observed delta is attributable to the reference kernel’s NURBS-loft approximation in the relief cutter rather than a brepkit defect.
Changes:
- Replace the prior roadmap claim of a “genuine deviation” with a detailed explanation localizing the volume delta to the relief cut /
buildSingleCellSocketcutter behavior. - Document that brepkit’s result is based on exact analytic faces (per the loft-recognition work in #1045), and that the acceptance pin should be recalibrated tool-side.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| census F=34 {plane:18,cylinder:8,cone:8}, zero NURBS — the #1045 | ||
| loft-recognition) while the reference keeps a NURBS loft that bulges ~0.062mm³ | ||
| and over-removes 0.146mm³ from the clip corners. brepkit's 46.701 is the MORE |
| census F=34 {plane:18,cylinder:8,cone:8}, zero NURBS — the #1045 | ||
| loft-recognition) while the reference keeps a NURBS loft that bulges ~0.062mm³ | ||
| and over-removes 0.146mm³ from the clip corners. brepkit's 46.701 is the MORE |
WASM Binary Size
✅ No size change. |
Greptile SummaryThis docs-only PR updates
Confidence Score: 4/5Safe to merge as a docs update, but the resolved item is still presented as part of the open REMAINING list, which the document's stated autonomous-session consumers rely on for work selection. No code is changed. The resolution analysis is technically coherent and the two mirrored sections are updated consistently. The main risk is that an autonomous session reading the REMAINING list will still see the volume pin as a live work item — the annotation says RESOLVED but the list position implies open. The entry also violates the file's own one-line-per-entry rule, making the section harder to scan. .claude/skills/roadmap/SKILL.md — the snapClip REMAINING list in both mirrored sections needs the resolved entry removed or explicitly excluded. Important Files Changed
Reviews (1): Last reviewed commit: "docs(skills): roadmap — snapClip bed-fla..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| cache — captured operands are fallback-poisoned, never replay them directly), | ||
| the by-edge-id acceptance gate is BLIND to position-duplicate leaks (poison | ||
| propagates silently — evaluate a position-quantized gate), and the bed-flat | ||
| clip volume 46.701 vs 46.6±0.05 pin (genuine deviation, the reference kernel | ||
| passes — per-op dual-kernel volume diff). | ||
| clip volume 46.701 vs 46.6±0.05 pin — RESOLVED, NOT a brepkit defect: the | ||
| per-stage dual-kernel diff localized the whole delta to the relief cut, whose | ||
| cutter (buildSingleCellSocket) brepkit represents as EXACT ANALYTIC (native | ||
| census F=34 {plane:18,cylinder:8,cone:8}, zero NURBS — the #1045 | ||
| loft-recognition) while the reference keeps a NURBS loft that bulges ~0.062mm³ | ||
| and over-removes 0.146mm³ from the clip corners. brepkit's 46.701 is the MORE | ||
| accurate value; the pin is calibrated to the reference's loft approximation | ||
| (the "snapshot pins are kernel-specific" class). Resolution is tool-side pin | ||
| recalibration, not a brepkit change. | ||
|
|
||
| Fit-offset groove-mouth sliver family — CLOSED (2026-07-16, PR #1078, fixture | ||
| `crates/io/tests/fitoffset_groove_mouth_inmem.rs`): each groove cutter's mouth |
There was a problem hiding this comment.
The bed-flat clip volume pin is now marked RESOLVED, but it is still embedded in the REMAINING after the deepened-opening union... sub-section of the snapClip family block. An autonomous session using this file as its work-selection oracle will read this section, see a REMAINING list with three entries, and may still treat the volume pin as actionable — especially because the heading says "deepened-notch remains" and the list structure implies all three bullets are open. The resolved entry should be removed from the REMAINING list (or the list suffix should explicitly exclude it) so the open-work set is unambiguous. The same issue applies to the second mirrored copy of this block at line ~577.
| propagates silently — evaluate a position-quantized gate), and the bed-flat | ||
| clip volume 46.701 vs 46.6±0.05 pin (genuine deviation, the reference kernel | ||
| passes — per-op dual-kernel volume diff). | ||
| clip volume 46.701 vs 46.6±0.05 pin — RESOLVED, NOT a brepkit defect: the | ||
| per-stage dual-kernel diff localized the whole delta to the relief cut, whose | ||
| cutter (buildSingleCellSocket) brepkit represents as EXACT ANALYTIC (native | ||
| census F=34 {plane:18,cylinder:8,cone:8}, zero NURBS — the #1045 | ||
| loft-recognition) while the reference keeps a NURBS loft that bulges ~0.062mm³ | ||
| and over-removes 0.146mm³ from the clip corners. brepkit's 46.701 is the MORE | ||
| accurate value; the pin is calibrated to the reference's loft approximation | ||
| (the "snapshot pins are kernel-specific" class). Resolution is tool-side pin | ||
| recalibration, not a brepkit change. | ||
|
|
||
| Fit-offset groove-mouth sliver family — CLOSED (2026-07-16, PR #1078, fixture | ||
| `crates/io/tests/fitoffset_groove_mouth_inmem.rs`): each groove cutter's mouth |
There was a problem hiding this comment.
The file's maintenance contract (line 15) reads: "Keep every entry to ONE line with a pointer (a test path, a git-history PR number, a memory-free source file) that carries the detail. Never duplicate the detailed truth here; point at the repro." The new text is ~5 sentences of inline prose. If the resolution detail is worth preserving, a pointer such as RESOLVED — see PR #1108 dual-kernel diff would satisfy the rule; the full breakdown belongs in the PR or a linked note, not inline. The same applies to the mirrored copy near line 585.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Summary
Resolves the long-standing snapClip bed-flat clip volume question (46.701 brepkit vs the 46.6±0.05 test pin) — it is not a brepkit defect; brepkit is the more accurate kernel.
A per-stage dual-kernel volume diff of
buildSnapCliplocalized the entire delta to the relief cut:The relief cutter is
buildSingleCellSocket(a lofted gridfinity socket foot). A native face census of brepkit's foot shows F=34, {plane:18, cylinder:8, cone:8}, zero NURBS — brepkit represents it as exact analytic geometry (the #1045 loft-recognition). The reference kernel keeps it as a NURBS loft that bulges ~0.062mm³ outward; used as a relief cutter, that bulging wall removes 0.146mm³ more from the clip's top-bridge corners. The cutters' total volumes are identical to 0.001% — the whole difference is the local loft-surface approximation in the corner-overlap sliver.So brepkit's 46.701 is the more accurate value, and the 46.6±0.05 pin is calibrated to the reference's NURBS-loft approximation — the roadmap's "snapshot pins are kernel-specific" class. The resolution is tool-side pin recalibration, not a brepkit change.
This also corrects a prior roadmap claim ("genuine deviation, the reference kernel passes") that saw the reference pass the pin but never checked which kernel is more correct.
Docs-only; no code change.
Summary by cubic
Updates the roadmap docs to resolve the snapClip bed-flat clip volume pin issue: a per-stage dual-kernel diff shows the delta comes from the relief cut, where
brepkit’s analytic loft is more accurate than the reference’s NURBS; the fix is tool-side pin recalibration, not abrepkitchange. Also corrects the earlier claim that this was a genuine deviation that the reference kernel passed.Written for commit 293ee60. Summary will update on new commits.