systemlink-cli 1.13.7__tar.gz → 1.13.9__tar.gz

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: systemlink-cli
-Version: 1.13.7
+Version: 1.13.9
 Summary: SystemLink Integrator CLI - cross-platform CLI for SystemLink workflows and templates.
 License-File: LICENSE
 Author: Fred Visser

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "systemlink-cli"
-version = "1.13.7"
+version = "1.13.9"
 description = "SystemLink Integrator CLI - cross-platform CLI for SystemLink workflows and templates."
 authors = ["Fred Visser <fred.visser@emerson.com>"]
 packages = [{ include = "slcli" }]

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/slcli/_version.py

@@ -1,4 +1,4 @@
 """Version information for slcli."""
 
 # This file is auto-generated. Do not edit manually.
-__version__ = "1.13.7"
+__version__ = "1.13.9"

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/slcli/skills/slcli/SKILL.md

@@ -164,6 +164,52 @@ slcli example install <EXAMPLE_ID> [--workspace NAME]    # Provision example res
 slcli example delete <EXAMPLE_ID> [--workspace NAME]     # Remove provisioned resources
 ```
 
+### routine — Routine management
+
+`slcli routine` spans two different services with different trigger payload shapes.
+Document the API version and trigger schema explicitly when generating commands.
+
+#### v1 notebook routines
+
+Use `--api-version v1` for notebook-execution routines. These map to the
+Routine Manager API and use `--type`, `--notebook-id`, plus either `--trigger`
+or `--schedule`.
+
+Notes for v1 triggers:
+
+- `trigger.filter` is required by the v1 API schema for triggered routines.
+- The only trigger `source` documented by the swagger is `FILES`.
+- The documented `events` values are `CREATED` and `UPDATED`.
+- The simplest documented filter is `extension=".xml"`, but observed live examples also combine `workspace = ...` and `name.Contains(...)` checks.
+- Treat the filter string as service-owned syntax, not LINQ or OData. Do not rewrite it as `--filter` CLI syntax.
+- When working with an existing v1 routine, prefer `slcli routine get --api-version v1 <ID>` because the default API version is v2.
+
+#### v2 event-action routines
+
+Use the default `v2` API for event-action routines. These map to the newer
+Routine Service and use `--event` plus `--actions`.
+
+For v2 routines, there is no top-level `filter` field in the create/update
+request. Filtering is event-type-specific and lives inside
+`event.triggers[].configuration`.
+
+Notes for v2 triggers:
+
+- `event.type` selects the event provider/plugin.
+- `event.triggers[]` contains one or more named conditions.
+- Each trigger's `configuration` object is provider-specific; the v2 swagger does not enumerate a universal set of filter keys.
+- Some v2 providers do use a `configuration.filter` field, but it is part of the provider-specific trigger configuration, not a top-level routine field.
+- Other v2 providers use structured condition fields such as `path`, `type`, `comparator`, `thresholds`, and `deadband` instead of a `filter` string.
+- Do not assume the v1 file-trigger filter string syntax applies to v2 routines.
+- When documenting v2 routines, show the exact JSON shape and note that valid configuration keys depend on the event type.
+- Live survey on the demo environment found these v2 event types in use: `TAG`, `TESTRESULTCHANGED`, and `WORKITEMCHANGED`.
+- Live survey on the demo environment found these v2 action types in use: `ALARM` and `NOTEBOOK`.
+- Observed TAG routines also use comparator-driven configurations such as `IN_RANGE`, `NOT_EQUAL`, and `GREATER_THAN_OR_EQUAL`.
+- Observed `TESTRESULTCHANGED` and `WORKITEMCHANGED` filters use provider-specific expression syntax such as nested field comparisons, `after.properties["key"]`, `DateTime.parse(...)`, `.Any(...)`, and `!Contains(...)`.
+- Common NOTEBOOK action fields in v2 are `notebookId`, `parameters`, `resourceProfile`, `priority`, and `serviceAccount`.
+- ALARM-producing routines need the clear/reset action that uses trigger `nisystemlink_no_triggers_breached`.
+- Load [routine-examples.md](./references/routine-examples.md) for sanitized live examples of compound v1 FILES filters and advanced v2 configurations.
+
 ## Reference docs
 
 Consult these for detailed guidance. Load only what you need for the current task.
@@ -171,6 +217,7 @@ Consult these for detailed guidance. Load only what you need for the current tas
 | Topic                       | File                                                        | When to load                                                  |
 | --------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- |
 | CLI command reference       | [commands.md](./references/commands.md)                     | Looking up command syntax, options, or examples               |
+| Routine examples            | [routine-examples.md](./references/routine-examples.md)     | Provider-specific v1/v2 payload shapes and sanitized live examples |
 | Datasheet-to-specs workflow | [datasheet-workflow.md](./references/datasheet-workflow.md) | Importing specs from PDF, CSV, or structured text             |
 | Filtering guide             | [filtering.md](./references/filtering.md)                   | Advanced LINQ expressions, parameterized queries              |
 | Analysis recipes            | [analysis-recipes.md](./references/analysis-recipes.md)     | Multi-step analysis: yield, calibration, operator performance |

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/slcli/skills/slcli/references/commands.md

@@ -358,6 +358,11 @@ Two API versions are supported:
 - **v2** (default): General event-action routines — monitor tags, work-item changes, and more; trigger alarms, emails, or notebook executions.
 - **v1**: Notebook-execution routines with SCHEDULED or TRIGGERED types.
 
+Observed on the demo environment:
+
+- v2 event types: `TAG`, `TESTRESULTCHANGED`, `WORKITEMCHANGED`
+- v2 action types: `ALARM`, `NOTEBOOK`
+
 ```bash
 # List routines
 slcli routine list [OPTIONS]
