Skip to content

Insulate body-finding behind sp (API-containment increment 1)#51

Open
YLZha wants to merge 1 commit into
mainfrom
insulate-body-finding
Open

Insulate body-finding behind sp (API-containment increment 1)#51
YLZha wants to merge 1 commit into
mainfrom
insulate-body-finding

Conversation

@YLZha

@YLZha YLZha commented May 31, 2026

Copy link
Copy Markdown
Collaborator

First increment of option 1 from the API-fragility review: make sp a deliberate insulation boundary so each Fusion-API quirk has one implementation site to maintain across version drift, instead of N copies in templates.

This increment: body-finding

Six templates each carried a private _all_bodies / _find_body loop over comp.bRepBodies + name matching — the exact pattern the audit flagged as fragile (wrong body picked after a mirror/pattern rename or proxy/native mismatch).

  • Added standalone sp.bodies_in(comp), sp.find_body(name, comp), sp.find_bodies(pattern, comp) — thin wrappers over the already-canonical _util recursive helpers that DesignContext uses.
  • Routed drawbore, tusk_tenon, splayed_legs, domino, scarf_joint, bed_rail_fastener through them. No raw .bRepBodies iteration remains in those files.

The fragile name-based identification now lives in one place — so the later hardening (UUID/feature association instead of name matching) is a single-site change.

Behavior-preserving by construction

  • bodies_in returns the same shallow list as the old _all_bodies.
  • find_body = _find_body_recursive (checks the component's own bodies first, then descendants — the same fallback the locals already delegated to).
  • The 4 templates with local helpers keep their _find_body/_all_bodies signature (now one-line delegations) → zero call-site churn. scarf_joint/bed_rail had inline loops, replaced directly.

Verification

  • py_compile clean on all 7 files; confirmed no raw .bRepBodies left in the migrated templates.
  • The template Fusion fixtures (tests/test_template_drawbore.py, _splayed_legs, _domino, …) are the real regression guard — they run in Fusion and should be exercised there to confirm (I can't run them offline).

Next increments (separate PRs, same pattern)

  • (B) addTwoPointRectanglesp.sketch_rect* where parametric matters (skip throwaway cut-tool sketches)
  • (C) hand-built Matrix3D/Move → an sp rotate/move shim
  • (D) raw createForAssemblyContextsp proxy helper (one place to add the .isValid guard)
  • (E) raw participantBodies set → sp.ext_op

🤖 Generated with Claude Code

Part of making the `sp` layer a deliberate insulation boundary: route the raw
Fusion-API uses in templates through named helpers so each quirk has ONE
implementation site to maintain when the API drifts (instead of N copies across
templates).

This increment: body-finding. Six templates each carried a private `_all_bodies`
/ `_find_body` loop over `comp.bRepBodies` + name matching — the exact pattern the
audit flagged as fragile (name collisions after mirror/pattern renames, proxy vs
native). Added standalone `sp.bodies_in` / `sp.find_body` / `sp.find_bodies`
(thin wrappers over the already-canonical `_util` recursive helpers that
`DesignContext` uses), and routed drawbore, tusk_tenon, splayed_legs, domino,
scarf_joint, bed_rail_fastener through them. No raw `.bRepBodies` iteration
remains in those files.

Behavior-preserving by construction: `bodies_in` returns the same shallow list as
`_all_bodies`; `find_body` is `_find_body_recursive` (checks the component's own
bodies first, then descendants — the same fallback the locals already used). The
fragile name-based identification now lives in one hardenable place.

py_compile clean. The template Fusion fixtures (tests/test_template_*) are the
regression guard and should be run in Fusion to confirm.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant