# L4 live-UI record — Fusion 2704.1.53 — 2026-09-06

Milestone **M2, step 5** (the command dialog and the `CustomGraphics` preview). Companion to
`L4-2704.1.53-2026-09-06.md`, which covers the adapter. Every figure below came from a probe
run through `tools/fusion_exec.py`; none is inferred, and the negative results are recorded
in as much detail as the positive ones.

| | |
|---|---|
| Fusion version | 2704.1.53 |
| Python | 3.14.0 (Fusion's bundled interpreter) |
| Platform | macOS x86_64 |
| Documents opened | one scratch design per probe, closed without saving; 0 open at exit |
| Bodies | all from `TemporaryBRepManager`; the user's data was never touched |
| Probes | `p13_ui_smoke`, `p14a_dialog_build` + `p14b_dialog_verify`, `p15_preview_visibility` |

## 1. Add-in lifecycle (FR-9.1)

| Claim | Verdict |
|---|---|
| `start()` creates the panel, the command definition and both toolbar controls | **CONFIRMED** |
| Calling `start()` twice — what a reload does — leaves exactly one of each | **CONFIRMED** |
| `stop()` removes the panel, the command and both controls | **CONFIRMED** |
| `addButtonDefinition(id, name, tooltip, "")` accepts an **empty** resource folder | **CONFIRMED** |

**FR-9.1's stated location does not exist on this build.** FR-9.1 asks for a button in "the
Solid tab (Utilities panel or a dedicated panel)". Measured: the `SolidTab` (display name
`SOLID`) has ten panels and **none of them is a Utilities panel** — `SolidCreatePanel`,
`SolidModifyPanel`, `AssemblePanel`, `ConfigurePanel`, `ConstructionPanel`, `InspectPanel`,
`InsertPanel`, `PartAssemblePanel`, `SelectPanel`, `SnapshotPanel`. What Fusion calls
UTILITIES is a *tab*, `ToolsTab`, and it holds `SolidScriptsAddinsPanel` (display name
"Add-ins").

The add-in therefore takes FR-9.1's other option — a dedicated panel — creating
`MightyMiterPanel` in `SolidTab`, and adds its second entry to `SolidScriptsAddinsPanel`.
Both anchors are asserted in `tests/live/test_ui_api_shapes.py` so a renamed tab id fails
loudly rather than leaving the add-in with no button.

## 2. Host-face candidates on the reference joint (FR-1.5, PRD 7.13)

The cope edge of a 28.6 mm tube cut by a 32 mm tube at 60°:

```
1.  - D 28.60 mm, 7739 mm2, 92.9 mm long, centered at 3.6 mm
2.  - D 32.00 mm,  858 mm2, 33.0 mm long, centered at 9.2 mm
```

| Claim | Verdict |
|---|---|
| The cope edge bounds **two** cylindrical faces | **CONFIRMED** |
| `require_single_host_face` refuses rather than choosing | **CONFIRMED** (`AmbiguousHostFaceError`) |

Note the empty component names in that listing: that is the finding below, caught by this
probe and fixed.

**`TemporaryBRepManager` bodies report `name == ""`, not `None`.** The candidate label read
`face.body.name if face.body else "unnamed body"`, which passes the truthiness test on
`body` and hands the empty string through, so the listing lost the component FR-1.5
requires. Every fixture in the corpus is a temporary body, so this is the normal case under
test and the rare one in production — the shape of bug that survives a test suite. Fixed by
`ui.command._body_label`.

## 3. Axial extent of a face — and why the obvious method is unusable

`axial_extent_mm` needs the axial reach of a cylindrical face for FR-2.4's straight-run
readout and FR-1.5's candidate labels. Two candidate methods, measured on five faces:

| Face | true length | evaluated parametric extremes | world bounding box |
|---|---|---|---|
| untrimmed, axis-aligned `+Z` | 100 mm | **100.000000000 mm** | 100.000000000 mm |
| untrimmed, tilted `(1,1,1)` | 100 mm | **100.000000000 mm** | **140.446507884 mm** |
| untrimmed, 7 mm long | 7 mm | **7.000000000 mm** | 7.000000000 mm |
| trimmed coped host, r = 14.3 mm | — | **92.850291271 mm** | — |
| trimmed cutting tool, r = 16 mm | — | **33.024435398 mm** | — |

