Welcome & Repo Map

Goal of this chapter. After 60 minutes you understand what Flux is, where the code lives, how the modules fit together, and where to read next — without writing a single line of code.

Audience. New engineers joining Flux development. No prior CAM knowledge assumed.

Flux in ten lines

Flux is a sheet-metal CAD/CAM application from the Metamation/Trumpf family.
Business domains: laser cutting, punching, press-brake bending, panel-bender folding, nesting, bend-cell automation (robot).
Stack: C# on .NET 10 (Windows, x64-only), UI in WPF (with WinForms residue), 3D import via HOOPS through a C++/CLI wrapper (Flux.Hula64).
One solution: X:\Src\Flux.sln with eight projects (Base, Core, UI, App, API, Console, Migrate, Test).
Architecture: Model → View → Glob (Glob ≈ controller). Models and views sit together in Flux.Core; controllers live in Flux.UI.
Data formats: geometry/settings as Curl (text) or Au/Gold (binary); read-only assets bundled into Flux.wad. Press-brake NC post-processors are C# classes in Src\API\Bend\Post\ (one per dialect — Trumpf DLD, Bystronic, LVD, Cybelec, Safan, …); the .hx extension still appears in machine config but is only a routing token now.
One executable (Flux.exe), but eight flavors (Dev, Flux, Trumpf, Boost, Engine, B23, Fold, Tech) — selected at runtime via a Flux.flavor text file next to the EXE.
Tests: a custom framework called Flit, with [TestFixture] / [Test] attributes. ~169 test files, inputs under X:\TData.
Docs: built-in tech notes live in X:\Notes in the proprietary FTex format. Excellent in spirit — and partially outdated (see §8).
You don’t have to commit anything productive in the first six months. Read, navigate, understand, ask. That’s what this chapter is for.

1. What is Flux?

Flux is the next-generation CAM stack from Metamation, replacing the older MetaCAM system step by step. It ships under multiple brand names (see §7 Flavors). The header in every source file states:

// Flux ~ Sheet metal CAD/CAM system
// Copyright (c) Metamation India.

The value chain Flux models in code, for a typical part:

CAD import (STEP / IGES / DXF / DWG / ...)
        │
        ▼
Geometry model (B-Rep, mesh, polylines)        ←  Flux.Base + Flux.Core/Model
        │
        ▼
Feature & operation detection                  ←  Flux.Core/Bend, /Laser, /Punch, /Fold
        │
        ▼
Toolpath / NC generation                       ←  Flux.Core/Bend, /Laser, /Punch
        │
        ▼
Simulation & collision                         ←  Flux.Core/Sim, /BCell
        │
        ▼
Post-processor → NC code (G/M-code, BCC, DLD, ...)  ←  C# writers in Src\API\Bend\Post\ (dispatched via Hub.GenerateNC by post name)

Important consequence: Flux is not a CRUD business application. "Model" and "view" are often the same object — for example, an E3Plane knows how to render itself in OpenGL. This point is laid out at length in Notes\Dev\1002.BuildingFlux.ftx lines 31—61: the original MVC separation was rolled back because it forced ugly workarounds (the so-called Hub whiteboard).

So if it surprises you that a class like LaserCutVM lives in the Core layer — that’s intentional.

2. Repo map (top-level)

X:\
├── Src\          C# source code (single solution: Flux.sln)
│   ├── Base\     Foundation: geometry, mesh, polylines, IO primitives, rendering layer (Lux)
│   ├── Core\     "Engine": domain models + their views (VModel hierarchy)
│   ├── UI\       Controllers (Glob hierarchy) + WPF dialogs
│   ├── App\      Main window, tabs, shell — this is what gets compiled into Flux.exe
│   ├── API\      Narrow wrapper for 3rd-party automation
│   ├── Console\  Developer CLI (metadata rebuild and other utilities)
│   ├── Migrate\  CLI migration from MetaCAM / TOPS legacy data
│   ├── Hula\     C++/CLI wrapper around HOOPS (3D import) — built separately
│   ├── Lib\      External NuPkgs / DLLs (Aegis, Trumpf-Licensing, ...)
│   ├── Publish\  Publish profiles / setup scripts
│   ├── bin\      Build output (all DLLs end up here)
│   └── obj\      Intermediate output
├── Test\         Test project (Flux.Test.csproj — framework is "Flit")
├── TData\        Test input data (.geo, .vdwg, ...) organized by domain
├── Data\         Runtime data: machines, tools, materials
├── Doc\          Images and concept diagrams (with a `.png` gallery per domain)
├── Help\         End-user manual (FTex)
├── Notes\        DEVELOPER notes (FTex) — see §8, well worth reading
├── Resources\    Fonts, HOOPS binaries, icons
├── Tools\        Helper utilities
├── Wad\          Read-only resources packed into Flux.wad
├── SDK\          SDK artifacts for API consumers
└── .github\      CI/CD

