systemlink-cli 1.27.0__tar.gz → 1.27.2__tar.gz

{systemlink_cli-1.27.0 → systemlink_cli-1.27.2}/PKG-INFO

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

{systemlink_cli-1.27.0 → systemlink_cli-1.27.2}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "systemlink-cli"
-version = "1.27.0"
+version = "1.27.2"
 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.27.0 → systemlink_cli-1.27.2}/slcli/_version.py

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

systemlink_cli-1.27.2/slcli/skills/slcli/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: slcli
+description: >-
+  Query and manage NI SystemLink resources using the slcli command-line interface.
+  Use when the user asks about test results, assets, systems, work items,
+  specifications, webapps, notebooks, dataframes, files, feeds, tags,
+  authorization, users, example fixture authoring, example config.yaml files,
+  or other SystemLink resource workflows. Use it when the user asks to create,
+  validate, review, install, or troubleshoot a SystemLink example fixture.
+argument-hint: >-
+  Describe the SystemLink workflow you want to inspect, automate, scaffold, or
+  troubleshoot.
+---
+
+# SystemLink CLI
+
+Use this skill when the task is primarily about `slcli` commands or a
+SystemLink resource workflow that should be driven from the CLI.
+
+## When to use it
+
+- Querying or managing SystemLink resources through `slcli`
+- Looking up exact command syntax, flags, or JSON output patterns
+- Building command sequences for analysis, provisioning, packaging, or cleanup
+- Creating, validating, or reviewing `slcli example` fixture YAML
+- Troubleshooting CLI behavior, platform gating, or command selection
+
+## Reference docs
+
+Load only what the current task needs.
+
+| Topic | File | When to load |
+| --- | --- | --- |
+| CLI command reference | [commands.md](./references/commands.md) | Looking up command syntax, options, or examples |
+| Example fixture authoring | [example-authoring.md](./references/example-authoring.md) | Creating or reviewing `config.yaml`, resource references, file-backed fixtures, or validation behavior |
+| Datasheet-to-spec workflow | [datasheet-workflow.md](./references/datasheet-workflow.md) | Importing specifications from PDF, CSV, or structured text |
+| Minimal spec import payload | [import-specs.min.json](./references/import-specs.min.json) | Need a bundled create-compatible starter payload or conditions |
+| Spec import helper | [spec_import_helper.py](./scripts/spec_import_helper.py) | Scaffold or validate a datasheet spec import payload |
+| Filtering guide | [filtering.md](./references/filtering.md) | Advanced filters, LINQ syntax, and query composition |
+| Analysis recipes | [analysis-recipes.md](./references/analysis-recipes.md) | Multi-step analysis workflows and reporting patterns |
+| Troubleshooting | [troubleshooting.md](./references/troubleshooting.md) | SSL, workspace IDs, encoding, or scripting pitfalls |
+| Notebook workflow | [notebook/overview.md](./references/notebook/overview.md) | Creating notebooks for SystemLink |
+| Webapp workflow | [webapp/overview.md](./references/webapp/overview.md) | Hosted Angular webapp scaffolding and deployment |
+| Python test workflow | [python-test/overview.md](./references/python-test/overview.md) | Python test app structure and deployment |
+| Job debugging | [job-debugging/overview.md](./references/job-debugging/overview.md) | Salt job triage and recovery |
+| NI package files | [nipkg/overview.md](./references/nipkg/overview.md) | File-package assembly and `nipkg pack` guidance |
+
+## Default approach
+
+1. Prefer long-form flags in generated commands.
+2. Use `--format json` when the result will be filtered, transformed, or piped
+   into other tools.
+3. Use `--summary --group-by` for aggregation before fetching large raw result sets.
+4. Use convenience filters first, then fall back to `--filter` with `--substitution` for complex queries.
+5. Stay scoped to the user’s requested resource or workflow.
+6. Load deeper references only when the command surface alone is not enough.
+7. For example authoring or review, load `example-authoring.md` before proposing YAML.
+8. Prefer workspace IDs over names in scripted workflows when an endpoint is strict about identity.
+9. Use `make_api_request` from `slcli.utils` for helper scripts so auth, SSL, and error handling stay consistent.
+10. For datasheet imports, default to autonomy when the product or workspace can be resolved unambiguously.
+
+## Common command groups
+
+| Group | Purpose | Key subcommands |
+| --- | --- | --- |
+| `testmonitor` | Test results and products | `result list/get`, `product list/create/update` |
+| `alarm` | Alarm monitoring and lifecycle actions | `list`, `get`, `acknowledge`, `force-clear`, `delete`, `transition`, `monitor` |
+| `spec` | Specifications | `list`, `query`, `get`, `create`, `import`, `export` |
+| `asset` | Assets and calibration | `list`, `get`, `summary`, `calibration` |
+| `system` | System fleet | `list`, `get`, `compare`, `summary`, `job` |
+| `tag` | Tag read/write | `list`, `get-value`, `set-value`, `create` |
+| `routine` | Event-action routines | `list`, `create`, `enable/disable` |
+| `comment` | Resource comments | `list`, `add`, `update`, `delete` |
+| `workitem` | Work items and workflows | `list`, `create`, `schedule`, `template`, `workflow` |
+| `file` | File management | `list`, `upload`, `download`, `query`, `watch` |
+| `notebook` | Jupyter notebooks | `manage list/create`, `execute start/sync` |
+| `feed` | Package feeds | `list`, `create`, `package upload` |
+| `customfield` | Dynamic form fields | `list`, `create`, `export`, `edit` |
+| `template` | Test plan templates | `list`, `import`, `export` |
+| `webapp` | Web applications | `new`, `pack`, `publish`, `list` |
+| `config` | Connection profiles | `list`, `use`, `add`, `delete` |
+| `user` | User management | `list`, `get`, `create`, `update` |
+| `auth` | Authorization policies | `policy list/create`, `template list` |
+| `workspace` | Workspaces | `list`, `get` |
+| `skill` | AI skill installation | `install` |
+| `example` | Demo provisioning | `list`, `install`, `delete` |
+
+Example package fixtures are declared as `package` resources after a `feed`
+resource. Use `source.type: dummy` for deterministic packages, `file` for a
+fixture-relative `.nipkg`, or `repository` for an explicit HTTPS package URL.
+The repository catalog can identify packages and feeds, but package bytes must
+come from a direct package URL or an existing feed download path.
+
+## Mandatory scope resolution
+
+Before the first resource query, resolve the profile and workspace separately.
+Treat a workspace supplied by the user as a workspace identifier, never as a
+profile name. Match it exactly against either the workspace name or UUID.
+
+1. Run `slcli config list --format json` and select profiles whose `workspace`
+  field matches the requested workspace name. If the user supplied a UUID,
+  probe configured profiles sequentially instead. Do not infer a profile from
+  a similar name such as `demo-fred` or `fred-roaster`.
+2. Use the global `--profile NAME` override on every command. The option goes
+  before the command group, for example:
+
+  ```bash
+  slcli --profile PROFILE_NAME workspace list --format json
+  ```
+
+  This preserves the user's global active profile.
+3. If several profiles match, probe them sequentially with
+  `slcli --profile NAME info --skip-health --format json`. Continue past a
+  missing credential, unavailable endpoint, or permission error. Confirm the
+  selected candidate with one read-only workspace query before issuing the
+  actual resource query. Do not fan out the same query across candidates.
+4. Use the first authorized candidate. Ask the user only when several
+  candidates are authorized and the choice could change the answer.
+5. With the selected profile, run `workspace list --format json` and resolve
+  the requested workspace by exact name or UUID. Carry both the display name
+  and UUID, but use the UUID for subsequent queries when the command accepts
+  it.
+
+When reading `slcli info --format json`, use `active_profile_name` as the
+effective profile after CLI or environment overrides. `current_profile` is the
+persisted config pointer and may differ. Use `api_url_source` to confirm where
+the effective endpoint came from; never use `current_profile` alone to decide
+which profile served a query.
+
+## Mandatory non-interactive webapp deployment protocol
+
+For every webapp creation, publish, redeploy, or update task, load
+[deployment.md](./references/webapp/deployment.md) and follow its ordered
+protocol. Do not build or upload an artifact until the deployment target has
+been resolved. The protocol is non-interactive: use JSON output and bounded
+inventory commands, and do not rely on table pagination or terminal prompts.
+
+1. Discover the installed command surface before composing commands:
+  ```bash
+  slcli config list --format json
+  slcli webapp publish -h
+  slcli webapp list -h
+  ```
+  Installed `--help` wins over this skill and its references. Confirm every
+  option on the installed CLI; `webapp publish` currently has `--id`, `--name`,
+  and `--workspace`, while `webapp list` has bounded JSON output and `-f`.
+  Prefer long options in generated commands after confirming they exist.
+2. Resolve the effective profile and target workspace separately. Probe a
+  candidate with `info --skip-health --format json`, resolve the workspace
+  display name to its UUID with `workspace list --format json`, and carry the
+  UUID into every later command. Never use a similar profile name as a
+  substitute for workspace identity.
+3. Resolve the exact webapp target before building or uploading. Use a
+  bounded, filtered, non-interactive inventory, for example:
+  ```bash
+  slcli --profile PROFILE webapp list \
+    --workspace WORKSPACE_ID --filter "Coffee Tasting" \
+    --take 10 --format json
+  ```
+  The server-side `--filter` is a substring filter, so compare returned names
+  locally. One exact name match means update that webapp with its returned ID
+  by default. Multiple exact matches are ambiguous and require a selected ID.
+  No exact match means report that a new resource would be created and obtain
+  explicit confirmation or an explicit create instruction before using
+  `--name`; never create a duplicate as an implicit fallback.
+4. Inspect the project contract before running its dev server or production
+  build. Read `package.json` and `angular.json`; do not append `--host` when
+  the package script already supplies it. Remove or correct legacy Angular
+  options such as `buildOptimizer` and `vendorChunk` when they make `ng serve`
+  reject the configuration. Run the production build, detect its actual
+  output directory, and verify the hosted routing, CSP, authentication, and
+  service/workspace contract. The Test Monitor results service prefix is
+  `/nitest/v2/query-results`, not `/nitestmonitor/v2/query-results`; do not
+  hardcode `workspace=Default` when the target workspace was resolved.
+5. Publish only after steps 1-4 pass. Pass the resolved workspace for a new
+  webapp, or the exact existing webapp ID for an update. Capture the returned
+  webapp ID, published URL, and publish timestamp in the task record.
+6. Validate at three levels: deployment metadata with `webapp get`, an
+  authenticated CLI query for the target workspace and required resources,
+  and an authenticated browser check of the hosted URL. A reachable URL is
+  not proof of an authenticated app. If the browser redirects to login or
+  returns 401, report exactly: `deployment reachable, interactive hosted
+  validation pending.`
+
+## Product lookup and overview defaults
+
+For product discovery, use this order:
+
+1. Try an exact or likely part number with `testmonitor product list
+  --part-number`.
+2. Try the name and family convenience filters.
+3. If a convenience filter returns `[]`, treat that as inconclusive. Scan the
+  resolved workspace catalog with a bounded JSON query and match name or part
+  number locally with `jq`.
+4. Fetch the selected product with `testmonitor product get <PRODUCT_ID>`.
+
+For a product overview, fetch the product record and directly linked metadata
+only. Use `--summary` for counts and statuses, and grouped summaries for
+profiles, programs, or other supported dimensions. For result data, use only
+dimensions exposed by the command, such as `status` and `programName`. Fetch
+only the latest 5 to 10 results, projecting relevant fields with `jq`. Fetch
+full result details only for a specific run or failure. Record an explicit UTC
+`as of` time and treat counts from separate live queries as separate
+observations.