The world-axis-aligned bounding box over-reports a tilted tube by **40 %**, 4045× the
FR-4.1 budget, because a world-aligned box around a tilted cylinder is not a box around the
cylinder. The implementation evaluates the two parametric extremes and projects the
resulting **points** onto the axis.

Two further facts from the same run:

- **`(umax - umin) * radius` agreed with the evaluated points to 0.000000000 mm on all five
  faces, including the one with `isParamReversed = True`** (the r = 16 mm cutting-tool
  face). It is still not used: evaluating points is immune to the parameterization's
  direction by construction, and CLAUDE.md section 6 records that `isParamReversed` varies
  between faces of one design. This is the corpus's **first measurement of a face with
  `isParamReversed = True`**; the cone residual in PRD 6.0 remains open, as that is a
  different surface type.
- `getPointAtParameter` returned `ok = True` at a parametric extreme where
  `isParameterOnFace` was `False` (the trimmed coped face). That is the documented
  behavior — `ok` is not a domain check — and it is what makes the method correct here: the
  extent wanted is that of the parametric box, not of the trimmed region at one `v`.
- The trimmed host face reported `v ∈ [−π, +π]` where its untrimmed twin reported
  `[0, 2π]`, independently reproducing PRD 7.14 for the third time.

## 4. The pipeline, run through the product's own `_solve`

| Quantity | Measured |
|---|---|
| host radius | 14.300000000 mm |
| outward axis | `(0, 0, +1)` — away from the cut at `z = 0`, as required |
| unrolled `x` span | 89.849549893 mm |
| `2πr` | 89.849549893 mm |
| **Tier A closure error** | **0.000000000 mm** |
| FR-3.3: template `x` of the deepest point of the cut | 0.000000000 mm |
| FR-3.4: axial offset of the tip of the cut | 0.000000000 mm |

PRD 11.9(c) reproduced a second time, now through the UI layer's own code path rather than
the adapter's.

**A limitation of the default datum, measured and not fixed.** The datum reference came out
as `(+0.999933, −0.011554, 0)` rather than exactly `+X`, because FR-3.3's "deepest point" is
taken from the *stroked samples*, and the nearest sample sits up to half a spacing from the
true extremum. Here that is 0.662°, **0.165 mm of arc** at r = 14.3 mm. The consequence is
that the default datum moves slightly when the tessellation tolerance changes; the template
is internally consistent regardless, since everything on it is measured from that datum.
It matters only for clocking two templates to each other, which FR-3.3 explicitly says the
default is not a substitute for. Fitting a parabola through the three samples around the
extremum would make it tolerance-independent to second order; that is a candidate for M3
when "clock to" arrives, not a defect in M2.

## 5. Preview performance against FR-9.6's 300 ms budget

Measured **inside Fusion's own interpreter**, which is the only place the figure means
anything (PRD 11.12: ~5× slower than stock CPython). The clock covers the whole
`executePreview` path — stroke, solve, unroll, build, draw.

**15 previews across five probe runs**, every one drawing the identical 151 curve points,
36 major + 36 minor ticks, 223 primitives:

| Run | Attempt 1 | Attempt 2 | Attempt 3 |
|---|---|---|---|
| 1 | 55.04 ms | 51.19 ms | 54.05 ms |
| 2 | — | — | 91.22 ms (worst) |
| 3 | 88.94 ms | 50.88 ms | 52.82 ms |
| 4 | 8.57 ms | 7.41 ms | 6.97 ms |
| 5 | 56.28 ms | 52.12 ms | 48.28 ms |

**Best 6.97 ms, typical ~52 ms, worst 91.22 ms — 30.4 % of the 300 ms budget.**

The 13× spread deserves a sentence, because the first run of this measurement was reported
as "55.04 ms, 18.3 % of budget" from a single set of three attempts, and that was the wrong
number to quote. The work is bit-for-bit identical on every one of the 15 previews — same
edge, same tolerance, same 223 primitives — so the variance is Fusion-side, not ours. A
budget conclusion therefore has to rest on the **worst** observed case, which still leaves
69 % of FR-9.6's budget unspent. A run that happens to land at 6.97 ms proves nothing.

Everything drawn lay on the host cylinder to 0.000000000 mm, and the graphics group count
returned to its starting value after `deleteMe()`.

## 6. `getStrokes` is not monotonic in its tolerance — PRD 11.7's reading is corrected

