@thatopen/services 0.7.0 → 0.9.0

package/src/built-in/UIManager/src/topics-panel/example.ts

@@ -1,170 +1,170 @@
-/* MD
-  ## topics-panel
-  ---
-  Every coordination workflow needs a place to track issues, clashes, and
-  action items against a 3D model — who's responsible, what still needs
-  review, and where in the model it actually is. Building that from scratch
-  means a BCF-compatible data model, a form, comment threads, viewpoint
-  capture/navigation, document links, and a persistence layer — all before a
-  single issue gets tracked.
-
-  `topics-panel` is a ready-made web component that delivers exactly that. It
-  connects to `@thatopen/components`' `BCFTopics` (and `Viewpoints`)
-  automatically and manages the entire workflow: the topic list with search,
-  full CRUD on topics/comments/viewpoints/documents, camera navigation,
-  BCF export/import, and auto-save — without you writing any UI code.
-
-  This tutorial covers the prerequisites before mounting the panel; dropping
-  it into a `top-app` layout alongside a 3D viewer; and a breakdown of
-  everything the panel handles automatically so you know what you do not need
-  to implement yourself.
-
-  By the end, you'll have a fully working topics/issues environment running
-  in your application with a single line of markup.
-*/
-
-import { html } from "lit";
-import * as THREE from "three";
-import * as OBC from "@thatopen/components";
-import * as OBF from "@thatopen/components-front";
-import * as FRAGS from "@thatopen/fragments";
-import * as BUI from "@thatopen/ui";
-import { PlatformClient, UIManager, TopicsManager } from "@thatopen/services";
-import type { App } from "../app/index";
-
-
-/* MD
-  ### ✅ Prerequisites
-
-  Two conditions must be met before the panel mounts:
-
-  1. **`UIManager` must be in the setup call.** It registers all platform web
-     components, including `<top-topics-panel>` itself. Without it the
-     element is unknown to the browser and renders as an empty box.
-
-  2. **`TopicsManager.init(client)` must have resolved.** It configures
-     `BCFTopics` (version, author, assignable users — all from real project
-     data) and loads whatever BCF was previously saved for this project. The
-     panel mounts into an empty state and never catches up on its own if you
-     load a BCF after the fact; it only subscribes to change events, it does
-     not poll.
-
-  Both conditions are naturally satisfied when you call `init` before
-  appending `top-app` to the document, which is the pattern shown below.
-*/
-
-const client = PlatformClient.fromPlatformContext();
-
-// The `{ uuid }` entries tell the platform which built-ins to register for
-// this app — one per built-in beyond the "stable" `@thatopen/components`
-// globals passed as the first argument.
-const { components } = (await client.setup(
-  { OBC, OBF, BUI, THREE, FRAGS },
-  { uuid: UIManager.uuid },
-  { uuid: TopicsManager.uuid },
-)) as { components: OBC.Components };
-
-components.get(UIManager).init();
-
-// init must resolve before top-app (and therefore topics-panel) mounts.
-await components.get(TopicsManager).init(client);
-
-/* MD
-  ### 🖥️ Wiring the panel
-
-  Add `topics-panel` as a named area in `app.elements` and reference it in
-  your layout template, next to the 3D viewer — the panel controls the
-  camera and element selection directly in the scene when you click a
-  viewpoint.
-*/
-
-const app = document.createElement("top-app") as unknown as App;
-
-app.setup = (waitUntil) => {
-  waitUntil(
-    (async () => {
-      const fragments = components.get(OBC.FragmentsManager);
-      const workerUrl = await FRAGS.FragmentsModels.getWorker();
-      fragments.init(await FRAGS.toClassicWorker(workerUrl), { classicWorker: true });
-    })(),
-    "Fragments Core",
-  );
-  return { components, client };
-};
-
-app.elements = {
-  viewer: () => html`<top-viewer><top-viewer-tools></top-viewer-tools></top-viewer>`,
-  topics: () => html`<top-topics-panel></top-topics-panel>`,
-};
-
-app.layouts = {
-  main: {
-    label: "Main",
-    icon: "solar:3d-square-bold",
-    template: `"viewer topics" 1fr / 1fr 30rem`,
-  },
-};
-
-app.layout = "main";
-
-const container = document.getElementById("that-open-app") ?? document.body;
-container.appendChild(app);
-document.body.style.margin = "0";
-
-/* MD
-  ### 🤖 What's handled automatically
-
-  **`TopicsManager`** resolves `Viewpoints.world` in the background once
-  `top-viewer` creates it (which only happens after `top-app` finishes
-  mounting), including backfilling it onto viewpoints that were restored
-  from the saved BCF before the world existed — `Viewpoint.go()` would
-  otherwise silently no-op for every one of them. Nothing to wire yourself.
-
-  **`topics-panel`**, once mounted, takes ownership of the following without
-  any further code from you:
-
-  **Full topic CRUD** — create, edit, and delete (behind a confirmation
-  modal) topics with title, type, status, priority, assigned-to, due date,
-  and stage. The list shows a search bar, a type badge next to each title,
-  and switches to an empty state with a "New topic" call-to-action when
-  there's nothing yet.
-
-  **Comments** — add, edit, and delete (with confirmation) threaded comments
-  on a topic, each optionally linked to a specific viewpoint via a clickable
-  tag that jumps the camera there.
-
-  **Viewpoints** — capture the current camera + selection as a new
-  viewpoint, browse them in a snapshot carousel, and click one to fly the
-  camera and re-apply its selection highlight. Navigation is a no-op (not an
-  error) if no models are loaded yet, so a stray click can't fly the camera
-  toward nothing.
-
-  **Documents** — link files from the project's CDE storage (searchable tree
-  picker), unlink from just this topic or hard-delete everywhere it's
-  referenced, and download. Linking is genuinely shared: the same file
-  referenced by two topics reuses one document entry instead of duplicating
-  it.
-
-  **BCF export/import** — export the selected topics (or, with nothing
-  selected, the whole project) to a single `.bcf` file named after the
-  project or the lone topic's title. Import merges a `.bcf` into the current
-  project instead of replacing it; a topic sharing a GUID with an existing
-  one is overwritten (treated as an update from elsewhere, not a conflict).
-
-  **Persistence** — every mutation is auto-saved through `top-app`'s
-  `projectStorageContext`, debounced per file so rapid edits collapse into
-  one upload. A small "Saving..." indicator (shared with any other built-in
-  using the same context, e.g. `clashes-panel`) reflects the real
-  debounce-then-upload cycle: just the icon while pending, the full pill
-  while actually uploading.
-
-  **Author/assignee names** — emails resolve to real names (with an
-  initials avatar) via `top-app`'s `projectDataContext`, which already
-  covers the project owner as well as regular collaborators — no separate
-  lookup needed.
-
-  **Cross-panel awareness** — the list updates live even when a topic is
-  created somewhere else entirely (e.g. `clashes-panel`'s "Create topic from
-  clash"), including the empty-state → list transition if this was the
-  project's first topic.
-*/
+/* MD
+  ## topics-panel
+  ---
+  Every coordination workflow needs a place to track issues, clashes, and
+  action items against a 3D model — who's responsible, what still needs
+  review, and where in the model it actually is. Building that from scratch
+  means a BCF-compatible data model, a form, comment threads, viewpoint
+  capture/navigation, document links, and a persistence layer — all before a
+  single issue gets tracked.
+
+  `topics-panel` is a ready-made web component that delivers exactly that. It
+  connects to `@thatopen/components`' `BCFTopics` (and `Viewpoints`)
+  automatically and manages the entire workflow: the topic list with search,
+  full CRUD on topics/comments/viewpoints/documents, camera navigation,
+  BCF export/import, and auto-save — without you writing any UI code.
+
+  This tutorial covers the prerequisites before mounting the panel; dropping
+  it into a `top-app` layout alongside a 3D viewer; and a breakdown of
+  everything the panel handles automatically so you know what you do not need
+  to implement yourself.
+
+  By the end, you'll have a fully working topics/issues environment running
+  in your application with a single line of markup.
+*/
+
+import { html } from "lit";
+import * as THREE from "three";
+import * as OBC from "@thatopen/components";
+import * as OBF from "@thatopen/components-front";
+import * as FRAGS from "@thatopen/fragments";
+import * as BUI from "@thatopen/ui";
+import { PlatformClient, UIManager, TopicsManager } from "@thatopen/services";
+import type { App } from "../app/index";
+
+
+/* MD
+  ### ✅ Prerequisites
+
+  Two conditions must be met before the panel mounts:
+
+  1. **`UIManager` must be in the setup call.** It registers all platform web
+     components, including `<top-topics-panel>` itself. Without it the
+     element is unknown to the browser and renders as an empty box.
+
+  2. **`TopicsManager.init(client)` must have resolved.** It configures
+     `BCFTopics` (version, author, assignable users — all from real project
+     data) and loads whatever BCF was previously saved for this project. The
+     panel mounts into an empty state and never catches up on its own if you
+     load a BCF after the fact; it only subscribes to change events, it does
+     not poll.
+
+  Both conditions are naturally satisfied when you call `init` before
+  appending `top-app` to the document, which is the pattern shown below.
+*/
+
+const client = PlatformClient.fromPlatformContext();
+
+// The `{ uuid }` entries tell the platform which built-ins to register for
+// this app — one per built-in beyond the "stable" `@thatopen/components`
+// globals passed as the first argument.
+const { components } = (await client.setup(
+  { OBC, OBF, BUI, THREE, FRAGS },
+  { uuid: UIManager.uuid },
+  { uuid: TopicsManager.uuid },
+)) as { components: OBC.Components };
+
+components.get(UIManager).init();
+
+// init must resolve before top-app (and therefore topics-panel) mounts.
+await components.get(TopicsManager).init(client);
+
+/* MD
+  ### 🖥️ Wiring the panel
+
+  Add `topics-panel` as a named area in `app.elements` and reference it in
+  your layout template, next to the 3D viewer — the panel controls the
+  camera and element selection directly in the scene when you click a
+  viewpoint.
+*/
+
+const app = document.createElement("top-app") as unknown as App;
+
+app.setup = (waitUntil) => {
+  waitUntil(
+    (async () => {
+      const fragments = components.get(OBC.FragmentsManager);
+      const workerUrl = await FRAGS.FragmentsModels.getWorker();
+      fragments.init(await FRAGS.toClassicWorker(workerUrl), { classicWorker: true });
+    })(),
+    "Fragments Core",
+  );
+  return { components, client };
+};
+
+app.elements = {
+  viewer: () => html`<top-viewer><top-viewer-tools></top-viewer-tools></top-viewer>`,
+  topics: () => html`<top-topics-panel></top-topics-panel>`,
+};
+
+app.layouts = {
+  main: {
+    label: "Main",
+    icon: "solar:3d-square-bold",
+    template: `"viewer topics" 1fr / 1fr 30rem`,
+  },
+};
+
+app.layout = "main";
+
+const container = document.getElementById("that-open-app") ?? document.body;
+container.appendChild(app);
+document.body.style.margin = "0";
+
+/* MD
+  ### 🤖 What's handled automatically
+
+  **`TopicsManager`** resolves `Viewpoints.world` in the background once
+  `top-viewer` creates it (which only happens after `top-app` finishes
+  mounting), including backfilling it onto viewpoints that were restored
+  from the saved BCF before the world existed — `Viewpoint.go()` would
+  otherwise silently no-op for every one of them. Nothing to wire yourself.
+
+  **`topics-panel`**, once mounted, takes ownership of the following without
+  any further code from you:
+
+  **Full topic CRUD** — create, edit, and delete (behind a confirmation
+  modal) topics with title, type, status, priority, assigned-to, due date,
+  and stage. The list shows a search bar, a type badge next to each title,
+  and switches to an empty state with a "New topic" call-to-action when
+  there's nothing yet.
+
+  **Comments** — add, edit, and delete (with confirmation) threaded comments
+  on a topic, each optionally linked to a specific viewpoint via a clickable
+  tag that jumps the camera there.
+
+  **Viewpoints** — capture the current camera + selection as a new
+  viewpoint, browse them in a snapshot carousel, and click one to fly the
+  camera and re-apply its selection highlight. Navigation is a no-op (not an
+  error) if no models are loaded yet, so a stray click can't fly the camera
+  toward nothing.
+
+  **Documents** — link files from the project's CDE storage (searchable tree
+  picker), unlink from just this topic or hard-delete everywhere it's
+  referenced, and download. Linking is genuinely shared: the same file
+  referenced by two topics reuses one document entry instead of duplicating
+  it.
+
+  **BCF export/import** — export the selected topics (or, with nothing
+  selected, the whole project) to a single `.bcf` file named after the
+  project or the lone topic's title. Import merges a `.bcf` into the current
+  project instead of replacing it; a topic sharing a GUID with an existing
+  one is overwritten (treated as an update from elsewhere, not a conflict).
+
+  **Persistence** — every mutation is auto-saved through `top-app`'s
+  `projectStorageContext`, debounced per file so rapid edits collapse into
+  one upload. A small "Saving..." indicator (shared with any other built-in
+  using the same context, e.g. `clashes-panel`) reflects the real
+  debounce-then-upload cycle: just the icon while pending, the full pill
+  while actually uploading.
+
+  **Author/assignee names** — emails resolve to real names (with an
+  initials avatar) via `top-app`'s `projectDataContext`, which already
+  covers the project owner as well as regular collaborators — no separate
+  lookup needed.
+
+  **Cross-panel awareness** — the list updates live even when a topic is
+  created somewhere else entirely (e.g. `clashes-panel`'s "Create topic from
+  clash"), including the empty-state → list transition if this was the
+  project's first topic.
+*/