{systemlink_cli-1.27.0 → systemlink_cli-1.27.2}/slcli/skills/slcli/references/analysis-recipes.md

@@ -17,10 +17,94 @@ Each recipe maps to a real-world scenario and shows the exact commands needed.
 - [Recipe 9: Product family workload distribution](#recipe-9-product-family-workload-distribution)
 - [Recipe 10: Environmental condition failure patterns](#recipe-10-environmental-condition-failure-patterns)
 - [Recipe 11: Create and schedule a work item on a specific fixture/slot and system](#recipe-11-create-and-schedule-a-work-item-on-a-specific-fixtureslot-and-system)
+- [Product discovery and overview](#product-discovery-and-overview)
 - [General tips](#general-tips)
 
 ---
 
+## Product discovery and overview
+
+**Question:** Tell me about a product in a specific workspace without
+producing an oversized, inconsistent report.
+
+**Prerequisite:** Complete the mandatory profile and workspace resolution in
+the main `slcli` skill. Set `PROFILE` to the selected profile and
+`WORKSPACE_ID` to the resolved workspace UUID. Capture the observation time
+before querying live data:
+
+```bash
+PROFILE="<PROFILE_NAME>"
+WORKSPACE_ID="<WORKSPACE_UUID>"
+AS_OF="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
+printf 'As of %s\n' "$AS_OF"
+```
+
+**Lookup order:**
+
+```bash
+# 1. Exact or likely part number
+slcli --profile "$PROFILE" testmonitor product list \
+  --workspace "$WORKSPACE_ID" --part-number "<PART_NUMBER>" \
+  --format json --take 25
+
+# 2. Name or family convenience filters, when the part-number lookup is empty
+slcli --profile "$PROFILE" testmonitor product list \
+  --workspace "$WORKSPACE_ID" --name "<PRODUCT_NAME>" \
+  --format json --take 25
+slcli --profile "$PROFILE" testmonitor product list \
+  --workspace "$WORKSPACE_ID" --family "<FAMILY>" \
+  --format json --take 25
+
+# 3. Bounded workspace catalog fallback when convenience filters are empty
+slcli --profile "$PROFILE" testmonitor product list \
+  --workspace "$WORKSPACE_ID" --format json --take 100 |
+  jq --arg name "<PRODUCT_NAME>" --arg part "<PART_NUMBER>" '
+    [ .[] | select(
+        (($name != "") and ((.name // "" | ascii_downcase) | contains($name | ascii_downcase)))
+        or (($part != "") and ((.partNumber // "" | ascii_downcase) | contains($part | ascii_downcase)))
+      ) | {id, name, partNumber, family, workspace} ]'
+```
+
+An empty result from a name or family filter does not prove that the product is
+absent. Increase the bounded catalog limit only deliberately, and project the
+candidate fields in `jq` before displaying them. Fetch the selected record only
+after identifying its ID:
+
+```bash
+slcli --profile "$PROFILE" testmonitor product get <PRODUCT_ID> --format json
+```
+
+**Overview budget:**
+
+```bash
+# Directly linked metadata, only when relevant to the question
+slcli --profile "$PROFILE" spec list --product <PRODUCT_ID> --format json
+
+# Compact counts and status breakdown
+slcli --profile "$PROFILE" testmonitor result list \
+  --part-number "<PART_NUMBER>" --summary --group-by status \
+  --format json
+
+# Grouped program summary
+slcli --profile "$PROFILE" testmonitor result list \
+  --part-number "<PART_NUMBER>" --summary --group-by programName \
+  --format json
+
+# Latest 5 to 10 results, projected to relevant fields
+slcli --profile "$PROFILE" testmonitor result list \
+  --part-number "<PART_NUMBER>" --order-by STARTED_AT --descending \
+  --take 10 --format json |
+  jq '[.[] | {id, status: .status.statusType, startedAt, programName,
+               partNumber, serialNumber}]'
+```
+
+Use `testmonitor result get <RESULT_ID> --include-steps --format json` only
+when the user asks about a particular run or failure. Counts from separate
+commands are not one atomic snapshot; report the `as of` time and call out
+live-data changes when totals do not agree.
+
+---
+
 ## Recipe 1: Operator failure rate analysis
 
 **Question:** Which operators have the highest failure rates and what should they
@@ -482,8 +566,9 @@ slcli workitem schedule wi-12345 \
 - **Start with `--summary`** to understand data shape before fetching raw records.
 - **Use `--group-by`** with `--summary` for aggregation: `status`, `programName`,
   `serialNumber`, `operator`, `hostName`, `systemId`.
-- **Chain with `jq`** for complex transformations — always use `-f json`.
-- **Use `--take` wisely** — start small (100-500), increase if needed.
+- **Chain with `jq`** for complex transformations — always use `--format json`.
+- **Use `--take` wisely** — start with 5-10 for recent detail and a bounded
+  catalog query for discovery; increase only when the question requires it.
 - **For rate calculations**, query total count and filtered count separately, then divide.
 - **Use `--order-by TOTAL_TIME_IN_SECONDS --descending`** to find slowest tests quickly.
 - **Asset `--connected` flag** limits to assets in currently connected systems.

{systemlink_cli-1.27.0 → systemlink_cli-1.27.2}/slcli/skills/slcli/references/commands.md

@@ -28,6 +28,31 @@ Complete option reference for all `slcli` command groups.
 - [webapp — Web application management](#webapp--web-application-management)
 - [skill — AI skill installation](#skill--ai-skill-installation)
 - [example — Built-in example resource provisioning](#example--built-in-example-resource-provisioning)
+- [Scope and capability discovery](#scope-and-capability-discovery)
+
+## Scope and capability discovery
+
+Resolve a requested workspace before querying its resources. `--profile` is a
+global option and must precede the command group:
+
+```bash
+# Find profiles mapped to the requested workspace
+slcli config list --format json | \
+  jq -r --arg workspace "Fred" '.[] | select((.workspace // "") == $workspace) | .name'
+
+# Probe candidates one at a time without changing the active profile
+slcli --profile <PROFILE_NAME> info --skip-health --format json
+slcli --profile <PROFILE_NAME> workspace list --format json
+```
+
+In `info` JSON, `active_profile_name` is the effective profile for the command,
+while `current_profile` is the persisted config pointer. `api_url_source`
+identifies the source of the effective API URL. Use the effective fields when
+they disagree; `current_profile` alone is not a reliable query-scope signal.
+
+Consult `<command> --help` whenever a flag or alias is uncertain. Format aliases
+are command-specific, and the installed CLI help is authoritative. Generated
+commands should prefer the long form `--format json`.
 
 ## testmonitor — Test data analysis
 
@@ -78,7 +103,7 @@ slcli testmonitor product list [OPTIONS]
   --workspace, -w TEXT       # Filter by workspace name or ID
   --summary                  # Show summary statistics
   --take, -t INTEGER         # Items per page (default 25)
-  -f [table|json]
+  --format, -f [table|json]
 
 # Get a single product
 slcli testmonitor product get <PRODUCT_ID> [-f json]
@@ -427,11 +452,11 @@ slcli dataframe delete <TABLE_ID>... [--yes]
 
 ```bash
 slcli tag list [OPTIONS]                            # List tags (filter by path glob, workspace)
-slcli tag get <TAG_PATH> [-f json]                  # Get tag metadata
+slcli tag get <TAG_PATH>                            # Get tag metadata
 slcli tag get-value <TAG_PATH>                      # Read current tag value
 slcli tag history <TAG_PATH> [-w WORKSPACE] [-t TAKE] [-f json] [--graph]  # Read or graph history
 slcli tag set-value <TAG_PATH> <VALUE>              # Write a tag value
-slcli tag create --path <PATH> --data-type <TYPE>   # Create a new tag
+slcli tag create <TAG_PATH> --type <TYPE> [OPTIONS]  # Create a new tag
 slcli tag update <TAG_PATH> [OPTIONS]               # Update tag metadata
 slcli tag delete <TAG_PATH>                         # Delete a tag
 ```
@@ -665,8 +690,9 @@ slcli comment delete <ID1> <ID2> <ID3>
 ## workspace — Workspace management
 
 ```bash
-slcli workspace list [-f json]
-slcli workspace get <WORKSPACE_ID> [-f json]
+slcli workspace list [--format json]
+slcli workspace get --workspace WORKSPACE_ID [--format json]
+slcli workspace disable --id WORKSPACE_ID [--yes]
 ```
 
 ## config — Profile and credential management
@@ -680,10 +706,10 @@ slcli logout [--profile NAME] [--all] [--force]
 slcli info [-f json] [--skip-health]            # Show active profile and service health
 slcli completion [--shell SHELL] [--install]    # Generate or install shell tab completion
 
-slcli config list [-f json]                     # List all profiles
+slcli config list [--format json]               # List all profiles
 slcli config current                            # Show the active profile name
 slcli config use <PROFILE>                      # Switch the active profile
-slcli config view [--profile NAME] [-f json]    # Show full profile details
+slcli config view [-f json] [--show-secrets]    # Show stored profile details
 slcli config add [--profile NAME] [OPTIONS]     # Add or update a profile
 slcli config delete <PROFILE> [--force]         # Delete a profile
 slcli config migrate                            # Migrate legacy keyring credentials
@@ -693,10 +719,10 @@ slcli config migrate                            # Migrate legacy keyring credent
 
 ```bash
 slcli user list [--workspace NAME] [-t INT] [-f json]
-slcli user get <USER_ID> [-f json]
+slcli user get [--id USER_ID | --email EMAIL] [-f json]
 slcli user create [OPTIONS]         # Create a new user
-slcli user update <USER_ID> [OPTIONS]
-slcli user delete <USER_ID>
+slcli user update --id USER_ID [OPTIONS]
+slcli user delete --id USER_ID [--yes]
 ```
 
 ## auth — Authorization policies and templates
@@ -705,10 +731,10 @@ slcli user delete <USER_ID>
 # Policies
 slcli auth policy list [--type CHOICE] [--builtin] [-t INT] [-f json]
 slcli auth policy get <POLICY_ID> [-f json]
-slcli auth policy create --name TEXT [OPTIONS]
+slcli auth policy create TEMPLATE_ID --name TEXT --workspace WORKSPACE [OPTIONS]
 slcli auth policy update <POLICY_ID> [OPTIONS]
 slcli auth policy delete <POLICY_ID>
-slcli auth policy diff <POLICY_ID>              # Show diff of a pending policy change
+slcli auth policy diff <POLICY_ID_1> <POLICY_ID_2>  # Compare two policies
 
 # Policy templates
 slcli auth template list [-t INT] [-f json]
@@ -723,28 +749,29 @@ Supports Windows (.nipkg) and NI Linux RT (.ipk/.deb).
 
 ```bash
 slcli feed list [-w WORKSPACE] [-t INT] [-f json]
-slcli feed get <FEED_ID> [-f json]
+slcli feed get --id FEED_ID [-f json]
 slcli feed create --name TEXT [--workspace NAME] [OPTIONS]
-slcli feed delete <FEED_ID>
-slcli feed replicate --source-id FEED_ID --target-workspace WORKSPACE [OPTIONS]
+slcli feed delete --id FEED_ID [--yes] [--wait] [--timeout INT]
+slcli feed replicate --name NAME --platform [windows|ni-linux-rt] --url URL [OPTIONS]
 
 # Packages within a feed
-slcli feed package list --feed-id FEED_ID [-f json]
+slcli feed package list --feed-id FEED_ID [--take INT] [--format json]
 slcli feed package upload --feed-id FEED_ID --file PATH
-slcli feed package delete --feed-id FEED_ID --package-name NAME
+slcli feed package delete --id PACKAGE_ID [--yes] [--wait] [--timeout INT]
 ```
 
 ## file — File Service management
 
 ```bash
-slcli file list [--workspace NAME] [--name TEXT] [-t INT] [-f json]
+slcli file list [--workspace NAME] [--filter TEXT] [--id-filter IDS] [-t INT] [-f json]
 slcli file get <FILE_ID> [-f json]
-slcli file upload --file PATH [--workspace NAME] [OPTIONS]
-slcli file download <FILE_ID> -o OUTPUT_PATH
-slcli file delete <FILE_ID>
+slcli file upload FILE_PATH [--workspace NAME] [--name NAME] [--properties JSON]
+slcli file download <FILE_ID> [-o OUTPUT_PATH] [--force]
+slcli file delete --id FILE_ID [--force]
 slcli file query [--filter TEXT] [-t INT] [-f json]      # Advanced filter query
 slcli file update-metadata <FILE_ID> [OPTIONS]
-slcli file watch [--workspace NAME] [--filter TEXT]      # Stream new file events
+slcli file watch WATCH_DIR [--workspace NAME] [--move-to DIRECTORY | --delete-after-upload]
+                         [--pattern GLOB] [--debounce SECONDS] [--recursive]
 ```
 
 ## notebook — Jupyter Notebook management and execution
@@ -754,21 +781,26 @@ slcli file watch [--workspace NAME] [--filter TEXT]      # Stream new file event
 slcli notebook init [--name NAME] [--directory DIR]      # Create a local .ipynb template
 
 # Remote notebook management
-slcli notebook manage list [-w WORKSPACE] [-t INT] [-f json]
-slcli notebook manage get <NOTEBOOK_ID> [-f json]
-slcli notebook manage create --file PATH [--workspace NAME]
-slcli notebook manage update <NOTEBOOK_ID> --file PATH
-slcli notebook manage set-interface <NOTEBOOK_ID> [OPTIONS]  # Define parameter interface
-slcli notebook manage download <NOTEBOOK_ID> -o PATH
-slcli notebook manage delete <NOTEBOOK_ID>
+slcli notebook manage list [-w WORKSPACE] [--filter TEXT] [-t INT] [-f json]
+slcli notebook manage get --id NOTEBOOK_ID [-f json]
+slcli notebook manage create [--file PATH] [--workspace NAME] --name NAME [--interface CHOICE]
+slcli notebook manage update --id NOTEBOOK_ID [--metadata FILE] [--content FILE] [--interface CHOICE]
+slcli notebook manage set-interface --id NOTEBOOK_ID --interface CHOICE
+slcli notebook manage download [--id NOTEBOOK_ID | --name NAME] [--workspace NAME]
+                                     [--output PATH] [--type CHOICE]
+slcli notebook manage delete --id NOTEBOOK_ID [--yes]
 
 # Notebook executions
-slcli notebook execute list [-w WORKSPACE] [-t INT] [-f json]
-slcli notebook execute get <EXECUTION_ID> [-f json]
-slcli notebook execute start <NOTEBOOK_ID> [--params JSON] [--workspace NAME]
-slcli notebook execute sync <EXECUTION_ID>               # Wait for completion
-slcli notebook execute cancel <EXECUTION_ID>
-slcli notebook execute retry <EXECUTION_ID>
+slcli notebook execute list [-w WORKSPACE] [--status STATUS] [--notebook-id NOTEBOOK_ID]
+                                  [-t INT] [-f json]
+slcli notebook execute get --id EXECUTION_ID [-f json]
+slcli notebook execute start --notebook-id NOTEBOOK_ID [--workspace NAME] [--parameters JSON]
+                                      [--timeout INT] [--no-cache] [--format table|json]
+slcli notebook execute sync --notebook-id NOTEBOOK_ID [--workspace NAME] [--parameters JSON]
+                                      [--timeout INT] [--poll-interval FLOAT] [--max-wait INT]
+                                      [--format table|json] [--no-cache]
+slcli notebook execute cancel --id EXECUTION_ID
+slcli notebook execute retry --id EXECUTION_ID
 ```
 
 ## customfield — Custom field (DFF) configuration
@@ -776,14 +808,15 @@ slcli notebook execute retry <EXECUTION_ID>
 Manage Dynamic Form Field definitions used to attach custom metadata to resources.
 
 ```bash
-slcli customfield list [-w WORKSPACE] [-t INT] [-f json]
-slcli customfield get <FIELD_ID> [-f json]
-slcli customfield create --name TEXT --entity-type TYPE [OPTIONS]
-slcli customfield update <FIELD_ID> [OPTIONS]
-slcli customfield delete <FIELD_ID>
-slcli customfield export [-o FILE]                       # Export all custom fields to JSON
-slcli customfield init [--directory DIR]                 # Scaffold a local config template
-slcli customfield edit [--directory DIR]                 # Interactively edit + push config
+slcli customfield list [-w WORKSPACE] [--take INT] [-f json]
+slcli customfield get --id FIELD_ID [-f json]
+slcli customfield create --file FILE
+slcli customfield update --file FILE
+slcli customfield delete --id CONFIG_ID [--group-id GROUP_ID] [--field-id FIELD_ID]
+                              [--no-recursive] [--yes]
+slcli customfield export --id CONFIG_ID [-o FILE]         # Export a configuration to JSON
+slcli customfield init [--name NAME] [--workspace NAME] [--resource-type TYPE] [-o FILE]
+slcli customfield edit [--file FILE] [--id CONFIG_ID] [--port INT] [--no-browser]
 ```
 
 ## template — Test plan template management
@@ -795,12 +828,12 @@ slcli customfield edit [--directory DIR]                 # Interactively edit +
 > when provisioning new test plan instances.
 
 ```bash
-slcli template init [--name TEXT] [--directory DIR]      # Scaffold a local template file
+slcli template init [--name TEXT] [--template-group TEXT] [-o FILE]  # Scaffold a local template file
 slcli template list [-w WORKSPACE] [-t INT] [-f json]
-slcli template get <TEMPLATE_ID> [-f json]
-slcli template export [-o FILE] [-w WORKSPACE]           # Export all templates to JSON
-slcli template import --file PATH [--workspace NAME]     # Import templates from JSON
-slcli template delete <TEMPLATE_ID>
+slcli template get [--id TEMPLATE_ID | --name NAME] [-f json]
+slcli template export [--id TEMPLATE_ID | --name NAME] [-o FILE]  # Export templates to JSON
+slcli template import --file PATH                         # Import templates from JSON
+slcli template delete --id TEMPLATE_ID [--yes]
 ```
 
 ## workitem — Work item, template, and workflow management
@@ -846,13 +879,13 @@ slcli workitem template delete <TEMPLATE_ID>... [--yes]
 # Workflow subgroup
 slcli workitem workflow list [-w WORKSPACE] [-t INT] [-f json]
 slcli workitem workflow get [--id WORKFLOW_ID] [--name NAME] [-f json]
-slcli workitem workflow init [--name TEXT] [--directory DIR]   # Scaffold a local workflow file
-slcli workitem workflow create --file PATH [-w WORKSPACE]      # Create from JSON file
+slcli workitem workflow init [--name TEXT] [--description TEXT] [--workspace NAME] [-o FILE]
 slcli workitem workflow import --file PATH [-w WORKSPACE]      # Import workflow from JSON
 slcli workitem workflow export [--id WORKFLOW_ID] [--name NAME] [-o FILE]  # Export to JSON
 slcli workitem workflow update --id WORKFLOW_ID --file PATH    # Update from JSON file
 slcli workitem workflow delete --id WORKFLOW_ID [--yes]
-slcli workitem workflow preview [--file PATH] [--id WORKFLOW_ID] [--html] [--no-open] [-o FILE]
+slcli workitem workflow preview [--file PATH | --id WORKFLOW_ID] [--format html|mmd]
+                                [--no-emoji] [--no-legend] [--no-open] [-o FILE]
 ```
 
 **Create work item options:**
@@ -878,23 +911,33 @@ slcli workitem create \
 
 ## webapp — Web application management
 
-Scaffold, package, and publish custom web applications to SystemLink.
+Create, package, and publish custom web applications to SystemLink.
+
+For new applications, use `slcli webapp new <app-name>`. Treat the older
+`slcli webapp init` command as a compatibility-only manual bootstrap path; it
+is intentionally omitted from the recommended command sequence.
 
 ```bash
-slcli webapp init <DIRECTORY>                      # Scaffold the Angular starter
+slcli webapp new <APP_NAME> [OPTIONS]                # Generate a hosted Angular webapp
 slcli webapp manifest init <DIRECTORY> [OPTIONS]  # Create nipkg.config.json for packaging
-slcli webapp pack [FOLDER] [--config FILE] [-o OUTPUT_FILE]  # Package a webapp into a .nipkg
-slcli webapp list [-w WORKSPACE] [-t INT] [-f json]
-slcli webapp get <WEBAPP_ID> [-f json]
-slcli webapp publish PATH [--workspace NAME]             # Upload and publish a webapp
-slcli webapp delete <WEBAPP_ID>
-slcli webapp open <WEBAPP_ID>                            # Open webapp URL in browser
+slcli webapp pack [FOLDER] [--config FILE] [--output OUTPUT_FILE]  # Package a webapp into a .nipkg
+slcli webapp list [-w WORKSPACE] [--filter TEXT] [--take INT] [--format FORMAT] [-f FORMAT]
+slcli webapp get --id WEBAPP_ID [--format json]
+slcli webapp publish PATH --id WEBAPP_ID                # Update an existing webapp
+slcli webapp publish PATH --name NAME --workspace NAME  # Create metadata and upload
+slcli webapp delete --id WEBAPP_ID [--yes]
+slcli webapp open --id WEBAPP_ID                          # Open webapp URL in browser
 ```
 
-`webapp init` creates the SystemLink Angular starter, not a generic HTML app. The starter installs
-project-scoped skills into `.agents/skills/` and creates `PROMPTS.md` plus `START_HERE.md` so an
-AI assistant can bootstrap the Angular workspace in place with the same Nimble/SystemLink
-conventions described by the webapp overview inside the `slcli` skill.
+`webapp list` supports both `--format` and `-f` in the current CLI. Older
+installed versions may expose only the long form, so use `slcli webapp list
+--help` to verify the local command surface before scripting against it.
+`webapp publish` has no output-format option; use `webapp get --format json`
+after publishing when structured deployment metadata is needed.
+
+For an existing Angular project, work in that project directly and load the
+webapp references as needed. Do not introduce the legacy `webapp init` step
+into a new project workflow.
 
 `webapp manifest init` writes `nipkg.config.json` using the Plugin Manager field names
 (`section`, `maintainer`, `homepage`, `xbPlugin`, `slPluginManagerTags`,
@@ -921,7 +964,6 @@ Notes:
 
 - `agents` is the default client in interactive mode.
 - The bundled `slcli` skill now covers the previous standalone workflow skills.
-- `webapp init` installs project-scoped skills into `.agents/skills/` by default.
 
 ## example — Built-in example resource provisioning
 
@@ -930,10 +972,10 @@ for training, testing, or evaluation.
 
 ```bash
 slcli example list [-f json]                             # List available examples
-slcli example info <EXAMPLE_ID>                          # Show example details
-slcli example install <EXAMPLE_ID> [--workspace NAME]    # Provision example resources
-slcli example install --file PATH [--workspace NAME]     # Install a local fixture
-slcli example delete <EXAMPLE_ID> [--workspace NAME]     # Remove provisioned resources
+slcli example info <EXAMPLE_NAME>                        # Show example details
+slcli example install [EXAMPLE_NAME] --workspace NAME    # Provision example resources
+slcli example install --file PATH --workspace NAME      # Install a local fixture
+slcli example delete <EXAMPLE_NAME> --workspace NAME     # Remove provisioned resources
 ```
 
 For a local fixture, `PATH` points to its `config.yaml`; referenced files are