Crate brep_app 

Shared eframe application for native windows and WebAssembly canvases. app::BrepApp hosts the renderer and egui in one wgpu frame.

Modules

app

BrepApp — the THIN shell of the engine-native UI.

automation

The automation layer — the one command channel the app exposes to a host (brep-mcp headless / window, or a dial-in adapter).

column_tree

A tree table with resizable, reorderable, hideable, sortable columns.

desktop_loop

The desktop event loop: eframe’s winit application plus application-command dispatch that does not wait for a frame (a hidden Wayland window gets none). The desktop event loop.

diagnostics

What this build is running on — the ONE record of it.

document

Open documents and their active tab. Each document owns an engine, store identity, and clean baseline for dirty tracking. Keeping engine access on Documents allows separate mutable borrows of other app fields.

document_class

The three document classes (.nbrep / .fbrep / .tbrep). The three document classes: a normal part (.nbrep), a family seed (.fbrep) and a template (.tbrep).

family_table

A family seed’s table and its Generate (.fbrep). A family seed’s table (.fbrep): one row per member, and the Generate that writes each row out as an ordinary .nbrep part next to the family file.

file_association

Register this build as the system’s .nbrep opener (brep-app --install-file-associations). Native only: the browser has no file association to claim. Register this executable as the system’s opener for its three document classes: .nbrep parts, .fbrep family seeds and .tbrep templates.

fonts

Font setup — the OS’s default monospace font for all text.

form

The generic, schema-driven egui form engine — ONE per-field renderer for BOTH the display-settings dialog AND the schema-driven feature dialogs (the user’s principle: the structure of a thing drives the UI; you don’t rewrite UI code per field, and you don’t write two dialog engines).

form_view

Schema-driven form layout built on form::field_input.

handles

Public handles: the opaque <kind>_<epoch>_<nonce> strings an agent names a document by (the contract’s §3). The epoch is random per process, so a handle from an earlier run is recognisably stale; the nonce is random per object, so a handle cannot be guessed from another. Both are 128 random bits written as 22 characters of unpadded base64url. The app’s own Document::id (a counter) stays the internal key and never leaves the process.

icon_text

IconText — a label that draws catalogued characters as real SVG images, inline with the surrounding text.

icons

The inline-icon catalog: every assets/glyphs/*.svg as SVG source, keyed by the character it draws.

instructions

Manufacturing instructions in the app: making an instructions document from an assembly, the open one or a stored one.

javascript

In-app scratch scripts. Source is saved only on request and never on a model.

logger

The native binary’s log sink (main.rs): RUST_LOG to stderr. Replaces env_logger; the wasm build logs through the browser console instead. The native binary’s log sink: RUST_LOG-filtered lines to stderr.

mcp

The embedded MCP server (brep-app --mcp); native builds with mcp. The embedded MCP server — brep-app --mcp.

offsite

Features that call another site, on a CAD app hosted by a PLM.

palette

A generic, reusable searchable command-palette modal — engine-agnostic.

panels

The left-control-panel modules — one file per panel, each following ONE pattern so parallel agents can add a new panel with minimal conflict:

perf

Where a frame’s milliseconds go — the per-frame timing record behind the __brepPerf blob and the Info window’s Performance rows. Where a frame’s milliseconds go — the ONE per-frame timing record.

plm

The PLM client: config, transport, sign-in and the PLM store backend. Inert with no server configured. The PLM client: where the server is, how a request reaches it, and — in client — sign-in, the refusals, the change feed and the version check. Nothing here runs unless a server is configured; the file-based app never constructs any of it.

plugins

Explicit installation and host-only acquisition. Document opening never installs code.

recovery

Autosave unsaved documents under RECOVERY_KEY for recovery at next boot.

scripting

Scripts in the CAD app: the CAD host for the PLM’s interpreter core (S11). Scripts in the CAD app: the CAD-side host for the interpreter the PLM’s administrator hooks run on (BREP_script_core, plm-cad-integration-todo §3 S11).

simulation_export

A motion study as a video file: GIF (the image crate’s encoder, every frame its own palette, looping) or MP4 (H.264 through the pure-Rust rusty_h264 encoder, muxed by mp4e), at a chosen size and fps.

store

The persistent-storage / filesystem seam — the ONE platform exception in the engine-native UI. Settings, dock layout, and model documents all use the same ModelStore::read / ModelStore::write API. Only its backend differs: desktop writes files; the browser mirrors an ASYNC, swappable mirror_store::StoreBackend — IndexedDB today, a remote server next — into memory and writes behind it, which is what keeps this whole API synchronous.

template

A template’s input marks and its spin-out (.tbrep). A template (.tbrep): a seed whose MARKED expressions are the user’s inputs. Inserting one never places the template: it asks for a new name and the input values, spins out a unique normal part with those values baked into its expressions, and places that.

viewport

The 3D viewport — everything that draws + drives the central brep-render scene, split out of the thin app shell.

webmcp

The browser’s tool surface (WebMCP): the MCP server’s tool set, served by the page as the tools it registers with document.modelContext, answered through the automation queue. The pure half compiles natively for its tests; the host and the exports web/webmcp.js imports exist on wasm only. The browser’s tool surface: WebMCP for the wasm build, serving the SAME tool set the desktop MCP server does.

workbench

Per-file WORKBENCH registry — a UI FILTER over feature-CREATION.