Code volume (rough, current)

Module	C# files
Flux.App	301
Flux.Core	278
Flux.Test	169
Flux.UI	117
Flux.Base	109
Flux.API	98

Plus a handful of C++ files in Src\Hula\ (Hula.cpp ≈ 40 KB is the main one). Total: ~938 .cs files under Src\.

3. The eight projects in the solution

Project Type Purpose Read here

Project	Type	Purpose	Read here
Flux.Base	C#	Geometry primitives, mesh, polyline, GL context, IO helpers, undo system, Lux rendering layer	`Src\Base\Geo\`, `Src\Base\Mesh\`, `Src\Base\Lux\`
Flux.Core	C#	Domain engine: Bend, Fold, Laser, Punch, Nest, BCell, Sim, Drawing, Layout, Trim, IO, Settings, Model, OEM, Part, Report	`Src\Core\Bend\BendCore.cs`, `Src\Core\Laser\LaserCore.cs`, `Src\Core\Part\Part.cs`
Flux.UI	C#	Per-domain Glob controllers + WPF editors (TurretEditor, SheafEditor, LaserDBEditor, …)	`Src\UI\Editor\`, `Src\UI\<domain>\*UI.cs`
Flux.App	C#	Main window, tab management, global UI state, selection, undo lifecycle. This DLL is the bulk of `Flux.exe`.	—
Flux.API	C#	Restricted, hardened wrapper for 3rd parties — no direct Core exposure	`Src\API\Job\`, `Src\API\Cut\`
Flux.Console	C#	Developer CLI (metadata rebuild, internal maintenance)	Mostly for in-house Metamation use
Flux.Migrate	C#	One-shot CLI migration: tool libraries from TOPS, machine definitions from MetaCAM	Run once at the customer site
Flux.Test	C#	Test suites (Flit framework) + GUI test runner	`Test\Bend\BasicBendAuto.cs` is the canonical example

Flux.Base

Geometry primitives, mesh, polyline, GL context, IO helpers, undo system, Lux rendering layer

Src\Base\Geo\, Src\Base\Mesh\, Src\Base\Lux\

Flux.Core

Domain engine: Bend, Fold, Laser, Punch, Nest, BCell, Sim, Drawing, Layout, Trim, IO, Settings, Model, OEM, Part, Report

Src\Core\Bend\BendCore.cs, Src\Core\Laser\LaserCore.cs, Src\Core\Part\Part.cs

Flux.UI

Per-domain Glob controllers + WPF editors (TurretEditor, SheafEditor, LaserDBEditor, …)

Src\UI\Editor\, Src\UI\<domain>\*UI.cs

Flux.App

Main window, tab management, global UI state, selection, undo lifecycle. This DLL is the bulk of Flux.exe.

—

Flux.API

Restricted, hardened wrapper for 3rd parties — no direct Core exposure

Src\API\Job\, Src\API\Cut\

Flux.Console

Developer CLI (metadata rebuild, internal maintenance)

Mostly for in-house Metamation use

Flux.Migrate

One-shot CLI migration: tool libraries from TOPS, machine definitions from MetaCAM

Run once at the customer site

Flux.Test

Test suites (Flit framework) + GUI test runner

Test\Bend\BasicBendAuto.cs is the canonical example

Outside the solution but required at runtime: Flux.Hula64.dll (C++/CLI). The build process is described in Notes\Dev\1002.BuildingFlux.ftx lines 129—187 — do not compile it yourself, copy it from X:\Resources\Hoops to bin.

Dependency direction

Flux.Base   ◄── Flux.Core   ◄── Flux.UI   ◄── Flux.App
                  ▲                 ▲           │
                  │                 └───────────┘
                  └── Flux.API    (facade over Core)
                  └── Flux.Test   (references Core directly)
                  └── Flux.Migrate, Flux.Console (console front-ends)
                  └── Flux.Hula64.dll (HOOPS wrapper, native reference)

Source: Src\Flux.sln and the explicit <ProjectReference> / <Reference> entries in each .csproj.

4. Domains under `Flux.Core`

