CADKit adopts AIS selection state instead of running a parallel one

[gsdali]

Phase 3 of the picking consolidation (ecosystem#43). Needs phase 2.

The OCCTSwiftCADKit target holds an InteractiveContext from the OCCTSwiftAIS target and then runs its own selection alongside it. Its own source describes the situation:

.body has no effect here (there is no whole-body PickedEntity case); it exists on SelectionMode for OCCTSwiftAIS.InteractiveContext.selectionMode, a separate, independent selection system this service does not share state with.

Two selection systems in one service, in one package, is the duplication this merge exists to remove.

• CADKit drives InteractiveContext for selection state rather than keeping its own selectionModes/selected.
• Remove the duplicate SelectionSummary. It is defined in both CADKit and OCCTSwiftUX, same name, different types.
• Decide whether PickedFaceInfo/PickedEdgeInfo/PickedVertexInfo survive. They carry cached geometry for the UI, so keeping them as presentation types built from SubShapeRef trades a smaller diff for one remaining mapping layer. Deleting them outright is cleaner but is a breaking change for OCCTSwiftUX and PadCAM.

This phase is the only one that breaks a consumer, so it sets the version step for the package.

[gsdali]

Bakeoff: the two selection systems, SelectionSummary, and Axis

Posted before any deletion, per the rule on ecosystem#43. Three collisions, three different verdicts. Only one of them is a merge.

Method follows the two corrections posted after phase 2: measure the overlapping logic, not the function length, and check what a bounds test is testing against, not merely that one exists.

---

1. select / clearSelection / remove / removeAll

Behaviour	OCCTSwiftAIS.InteractiveContext	OCCTSwiftCADKit.CADViewportService
What the selection is stored as	Selection, a Set<SubShape>	[PickedEntity], an ordered Array
Membership rule	SubShapeRef.==: uid when both sides have one, else ordinal, with the body carried by the enclosing InteractiveObject	PickedFaceInfo.== and siblings: uid when both sides have one, else ordinal plus bodyID. Three hand-written copies, each commented "Mirrors OCCTSwiftAIS.SubShapeRef.== exactly"
Idempotent re-select	yes, by Set	yes, by explicit contains check
Combination schemes	.add (select) and .remove (deselect) only; .replace/.xor reachable only through the internal setSelection	all four, .replace/.add/.remove/.xor
Ordering	none, it is a Set	insertion order
Mode set	selectionMode: Set<SelectionMode>, default [.body], clears the selection when changed	selectionModes: Set<SelectionMode>, default [.face], plain storage, no clear
.body honoured	yes, including the whole-body fallback on a failed face pick	no, and the source says so
Filters gate picks	yes, [any SelectionFilter], AND-combined	no
Hover	yes	no
Clip-plane pre-filter	no	yes, per picked primitive
Selection survives a mutation (update(_:to:absorbing:))	yes, remapped through the BRepGraph	no such path exists
Highlight on selection change	per-triangle triangleStyles on the source body, plus viewport.selectedBodyIDs	up to three aggregate highlight bodies, one per kind
remove	remove(_ object: InteractiveObject): drops the object, prunes selection by object.id and hover	remove(id: String): drops an entity (a group of bodies), prunes selection by bodyID, comparison, and escalation
removeAll	bodies, entries, selection, hover, dimensions, viewport measurements	model state, entities, comparison, clipping backups, escalation, selection

Findings

1. remove and removeAll are not duplicates. They are two methods on two unrelated types with one name. InteractiveContext.remove(_:) takes an InteractiveObject; CADViewportService.remove(id:) takes an entity id naming a group of bodies. No call site can confuse them, and neither scope is a subset of the other. Overlapping logic: the three statements that mean "drop the selection entries that named the thing being removed". That is all. Same for removeAll: one statement each.

2. The measurement. Counting statements, not lines:

	AIS	CADKit
Total selection-state statements	16	22
Of which genuinely duplicated	12	15
Layer-appropriate, stays put	4	7

The four function bodies plus their documentation run to about 120 lines. Quoting that number would have overstated the duplication roughly eightfold, which is the phase 2 lesson applied. The 15 duplicated statements break down as: 8 for scheme combination, 4 for holding and gating on the mode set, 2 for pruning on removal, 1 for emptying.

3. The duplication that matters here is not the statements, it is the two stores. selectionModes and selectionMode are two variables that mean the same thing and are free to disagree, and today they do: one defaults to [.face], the other to [.body], in a service that owns both. select is 15 statements; the ability for the two answers to differ is the actual defect.

4. CADKit's select genuinely wins on schemes; AIS's genuinely wins on everything else. The merged version is AIS's store with CADKit's scheme parameter. InteractiveContext gains select(_:scheme:); the existing select(_:) keeps its exact current meaning (.add) as a one-line forwarder, so no AIS call site changes behaviour. Adding a defaulted scheme: to the existing method instead would have silently flipped every context.select(x) from add to replace, which is why the scheme parameter is non-defaulted on the AIS side and keeps its .replace default on the CADKit side, where that is the documented contract.

5. Applying the bounds lesson. Two guards look like the same check and are not.

• resolveFacePick's guard let faceBounds = face.bounds else { return nil } tests the face's own 3D bounding box, and exists only because PickedFaceInfo.bounds is non-optional. Phase 2 called this enrichment rather than a fourth behaviour; that holds, and it has a consequence for the judgement call below: delete PickedFaceInfo and this guard goes with it, which changes pick behaviour, because a pick on a face with a void bounding box would then resolve instead of being discarded.
• selectionSummary's face branch re-derives Face(info.shape).bounds rather than reading info.bounds, which looks like a missed reuse. It is not: info.bounds is FaceBounds, XY only and Float, while the aggregate is 3D and Double. The edge and vertex branches read their cached values because those are 3D. Correct as written.
• pruneSelection guards on bodyID; InteractiveContext.remove guards on object.id. Two keys for one question. They become one key once CADKit mints one InteractiveObject per body, which is what the merge requires anyway.

6. What must not merge. Three CADKit behaviours are layer-appropriate where they are, for the same reasons phase 2 found:

• The clip-plane pre-filter. AIS has no equivalent, so this is not a collision at all. It tests the picked primitive's world position (triangle centroid, segment midpoint, point), not the resolved sub-shape's, so it cannot be expressed as an AIS SelectionFilter, which sees only a SubShape. A large face straddling a clip plane must be pickable on its visible half and not on its hidden half; a sub-shape-level filter cannot tell those apart. It stays a caller-side pre-filter on the raw PickResult. (OCCTSwiftViewport.ViewportController.selectionFilter is the layer-correct long-term home, since it gates the pick stream before either selection system sees it, but it is a single slot a consumer may want for itself, so not in this PR.)
• Geometry enrichment, and the two highlight systems. AIS paints triangleStyles on the source body; CADKit builds separate aggregate highlight bodies. These are not interchangeable: CADKit already uses triangleStyles for scalar fields, so adopting AIS's highlight would silently destroy any painted field. This is also the reason CADKit's bodies are not registered as AIS entries: updateSelectionVisuals would fight setScalarField for the same array.
• Hover and mutation remap stay AIS-only. CADKit has no equivalent to collide with.

Verdict

Merge, one way: AIS owns the state, CADKit projects it.

• InteractiveContext.selection becomes the only selection store. CADViewportService.selection becomes a projection of it, mirrored into stored state so SwiftUI observation still fires, exactly as bodies already mirrors interactiveContext.bodies in the same class.
• CADViewportService.selectionModes stops being storage and forwards to interactiveContext.selectionMode. One knob. .body stops being a mode this service ignores.
• InteractiveContext gains select(_:scheme:). CADKit's select(_:scheme:) becomes an adapter over it.
• remove/removeAll keep both implementations and both names; only their selection pruning routes through the context.

---

2. SelectionSummary, OCCTSwiftCADKit and OCCTSwiftUX

	OCCTSwiftCADKit.SelectionSummary	OCCTSwiftUXKit.SelectionSummary
Input	[PickedEntity]	[EntityRef] plus a SelectionSignature
Output	faceCount, edgeCount, vertexCount, totalArea, totalLength, bounds	label: String, symbol: SymbolName
What it is	a geometric aggregate	a UI pill's caption and SF Symbol
Sample value	(2, 1, 0, 314.16, 40.0, bounds)	"3 edges · loop"
Depends on OCCT	yes	no
Consumed by	nothing outside its own tests	SelectionPill.swift, two lines
Overlapping fields	zero
Overlapping logic	zero statements

OCCTSwiftUX does not depend on OCCTSwiftCADKit at all, in either direction. There is no import OCCTSwiftCADKit anywhere in that repository. These two types have never been in the same compilation unit and cannot currently collide.

Verdict

Not a duplicate, and the issue text is wrong to call it one. Nothing to remove: there is no shared behaviour, no shared field, and no consumer of either that could switch to the other. Deleting CADKit's would delete a working feature; moving it to UX would need a dependency edge that does not exist and would point the wrong way.

What is real is the name. Two public types called SelectionSummary in one ecosystem is a trap for the first file that imports both, and this is the phase that is allowed to break things. Resolved the way phase 1 resolved SelectionFilter, by naming, not by merging: CADKit's becomes SelectionMeasurements, which is what it actually is, with a deprecated SelectionSummary alias and a deprecated selectionSummary property forwarding to selectionMeasurements.

---

3. Axis, OCCTSwiftAIS and OCCTSwiftCADKit

	OCCTSwiftAIS.ManipulatorWidget.Axis	OCCTSwiftCADKit.Axis
Scope	nested inside ManipulatorWidget	top level
Spelled at file scope as	ManipulatorWidget.Axis	Axis
Conformances	Hashable, Sendable, CaseIterable	Sendable, Equatable, CaseIterable
Members	direction (public), color (public), suffix (fileprivate)	unitVector (internal)
Used for	gizmo arrow direction, handle colour, body id suffix	the .wipe comparison split plane
Overlapping logic	3 statements: direction and unitVector are the same three unit vectors

There is no collision. AIS's is a nested type, so it is never spelled Axis at file scope, and CADKit already imports OCCTSwiftAIS and compiles today with its own top-level Axis unambiguously resolved. The epic's list came from a name scan that did not account for nesting. Correcting the epic: this row was never a collision, only a shared spelling of a nested member.

Verdict

Leave both. Three statements of shared arithmetic is not worth a dependency from comparison-mode code to a widget type, which CADKit's own doc comment already rejects in writing, and hoisting a fourth x/y/z enum into OCCTSwiftTools would create a type to serve two callers that do not want the same members (color is meaningless to a wipe plane; unitVector is Float where the gizmo wants a direction).

---

The judgement call: do PickedFaceInfo / PickedEdgeInfo / PickedVertexInfo survive?

Yes, as presentation types, and they become structurally derived from SubShapeRef rather than parallel to it. Each stores a ref: SubShapeRef and forwards shape / uid / faceIndex(edgeIndex, vertexIndex) from it.

Four reasons, in order of weight:

1. Two of their fields cannot be derived from a SubShapeRef, now or ever. scalarValue is resolved at pick time from the picked triangle for a .perTriangle field; the triangle index does not exist anywhere in a SubShapeRef, which is per-sub-shape by construction. description is formatted prose. Delete the types and that information has no home.
2. Phase 2 kept the enrichment in CADKit on purpose. These types are that enrichment's output. Keeping the enrichment while deleting its return type would mean returning loose tuples, which is worse than the mapping layer it was meant to avoid.
3. The consumer cost is real and the architectural gain is zero. PadCAM's entire consumption of CADKit selection is selectedFace and clearSelection(), reading exactly three members: bounds, zLevel, description. Nothing in either consumer constructs one, uses PickedEntity, or reads .selection / .selected / .selectionModes / .select(_:scheme:) / .selectionSummary. Deleting the types breaks four PadCAM files to remove a projection, after the state those files never touched has already moved.
4. They stop being a second identity system, which was the actual objection. Today each carries its own hand-written == documented as "Mirrors OCCTSwiftAIS.SubShapeRef.== exactly": three copies of one rule, 18 lines, free to drift, and exactly the pattern this epic exists to stop. Storing the ref collapses all three to lhs.ref == rhs.ref.

No .body case is added to PickedEntity. Whole-body selection is now genuinely reachable, because selectionMode is shared state, but it lives in interactiveContext.selection as SubShape.body, where AIS's whole-body fallback and its body-level highlight already are. CADKit's selection stays the sub-shape projection and says so. Adding a fourth case would break every consumer switch to surface a concept CADKit expresses better through entities / visibility / focus(on:).

---

ComesFromDecomposition, inherited from phase 2

Still no, and this phase is the one that was supposed to change the answer. Phase 2's argument was that a flag on SubShapeRef would be a constant true, since no index space has an ordinal meaning "the entire object", and that it only becomes load-bearing if SubShape loses .body.

Implementing the selection-state merge did not produce a single site that wanted to ask "did this ref come from decomposition?". Every site that cared asked "is this .body?" and got a compiler-checked answer from the sum type. Two additional points this phase adds:

• Dropping .body in favour of a flagged ref over the root shape would push the distinction from the compiler to the reader at every consumer switch, including CADKit's own three-way projection. That is a strictly worse trade than OCCT's, and OCCT only takes it because SelectMgr_EntityOwner is one C++ type serving both cases.
• The flag would still be a constant. SubShapePickResolver remains the only supported way to mint a SubShapeRef, and it still cannot mint one for a whole body.

Closing it here rather than deferring it again.

[gsdali]

Corrections to the bakeoff above, from implementing it

Done in #6. Two things in the matrix were wrong or incomplete once the code was open, and one thing outside it turned out to be the sharpest edge in the whole change. Recording them because phases 4 and 5 will read that matrix.

1. The three == implementations do not collapse to lhs.ref == rhs.ref. I wrote that they would. SubShapeRef.== compares uids when both sides have one, but falls back to the ordinal alone when neither does, and an ordinal means nothing across bodies. In OCCTSwiftAIS the enclosing SubShape supplies that qualification through its InteractiveObject; the CADKit info types carry a bodyID instead, so the rule has to append it explicitly, or two faces at ordinal 0 on different bodies start comparing equal. There is a test named for exactly that. The collapse is real, just smaller than advertised: three hand-written 6-line copies became one 4-line isSamePick plus three one-line calls, 18 statements to 7, not 18 to 3.

2. The matrix compared what each system does when it selects, and never what each does when it fails to. That is where they actually conflict. Both handlePick implementations fire on every pick: InteractiveContext's leaves the selection alone on a miss, CADViewportService's clears it. Independent stores made that a non-question; one store makes it a bug. A pick on an object displayed into the context (PadCAM's stock box, a manipulator target) is unresolvable by CADViewportService, which would then clear the selection the context had just legitimately set, on every single pick.

Fixing it needed a new public InteractiveContext.displaysBody(withID:), so a host compositing its own bodies into bodies can tell "not mine" from "unresolved". The lesson for the remaining bakeoffs: give every merged operation a "what happens on the failure path" row. Two implementations can agree completely on success and still be incompatible.

3. The mode-set defaults were the one row that could not be reconciled, only chosen. selectionMode defaults to [.body], selectionModes to [.face], and a shared setting has exactly one default. CADViewportService.init now sets [.face], preserving its own behaviour and overriding the context's, which is a real behaviour change for any app that displays extra geometry into that context. This is the kind of thing worth putting in a matrix cell rather than describing a property abstractly: "both hold a Set<SelectionMode>" reads as agreement, and the defaults are where the disagreement was.

Everything else held. SelectionSummary is not a duplicate and the naming fix landed as described; Axis was never a collision; the picked-info family survives as presentation types for the reasons given; and ComesFromDecomposition stays off SubShapeRef, with the extra argument that dropping SubShape.body would move a compiler-checked distinction into a flag the reader has to remember, at every consumer switch.