Ryan Schultz
44339de804
Lets an occurrence's extrusion length be either driven by the type (typed/shared, e.g. Revit-mapped mullions) or owned by the occurrence (per-instance, editable), and lets the user switch between the two. - bim.make_profile_length_per_instance: un-maps a shared mapped body into a per-instance SweptSolid (shared IfcProfileDef kept; the old mapped body is orphaned, not deleted, to avoid cascading to sibling instances), gives the occurrence its own IfcMaterialProfileSetUsage (so the Length UI appears), and normalizes the placement so the extrusion runs local Z 0->depth -- Revit puts the object and extrusion origins on opposite ends, which made extend_profile flip the origin. - bim.make_profile_length_type_driven: the inverse -- re-maps the occurrence onto the type's shared representation, promoting the occurrence's body onto the type first if the type has no RepresentationMap. - A "Per-instance Length" checkbox in the Type panel (a get/set property that reads the current mode straight from the IFC, so there is no stored state to desync). - New occurrences of a mapped/typed profile type default to per-instance. - recreate_profile now skips mapped bodies (reloading the mesh instead of regenerating), so assigning a length-driven type keeps the occurrence typed rather than un-mapping it mid-assign and emptying sibling instances via the shared-representation removal cascade. - assign_type preserves a per-instance occurrence's own geometry/length (should_map_representations=False) instead of converting it to typed. Design/working notes under docs/dev-notes/profile-length-per-instance.md. Closes #8657 Closes #8656 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Developer notes (in-progress features)
This directory holds living design/working notes for unmerged feature branches,
one Markdown file per feature, named after its branch (e.g.
opening-template-on-type.md).
Purpose
A shared scratchpad so collaborators — and the AI agents they work with — can pick up the context behind an in-progress branch: the problem, the design decisions and the why, dead ends already ruled out, and what still needs testing. Because the note is committed on the branch, it travels with the PR and shows up in the diff, so it is discoverable without anyone being told where to look.
How to use it (humans and agents)
- Before working on a feature branch, read its note here if one exists.
- As the PR is refined, keep the note current — append decisions, correct things that changed, update the test checklist.
- One file per feature, named after the branch.
Lifecycle
These are not permanent user documentation. When a PR merges, either remove its note or promote the durable parts (the load-bearing "why") into code comments or the regular docs, so stale notes do not accumulate on the default branch.