package/src/built-in/index.ts

@@ -1142,7 +1142,7 @@ export type ContextMode = "default" | "hidden";
 /** The three kinds of change a commit can carry. */
 export type ChangeKind = "create" | "update" | "delete";
 /**
- * Stable id for a commit across models — which is now just its guid.
+ * Stable id for a commit across models — which is now just its guid.
  *
  * It used to have to be `${model}:${id}`, because the id was a per-model version number and every
  * model had a commit 3. A guid needs no help being unique, and that is exactly what it was for.
@@ -1155,25 +1155,25 @@ export declare const commitKey: (c: {
 }) => string;
 /** How the commit is shown in 3D: review colours, or the model as it ended up. */
 export type HighlightMode = "colored" | "plain";
-/** Dominant change type of a commit: delete → create → update. */
+/** Dominant change type of a commit: delete → create → update. */
 export declare function dominantChange(commit: RevitFlowCommit): DominantChange;
 /**
- * GitHistoryManager — headless engine for the revit-flow git-history built-in.
+ * GitHistoryManager — headless engine for the revit-flow git-history built-in.
  *
- * Owns ALL viewer mutation for the change outlines. It does NOT load the model —
+ * Owns ALL viewer mutation for the change outlines. It does NOT load the model —
  * the user opens a model from the Project Files panel, and this manager reacts to
  * that load: it reads the model's hidden `revitflow_history.json` (if any) and
  * publishes the commit list. Showing a commit outlines its changed elements
- * (create → green, update → blue, delete → red) via three independently-colored
- * `OBF.Outliner` groups — a cheap post-process outline that never recolors the
+ * (create → green, update → blue, delete → red) via three independently-colored
+ * `OBF.Outliner` groups — a cheap post-process outline that never recolors the
  * fragment geometry. The Lit panel (`top-git-history`) is intent-only: it calls
  * these methods and subscribes to the events below.
  *
  * Data model, per loaded model (fileId == modelId), all HIDDEN children of it:
- *   - revitflow_history.json — { model, commits: [{ id, parent, author, source,
+ *   - revitflow_history.json — { model, commits: [{ id, parent, author, source,
  *       timestamp, changes:[{type,uniqueId}], counts }] }. The first commit is the
  *       INITIAL full-model capture (its geometry == the visible baseline file).
- *   - revitflow_frag_<N>.frag — delta fragments for commit N (its created+modified
+ *   - revitflow_frag_<N>.frag — delta fragments for commit N (its created+modified
  *       geometry), loaded on demand so created elements can be colored.
  */
 declare class _GitHistoryManager extends OBC.Component {
@@ -1186,15 +1186,40 @@ declare class _GitHistoryManager extends OBC.Component {
     readonly onError: OBC.Event<string>;
     /** The GUID currently selected in the 3D view (null when the selection is cleared). */
     readonly onSelectedGuidChanged: OBC.Event<string | null>;
+    /** A source icon was added or replaced. */
+    readonly onSourceIconsChanged: OBC.Event<void>;
+    /**
+     * Which mark to draw on a commit, by the application that wrote it.
+     *
+     * Every commit already says who made it, in `source`. The panel used to draw the Revit logo on
+     * all of them regardless, which was true while Revit was the only thing that could write one and
+     * became a lie the moment anything else did: a commit from another tool would claim to be a
+     * Revit commit, on the one part of the row whose whole job is to say where a change came from.
+     *
+     * The format is deliberately open about who writes history, so the icons have to be too. This is
+     * the registry. Only `revit` is built in; an application adds its own:
+     *
+     *   const history = components.get(GitHistoryManager);
+     *   history.setSourceIcon("rhino", "https://…/rhino.svg");   // a URL, or a data: URI
+     *   history.setSourceIcon("tekla", "<svg viewBox='0 0 24 24'>…</svg>");   // or the markup
+     *
+     * A source with no icon gets a neutral one rather than somebody else's.
+     */
+    readonly sourceIcons: Map<string, string>;
+    /**
+     * @param source the commit's own `source` value, matched case-insensitively.
+     * @param icon a URL, a `data:` URI, or inline `<svg>` markup.
+     */
+    setSourceIcon(source: string, icon: string): void;
     world?: OBC.World;
     /**
      * What happens to elements that are NOT part of the selected commit:
-     *   "default" — left as they are (the change outlines sit on the full model)
-     *   "hidden"  — hidden entirely, isolating the commit's elements
+     *   "default" — left as they are (the change outlines sit on the full model)
+     *   "hidden"  — hidden entirely, isolating the commit's elements
      *
      * A dimmed ("ghost") middle ground was dropped: the fragments x-ray writes depth
      * from the pixels its screen door keeps, so dimmed geometry still occluded the very
-     * elements under review — worse the denser the model in front. Fixing that properly
+     * elements under review — worse the denser the model in front. Fixing that properly
      * belongs in the renderer, not here, so this offers the two states that are exact.
      */
     contextMode: ContextMode;
@@ -1212,18 +1237,18 @@ declare class _GitHistoryManager extends OBC.Component {
     prefetchRadius: number;
     /**
      * How a commit is presented in 3D:
-     *   "colored" — outline created/edited/deleted in their colours (the review lens)
-     *   "plain"   — no outlines: the model simply as it stood AFTER the commit, so the
+     *   "colored" — outline created/edited/deleted in their colours (the review lens)
+     *   "plain"   — no outlines: the model simply as it stood AFTER the commit, so the
      *               deleted elements are hidden rather than painted red
      */
     highlightMode: HighlightMode;
-    /** @deprecated kept so older callers still compile — maps onto contextMode. */
+    /** @deprecated kept so older callers still compile — maps onto contextMode. */
     get isolateChanges(): boolean;
-    /** Green — created elements. */
+    /** Green — created elements. */
     readonly COLOR_CREATED = "#22c55e";
-    /** Golden yellow — modified elements. */
+    /** Golden yellow — modified elements. */
     readonly COLOR_MODIFIED = "#e3b341";
-    /** Red — deleted elements. */
+    /** Red — deleted elements. */
     readonly COLOR_DELETED = "#ef4444";
     readonly GROUP_CREATED = "revitflow-created";
     readonly GROUP_MODIFIED = "revitflow-modified";
@@ -1232,7 +1257,7 @@ declare class _GitHistoryManager extends OBC.Component {
     private _projectId?;
     /**
      * One entry per loaded revit-flow model. Commit ids are per-model version numbers, so
-     * they collide across models — every commit is tagged with its modelId and a commit is
+     * they collide across models — every commit is tagged with its modelId and a commit is
      * addressed by {@link commitKey}, never by id alone.
      */
     private _models;
@@ -1304,7 +1329,7 @@ declare class _GitHistoryManager extends OBC.Component {
     init(client: PlatformClient): Promise<void>;
     /**
      * Follow the viewer's selection so the element view tracks whatever the user clicks in
-     * 3D — no "trace this" button to press. The Highlighter's events appear asynchronously
+     * 3D — no "trace this" button to press. The Highlighter's events appear asynchronously
      * (they're registered when the viewer sets it up), so retry briefly until they exist.
      */
     private _watchSelection;
@@ -1313,7 +1338,7 @@ declare class _GitHistoryManager extends OBC.Component {
     /**
      * Probe a loaded model for a sibling visible `revitflow_history.json` in its
      * folder. If present, adopt it as the active model and publish its commits.
-     * Silent for non-revit models and for our own delta frags — only genuine
+     * Silent for non-revit models and for our own delta frags — only genuine
      * fetch/parse failures raise onError.
      */
     private _probeModel;
@@ -1348,7 +1373,7 @@ declare class _GitHistoryManager extends OBC.Component {
      * Show the model as it stood AT `commit`: the visible baseline is the model at its
      * INITIAL commit, and everything created later lives in per-commit delta .frags loaded
      * as separate models. Those deltas stay loaded (the prefetch window keeps neighbours
-     * warm), so stepping BACK has to hide the ones from later commits — otherwise a wall
+     * warm), so stepping BACK has to hide the ones from later commits — otherwise a wall
      * added in commit 3 was still sitting there while you were looking at commit 2.
      * Only touches deltas of the commit's own model; other models keep their own state.
      */
@@ -1388,7 +1413,7 @@ declare class _GitHistoryManager extends OBC.Component {
     selectedGuids(): Promise<string[]>;
     selectedGuid(): Promise<string | null>;
     /**
-     * Select every element the commit touched, in the viewer's own selection — so the
+     * Select every element the commit touched, in the viewer's own selection — so the
      * usual tools (properties, isolate, zoom) work on it like any hand-made selection.
      * Honours the current type filter, so "only deletions" selects only those.
      * @returns how many elements ended up selected.
@@ -1402,11 +1427,11 @@ declare class _GitHistoryManager extends OBC.Component {
     private _outliner;
     /**
      * Create the three independently-colored outline groups once. The viewer
-     * owns the Outliner's DEFAULT group (selection) — we only add our own named
+     * owns the Outliner's DEFAULT group (selection) — we only add our own named
      * groups and never touch "default".
      */
     private _ensureGroups;
-    /** Clear our three outline groups only — leaves the viewer's default group. */
+    /** Clear our three outline groups only — leaves the viewer's default group. */
     private _clearOutlines;
     /**
      * Resolve each change bucket's GUIDs to localIds across every loaded model
@@ -1420,7 +1445,7 @@ declare class _GitHistoryManager extends OBC.Component {
     private _dropSuperseded;
     /**
      * Hide (or restore) the elements a commit deleted. Tracked separately from the context
-     * modes so switching Colored↔Plain doesn't disturb ghosting or the rest of the model.
+     * modes so switching Colored↔Plain doesn't disturb ghosting or the rest of the model.
      */
     private _applyDeletedVisibility;
     /**
@@ -1429,14 +1454,14 @@ declare class _GitHistoryManager extends OBC.Component {
      * THE BUG THIS EXISTS FOR. The baseline .frag holds the whole model as of the first
      * commit, and every later commit ships a delta .frag with the geometry it created AND
      * the geometry it modified. Both stay in the scene. For a CREATED element that is
-     * right — it exists in exactly one place. For a MODIFIED one it is not: the element is
+     * right — it exists in exactly one place. For a MODIFIED one it is not: the element is
      * in the baseline at its old shape and in the delta at its new one, and the viewer drew
      * both. Measured 2026-08-05 on a wall whose height Quim raised: the new wall stood
      * proud of the old one, with the coincident faces z-fighting into a dotted band.
      *
      * The rule is the obvious one once stated: for any element, only the newest VISIBLE
      * source may draw it. Deltas are walked newest-first, each guid is claimed by the first
-     * source that has it, and every older copy — in an older delta or in the baseline — is
+     * source that has it, and every older copy — in an older delta or in the baseline — is
      * hidden. Deltas newer than the commit being shown are already hidden wholesale by
      * `_applyFutureVisibility`, so they never get to claim anything.
      *
@@ -1454,13 +1479,13 @@ declare class _GitHistoryManager extends OBC.Component {
      * load that commit's delta, which is the last place its geometry existed.
      */
     private _ensureDeletedGeometry;
-    /** GUIDs → { modelId: Set<localId> } across the given models. */
+    /** GUIDs → { modelId: Set<localId> } across the given models. */
     private _buildMap;
     private _mergeMaps;
     /**
      * Dim ("ghost") or hide every element that is NOT part of the shown commit, per the
      * chosen context mode. Best-effort per model: a model that doesn't support the call is
-     * simply left alone — the outlines still convey the change.
+     * simply left alone — the outlines still convey the change.
      */
     private _applyContext;
     /** Undo whatever the context mode did: drop the ghost overlay and restore visibility. */
@@ -1479,42 +1504,42 @@ declare class _GitHistoryManager extends OBC.Component {
 }
 
 /**
- * GitHistoryManager — headless engine for the revit-flow git-history built-in.
+ * GitHistoryManager — headless engine for the revit-flow git-history built-in.
  *
- * Owns ALL viewer mutation for the change outlines. It does NOT load the model —
+ * Owns ALL viewer mutation for the change outlines. It does NOT load the model —
  * the user opens a model from the Project Files panel, and this manager reacts to
  * that load: it reads the model's hidden `revitflow_history.json` (if any) and
  * publishes the commit list. Showing a commit outlines its changed elements
- * (create → green, update → blue, delete → red) via three independently-colored
- * `OBF.Outliner` groups — a cheap post-process outline that never recolors the
+ * (create → green, update → blue, delete → red) via three independently-colored
+ * `OBF.Outliner` groups — a cheap post-process outline that never recolors the
  * fragment geometry. The Lit panel (`top-git-history`) is intent-only: it calls
  * these methods and subscribes to the events below.
  *
  * Data model, per loaded model (fileId == modelId), all HIDDEN children of it:
- *   - revitflow_history.json — { model, commits: [{ id, parent, author, source,
+ *   - revitflow_history.json — { model, commits: [{ id, parent, author, source,
  *       timestamp, changes:[{type,uniqueId}], counts }] }. The first commit is the
  *       INITIAL full-model capture (its geometry == the visible baseline file).
- *   - revitflow_frag_<N>.frag — delta fragments for commit N (its created+modified
+ *   - revitflow_frag_<N>.frag — delta fragments for commit N (its created+modified
  *       geometry), loaded on demand so created elements can be colored.
  */
 export type GitHistoryManager = InstanceType<typeof _GitHistoryManager>;
 /**
- * GitHistoryManager — headless engine for the revit-flow git-history built-in.
+ * GitHistoryManager — headless engine for the revit-flow git-history built-in.
  *
- * Owns ALL viewer mutation for the change outlines. It does NOT load the model —
+ * Owns ALL viewer mutation for the change outlines. It does NOT load the model —
  * the user opens a model from the Project Files panel, and this manager reacts to
  * that load: it reads the model's hidden `revitflow_history.json` (if any) and
  * publishes the commit list. Showing a commit outlines its changed elements
- * (create → green, update → blue, delete → red) via three independently-colored
- * `OBF.Outliner` groups — a cheap post-process outline that never recolors the
+ * (create → green, update → blue, delete → red) via three independently-colored
+ * `OBF.Outliner` groups — a cheap post-process outline that never recolors the
  * fragment geometry. The Lit panel (`top-git-history`) is intent-only: it calls
  * these methods and subscribes to the events below.
  *
  * Data model, per loaded model (fileId == modelId), all HIDDEN children of it:
- *   - revitflow_history.json — { model, commits: [{ id, parent, author, source,
+ *   - revitflow_history.json — { model, commits: [{ id, parent, author, source,
  *       timestamp, changes:[{type,uniqueId}], counts }] }. The first commit is the
  *       INITIAL full-model capture (its geometry == the visible baseline file).
- *   - revitflow_frag_<N>.frag — delta fragments for commit N (its created+modified
+ *   - revitflow_frag_<N>.frag — delta fragments for commit N (its created+modified
  *       geometry), loaded on demand so created elements can be colored.
  */
 export const GitHistoryManager = { uuid: '3f9c1a7e-6b2d-4e18-9a5c-7d0e2f4b6c81' } as typeof _GitHistoryManager & { uuid: '3f9c1a7e-6b2d-4e18-9a5c-7d0e2f4b6c81' };