@@ -375,6 +380,9 @@ slcli routine list [OPTIONS]
 # Get a single routine by ID
 slcli routine get <ROUTINE_ID> [--api-version v1|v2] [-f json]
 
+# Note: the default API version is v2. Use --api-version v1 when reading or
+# updating notebook routines created through the older Routine Manager service.
+
 # Create a v2 event-action routine
 # --event: JSON object with `type` and `triggers` array
 # --actions: JSON array of action objects
@@ -401,7 +409,10 @@ slcli routine create --api-version v1 \
   --name "On Upload" \
   --type TRIGGERED \
   --notebook-id <NOTEBOOK_ID> \
-  --trigger '{"source":"FILES","events":["CREATED"],"filter":"extension=\".csv\""}'
+  --trigger '{"source":"FILES","events":["CREATED"],"filter":"extension=\".xml\""}'
+
+# For compound FILES filters and provider-specific live examples, load
+# routine-examples.md in this folder.
 
 # Update a routine (only supplied fields are changed)
 slcli routine update <ROUTINE_ID> [--api-version v1|v2] \
@@ -420,6 +431,10 @@ slcli routine delete <ROUTINE_ID> [--api-version v1|v2] [-y]
 
 ### v2 event JSON structure
 
+For v2 routines, there is no top-level routine `filter` field. Filtering is
+provider-specific and belongs inside `event.triggers[].configuration` when the
+provider supports it.
+
 ```json
 {
   "type": "TAG",
@@ -437,9 +452,41 @@ slcli routine delete <ROUTINE_ID> [--api-version v1|v2] [-y]
 }
 ```
 
-Supported TAG comparators: `GREATER_THAN`, `LESS_THAN`, `EQUAL`, `NOT_EQUAL`.
+Observed TAG comparators include `GREATER_THAN`, `GREATER_THAN_OR_EQUAL`, `LESS_THAN`, `EQUAL`, `NOT_EQUAL`, and `IN_RANGE`.
 Tag data types: `DOUBLE`, `INT32`, `U_INT64`, `STRING`, `BOOLEAN`.
 