Flux.Core is internally split into domain packages. Each folder under Src\Core\ is a topic of its own:

Folder Domain Reading entry point

Folder	Domain	Reading entry point
`Bend` (47 files)	Press-brake CAM (folding with stamp/die)	`BendCore.cs`, `BendOp.cs`, `BendTech.cs`, `BendMachine.cs`
`Fold` (42 files)	Panel-bender CAM (TecZoneFold)	search `Grep "class FoldOp"`
`Laser`	Laser cutting	`LaserCore.cs`, `LaserCut.cs`, `LaserAuto.cs`, `AutoRouter.cs`
`Punch` (13 files)	Punching	`PunchCore.cs`
`Nest` (10 files)	Nesting multiple parts on a sheet	`Src\Core\Nest\`
`BCell` (34 files)	Bend-cell automation (robot, gripper, suction cups)	image gallery at `Doc\Img\BCell\` for vocab
`Sim` (5 files)	Simulation & collision	`Src\Core\Sim\`
`Drawing` (7 files)	2D drawing / sketch mode	—
`Layout` (14 files)	Machine / setup layouts	—
`Trim`	Trim / edge processing	—
`Part`	Part model (links domains)	`Part.cs` (the canonical "job")
`IO`	File import/export per format	`DXFReader.cs`, `GeoReader.cs`, `HXReader.cs` (the HOOPS reader, despite the misleading name), …
`Model`	Shared 2D / 3D model classes (E2, E3)	`E3Plane.cs`, `E3Flex.cs`, `Entity3.cs`
`Settings`	Settings / configuration	`Sheaf.cs` (cascaded settings dictionary)
`Report`	Setup sheets, PDF reports	—
`OEM`	OEM-specific customizations	—

Bend (47 files)

Press-brake CAM (folding with stamp/die)

BendCore.cs, BendOp.cs, BendTech.cs, BendMachine.cs

Fold (42 files)

Panel-bender CAM (TecZoneFold)

search Grep "class FoldOp"

Laser

Laser cutting

LaserCore.cs, LaserCut.cs, LaserAuto.cs, AutoRouter.cs

Punch (13 files)

Punching

PunchCore.cs

Nest (10 files)

Nesting multiple parts on a sheet

Src\Core\Nest\

BCell (34 files)

Bend-cell automation (robot, gripper, suction cups)

image gallery at Doc\Img\BCell\ for vocab

Sim (5 files)

Simulation & collision

Src\Core\Sim\

Drawing (7 files)

2D drawing / sketch mode

—

Layout (14 files)

Machine / setup layouts

—

Trim

Trim / edge processing

—

Part

Part model (links domains)

Part.cs (the canonical "job")

IO

File import/export per format

DXFReader.cs, GeoReader.cs, HXReader.cs (the HOOPS reader, despite the misleading name), …

Model

Shared 2D / 3D model classes (E2, E3)

E3Plane.cs, E3Flex.cs, Entity3.cs

Settings

Settings / configuration

Sheaf.cs (cascaded settings dictionary)

Report

Setup sheets, PDF reports

—

OEM

OEM-specific customizations

—

Reading heuristic. A class name like BendOp is the operation, BendCalc is the pure calculation, BendVM is the view aspect (rendering), BendTech is the high-level facade ("generate NC code"). BendCore typically holds central, shared types for the domain.

5. Architecture pattern: Model → View → Glob

Flux follows an opinionated but consistent MVC variant. The terms appear everywhere — internalize them early:

Layer What Where in code Example classes

Layer	What	Where in code	Example classes
Model	Pure domain data	`Flux.Core\<domain>\`	`E3Plane`, `E2Spline`, `LaserCut`, `BendOp`
VModel (view)	Knows how to render the model (OpenGL via Lux)	`Flux.Core\<domain>\` (same folder!)	`E3PlaneVM`, `E2SplineVM`, `LaserCutVM`, `BendMountVM`
Glob (controller)	UI shell exposing properties + commands	`Flux.UI\<domain>\`	`BendOpGlob`, `BendOpsGlob`
GElement	Abstract UI description of glob properties	`Flux.UI\`	—
PanelMaker	Translates `GElement` → real WPF controls	`Flux.UI\`	—

Model

Pure domain data

Flux.Core\<domain>\

E3Plane, E2Spline, LaserCut, BendOp

VModel (view)

Knows how to render the model (OpenGL via Lux)

Flux.Core\<domain>\ (same folder!)

E3PlaneVM, E2SplineVM, LaserCutVM, BendMountVM

Glob (controller)

UI shell exposing properties + commands

Flux.UI\<domain>\

BendOpGlob, BendOpsGlob

GElement

Abstract UI description of glob properties

Flux.UI\

—

PanelMaker

Translates GElement → real WPF controls

Flux.UI\

—

Multi-selection. When the user selects multiple objects, the glob system builds a composite glob showing the shared properties and applying commands to all selections. This is the only clean way to implement bulk edits — don’t iterate selections by hand.

Why this matters. When you add a new domain feature, you almost always touch three places: the model, its VM, and a glob. Miss one, and the UI hook is broken.

Rendering layer. The OpenGL drawing primitives live in Src\Base\Lux\. VModel.Draw() is the common entry; rendering goes through Lux.DrawMesh, Lux.Layer, LuxShading, etc. Each VModel registers a chain of scene-graph nodes (SGNode) and gets a process-wide unique Id once it is "live" on a screen.

6. Data and language building blocks

Term Meaning Defined / documented in

Term	Meaning	Defined / documented in
Curl	Text format for serializing config / data	`Notes\Tech\2007.CurlFiles.ftx` (very thorough)
Au / Gold	Binary format (compact)	`Notes\Dev\1003.AuGoldEncoding.ftx`
VDwg	Format for rendering geometric images	`Notes\Dev\1013.TheVdwgFileFormat.ftx`
NC post writers	One C# class per NC dialect (TrumpfDLD, Bystronic, LVD, …)	`Src\API\Bend\Post\` — dispatched via `Hub.GenerateNC` (see `Src\API\Basis\Basis.cs:138`)
Hex	Originally planned post-processor language (Note 2004, 2016). Postprocessors have since been rewritten in C#. Hex may survive only as a legacy / scripting artifact.	`Src\Base\HexLib.cs`; historical context in `Notes\Tech\2004.TheHexLanguage.ftx`
PDL	Legacy post-processor language. Effectively deprecated.	historical
CMD files	Batch processing	`Notes\Tech\2005.FluxCommandFiles.ftx`
FX file	Native Flux file (with thumbnail)	mentioned in `1002.BuildingFlux.ftx` line 56
Wad	ZIP of read-only resources (shaders, metadata)	`Notes\Dev\1002.BuildingFlux.ftx` lines 223—238
Mech	3D machine model (animatable)	`X:\Data\Machine\<id>\Machine.mech`
TDATA	Test data root	`X:\TData`
Sheaf	Cascaded settings dictionary (parent-child fallback)	`Src\Core\Settings\Sheaf.cs`
Hub	Static glue-point wiring components across layers	`Src\Core\Hub.cs`

Curl

Text format for serializing config / data

Notes\Tech\2007.CurlFiles.ftx (very thorough)

Au / Gold

Binary format (compact)

Notes\Dev\1003.AuGoldEncoding.ftx

VDwg

Format for rendering geometric images

Notes\Dev\1013.TheVdwgFileFormat.ftx

NC post writers

One C# class per NC dialect (TrumpfDLD, Bystronic, LVD, …)

Src\API\Bend\Post\ — dispatched via Hub.GenerateNC (see Src\API\Basis\Basis.cs:138)

Hex

Originally planned post-processor language (Note 2004, 2016). Postprocessors have since been rewritten in C#. Hex may survive only as a legacy / scripting artifact.

Src\Base\HexLib.cs; historical context in Notes\Tech\2004.TheHexLanguage.ftx

PDL

Legacy post-processor language. Effectively deprecated.

historical

CMD files

Batch processing

Notes\Tech\2005.FluxCommandFiles.ftx

FX file

Native Flux file (with thumbnail)

mentioned in 1002.BuildingFlux.ftx line 56

Wad

ZIP of read-only resources (shaders, metadata)

Notes\Dev\1002.BuildingFlux.ftx lines 223—238

Mech

3D machine model (animatable)

X:\Data\Machine\<id>\Machine.mech

TDATA

Test data root

X:\TData

Sheaf

Cascaded settings dictionary (parent-child fallback)

Src\Core\Settings\Sheaf.cs

Hub

Static glue-point wiring components across layers

Src\Core\Hub.cs

7. Flavors — one binary, many products

Flux ships under different brands. The binaries are identical; a Flux.flavor file next to Flux.exe decides at runtime which flavor is active:

Flavor Branding Licensing Where

Flavor	Branding	Licensing	Where
`Dev`	developer build	whitelist (developer PCs)	your local machine
`Flux`	MetaCAM	Aegis (online soft-locking)	US-Metamation, FA-Services
`Trumpf`	TecZoneBend	Trumpf WIBU	Trumpf standalone
`Boost`	TecZoneBend (Boost)	Trumpf WIBU	inside Boost
`Engine`	(no UI)	—	embedded in Praxis
`B23`	TecZoneBend (B23)	B23-APC identification	on TruBend HMI
`Fold`	TecZoneFold	Trumpf Sentinel	on TruBendCenter HMI
`Tech`	Flux-Tech demo	time-limited	partners (USMM/FAS)

Dev

developer build

whitelist (developer PCs)

your local machine

Flux

MetaCAM

Aegis (online soft-locking)

US-Metamation, FA-Services

Trumpf

TecZoneBend

Trumpf WIBU

Trumpf standalone

Boost

TecZoneBend (Boost)

Trumpf WIBU

inside Boost

Engine

(no UI)

—

embedded in Praxis

B23

TecZoneBend (B23)

B23-APC identification

on TruBend HMI

Fold

TecZoneFold

Trumpf Sentinel

on TruBendCenter HMI

Tech

Flux-Tech demo

time-limited

partners (USMM/FAS)

Which features are active in which flavor is a feature-bit table in Notes\Tech\2013.FluxFlavors.ftx lines 38—57. If a bug reproduces only in one flavor, it’s almost always a feature bit.

8. Build & run — what you actually need to know (current)

⚠️ Important caveat about the tech notes. Notes\Dev\1002.BuildingFlux.ftx is the official build doc, but several sections are outdated. For build / toolchain, trust the current .csproj files and the onboarding-buddy conversation, not 1002 verbatim.

What 1002 says (2017) vs. what holds today:

1002 says today

1002 says	today
.NET 4.6.1, C# 6	.NET 10, file-scoped namespaces, `#nullable enable` (see `Src\Core\Flux.Core.csproj`)
Mercurial / Kiln (`metamation.kilnhg.com`)	Git (branch `main`, GitHub-style PR numbers in `git log`)
Visual Studio 2015	recent Visual Studio (Solution format version 16, platform `x64`)
Any-CPU build with 32/64-bit Hula trick	x64-only (see `<PlatformTarget>x64</PlatformTarget>` in every csproj)
`FluxPreSetup.2017.A.exe`	newer pre-setup variant (ask internally)