The preview was first written to stroke coarsely, on PRD 11.7's evidence that a looser
tolerance returns fewer points. Measured on the reference joint's cope edge:

| tolerance (mm) | tolerance (cm) | points | max chordal sag (mm) | sag / tolerance |
|---|---|---|---|---|
| 1.0 | 0.1 | 44 | 0.088881487 | 0.089 |
| 0.5 | 0.05 | 65 | 0.047007535 | 0.094 |
| 0.1 | 0.01 | **151** | 0.009655191 | 0.097 |
| 0.05 | 0.005 | **65** | 0.047007535 | 0.940 |
| 0.01 | 0.001 | **151** | 0.009655191 | 0.966 |
| 0.005 | 0.0005 | 192 | 0.004781183 | 0.956 |
| 0.001 | 0.0001 | 456 | 0.000815806 | 0.816 |

Three conclusions, in order of how much they matter:

1. **The tolerance is always honored.** The achieved chordal sag never exceeded the
   requested tolerance at any value tried. FR-4.1's accuracy claim rests on this, and it
   holds. The sag is measured as `r − |midpoint|`, the amount a chord between two points on
   a cylinder falls inside it — computable without knowing the intersection curve's closed
   form.
2. **The point count is not monotonic in the tolerance.** Tightening from 0.1 mm to 0.05 mm
   *reduces* the count from 151 to 65. Fusion offers a discrete ladder of refinement levels
   and picks one by a rule that is not "the coarsest that fits"; a coarser request can land
   on a finer rung. **PRD 11.7's "floor on refinement" reading is therefore wrong** — a
   floor is monotonic, and this is not. What PRD 11.7 actually observed was two requests
   landing on the same rung.
3. **The count says nothing about accuracy, and neither does it about work.** Any reasoning
   from point counts — including the preview's original "coarse stroking is cheaper" —
   is unsound. The preview now strokes at the same tolerance as the export, which is what
   the 18.3 % budget figure above makes affordable, and it no longer claims to be
   approximate when it is not.

**Consumed budget at the default tolerance.** FR-4.4's default of 0.01 mm achieves a
0.009655 mm sag, which is **96.6 % of FR-4.1's 0.01 mm template budget**. The unrolling
contributes 0.000000000 mm, so essentially the whole budget goes to tessellation. Tightening
the default to 0.005 mm would halve it for 27 % more points. The PRD names 0.01 mm
explicitly, so this is recorded for a decision rather than changed.

## 7. What could NOT be verified, and why

**The command dialog cannot be executed from the development loop.**
`ui.command._CommandCreatedHandler` runs only inside Fusion's own command dispatch, and two
ways of reaching that dispatch were tried and measured:

| Mechanism | Result |
|---|---|
| `CommandDefinition.execute()` from the MCP script endpoint | `commandCreated` **never dispatched** (`dispatched = False`) |
| the same call deferred through a registered `CustomEvent` | the custom event handler **never fired** (`event_fired = False`) |

Fusion additionally swallows any exception escaping an event handler, so a broken dialog
leaves no traceback anywhere: the symptom is a toolbar button that does nothing. A first
attempt at this probe also produced a verdict it could not interpret, because the observing
run purged `mighty_miter` from `sys.modules` and thereby dropped the last strong reference
to the handler — the very garbage-collection hazard `ui/command.py` documents.

Three things were done rather than accepting the gap:

- **The selection filter strings are no longer literals.** `adsk.core.SelectionFilters` is
  backed by the C++ runtime, and the values were read from it: `Edges == "Edges"`,
  `CylindricalFaces == "CylindricalFaces"`. The dialog now uses those constants, so a typo
  is an `AttributeError` at import rather than a silent dead button. Control:
  `SelectionFilters.CylindricalFace` (singular) and `SelectionFilters.SolidEdges` are both
  **absent**, so the lookup discriminates.
- **Every other API name the handler touches was checked against the runtime** — seven
  `CommandInputs` factories, five `Command` events, thirteen further members
  (`addSelectionFilter`, `setSelectionLimits`, `clearSelection`, `addSelection`,
  `formattedText`, `isExpanded`, `ValueInput.createByReal`, `createFileDialog`,
  `TextListDropDownStyle`, `DialogOK`, `DialogYes`, `YesNoButtonType`, `QuestionIconType`)
  and seven `CustomGraphics` members. All present. These are now
  `tests/live/test_ui_api_shapes.py`.