+Some v2 providers use a string filter inside trigger configuration instead of
+structured comparator/path fields. Example from a `WORKITEMCHANGED` routine:
+
+```json
+{
+  "type": "WORKITEMCHANGED",
+  "triggers": [
+    {
+      "name": "8f4db567-9686-4e4b-ac2c-31345cb01691",
+      "configuration": {
+        "filter": "(before.assignedTo != after.assignedTo) && (after.assignedTo = \"a69caa22-7e24-445f-8e9f-084ed98ff6e3\")"
+      }
+    }
+  ]
+}
+```
+
+Another observed string-filter provider is `TESTRESULTCHANGED`:
+
+```json
+{
+  "type": "TESTRESULTCHANGED",
+  "triggers": [
+    {
+      "configuration": {
+        "filter": "(before.status != after.status) && (after.programName = \"...\")"
+      }
+    }
+  ]
+}
+```
+
 ### v2 actions JSON structure
 
 ```json
@@ -465,44 +512,13 @@ Tag data types: `DOUBLE`, `INT32`, `U_INT64`, `STRING`, `BOOLEAN`.
 
 The second ALARM entry with trigger `nisystemlink_no_triggers_breached` is required by the API — it handles the alarm clear/reset state. Email notifications are delivered via `dynamicRecipientList` inside the ALARM action configuration. Severity levels: 1 (low) – 4 (critical).
 
-### Full example: tag threshold monitor with alarm + email
+Load [routine-examples.md](./routine-examples.md) for sanitized live examples covering:
 
-```bash
-slcli routine create \
-  --name "Fred Tag Monitor" \
-  --description "Alert when fred.test.* exceeds 10.2" \
-  --enabled \
-  --event '{
-    "type": "TAG",
-    "triggers": [{
-      "name": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
-      "configuration": {
-        "comparator": "GREATER_THAN",
-        "path": "fred.test.*",
-        "thresholds": ["10.2"],
-        "type": "DOUBLE"
-      }
-    }]
-  }' \
-  --actions '[
-    {
-      "type": "ALARM",
-      "triggers": ["a1b2c3d4-e5f6-7890-abcd-ef1234567890"],
-      "configuration": {
-        "displayName": "Fred Test Tag Alarm",
-        "description": "Tag fred.test.* exceeded 10.2",
-        "severity": 4,
-        "condition": "Greater than: 10.2",
-        "dynamicRecipientList": ["fred.visser@emerson.com"]
-      }
-    },
-    {
-      "type": "ALARM",
-      "triggers": ["nisystemlink_no_triggers_breached"],
-      "configuration": null
-    }
-  ]'
-```
+- v1 FILES filters that combine workspace checks, `name.Contains(...)`, and extension matching
+- v2 TAG routines using `IN_RANGE`, `NOT_EQUAL`, and `GREATER_THAN_OR_EQUAL`
+- v2 `TESTRESULTCHANGED` filters with nested field checks, indexed property access, and `DateTime.parse(...)`
+- v2 `WORKITEMCHANGED` filters with `.Any(...)` and `!Contains(...)`
+- Representative NOTEBOOK and ALARM action payloads
 
 ## comment — Resource comments
 

systemlink_cli-1.13.9/slcli/skills/slcli/references/routine-examples.md

@@ -0,0 +1,186 @@
+# Routine Configuration Examples
+
+Load this file when you need sanitized live examples for provider-specific
+routine payloads beyond the minimal syntax in `commands.md`.
+
+## v1 notebook routines
+
+### Scheduled notebook execution
+
+```bash
+slcli routine create --api-version v1 \
+  --name "Daily Notebook" \
+  --type SCHEDULED \
+  --notebook-id <NOTEBOOK_ID> \
+  --schedule '{"startTime":"2026-01-01T00:00:00Z","repeat":"DAY"}'
+```
+
+### FILES trigger with compound filter
+
+Observed v1 routines use the service-owned `trigger.filter` string directly.
+This can be more expressive than the simple `extension=".xml"` example.
+
+```json
+{
+  "trigger": {
+    "source": "FILES",
+    "events": ["CREATED"],
+    "filter": "workspace = \"<WORKSPACE_ID>\" && (name.Contains(\"Specs\") && extension = \"xlsx\")"
+  },
+  "execution": {
+    "type": "NOTEBOOK",
+    "definition": {
+      "notebookId": "<NOTEBOOK_ID>"
+    }
+  }
+}
+```
+
+Notes:
+
+- Keep the v1 filter string in the service's own syntax.
+- Observed FILES filters can combine workspace checks, `name.Contains(...)`, and extension checks.
+
+## v2 event-action routines
+
+### TAG alarm with structured trigger fields
+
+Observed TAG routines can use comparator-driven configuration instead of a
+string `filter`.
+
+```json
+{
+  "event": {
+    "type": "TAG",
+    "triggers": [
+      {
+        "configuration": {
+          "comparator": "IN_RANGE",
+          "deadband": 2,
+          "path": "*.path.to.tag",
+          "thresholds": ["1", "12"],
+          "type": "INT"
+        }
+      },
+      {
+        "configuration": {
+          "comparator": "NOT_EQUAL",
+          "path": "*.path.to.tag",
+          "thresholds": ["3"],
+          "type": "INT"
+        }
+      }
+    ]
+  },
+  "actions": [
+    {
+      "type": "ALARM",
+      "configuration": {
+        "displayName": "Alarm Name",
+        "severity": 4,
+        "condition": "In range: [1, 12]",
+        "dynamicRecipientList": ["user@example.com"]
+      }
+    }
+  ]
+}
+```
+
+### TAG health monitor with threshold alarm
+
+```json
+{
+  "event": {
+    "type": "TAG",
+    "triggers": [
+      {
+        "configuration": {
+          "comparator": "GREATER_THAN_OR_EQUAL",
+          "deadband": 5,
+          "path": "*.Health.Memory.UsePercentage",
+          "thresholds": ["80"],
+          "type": "DOUBLE"
+        }
+      }
+    ]
+  },
+  "actions": [
+    {
+      "type": "ALARM",
+      "configuration": {
+        "displayName": "High memory usage on <system>",
+        "severity": 3,
+        "condition": "Greater than or equal: 80"
+      }
+    }
+  ]
+}
+```
+
+Notes:
+
+- Observed TAG comparators include `GREATER_THAN`, `GREATER_THAN_OR_EQUAL`, `NOT_EQUAL`, and `IN_RANGE`.
+- Alarm-producing TAG routines still need the clear/reset action that uses trigger `nisystemlink_no_triggers_breached`.
+
+### TESTRESULTCHANGED filter with nested fields and time parsing
+
+```json
+{
+  "event": {
+    "type": "TESTRESULTCHANGED",
+    "triggers": [
+      {
+        "configuration": {
+          "filter": "(before.partNumber != after.partNumber) && ((after.status.statusType = \"Done\" && after.hostName = \"<HOST_NAME>\" && after.operator = \"<OPERATOR>\" && after.properties[\"key\"] = \"value\" || after.programName = \"Test Name\" && DateTime(after.updatedAt) > DateTime.parse(\"2026-05-14T19:23:15.275Z\")))"
+        }
+      }
+    ]
+  },
+  "actions": [
+    {
+      "type": "NOTEBOOK",
+      "configuration": {
+        "notebookId": "<NOTEBOOK_ID>",
+        "resourceProfile": "LOW",
+        "priority": "MEDIUM",
+        "serviceAccount": "<SERVICE_ACCOUNT_ID>"
+      }
+    }
+  ]
+}
+```
+
+Notes:
+
+- Observed filters can combine before/after comparisons, nested status fields, indexed property lookups, and `DateTime.parse(...)`.
+
+### WORKITEMCHANGED filter with collection predicates
+
+```json
+{
+  "event": {
+    "type": "WORKITEMCHANGED",
+    "triggers": [
+      {
+        "configuration": {
+          "filter": "(before.assignedTo != after.assignedTo) && (after.resources.assets.selections.Any(s => s.id == \"<ASSET_ID>\") && !after.description.Contains(\"description\") && after.templateId = \"123\")"
+        }
+      }
+    ]
+  },
+  "actions": [
+    {
+      "type": "NOTEBOOK",
+      "configuration": {
+        "resourceProfile": "HIGH",
+        "priority": "HIGH"
+      }
+    }
+  ]
+}
+```
+
+Notes:
+
+- Observed `WORKITEMCHANGED` filters can use `.Any(...)`, negated string checks, and exact template matching.
+- Common NOTEBOOK action fields across v2 examples are `notebookId`, `parameters`, `resourceProfile`, `priority`, and `serviceAccount`.

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/slcli/skills/systemlink-webapp/SKILL.md

@@ -38,7 +38,7 @@ Before generating code, clarify only the details that change the implementation:
 4. Auth context: same-origin hosted app versus remote/dev API-key flow.
 5. Deployment target: ordinary hosted webapp only, or Plugin Manager package as well.
 
-Do not ask about Angular or Nimble versions unless the user is constrained by an existing project. Default to Angular 20 and the latest compatible `@ni/nimble-angular`.
+Do not ask about Angular or Nimble versions unless the user is constrained by an existing project. Default to Angular 20 and the latest compatible `@ni/nimble-angular`, but verify the installed versions immediately after scaffold instead of assuming the generator produced the expected combination.
 
 For new SystemLink apps, recommend installing the NI Angular UI packages together unless the user is intentionally minimizing dependencies. `@ni/nimble-angular` remains the default foundation, `@ni/spright-angular` adds Spright chat and icon components, and `@ni/ok-angular` adds OK-specific controls such as accordion items and search input.
 
@@ -56,11 +56,31 @@ Then generate Angular in that starter directory so the SystemLink scaffolding st
 
 ```bash
 npx -y @angular/cli@20 new <app-name> --directory . --routing --style=scss --skip-git --no-standalone --defaults --force