.NET 4.6.1, C# 6

.NET 10, file-scoped namespaces, #nullable enable (see Src\Core\Flux.Core.csproj)

Mercurial / Kiln (metamation.kilnhg.com)

Git (branch main, GitHub-style PR numbers in git log)

Visual Studio 2015

recent Visual Studio (Solution format version 16, platform x64)

Any-CPU build with 32/64-bit Hula trick

x64-only (see <PlatformTarget>x64</PlatformTarget> in every csproj)

FluxPreSetup.2017.A.exe

newer pre-setup variant (ask internally)

What still holds:

Three subst drives are standard: X: (code/data), W: and N: (Trek). Paths in scripts often hard-code X:\….
Environment variables: FLUXDATA=X:\Data, FLUXTESTDATA=X:\TDATA, FLUXDEVELOPER=1, FLUXWAD=X:\Wad, TREKPATH=N:\Bin (for post-processors / code-finishers from the Trek stack).
A separate solution (Hula64.sln in Src\Hula\) for the HOOPS wrapper — don’t build it, copy the binary from Resources\Hoops\.

Concrete first build attempt:

X: set up as a subst (subst X: C:\Work\Flux or similar)?
Environment variables set?
HOOPS DLLs copied to Src\bin\hoops\?
Open Src\Flux.sln, build *Release

