BREP_app 0.4.0

The BREP CAD application: an eframe (egui + wgpu) host that draws the brep-render 3D engine into an egui frame — native + wasm from one codebase.
Documentation
# BREP_app

The BREP CAD application: one Rust egui/wgpu codebase for native desktop and
WebAssembly. Package `BREP_app`, library `brep_app`, manifest version 0.4.0.
The 3D engine is `BREP_render`; geometry comes from `BREP_kernel`.

## Build and run

From the repository root:

```sh
./build.sh app
./build.sh serve
./build.sh native
```

The web build writes `BREP_app/pkg/`; serve opens the app at
`http://localhost:8080/web/`. It also generates help from the user-facing docs.

From this crate directory:

```sh
cargo build --release
./target/release/brep-app
./target/release/brep-app --mcp
cargo build --release --target x86_64-pc-windows-gnu
```

The Windows cross-build needs the GNU target and mingw-w64 linker. The pinned
toolchain (`rust-toolchain.toml`) and setup commands are in the
[root guide](../README.md); this crate's own floor is `rust-version = "1.92"`,
which is what eframe/egui 0.35 declare.
`--mcp` serves the visible native app over loopback HTTP; the separate
`BREP_mcp` tool supplies a headless host. [Automation guide](../docs/automation/index.md).

## Architecture

| Module | Responsibility |
|---|---|
| `src/app.rs` | eframe shell, document lifecycle and action dispatch |
| `src/document.rs` | Open documents, each with one `EngineState` |
| `src/viewport.rs`, `src/viewport/` | Offscreen 3D render, egui composition, input and labels |
| `src/panels/` | History, scene, sketches, files, assemblies, PMI, harness and other panels |
| `src/form.rs`, `src/form_view.rs` | Shared schema fields and complete forms |
| `src/workbench/` | Six definitions, feature predicates, contributed actions and panel claims |
| `src/store.rs` | Native filesystem and browser persistence |
| `src/recovery.rs` | Dirty-document autosave and startup recovery |
| `src/automation/` | Command/state/hit-key registries, queue and virtual input |
| `src/mcp.rs` | Native attached-window server host |

`EngineState` owns the editable history, undo, scene, camera, selections and
editing modes. Panels borrow it and apply intents; they do not keep another
feature list. Native and browser runners evaluate history off the UI thread.

History has a tree and a separate form. The same form view serves features,
assembly constraints, PMI annotations and dialog screenshots. Workbenches filter
creation and panel/action visibility; existing histories remain editable.
PMI additionally activates captured views and restores modeling display state.

The viewport renders into an app-owned texture on eframe's wgpu device. A paint
callback composites it into the egui frame. Scene-row hover and viewport hover
use the same engine highlighting. Glyphs are SVG artwork from the asset catalogue.

The design notes behind this — application architecture, shared forms and the
workbench registry — are `docs/developer/engine-native-ui-design.md`,
`feature-dialog-redesign-plan.md` and `architecture/workbench-architecture.md`
under `BREP-dev-data/reference/`, the private development submodule.

## Files and persistence

Open, Save As, Import and Export use the shared in-app file explorer. Desktop
storage uses real filesystem paths; browser storage uses an IndexedDB mirror
with upload/download bridging. Saved document state and user settings are separate.
Startup offers dirty-document recovery instead of silently reopening an old session.
[Storage guide](../docs/saving-and-storage.md).

## Testing and documentation

```sh
# repository root
./build.sh test-ui
./build.sh test-mcp
cargo run --manifest-path BREP_docs/Cargo.toml --locked

# repository root: regenerate visible form screenshots privately
python3 BREP-dev-data/testing/run.py -- cargo run --manifest-path BREP_app/Cargo.toml --example capture_dialogs
```

Browser interaction verifiers live under `BREP-dev-data/testing/overlay/BREP_app/web/`; their migration is
tracked in the MCP automation build spec (`BREP-dev-data/reference/docs/developer/mcp-automation-build-spec.md`).
Use the checks appropriate to the changed behavior and target, including actual
pointer/capture assertions for widget changes. Geometry changes also require
kernel/case gates; the testing policy
(`BREP-dev-data/reference/docs/developer/testing-policy.md`) states which gate a
change selects.

User docs build into `web/help/`; developer plans are excluded from the help site.
The generator uses feature/workbench glyphs in headings and navigation. The
`docs_feature_icons` integration test checks documentation icons against the catalogue.
The site closes with a Licences section: the project licence, the third-party
notices, and a crate inventory generated from `cargo metadata` at build time,
grouped by licence expression, with the font notices that must accompany the
embedded fonts reproduced in full. `python3 BREP-dev-data/testing/run.py -- cargo test --manifest-path BREP_docs/Cargo.toml`
covers the generator.

## Distribution

The native default `mcp` feature embeds `BREP_mcp_core`; wasm uses its automation
layer without the native server dependencies. Packaging must resolve that core
before the app. See the publishing guide (`BREP-dev-data/reference/PUBLISHING.md`),
[license](LICENSE.md) and
[third-party notices](../THIRD-PARTY-NOTICES.md).