Table of Contents

HiNC App Anatomy

Anatomy is the view ↔ model ↔ source reference for the shipped HiNC applications: one page per component, each naming the widget tree the user sees, the HiAPI types behind it, and the files that implement it. It documents how the shipped apps are put together — it is not a build tutorial, and for that see Getting Started.

The section is grouped by the surface that owns a page: a folder per live route that hosts a Control-Tree branch or several pages, a single page where a route needs only one, and — where the shipped surface owns nothing, as with a reusable control or a cross-screen rule — the source directory the components actually live in.

Important

Anatomy makes no claim that Control-Tree ids are stable across versions, and no page may state one. treeRoutes.ts guarantees something narrower: an old id keeps resolving, because each regroup adds a migration hop. The ids themselves have moved repeatedly.

Finding the Page From the App

What you are looking at Where its anatomy is
The window frame, its menu bar and its message bars App Shell
/execution, and ?tree=execution/… on it Execution Page — its Mission branch is under Mission
/general-setup, and ?tree=equipment/… on it General Setup Page — its Controller branch is under Controller
/machine-tool Machine Tool — the route is a read-only preview of the same branch
/tool-house/:toolId?/:tab?/:subtab?, and ?tree=toolhouse/… Tool House Page
/util/file-explorer, /util/mech-builder Utility Pages
/login, /preference/log Platform — the two routes that document the platform rather than a machining step
A geometry editor embedded in any of the above Geometry Panels
A control that appears on more than one screen Widgets
A rule that holds across screens rather than on one Conventions
Machinery under every screen — the Control-Tree engine, the ?tree= id surface, the locale bundles, the host process Platform
A directory in one of the source trees, rather than a screen By Source Directory

Sections

  • Conventions — The rules and shared contracts every page assumes: messaging, file paths, numeric values, the hub patterns, the canvas transport
  • Platform — The machinery every route sits on and no user can point at: the Control-Tree engine, the id and route surface, session state, the locale bundles, the login gate, the log viewer and the host process
  • App Shell — The frame every route renders inside: the Main Panel, its two message bars, and the Preference menu
  • Widgets — The reusable controls pages embed rather than own, most-embedded first
  • Geometry Panels — The primitive solids, the operators that combine and mesh them, and the switchboards that host both
  • Execution Page — The run cockpit: its tool bars, the step column, the charts, and the Mission branch it hosts
  • General Setup Page — The equipment Control Tree: the machine, the spindle envelope, the scene, the fixture, the workpiece and the controller branch
  • Tool House Page — The tool library and the per-tool editor tabs, cutter and holder
  • Legacy Controller Model (HardNcEnv) — The deprecating HardNc controller model the project still carries beside the runner: what the live pipeline still reads from it, the three settings that retire with it and the Align P0 action the runner path does not offer, what the Controller branch edits a runner-side copy of, and the engine files behind both
  • Utility Pages — The two /util/ routes: the File Explorer and the Mechanism Builder
  • By Source Directory — The same knowledge keyed on the source tree instead of the screen: one directory index per half of the flagship

The Codebase

A page's Source Code Path section lists the files that implement it in the flagship web service, which is the only application codebase Anatomy documents.

HiNC-2025-webservice is the flagship — a Quasar SPA (Vue 3 + TypeScript + Pinia) served by ASP.NET Core, and the only target for new feature work. Repository: HiNC-2025-webservice.git

Tip

The host process, its configuration and the address it listens on are documented in Program and Hosting.

Writing a Page Here

  1. Name the surface it documents in prose — the route, and where the component lives in a Control Tree, its ?tree= id. Make no claim that the id is stable.
  2. Layout — the widget tree as the user meets it, nested as the UI nests.
  3. Key Model — the backing HiAPI types, as <xref:> so the API reference is one click away.
  4. Source Code Path — the implementing files in the web service. Backtick every path, with its extension: tools/check-source-paths.ps1 resolves a full path against the source tree and a bare file name by its base name, and refuses an entry carrying no backticks at all.
  5. ## See Also — mandatory, and audited for reciprocity. An entry is not landed until the target links back. Anatomy is authoritative on component and source facts: when Manual and Anatomy disagree, Anatomy is corrected first and Manual follows.

See Also

  • Anatomy by Source Directory — the inverse index: enter by the directory a change landed in rather than by the screen it shows up on
  • Manual — the same shipped screens as an operating procedure rather than a component breakdown