@code3d/core 0.0.1-alpha.0 → 0.0.1-alpha.11

package/docs/runtime.md

@@ -0,0 +1,297 @@
+---
+title: Runtime and integration
+description: Cache computations, integrate native materials and embed the modeling runtime.
+sidebar:
+  order: 11
+---
+
+## Cached computations and custom primitives
+
+`cache(fn)` memoizes synchronous, deterministic data computations;
+`cache(fn, args)` immediately returns the cached result for an argument tuple.
+Both forms share the same function identity and argument keys. Supply custom
+codecs in the third argument: `cache(fn, undefined, options)` for a function or
+`cache(fn, args, options)` for a value.
+Pass changing captured state as arguments and treat returned data as immutable.
+Memory hits reuse the retained result; optional `encoder` / `decoder` pairs only
+run when saving to disk or restoring it. Newly computed entries are eligible
+for disk storage when computation reaches the configured threshold (1 ms by
+default). Faster results remain in memory and are not encoded or written on later
+memory hits. Change the threshold in **Settings → Cache** in the App; it applies
+to new computations and preserves existing cache entries. Existing
+disk records can still be restored. The App fingerprints static definitions
+and their dependencies for persistent reuse; dynamic closures and ordinary Node
+calls use function identity for memory reuse. No author cache IDs are needed.
+
+`definePrimitive(builder)` from `@code3d/core/replicad` also caches construction,
+normalization and geometry analysis. Each call still creates fresh model metadata
+and independently owned geometry handles. The builder transfers its returned
+solid to Core and owns its intermediate resources. Screws uses this shared cache.
+Read [cached computations](api.md#cached-computations)
+and [custom primitives](custom-primitives.mdx)
+for supported data, resource ownership and examples.
+
+## Materials and entry points
+
+`.material()` accepts a color or a native Three.js material. Use
+`@code3d/core/three` when constructing native materials, and
+[@code3d/materials](../../materials/README.md) for common presets. A model captures
+its material value; changing the original Three.js object later does not change
+that model. The renderer supplies lighting and environment reflections.
+
+| Import                  | Responsibility                                                           |
+| ----------------------- | ------------------------------------------------------------------------ |
+| `@code3d/core`          | Public model authoring API; Node entry initializes the kernel            |
+| `@code3d/core/three`    | Shared Three.js exports for material and geometry integration            |
+| `@code3d/core/replicad` | Replicad access for custom primitive builders                            |
+| `@code3d/core/tooling`  | Evaluation, inspection and resource lifetime integration used by the App |
+
+Tooling integrations own evaluation lifetimes and disposal. Follow the existing
+[tooling entry](../src/tooling/index.ts), [evaluation tests](../test/model-test.ts), and
+[App compiler](../../app/src/model/compiler.ts) when embedding the runtime. Ordinary
+model files should stay on the authoring API.
+
+## Source inspection
+
+Ordinary expression values preview directly, including models, anchors and collections.
+Model values retain their authored material opacity: an opaque color stays opaque,
+explicit alpha stays unchanged, and unstyled surfaces keep the default translucency.
+This also applies to ordinary call results and parameter fallbacks. Inspection
+scenes apply the target/focused/ambient opacity limits; an anchor's owner remains
+context behind the reference in both kinds of preview.
+Use `@code3d.inspect parameter callback` when a parameter needs additional context;
+use `@code3d.inspect callback` for an exceptional call-result view. A parameter
+first tries its parameter inspector, then the call inspector, then the ordinary
+call result. A declared closure body has its own scope: declining it continues
+outward without re-entering that same call's parameter or call inspector. The callback
+receives the original argument tuple and `InspectContext`; method receivers are
+in `context.receiver`. Its `target` and `ambient` arrays own the complete scene.
+Returning `undefined` declines the scope; returning `{}` intentionally displays
+an empty scene. Target values matching `context.focused.values` receive focus;
+generated geometry does not inherit focus from its inputs.
+
+Selecting an array member focuses that value while keeping the other inspection
+targets visible at a weaker level; selecting the whole array focuses its members.
+For cut tools and intersect operands, selected inputs are targets and other inputs
+are ambient. The generated cut volume (orange) or intersection (cyan) is a separate
+target, including when inspecting a single input. A failed intersection still
+shows the selected inputs and ambient operands without inventing a result.
+These region inspectors use ordinary unlit materials with depth testing disabled,
+so their colors remain visible through the translucent inputs.
+
+Core uses this mechanism for distance measurements, relate calls and their
+closures, on/align references, relative transformation stages, group children,
+expose sources, Boolean operands and loft sections/spines, plus box and extrusion
+dimensions. Selecting a normal constructor or Boolean function name
+still previews its return value. Inspectors retain the original operation frame,
+so a later relation or a different consumer cannot move its inspection.
+
+A closure can independently declare a context factory with
+`@code3d.inspect.context parameter callback` and a renderer with
+`@code3d.inspect.closure parameter callback`. Context factories run lazily once
+per actual execution. Inner inspectors can read `context.closure.data` and its
+parent contexts regardless of which renderer is selected. The first non-undefined
+inspector wins, searching from the selected expression outward.
+
+For relate, context includes only actual consumed relation participants. Unrelated
+values use ordinary preview. A collection is handled only when every member is
+related; mixed collections fall through as a whole, preserving every previewable
+member. Selecting an individual member tests that member independently.
+Relative transformation functions and pivot/axis chains share a call inspector:
+numeric and reference arguments inspect the consumed relation stage. Unconsumed
+chains do not invent a stage. The tool can edit an ambient participant without
+promoting its display tier.
+
+Topology accessors (`vertex`, `edge`, `surface` and their plural forms) keep
+ordinary anchor preview when they return references. Their inspector returns
+the owner as `ambient` when the call fails or the reference collection is empty.
+The owner therefore has the same background appearance before and after a
+selection; missing or invalid IDs still produce their normal modeling errors.
+
+### Call data
+
+The App runs JSDoc inspection callbacks when the corresponding source is selected.
+Callbacks return `target` and `ambient` preview values. The viewport retains its
+previous scene until the new inspection is ready; an inspection error preserves
+that scene and is reported separately from model evaluation errors.
+
+Models, anchors, sketches, sketch points and passive annotations share this scene.
+Sketches show their points and curves at their actual 3D placement, including open
+curves, inherited layers and multiple noncoplanar sketches. They do not need to
+form a face. The App's **Edit sketch** tool opens the selected authored sketch in
+its 2D plane; **Finish sketch** returns to the 3D preview. Inspection callbacks
+control passive appearance; editing and selection remain tool responsibilities.
+
+Use `captureInspectData(data)` inside a modeling function to retain facts from
+that invocation for its inspector. The function keeps its ordinary return type.
+`InspectContext<Return, Receiver, Data>` describes the callback's return value,
+receiver and recorded data. For example, a scalar query can retain its bounds:
+
+```ts
+import {
+  captureInspectData,
+  dimension,
+  type InspectContext,
+  type InspectResult,
+  type Model,
+  type Vec3,
+} from '@code3d/core';
+
+type SpanData = {owner: Model; minimum: Vec3; maximum: Vec3};
+
+/** @code3d.inspect spanX.inspect */
+export function spanX(owner: Model): number {
+  const {minimum, maximum} = owner.bounds();
+  captureInspectData({owner, minimum, maximum} satisfies SpanData);
+  return maximum[0] - minimum[0];
+}
+
+/** @internal */
+export namespace spanX {
+  export function inspect(
+    _args: [Model],
+    context: InspectContext<number, unknown, SpanData | undefined>,
+  ): InspectResult | undefined {
+    const data = context.data;
+    if (!data || context.return === undefined) return undefined;
+    return {
+      target: [
+        data.owner,
+        dimension({
+          owner: data.owner,
+          start: data.minimum,
+          end: [data.maximum[0], data.minimum[1], data.minimum[2]],
+          value: context.return,
+        }),
+      ],
+    };
+  }
+}
+```
+
+Data belongs to the actual call, including nested calls with equal return values.
+Without a record, `context.data` is `undefined`; multiple records in one call use
+the last value. Closure context factories can read their owning call's data from
+`execution.call.data`. The executor retains references without cloning them, so
+capture immutable facts when later changes must not alter the inspection.
+Inspectors do not run the modeling function again.
+
+A modeling function that throws can still be inspected if it was actually invoked.
+Its original evaluated arguments and last captured data remain available, with
+`context.return === undefined`. Argument evaluation failures and optional-chain
+short circuits do not create an invocation of the outer function. Entered closure
+callbacks follow the same rule. The original modeling diagnostic remains separate
+from any inspection error; inspectors decide what to render when no result exists.
+
+Without an inspection recording session, `captureInspectData` does nothing.
+Calls from an inspector also do not overwrite modeling records. Published
+callbacks use normal runtime exports; `@internal` with TypeScript's
+`stripInternal` can hide their declarations while keeping those exports.
+
+A dimension can provide fixed `start`/`end` points or a nonempty `candidates` list.
+All points use the owner's local frame. For candidates, the renderer picks the
+nearest segment when inspection begins, then retains it while orbiting or
+rechecking the same parameter. Leaving that inspection resets the choice.
+Both forms show a number, endpoint ticks and a screen-sized dashed line.
+
+```ts
+import {dimension, type Model} from '@code3d/core';
+
+function showLength(owner: Model) {
+  return {
+    target: [
+      owner,
+      dimension({
+        owner,
+        value: 10,
+        candidates: [
+          {start: [-5, -2, -3], end: [5, -2, -3]},
+          {start: [-5, 2, 3], end: [5, 2, 3]},
+        ],
+      }),
+    ],
+  };
+}
+```
+
+`boundsAnnotation` represents a finite range without adding CAD geometry. Its
+`frame` is relative to `owner`, centered on the box; `size` measures its three
+local axes. The App draws the existing bounds corners at a fixed screen width.
+It can represent the exact support range of an `on` relation, including flat or
+linear ranges, instead of substituting the whole owner's bounding box.
+
+```ts
+import {boundsAnnotation, type Model} from '@code3d/core';
+
+function showRange(owner: Model) {
+  return {
+    target: [
+      owner,
+      boundsAnnotation({
+        owner,
+        size: [20, 10, 5],
+        frame: {position: [0, 0, 0], quaternion: [0, 0, 0, 1]},
+      }),
+    ],
+  };
+}
+```
+
+Use `anchorAnnotation(reference, {direction})` to choose `'none'`, `'forward'`
+or `'both'` for direction arrows while keeping the reference's geometry and
+placement. For curves, arrows follow the real endpoint tangents; reversing the
+reference reverses its authored direction. The annotation retains the reference's
+focus identity. Returning an ordinary Anchor keeps its default object preview.
+
+```ts
+import {anchorAnnotation, type SolidModel} from '@code3d/core';
+
+function showAxis(owner: SolidModel) {
+  return {
+    ambient: [owner],
+    target: [anchorAnnotation(owner.axis, {direction: 'forward'})],
+  };
+}
+```
+
+## Source and development
+
+For changes to Core itself, start with the [modeling architecture](../../../.agents/docs/architecture/modeling.md)
+and shared [development guide](../../../.agents/docs/development.md), then follow
+the implementation and tests below.
+
+- [Public exports](../src/library/index.ts), [model runtime](../src/library/runtime.ts),
+  and [public type tests](../test/public-types.ts).
+- [Spatial values](../src/library/spatial.ts), [relation solving](../src/library/relation-solver.ts),
+  and [topology](../src/library/topology.ts).
+- [Cached computations](../src/library/cached.ts), [fonts](../src/library/font.ts),
+  [text geometry](../src/library/text.ts) and their [tests](../test).
+- [Material values](../src/library/material.ts), [kernel cache](../src/library/kernel-cache.ts),
+  and [Node entry](../src/node/index.ts).
+- [Executable App examples](../../app/examples) and [runtime tests](../test).
+
+Public JavaScript entries are prebundled ESM with shared chunks. Node, browser,
+tooling and interop entries share the same kernel and cache instances. TypeScript
+declarations, declaration maps and their sources remain available for editor
+navigation. The build and npm `prepack` use the same package build script; see the
+[development guide](../../../.agents/docs/development.md#公开包产物) for installed
+tarball verification and CI publishing.
+
+For a standalone TypeScript project, include `ESNext` and `DOM` in `compilerOptions.lib`.
+Use `module: "ESNext"` and `moduleResolution: "Bundler"` when esbuild or another
+bundler handles execution. Code3D's App uses this resolution mode, supports
+extensionless relative imports and selects browser package exports.
+The public packages are built and verified with `skipLibCheck: false`. NodeNext
+currently needs `skipLibCheck` because the `manifold-3d@3.0.1` declarations omit
+relative `.js` extensions. Core includes the declaration dependencies needed by
+its HarfBuzz and Replicad integrations.
+
+From the repository root:
+
+```sh
+npm run build:packages
+npm test --workspace @code3d/core
+```
+
+Use the [agent entry](../../../docs/agents.md) to work on a project through the CLI,
+or the [App README](../../app/README.md) to develop the editor and visualization.

package/docs/shells.mdx

@@ -0,0 +1,70 @@
+---
+title: Making hollow parts
+description: Create uniform walls and choose openings directly on a solid.
+sidebar:
+  order: 8
+---
+
+import ModelExample from '../../web/src/components/ModelExample.astro';
+
+Start with a solid that describes the outside of your part. Use
+`shell(thickness, removedSurfaceIds?)` to hollow it and choose which faces
+become openings.
+
+<ModelExample id="shell" />
+
+## Set the wall thickness
+
+Positive thickness offsets inward, preserving the outside dimensions.
+The example keeps its 40 × 24 × 30 outside size with walls 1.5 units thick.
+Negative thickness offsets outward, keeping the original boundary on the
+inside; neighboring offset faces use rounded joins where they separate.
+
+Place the cursor inside `shell(1.5, [4])` to edit **Wall thickness** in the
+panel. Thickness must be finite and nonzero.
+
+## Pick the openings
+
+S4 is the input box's +Y face. In the **Openings** tool, click another face to
+open it, or click a selected face again to restore the wall. The viewport
+keeps the input faces available while showing the hollow result, so a removed
+face can still be selected.
+
+Selections write back immediately. **Close all openings** removes the surface
+array. Omitting it, or passing `[]`, creates a sealed cavity:
+
+```ts
+const sealed = box(40, 24, 30).shell(1.5);
+```
+
+At least one face must remain as a wall. Use Undo to revert a committed
+selection; moving the source cursor out of the call leaves the tool.
+
+## Select faces from the input
+
+An opening ID belongs to the solid before `shell`. For a two-section loft,
+the cap IDs carry their source-section paths:
+
+```ts
+const openEnds = body.shell(1, [
+  [1, 1],
+  [2, 1],
+]);
+```
+
+The outer array lists two openings; each inner array is one surface ID.
+After shelling, one-to-one inherited topology keeps its complete ID.
+Offset walls receive fresh numeric IDs without reusing retired ones. Pick later fillet or chamfer edges
+from the shell result. See [topology paths](topology.md#ids-belong-to-a-model)
+and the [loft cap example](/examples/topology-paths/).
+
+## Correct a failed shell
+
+Shelling requires one connected solid. Tight curves, narrow features, and
+complex intersections can prevent a valid offset or opening. The tool keeps
+the input available so you can change the thickness or selected faces.
+
+On some lofts between different profile shapes, a sealed cavity succeeds
+while opening an end fails, even at smaller thicknesses. The
+[bent loft example](/examples/loft/) has this known
+limitation. See [geometric operation limits](../../web/src/content/docs/docs/getting-started/limitations.md#what-to-account-for).

package/docs/sketches.md

@@ -0,0 +1,83 @@
+---
+title: Editable sketches
+description: Create constrained sketches and relate their planes to model geometry.
+sidebar:
+  order: 7
+---
+
+## Editable sketches
+
+Sketches are immutable 2D definitions, separate from B-Rep model values. Entries
+carry positive IDs within a layer; constraints express what should stay true.
+A derived layer can reference its upstream geometry.
+
+```ts
+import {sketch} from '@code3d/core';
+
+const profile = sketch(
+  [
+    ['point', 1, [0, 0]],
+    ['circle', 2, [1, 8]],
+  ],
+  {
+    constraints: [
+      ['fixed', 1],
+      ['radius', 2, 8],
+    ],
+  },
+);
+
+export const part = profile.face().extrude(3);
+```
+
+Closed regions bridge sketches to ordinary face and solid modeling. Read the
+[sketch reference](api.md#editable-sketch-regions)
+and [agent sketch workflow](../../../docs/agents/sketches.md) for constraints,
+derived layers, observations, and failure diagnostics. Exact tuple types and
+solver behavior live in [sketch.ts](../src/library/sketch.ts) and
+[sketch-solver.ts](../src/library/sketch-solver.ts).
+
+### Relating a sketch to a model plane
+
+`s.relate(self => self.plane.align(target))` returns a new sketch with spatial
+relations, leaving its shared 2D definition and the original sketch unchanged.
+It works before a face exists, including `sketch()` and open contours.
+
+```ts
+import {box, sketch} from '@code3d/core';
+
+const host = box(40, 20, 30).rotate(0, 0, 25);
+const profile = sketch([
+  ['point', 1, [0, 0]],
+  ['circle', 2, [1, 4]],
+]);
+const opening = profile.relate(s => s.plane.align(host.surface(4)));
+const result = host.cut([opening.face().extrude(-20)]);
+const draft = sketch().relate(s => s.plane.align(host.surface(2)));
+```
+
+The target may be a named plane or a planar `host.surface(id)`. The sketch plane
+normal is local `+Y`; alignment uses the same directed-plane alignment, composition-axis offset
+and rotation semantics as model relations. It does not implicitly center the
+sketch on a trimmed surface. An unbounded sketch plane cannot use `on()` to place
+finite geometry against a bound; use `align()`. Topology-only pivots such as
+`pivotVertex()` require a geometric model, not an empty sketch frame.
+
+`derive()`, `face()` / `faces()` and extrusion inherit the relations. Boolean
+operations and loft resolve their inputs in the shared composition context;
+placement is not baked into tuple coordinates. A spatial copy shares point
+identities with its original, so a derived layer can still use `profile.point(id)`.
+References target the actual immutable model value: creating a later rotated or
+repositioned model does not redirect existing sketch relations.
+The `relate` callback parameter represents the new sketch frame; every returned
+constraint must involve it. References to the original sketch's plane stay on
+the original frame.
+
+In the App, select the related value (`opening`) and choose **Edit sketch** to edit against read-only model
+outlines projected into the sketch's local plane. Select `profile` and choose **Edit sketch** for its original
+local view. Both edit the same source array, with ordinary undo; separate placements
+of that geometry are not separate authoring definitions. Context outlines are
+visual references only, not snapping targets or imported geometry constraints.
+The select-surface-and-create UI is tracked separately within
+[#114](https://github.com/vilicvane/code3d/issues/114).
+Try [mounting-plate.ts](../../app/examples/sketches/mounting-plate.ts).

package/docs/text.md

@@ -0,0 +1,23 @@
+---
+title: Text and fonts
+description: Build solid text with Google Fonts or local font files.
+sidebar:
+  order: 9
+---
+
+## Text and fonts
+
+```ts
+import {googleFont, text, extrude, group} from '@code3d/core';
+
+const face = googleFont('Play');
+export default group(extrude(text('Hello', face, 10), 1));
+```
+
+In the App, `googleFont()` uses a static family name and optional weight/italic
+settings; `font()` accepts a static font-file URL or TTF/OTF bytes. The engine
+prepares remote resources before synchronous model execution. Text returns
+ordinary planar faces with a common baseline; `extrude(faces, distance)` preserves
+their order and placement. Node can read local file URLs or use downloaded,
+decoded font bytes. See the [text reference](api.md#text),
+[runnable example](../../app/examples/text.ts) and [font notices](../THIRD_PARTY.md).

package/docs/topology.md

@@ -0,0 +1,152 @@
+---
+title: Selecting vertices, edges, and faces
+description: Pick topology for fillets, chamfers, shells, origins, and relation anchors.
+sidebar:
+  order: 6
+---
+
+Start with a box:
+
+```ts
+import {box} from '@code3d/core';
+
+const base = box(36, 4, 24).fillet(1);
+```
+
+## Round all edges
+
+`fillet(radius)` rounds every edge. `chamfer(distance)` bevels every edge.
+The number must fit the geometry: an operation can fail when its size consumes
+a small face or creates an invalid intersection.
+
+## Choose edges visually
+
+Place the cursor inside the `fillet` argument area. The edge tool lets you
+select the edges to round. Selecting specific edges adds their IDs as the
+second argument, for example `fillet(1, [2, 4])`.
+
+The tool keeps the operation's input edges available for selection while
+showing its result. Use the panel to adjust the radius or distance; those
+edits return to the source as you type.
+
+**Use all edges** removes the second argument. Deselecting every explicit edge
+also returns to all-edge mode; an empty array is not an explicit no-op.
+
+Selections write back immediately. Pressing `Esc` does not discard them or
+close the tool; move the editor cursor away from the call to leave it, and
+use Undo to revert an edit.
+
+## Hollow a solid
+
+`shell(thickness, removedSurfaceIds?)` creates uniform walls in a connected solid.
+Positive thickness offsets inward and preserves its outside boundary; negative
+thickness offsets outward and preserves the original boundary on the inside.
+Outward offsets use rounded joins where neighboring offset faces separate.
+
+```ts
+const enclosure = box(40, 24, 30).shell(1.5, [4]);
+const sealed = box(40, 24, 30).shell(1.5);
+```
+
+For this box, S4 is its +Y face. Removing it makes an open enclosure. Follow the
+[hollow-part guide](shells.mdx) for the runnable example. Place the
+cursor inside `shell(...)` to adjust **Wall thickness** and toggle **Openings**
+on the input model while viewing the result. IDs belong to that input model.
+The picker retains removed faces so you can close an opening again.
+
+Omitting the surface array, or passing `[]`, creates an enclosed cavity.
+**Close all openings** removes the array. Selecting every face is an error:
+at least one surface must remain as a wall. Thickness must be finite and nonzero.
+Offsets can fail around narrow features and complex curves; the input remains
+available to correct the thickness or openings.
+
+## IDs belong to a model
+
+Edge, face, and vertex IDs have separate namespaces within each model. An ID
+is not a position in a JavaScript array or a globally unique identifier.
+
+Primitives use numbers starting at `1`. Constructors such as loft, extrusion and
+Boolean operations create a new namespace. Inherited elements receive paths
+`[inputIndex, ...previousId]`, with input indices starting at `1`; new elements
+receive numeric IDs starting at `1` in that result.
+
+For `loft([start, end])`, the two cap faces are `surface([1, 1])` and
+`surface([2, 1])`; side faces are `surface(1)`, `surface(2)`, and so on. Changing
+the number of side faces does not move the cap IDs. Boolean operations use the
+same rule for every input, including cutting tools. Edges and vertices follow
+the same rules in their own namespaces.
+
+Local edits (`fillet`, `chamfer`, and `shell`) keep the input namespace. A
+one-to-one original `E10` remains `E10`, so a later chamfer can select it with
+`rounded.chamfer(0.5, [10])`. Existing paths also remain unchanged: a loft cap
+`S[2,1]` keeps that ID after a fillet. New elements use fresh numeric IDs above
+all numbers previously allocated in this namespace, including retired IDs.
+
+For example, `box(50, 3000, 100).fillet(5, [2, 4, 6, 8])` retains faces
+`S1`–`S6` and adds four rounded faces `S7`–`S10`. The two end faces are still
+`S3` and `S4`; rounding their corners does not break their one-to-one identity.
+
+In the [topology paths example](/examples/topology-paths/), inspect
+`inlet`, `outlet`, and `side` to compare inherited cap IDs with a new side
+face. The viewport labels paths as S[1,1] or E[1,10]; selections write the
+corresponding arrays into source.
+
+Only one-to-one descendants inherit an ID. Deleted elements have no descendant;
+ambiguous splits and merges receive new numeric IDs. A middle loft section is
+not a cap, and a section edge split by loft compatibility does not retain a
+single edge identity. New-element numbering follows deterministic construction
+and can change when that construction changes.
+
+Rotation, scaling, placement, and exposed references keep complete IDs. Always
+select IDs from the model passed into the operation being edited; IDs are not
+interchangeable between a source and its result.
+
+Shelling follows the same history rules: an unchanged boundary retains its ID,
+and offset walls get new numeric IDs. An opening rim can
+inherit its former cap's surface ID when the kernel records a one-to-one
+modification. To open both ends of a two-section loft, use
+`body.shell(1, [[1, 1], [2, 1]])`.
+
+## Use topology as a relation anchor
+
+`model.surface(id)`, `model.edge(id)`, and `model.vertex(id)` return
+face, line, and point anchors. Use their plural forms to obtain a collection;
+omitting the ID array returns all elements of that kind.
+
+Place the cursor in one of these calls to pick its topology in the viewport.
+Singular forms select one ID; plural forms let you toggle multiple IDs and
+can explicitly use `[]` for no elements. That is different from fillet and
+chamfer's all-edge behavior.
+
+Continue querying a selected face or edge:
+
+```ts
+const face = base.surface(1);
+const boundary = face.edges();
+const corners = boundary[0].vertices();
+const center = face.center;
+```
+
+Queries use the original model's IDs and stay within the selected element.
+`face.edge(id)` reports an error if that edge is outside the face. The viewport
+picker offers only the eligible edges or vertices, including when the geometry
+is exposed from an assembly.
+
+`center` is the selected geometry's local bounding-box center, carried through
+transforms. Edges also provide `start`, `midpoint`, and `end` point anchors at
+curve parameters 0, 0.5, and 1. A curve midpoint can differ from its center or
+half-length point. Calculated points do not acquire vertex IDs; `.vertices()`
+returns the actual topology, including a single vertex on a closed edge.
+
+To choose a vertex as a rotation pivot, use `.originVertex(id)`. See
+[origins and rotation](origins-and-rotation.mdx).
+
+A named element exposed by a reusable part usually communicates intent better
+than a caller maintaining its internal topology IDs. See
+[reusable models](../../web/src/content/docs/docs/guides/reusable-models.mdx).
+
+## Recover from an operation failure
+
+Check the input edges first, then reduce the radius or distance. A failed
+fillet or chamfer can still expose its input model to the contextual tool,
+so you can correct the operation without deleting it.