-npm install @ni/nimble-angular @ni/spright-angular @ni/ok-angular @ni/systemlink-clients-ts
+npm install @ni/nimble-angular @ni/nimble-components @ni/unit-format @ni/spright-angular @ni/ok-angular @ni/systemlink-clients-ts @angular/localize
+npm install --save-dev @angular-devkit/build-angular
 ```
 
 Prefer NgModule-based apps for this workflow. The Nimble Angular wrapper modules fit naturally into a centralized `AppModule`, which reduces template surprises and keeps imports explicit.
 
+Immediately after scaffold, inspect `package.json` and `angular.json` before building features. The generator or migrations may leave the workspace on the wrong Angular major or on a builder configuration that does not bundle `@ni/nimble-angular` cleanly.
+
+For the currently supported path, standardize on:
+
+- Angular 20.x
+- `@ni/nimble-angular` 33.2.x
+- `@ni/nimble-components` 35.8.x
+- `@ni/unit-format` 1.0.4+
+- `@angular/localize` installed and added to build and test polyfills
+
+If the workspace ends up on `@angular/build:application` and Nimble fails to bundle with `Could not resolve '@ni/nimble-components/dist/esm/...'`, switch `angular.json` back to the legacy Angular builders:
+
+- `@angular-devkit/build-angular:browser`
+- `@angular-devkit/build-angular:dev-server`
+- `@angular-devkit/build-angular:extract-i18n`
+- `@angular-devkit/build-angular:karma`
+
+This fallback is not optional when the Nimble packages fail under the application builder. Fix the builder mismatch before implementing more UI.
+
 Recommend installing `@ni/spright-angular` and `@ni/ok-angular` early even if the first slice only uses Nimble. That avoids dependency churn later when the UI needs chat surfaces, product-specific icons, accordion items, or the OK search input.
 
 If the user has not run `slcli webapp init` and explicitly wants a SystemLink-hosted webapp, recommend it first unless they want a manual setup.
@@ -76,6 +96,8 @@ These decisions prevent the most common hosted-webapp failures:
 - Do not add `CUSTOM_ELEMENTS_SCHEMA` just to silence missing Nimble module imports.
 - Put theme-aware color and shadow aliases on `nimble-theme-provider`, not on `:root`.
 - Import `@angular/localize/init` in Angular polyfills for both build and test paths.
+- Import Nimble fonts once in the root `src/styles.scss` with `@use '@ni/nimble-angular/styles/fonts' as *;`. Without this, Nimble components render with fallback system fonts instead of the required Source Sans Pro typeface.
+- Run a production build immediately after setup changes. Do not postpone the first `npm run build` until after the UI is implemented.
 
 If you need the exact module patterns or template wiring, load [references/nimble-angular.md](./references/nimble-angular.md).
 If you need a concise package-level inventory before choosing components, load [references/angular-ui-packages.md](./references/angular-ui-packages.md).
@@ -90,6 +112,16 @@ Use SystemLink-appropriate layout defaults instead of inventing page structure f
 - Use accordions for grouped fields and advanced configuration.
 - Use cards sparingly for summaries, not as the default editing or data layout.
 
+Treat Nimble alignment as a requirement, not a style preference:
+
+- Use Nimble controls for primary actions, selection, inputs, status, and data display.
+- Use raw HTML elements mostly for semantic grouping, layout wrappers, and text structure.
+- Do not build custom-styled buttons, inputs, dropdowns, tabs, or pseudo-cards when Nimble already provides the interaction primitive.
+- Prefer Nimble spacing, borders, focus states, and theme tokens over bespoke visual treatments.
+- If a page starts to look like a generic marketing dashboard instead of a SystemLink tool, pull it back toward table/list-detail, drawers, banners, tabs, and structured metadata panels.
+
+The goal is a webapp that feels native to the SystemLink shell, not an arbitrary Angular site hosted inside it.
+
 Load [references/layout-patterns.md](./references/layout-patterns.md) when the task turns into page composition, spacing, or shell layout work.
 
 ### 4. Integrate SystemLink APIs the low-risk way
@@ -117,6 +149,14 @@ When the user asks for implementation, prefer one working slice over a full app
 - one error banner
 - one settings/control path only if required
 
+For a new app, the first vertical slice should also prove the setup:
+
+- scaffold completes
+- Angular and NI package versions are compatible
+- the app builds successfully
+- one Nimble-based route renders
+- one real SystemLink query works in the hosted shell
+
 This keeps context narrow and usually reveals the real integration blockers faster than broad scaffolding.
 
 ### 6. Publish or package only after the hosted constraints are covered
@@ -137,6 +177,7 @@ Always verify:
 - the browser console is clear of blocking errors
 - the correct SystemLink data loads
 - light/dark theme switching updates the app in real time
+- the page still reads as a Nimble/SystemLink experience rather than a custom HTML dashboard
 
 Load [references/troubleshooting.md](./references/troubleshooting.md) for the hosted validation flow and symptom-based fixes.
 
@@ -145,14 +186,20 @@ Load [references/troubleshooting.md](./references/troubleshooting.md) for the ho
 Before you consider a SystemLink webapp slice correct, confirm all of the following:
 
 - Angular 20 workspace created in the intended starter directory.
+- Angular and NI package versions verified after scaffold, not assumed.
+- `@ni/nimble-components`, `@ni/unit-format`, `@angular/localize`, and `@angular-devkit/build-angular` installed when using `@ni/nimble-angular`.
+- `angular.json` uses builders that are known to bundle Nimble successfully.
 - `AppModule` provides `APP_BASE_HREF`.
 - `index.html` does not contain a `<base>` element.
 - Router uses `useHash: true`.
 - Production build disables `inlineCritical`.
+- Root `src/styles.scss` imports `@use '@ni/nimble-angular/styles/fonts' as *;`.
 - Nimble Angular modules are imported explicitly.
+- Primary interaction controls use Nimble wrappers rather than custom HTML surrogates.
 - No hardcoded colors in component SCSS.
 - Theme-aware aliases live on `nimble-theme-provider`.
 - API client uses the correct SystemLink service base URL.
+- `npm run build` passes before publish.
 - Hosted deployment is validated after publish.
 
 ## Default implementation stance
@@ -162,20 +209,26 @@ Use these defaults unless the user asks for a different tradeoff:
 - Angular 20
 - NgModule-based app
 - `@ni/nimble-angular`
+- `@ni/nimble-components`
+- `@ni/unit-format`
 - `@ni/spright-angular`
 - `@ni/ok-angular`
 - `@ni/systemlink-clients-ts`
 - table-first data presentation
 - same-origin cookie auth
 - long-form CLI flags in examples and commands
+- Nimble-first interaction design with minimal bespoke chrome
 
 ## Common mistakes to prevent up front
 
 - Treating the app like a normal root-hosted Angular SPA instead of an iframe/sub-path app.
+- Assuming the scaffolded Angular major or builder is already correct for Nimble.
+- Waiting until the end of implementation to run the first production build.
 - Checking only the `theme` attribute instead of verifying resolved Nimble tokens.
 - Putting theme-aware aliases on `:root`.
 - Overriding SDK base URLs with incomplete service prefixes.
 - Using raw HTML controls where Nimble primitives should define the interaction model.
+- Letting the page drift into a custom dashboard aesthetic that ignores Nimble interaction and spacing patterns.
 - Loading too much reference material before the task requires it.
 
 ## When to escalate into the references

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/slcli/skills/systemlink-webapp/references/deployment.md

@@ -3,7 +3,10 @@
 ## Prerequisites
 
 - `slcli` installed and authenticated (`slcli login` or config file present)
-- Angular app built to `dist/<app-name>/browser/`
+- Angular app built successfully
+- Publish path confirmed for the active builder:
+  - `dist/<app-name>/browser/` for the application builder
+  - `dist/<app-name>/` for the legacy browser builder
 
 ---
 
@@ -11,12 +14,19 @@
 
 ```bash
 # Run from project root