x64*.
Run Flux.exe from Src\bin\ (should detect Dev flavor because no Flux.flavor file is present).

If something breaks: ask buddy first, then read 1002, then search internal issues — in that order.

9. Code conventions (what you’ll see while reading)

From Notes\Dev\1001.FluxDevStyleGuide.ftx and observation of current code:

3 spaces for indentation (no tabs). Yes, three. "Goldilocks number."

K&R style with brace omission for single statements:

if (nLevel > 0 && !mLevelStack.IsEmpty)
   PopLevel ();

Spaces before ( and {, no space before [, no space inside ().
File header in every .cs file (the stylized ASCII hammer at the right margin is the internal logo — please keep it when adding new files).
Modern C# 10+ in new files: namespace Flux; (file-scoped), #nullable enable.
Class / file headers span the full width (column 100); region headers per top-level class.

Real example (Test\Bend\BasicBendAuto.cs):

namespace Flit;
#nullable enable

[TestFixture (4, "Basic bend auto-tooler tests", Module = "Bend", Subsystem = "AutoTool")]
class BasicBendAuto {
   [Test (82, "Tooling basic part: Bend_04.geo")]
   void Test1 () => Test ("Bend/Auto/Bend_04.geo");
   ...
}

10. Tests — what they look like

Framework: Flit (custom-built, not NUnit/xUnit). Attributes: [TestFixture(id, description, Module=..., Subsystem=...)] and [Test(id, description)].
Inputs: .geo files under X:\TData\<domain>\….
Organization: one directory per domain under Test\ (e.g. Test\Bend\, Test\Laser\). Inside that, often per-year regression bundles: Bend2017.cs, Bend2018.cs, …, Bend2025.cs. Each year-file is a layer of historically collected bugs.
Reading tip: to find a recent feature in Bend, look at Test\Bend\Bend<currentYear>.cs first — that’s where regression tests for PR-described issues land.

A 15-minute reading tour is described in detail in chapter 06.

11. Recommended reading order — the first five days

Day Read Goal

Day	Read	Goal
1	This document + `Notes\DevIndex.ftx` + `Notes\Dev\1002.BuildingFlux.ftx` (with §8 caveats)	Build a mental model
2	`Src\Flux.sln` + all 8 `.csproj`, trace dependencies. Then `Notes\Tech\2013.FluxFlavors.ftx`	Modules + delivery model
3	Pick a domain (recommended: Bend — best-documented with images at `Doc\Img\Bend\`). Read chapter 02.	Understand one domain in depth
4	Walk through `Test\Bend\BasicBendAuto.cs`, open a `.geo` file in `TData\Bend\Auto\`, step through a test in read-only debug mode	See how tests drive the code
5	`Notes\Dev\1005.BendAreaModeling.ftx` + `Notes\Tech\2007.CurlFiles.ftx`	Domain depth + data model

This document + Notes\DevIndex.ftx + Notes\Dev\1002.BuildingFlux.ftx (with §8 caveats)

Build a mental model

Src\Flux.sln + all 8 .csproj, trace dependencies. Then Notes\Tech\2013.FluxFlavors.ftx

Modules + delivery model

Pick a domain (recommended: Bend — best-documented with images at Doc\Img\Bend\). Read chapter 02.

Understand one domain in depth

Walk through Test\Bend\BasicBendAuto.cs, open a .geo file in TData\Bend\Auto\, step through a test in read-only debug mode

See how tests drive the code

Notes\Dev\1005.BendAreaModeling.ftx + Notes\Tech\2007.CurlFiles.ftx

Domain depth + data model

12. First reading exercise (~30 min)

Task: in at most half a page, explain what happens when the user edits a Bend setup through the UI.

Approach (read-only, no code change):

Grep for class BendSetup — where does the class live?
Find the matching glob in the UI layer.
Trace one BendSetup property edit: what methods get called?
Where is the change persisted? (Hint: Curl, Au, FX.)
Is undo registered? Where?

Rubric (for your mentor):

Level	Criterion
1	Finds `BendSetup`, knows roughly which domain it lives in
2	Also finds the UI controller, can sketch UI → model data flow
3	Plus: locates persistence and undo, can explain VModel’s role
4	Spots an edge case (e.g. multi-selection: how does the composite glob behave?) and backs the answer up with code/tests

More exercises in chapter 09.

13. What this chapter is not

Not a complete architecture reference (that’s chapter 01).
Not a build step-by-step (Notes/1002 owns that — even though ~30 % of it needs a refresh).
Not a domain deep-dive (chapter 02 covers Bend; companion chapters can be added per domain).
Not a fitness assessment (chapter 09 covers exercises and rubrics).

14. If you take just one thing from this chapter

Flux is intentionally not pure MVC. Models, views (VModel), and controllers (Glob) live in different assemblies, but model + view sit together in Flux.Core. If that surprises you, read Notes\Dev\1002.BuildingFlux.ftx lines 31—61 — it was a deliberate decision against the previous architecture.

The rest you can look up.

Last updated: 2026-05-04 — when this document disagrees with the repo, the repo wins. Chapter 00 is refreshed roughly quarterly. Report drift via PR or the onboarding maintainer.