- **What remains unverified is stated rather than papered over:** the *argument shapes* of
  those seven factory calls, and the behavior of the five event handlers. The only way to
  close it is to load the add-in in Fusion and click the button — a manual step, of the same
  kind as the L5 gates.

**`pytest` is absent from Fusion's bundled interpreter** (`ImportError: No module named
'pytest'`), so nothing in `tests/live/` is executed by pytest on this machine. Those modules
are the tripwire's specification; the probes are what execute the same facts today.

## 8. `CustomGraphics` shapes (PRD 11.5 V8, re-confirmed by execution)

| Claim | Verdict |
|---|---|
| `CustomGraphicsCoordinates.create(flat_list)` | **CONFIRMED** |
| `group.addLines(coords, [], True, [n])` returns `CustomGraphicsLines` | **CONFIRMED** |
| `addLines` with several strip lengths in one call, e.g. `[2, 2]` | **CONFIRMED** |
| `lines.weight` settable | **CONFIRMED** |
| `lines.lineStylePattern = centerLineStylePattern` | **CONFIRMED** (reads back as `1`) |
| `lines.color = CustomGraphicsSolidColorEffect.create(Color.create(...))` | **CONFIRMED** |
| `group.deleteMe()` returns the component's group count to its previous value | **CONFIRMED** |

## 9. New stub/runtime divergence

`Workspace.productType` **raises `RuntimeError: 3`** — *"No product type is associated to
this workspace object yet. Please get workspace object by
`UserInterface::workspacesByProductType()`"* — for at least one workspace reached by
iterating `ui.workspaces`. The property is declared readable. This joins CLAUDE.md
section 5's list; nothing in the add-in reads it, and the add-in resolves its workspace by
id (`FusionSolidEnvironment`) instead.

## 10. Session hygiene

`documents open at exit: 0` on every probe, verified by `p04b_state.py` before and after.
All bodies temporary; the sandbox project holds 0 data files; the toolbar was left clean
(`allToolbarPanels.itemById("MightyMiterPanel") is None`).


## 11. The first run by hand — and a coverage gap in section 5

Section 5 measured the preview path and declared it good. It was measured in an **empty
scratch document**, where nothing can occlude a line, and what it actually established was
that a `CustomGraphicsGroup` is created, styled and deleted. Whether the user can *see*
anything was never in evidence. When the add-in was loaded and driven by hand for the first
time on 2026-09-06, on a head-tube / top-tube joint, no preview appeared.

`p15_preview_visibility` closes the gap the only way a visual question can be closed: it
adds a real `BRepBody` to the document, draws the preview on it, and saves the viewport with
`Viewport.saveAsImageFile(path, 1400, 900)` — three images, one per condition.

| Claim | Verdict | Evidence |
|---|---|---|
| The preview is visible when drawn coincident with a solid face | **CONFIRMED** | image 1: orange miter curve, blue datum ruling and 73 grey ticks all legible against the tube |
| `CustomGraphicsEntity.depthPriority` is readable and settable | **CONFIRMED** | reads `0` on all four entities as drawn; accepts `1` |
| Raising `depthPriority` improves an on-surface preview | **REFUTED** | image 2 is indistinguishable from image 1 |
| The group leaves nothing behind | **CONFIRMED** | image 3 (control) shows the bare body; `customGraphicsGroups.count == 0` |

**`depthPriority` was not adopted.** It was the leading hypothesis for the invisible
preview — lines drawn exactly on a face tie in the depth buffer, and Fusion exposes the
property for that case — and the measurement refuted it. A change that buys nothing is
still a change someone has to defend later.

**What the failure actually was is still open.** The status box in the user's screenshot
still held the message written by the *previous* input change, which means `executePreview`
raised before reaching its own status update and Fusion discarded the exception (CLAUDE.md
section 5; FR-10.2 forbids exactly this). Since the same code path was then run end-to-end
against a fixture with no error, the cause is specific to that design and cannot be
reproduced from the development loop.

The remedy is not a guess at the cause. `inputChanged`, `validateInputs` and
`executePreview` now each catch their own exceptions, log through FR-10.3's rotating file
with the Fusion version, the add-in version and the OS, and write the failing line into the
status box. The next occurrence names itself.