-node_modules/.bin/ng build --configuration production --output-path dist/<app-name>
+node_modules/.bin/ng build --configuration production
 ```
 
 **Do NOT pass `--base-href`.** This would reintroduce a `<base>` element that violates SystemLink's CSP.
 
-Angular 19 places the browser output at `dist/<app-name>/browser/` — publish that subdirectory, not the parent.
+Angular may emit different publish roots depending on the active builder.
+
+- `@angular/build:application` emits browser assets under `dist/<app-name>/browser/`
+- `@angular-devkit/build-angular:browser` emits browser assets directly under `dist/<app-name>/`
+
+Always inspect the actual build output before publishing. Do not hardcode `/browser/` if the workspace is on the legacy builder.
+
+If `npm run build` fails with `Could not resolve '@ni/nimble-components/dist/esm/...'` while using `@ni/nimble-angular`, switch the workspace to the legacy Angular browser builder before continuing. Do not publish from a half-fixed setup.
 
 ### Background build (if terminal has heredoc/interrupt issues)
 
@@ -33,7 +43,7 @@ tail -f /tmp/ng-build.log
 ## First deploy (no existing webapp)
 
 ```bash
-slcli webapp publish dist/<app-name>/browser/ --workspace <workspace-name>
+slcli webapp publish <ACTUAL_BUILD_OUTPUT_DIR> --workspace <workspace-name>
 ```
 
 The command prints the new webapp ID. **Save it** — you need it for every future redeploy and for `slcli webapp open`.
@@ -49,7 +59,7 @@ Created webapp: 3727d9ac-86e1-4d6e-820e-d2630c1b28e9
 ## Redeploy (update existing webapp)
 
 ```bash
-slcli webapp publish dist/<app-name>/browser/ --workspace <workspace-name> --id <webapp-id>
+slcli webapp publish <ACTUAL_BUILD_OUTPUT_DIR> --workspace <workspace-name> --id <webapp-id>
 ```
 
 ---
@@ -86,9 +96,11 @@ Before publishing, verify:
 - [ ] `app.module.ts` provides `{ provide: APP_BASE_HREF, useValue: '/' }`
 - [ ] `app-routing.module.ts` uses `useHash: true`
 - [ ] `angular.json` has `inlineCritical: false` in production optimization
+- [ ] `angular.json` uses a builder that bundles `@ni/nimble-angular` successfully
 - [ ] `basePath` is `window.location.origin + '/<service-prefix>'` (not just origin)
 - [ ] `credentials: 'include'` (or equivalent) set on API client
 - [ ] Build succeeded with no errors (warnings about bundle size are OK if within 2MB error limit)
+- [ ] Publish path matches the active builder output
 
 ---
 
@@ -114,6 +126,11 @@ Before publishing, verify:
 - Beasties CSS inliner is injecting `onload` handlers
 - Fix: set `inlineCritical: false` in angular.json
 
+### Nimble packages fail to resolve during build
+
+- You may be on `@angular/build:application` with a Nimble package layout that esbuild does not resolve cleanly
+- Fix: install `@angular-devkit/build-angular` and switch to the legacy browser/dev-server builders in `angular.json`
+
 ### "Budget exceeded" build error
 
 Increase error limits in `angular.json`:

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/slcli/skills/systemlink-webapp/references/nimble-angular.md

@@ -10,6 +10,32 @@ When building Angular apps with Nimble, use `@ni/nimble-angular` wrapper modules
 - Do not add `CUSTOM_ELEMENTS_SCHEMA` just to silence unknown Nimble elements in templates. That usually hides a missing module import and weakens Angular's template validation.
 - If a Nimble icon or control is unknown, first look for the matching module in `@ni/nimble-angular` and import it.
 
+## Fonts
+
+Nimble requires the Source Sans Pro font family. Without this import, all Nimble components render with fallback system fonts (Arial) and the UI will not match the SystemLink design system.
+
+Import the fonts **once** in the root `src/styles.scss`:
+
+```scss
+@use '@ni/nimble-angular/styles/fonts' as *;
+```
+
+This registers `@font-face` declarations for Source Sans Pro (Regular, Light, SemiBold) and Source Code Pro, loading `.woff2` files bundled in `@ni/nimble-tokens`.
+
+To use Nimble design tokens (colors, font sizes, spacing) in component SCSS files, also import:
+
+```scss
+@use '@ni/nimble-angular/styles/tokens' as *;
+
+.my-element {
+  font-family: $ni-nimble-body-font-family;
+  font-size: $ni-nimble-body-font-size;
+  color: $ni-nimble-body-font-color;
+}
+```
+
+Do not duplicate the fonts import in component SCSS — it belongs only in the global `styles.scss`.
+
 ## nimble-theme-provider
 
 Wrap your entire app. Always place at the root component level.

{systemlink_cli-1.13.7 → systemlink_cli-1.13.9}/slcli/skills/systemlink-webapp/references/troubleshooting.md

@@ -46,6 +46,7 @@ If the `theme` attribute changes but the colors do not:
 | Error or symptom                          | Likely cause                                          | Fix                                                                              |
 | ----------------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------- |
 | `$localize is not defined`                | Angular localize polyfill missing                     | Add `@angular/localize/init` to Angular polyfills                                |
+| `Could not resolve '@ni/nimble-components/dist/esm/...'` during build | Nimble package layout not bundling under Angular application builder | Install `@angular-devkit/build-angular` and switch `angular.json` back to the legacy browser/dev-server builders |
 | NG04002 or blank screen                   | Path routing under SystemLink sub-path                | Use hash routing                                                                 |
 | CSP `base-uri` error                      | `<base>` tag present                                  | Remove `<base>` and provide `APP_BASE_HREF` via DI                               |
 | CSP `unsafe-inline` error from styles     | Critical CSS inlining injected handlers               | Set `inlineCritical: false`                                                      |
@@ -63,6 +64,7 @@ If the `theme` attribute changes but the colors do not:
 - confirm `nimble-theme-provider` is present
 - confirm the required Nimble Angular modules are imported
 - confirm the app uses Nimble components instead of native HTML controls for primary interactions
+- confirm the page is not relying on custom-styled HTML buttons, inputs, or cards where Nimble controls should own the interaction
 
 ### App follows the shell theme attribute but colors still look wrong
 
@@ -76,6 +78,13 @@ If the `theme` attribute changes but the colors do not:
 - verify cookie auth versus API-key mode
 - verify the generated request body shape matches the real API
 
+### Build fails before the app ever runs
+
+- verify the Angular major matches the installed `@ni/nimble-angular` peer dependency
+- verify `@ni/nimble-components`, `@ni/unit-format`, and `@angular/localize` are installed
+- if the workspace uses `@angular/build:application` and Nimble imports fail to resolve, move back to `@angular-devkit/build-angular:browser`
+- rerun `npm run build` before changing more application code
+
 ### Dialogs or advanced overlays do not open
 
 - do not gate `nimble-dialog` with `*ngIf`
@@ -87,6 +96,7 @@ Before publishing or redeploying, verify:
 
 - no hardcoded colors remain in component styles
 - Nimble primitives are used for the main controls and data views
+- the page reads as a Nimble/SystemLink tool rather than a bespoke HTML dashboard
 - `APP_BASE_HREF` is provided and no `<base>` tag exists
 - routing uses `useHash: true`
 - production build disables `inlineCritical`