E2E Support Matrix

E2E support matrix (latest nightly)

Overwritten by the nightly workflow; do not edit by hand.

• Run: 129
• Commit: c1c2aeb3d7c5
• Date: 2026-10-12 06:20 UTC

E2E consolidated report

Platform	OS	Total	Pass	Fail	Skip	Xfail	Status
MI300X (release) ROCm 7.14.1 · vLLM 0.26.0+rocm723 · lemonade 11.5.1	Linux Ubuntu 24.04.4 LTS	242	195	2	40	5	FAIL
MI300X (release) ROCm 7.14.1 · vLLM 0.26.0+rocm723 · lemonade 11.5.1	Linux Ubuntu 24.04.4 LTS	242	195	2	40	5	FAIL
MI350P (release) ROCm 7.14.1 · vLLM 0.26.0+rocm723 · lemonade 11.5.1	Linux Ubuntu 24.04.4 LTS	242	195	2	40	5	FAIL
R9700 (release) ROCm 7.14.1 · lemonade 11.5.1	Linux Ubuntu 24.04.4 LTS	242	187	1	47	7	FAIL
R9700 (release) ROCm 7.14.1 · lemonade 11.5.1	Linux Ubuntu 24.04.4 LTS	242	187	1	47	7	FAIL
Strix Halo (release) ROCm 7.14.1 · lemonade 11.5.1	Ubuntu Ubuntu 26.04.1 LTS	242	187	0	48	7	PASS
Strix Halo (release) ROCm 7.14.1 · lemonade 11.5.1	Ubuntu Ubuntu 26.04.1 LTS	242	187	0	48	7	PASS
Strix Halo (nightly) ROCm 10.1.0a20260822 · lemonade 11.5.1	WSL2 Ubuntu 24.04.5 LTS	242	171	0	68	3	PASS
Strix Halo (release) ROCm 7.14.1 · lemonade 11.5.1	WSL2 Ubuntu 24.04.5 LTS	242	171	0	68	3	PASS
Total		2178	1675	8	446	49

Mock runs the real rocm CLI, but fakes the inference backend: instead of downloading a runtime and launching a real engine (vLLM/lemonade) on a GPU, a tiny in-process HTTP server stands in for the OpenAI-compatible endpoint that engine would expose (/v1/models, /v1/chat/completions). This exercises CLI behaviour — alias resolution, service discovery, chat forwarding — with no GPU, no model download, and no engine process, so it runs on a GitHub-hosted runner. It gates the PR: it runs on every push, and if it fails the PR's required check goes red and the PR cannot merge. Every other platform is a real self-hosted GPU host running real engines — the rows below are the list, so naming them here would only go stale as lanes are added. They are non-blocking: they still run and are reported here, but a failure does NOT block the PR from merging (the hardware/runners are still being proven out, so their results are informational rather than a merge gate).

Column meanings: Pass = scenarios that passed as expected; Xfail = known bugs that failed as expected (healthy — the bug still reproduces); Skip = not applicable on this platform (e.g. a GPU-only scenario on Mock); Fail = unexpected — a scenario that should pass but failed, or a known bug that unexpectedly passed (its tag is now stale). Status is PASS unless a platform has any Fail.

Expectation grid (scenario × platform)

✅ pass · ✗ known bug, failed as expected (xfail) · n/a not applicable here · ❌FAIL regression · ⚠️XPASS bug fixed here (stale entry) · ✅XPASS (flaky) known flaky bug passed this run · ⚠️n/a-ran ran despite being marked n/a · ⚠️no-result expected to run but no result recorded · · no data.

Artifact prefetch cleanup

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
artifact-prefetch-01 - A failed artifact cache write leaves no temporary marker artifact-prefetch-failed-marker-leaves-no-temp	✅	✅	✅	✅	✅	✅

Automation watchers

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
automations-01 - Enabling a watcher confirms its mode automations-enable-confirms-mode	✅	✅	✅	✅	✅	✅
automations-02 - Disabling a watcher is confirmed automations-disable-confirmed	✅	✅	✅	✅	✅	✅
automations-03 - Enabling an unknown watcher is refused automations-enable-unknown-refused	✅	✅	✅	✅	✅	✅
automations-04 - Enabling during an in-flight daemon spawn starts no second daemon automations-autostart-defers-during-spawn-window	✅	✅	✅	✅	✅	✅

Benchmarking a served endpoint

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
bench-01 - Benchmarking a running server reports measured throughput bench-load-reports-throughput	✅	✅	✅	✅	✅	✅
bench-02 - A plain host address is accepted and still reaches the server bench-load-accepts-plain-address	✅	✅	✅	✅	✅	✅
bench-03 - A benchmark whose every request is rejected fails loudly bench-load-surfaces-failures	✅	✅	✅	✅	✅	✅
bench-04 - The recorded CSV row carries the engine and per-output-token latency bench-load-records-engine-and-tpot	✅	✅	✅	✅	✅	✅
bench-05 - Appending over results that predate the engine column warns about the split bench-load-warns-on-engine-split	✅	✅	✅	✅	✅	✅
bench-06 - Benchmarking a really served model reports throughput bench-load-real-serve	✅	✅	✗	✗	n/a	n/a

Chat and endpoint detection

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
chat-01 - A served model is discoverable through the services list chat-served-model-discoverable	✅	✅	✅	✅	✅	✅
chat-02 - The privacy notice is shown before using a local endpoint chat-privacy-notice-accurate	✅	✅	✅	✅	✅	✅
chat-03 - Interactive chat uses a running managed model chat-managed-model-interactive	✅	✅	✅	✅	✅	✅
chat-04 - The assistant is told what machine it is running on chat-assistant-is-told-which-machine-it-is-on	✅	✅	✅	✅	✅	✅
chat-05 - A served model's endpoint is shown in the services list chat-endpoint-shown-in-services	✅	✅	✅	✅	✅	✅
chat-06 - Chat requests that include tool definitions are accepted chat-tool-definitions-accepted	✗	✗	✗	✗	✅	✅
chat-07 - End-to-end chat through a locally served model chat-end-to-end-local-model	✅	✅	✗	✗	✅	✅
chat-08 - The chat CLI answers a one-shot prompt against a local server chat-cli-oneshot-prompt	✅	✅	✅	✅	✅	✅
chat-09 - The chat CLI reads a one-shot prompt from stdin chat-cli-stdin-prompt	✅	✅	✅	✅	✅	✅

ComfyUI install reports progress and makes failures actionable

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
comfyui-01 - A failed dependency install names the log it wrote comfyui-uv-install-failure-names-log	✅	✅	✅	✅	✅	✅
comfyui-02 - A dependency install streams progress output comfyui-uv-install-progress-streamed	✅	✅	✅	✅	✅	✅
comfyui-03 - ComfyUI install refuses an ambiguous runtime choice and names every remediation comfyui-ambiguous-runtime-actionable	✅	✅	✅	✅	✅	✅
comfyui-04 - The source-archive download spinner renders progress and clears on completion comfyui-source-download-shows-live-progress	✅	✅	✅	✅	✅	✅

Configuration mutations

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
config-01 - Setting and clearing the default engine is confirmed config-default-engine-set-and-cleared	✅	✅	✅	✅	✅	✅
config-02 - Setting and clearing the default runtime is confirmed config-default-runtime-set-and-cleared	✅	✅	✅	✅	✅	✅
config-03 - Choosing a telemetry mode is confirmed with its policy config-telemetry-mode-confirmed	✅	✅	✅	✅	✅	✅
config-04 - Choosing a permissions mode is confirmed config-permissions-mode-confirmed	✅	✅	✅	✅	✅	✅
config-05 - Configuring an engine requires a target config-set-engine-requires-target	✅	✅	✅	✅	✅	✅
config-06 - Enabling and disabling a cloud provider is confirmed config-provider-enable-disable	✅	✅	✅	✅	✅	✅
config-07 - The always-on local provider cannot be toggled as a cloud provider config-local-provider-not-toggleable	✅	✅	✅	✅	✅	✅
config-08 - Saving a provider key without secure storage fails without leaking the key config-provider-key-no-secret-storage	✅	✅	✅	✅	✅	✅

Diagnosing failures and listing fixes

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
diagnose-01 - Diagnosing a recognised failure reports a likely cause and a fix diagnose-matches-known-symptom	✅	✅	✅	✅	✅	✅
diagnose-02 - Diagnosing any failure always gives the user a way to escalate diagnose-always-offers-a-way-forward	✅	✅	✅	✅	✅	✅
diagnose-03 - A diagnosis is available in machine-readable form for tooling diagnose-json-has-match-flag	✅	✅	✅	✅	✅	✅
diagnose-04 - The user can see every fix the CLI knows how to apply diagnose-fix-lists-known-recipes	✅	✅	✅	✅	✅	✅
diagnose-05 - Previewing a fix explains the change without making it diagnose-fix-dry-run-changes-nothing	✅	✅	✅	✅	✅	✅
diagnose-06 - Asking for a fix the CLI does not know is refused clearly diagnose-fix-unknown-id-rejected	✅	✅	✅	✅	✅	✅
diagnose-07 - Asking for a fix by its position in the diagnosis is corrected diagnose-fix-position-argument-rejected	✅	✅	✅	✅	✅	✅
diagnose-08 - A fix that changes the machine is not applied without agreement diagnose-fix-requires-agreement-before-changing-anything	✅	✅	✅	✅	n/a	n/a
diagnose-09 - A tool is told plainly when no cause was established diagnose-json-states-when-nothing-matched	✅	✅	✅	✅	✅	✅
diagnose-10 - A platform the catalog does not cover says so and routes onward diagnose-states-whether-the-platform-is-covered	✅	✅	✅	✅	✅	✅
diagnose-11 - A fix meant for another operating system is declined, not attempted diagnose-fix-inapplicable-here-is-declined-not-attempted	✅	✅	✅	✅	✅	✅
diagnose-12 - The CLI offers every fix its catalog documents diagnose-fix-catalog-is-complete	✅	✅	✅	✅	✅	✅
diagnose-13 - A vLLM engine-startup import failure is recognised from its error text diagnose-recognises-the-engine-import-failure	✅	✅	✅	✅	n/a	n/a
diagnose-14 - A fix whose steps span two shells says which shell each step runs in diagnose-fix-says-which-shell-each-step-runs-in	✅	✅	✅	✅	✅	✅
diagnose-15 - A fix whose helper command fails explains why, on stderr, with exit code 4 diagnose-fix-command-failure-reported-on-stderr	✅	✅	✅	✅	n/a	n/a
diagnose-16 - Declining the confirmation prompt on a real terminal is reported the same way diagnose-fix-interactive-decline-reported	✅	✅	✅	✅	n/a	n/a
diagnose-17 - A WSL machine is never given a bare-metal cause diagnose-wsl-never-reports-bare-metal-causes	n/a	n/a	n/a	n/a	✅	✅
diagnose-18 - A WSL remedy is explained rather than carried out diagnose-wsl-fix-is-explained-not-attempted	n/a	n/a	n/a	n/a	✅	✅
diagnose-19 - Asking about a machine that cannot be reached is refused, not substituted diagnose-unreachable-machine-is-refused-not-substituted	✅	✅	✅	✅	✅	✅
diagnose-20 - Previewing a fix that needs sudo and a re-login says so, and that it's auto-applicable here diagnose-fix-preview-states-required-flags	✅	✅	✅	✅	n/a	n/a
diagnose-21 - A model this machine cannot serve is refused before anything is downloaded diagnose-model-too-large-is-refused-with-something-that-fits	✅	✅	✅	✅	✅	✅
diagnose-22 - A model this machine can serve is reported ready, with the engine that would serve it diagnose-model-that-fits-is-ready-and-names-the-engine	✅	✅	✅	✅	✅	✅
diagnose-23 - A recipe catalog that cannot be read is not reported as an incompatible model diagnose-model-unreachable-catalog-is-not-an-incompatible-model	✅	✅	✅	✅	✅	✅
diagnose-24 - A model outside the curated catalog is undetermined, not blocked diagnose-model-not-curated-is-undetermined-not-blocked	✅	✅	✅	✅	✅	✅
diagnose-25 - A model that runs below its recommended system RAM is degraded, not blocked diagnose-model-below-recommended-ram-is-degraded-not-blocked	✅	✅	✅	✅	✅	✅
diagnose-26 - Asking --model with --distro is refused before answering for the wrong machine diagnose-model-with-distro-is-refused-not-answered-for-the-local-host	✅	✅	✅	✅	✅	✅
diagnose-27 - A fix that only explains itself here is not advertised as one the CLI will run diagnose-fix-applicability-is-per-machine	✅	✅	✅	✅	✅	✅
diagnose-28 - A fix that needs more information says what it needs and changes nothing diagnose-fix-needing-an-argument-says-so	✅	✅	✅	✅	n/a	n/a
diagnose-29 - Asking what a report would say shows it and sends nothing diagnose-report-is-shown-and-not-sent	✅	✅	✅	✅	✅	✅
diagnose-30 - What a report would carry never identifies the machine diagnose-report-carries-no-identifying-detail	✅	✅	✅	✅	✅	✅
diagnose-31 - Asking the CLI for a way to send a report, without asking to see it first, is refused diagnose-send-without-report-is-refused	✅	✅	✅	✅	✅	✅
diagnose-32 - Asking to send on a machine with no desktop prints the address and a link instead of starting a mail client diagnose-send-on-a-headless-machine-prints-instead-of-opening	✅	✅	✅	✅	✅	✅
diagnose-33 - The fix for a shadowed compilation library changes nothing and recommends nothing diagnose-fix-comgr-conflict-is-advisory-only	✅	✅	✅	✅	✅	✅
diagnose-34 - A tool can read the catalog without parsing prose diagnose-fix-catalog-is-machine-readable	✅	✅	✅	✅	✅	✅
diagnose-35 - Asking to apply one fix in machine-readable form is refused diagnose-fix-catalog-json-rejects-a-fix-id	✅	✅	✅	✅	✅	✅
diagnose-36 - A vLLM startup OOM receives conditional remediation diagnose-vllm-oom-is-conditional	✅	✅	✅	✅	✅	✅
diagnose-37 - Another engine's OOM is not blamed on a vLLM mention elsewhere in the paste diagnose-vllm-oom-not-attributed-across-rendered-lines	✅	✅	✅	✅	✅	✅

Download-progress spinner under a real terminal

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
download-progress-01 - The tarball download spinner renders progress and clears on completion download-progress-linux-tarball-install-shows-live-progress	✅	✅	✅	✅	✅	✅

Driver installation planning

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
driver-install-01 - Previewing the WSL driver install produces an actionable packaged plan driver-install-wsl-dry-run-plan	n/a	n/a	n/a	n/a	✅	✅
driver-install-02 - Reviewing the WSL driver install requires approval before execution driver-install-wsl-review-requires-approval	n/a	n/a	n/a	n/a	✅	✅
driver-install-03 - Installing a ROCDXG release with no known digest is refused driver-install-wsl-unverified-release-refused	n/a	n/a	n/a	n/a	✅	✅

Engine shell

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
engine-shell-01 - Entering an engine shell is visibly different from the shell you left engine-shell-marks-the-prompt	✅	✅	✅	✅	✅	✅

GPU detection and system inspection

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
examine-01 - The CLI reports its version examine-version	✅	✅	✅	✅	✅	✅
examine-02 - The CLI lists all supported engines examine-engines-list	✅	✅	✅	✅	✅	✅
examine-03 - The help output lists subcommands in alphabetical order examine-help-lists-subcommands-alphabetically	✅	✅	✅	✅	✅	✅
examine-04 - System inspection detects the GPU and driver examine-detects-gpu-and-driver	✅	✅	✅	✅	n/a	n/a
examine-05 - System inspection names the engine this machine serves on examine-reports-host-default-engine	✅	✅	✅	✅	✅	✅
examine-06 - System inspection distinguishes CLI-managed from pre-existing ROCm examine-distinguishes-unmanaged-rocm	✅	✅	✅	✅	✅	✅
examine-07 - What the inspection tells a tool matches what it tells a person examine-machine-readable-report	✅	✅	✅	✅	✅	✅
examine-08 - Both forms of the inspection agree about the GPU examine-both-forms-agree-on-gpu	✅	✅	✅	✅	✗	✗
examine-09 - Inspecting a machine reports what it finds without failing examine-reports-without-failing	✅	✅	✅	✅	✅	✅
examine-10 - The user can leave the frameworks out of the inspection examine-can-skip-framework-probing	✅	✅	✅	✅	n/a	n/a
examine-11 - System inspection recognizes a WSL host examine-detects-wsl	n/a	n/a	n/a	n/a	✅	✅
examine-12 - The driver install dry-run shows the effective repo version examine-install-driver-dry-run-resolves-repo-version	✅	✅	✅	✅	✅	✅
examine-13 - Listing engines explains the default-engine marker examine-engines-list-shows-default-engine-legend	✅	✅	✅	✅	✅	✅
examine-14 - Inspecting the system explains the default-engine marker examine-shows-default-engine-legend	✅	✅	✅	✅	✅	✅
examine-15 - The framework report describes the runtime the engines will use examine-framework-names-the-interpreter-that-answered	✅	✅	✅	✅	n/a	n/a
examine-16 - The scripting form names the setup runtime folder unaided examine-json-names-the-setup-runtime-folder	✅	✅	✅	✅	✅	✅
examine-17 - The machine-readable report lists every GPU the kernel sees examine-lists-every-gpu-with-its-address-and-target	✅	✅	✅	✅	n/a	n/a
examine-18 - The inspection says which code object manager libraries the machine holds examine-reports-code-object-manager-copies	✅	✅	✅	✅	✅	✅
examine-19 - The inspection finds the compilation library the CLI installed itself examine-finds-the-managed-runtimes-own-compilation-library	✅	✅	✅	✅	n/a	n/a

Interactive dashboard

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
dash-01 - A user opens the dashboard and navigates to ROCm setup dash-opens-and-navigates	✅	✅	✅	✅	✅	✅
dash-02 - A user receives a response in interactive chat dash-chat-offline-reply	✅	✅	✅	✅	✅	✅
dash-03 - The dashboard reports a model that is still loading as loading dash-loading-service-status	✅	✅	✅	✅	✅	✅
dash-04 - Observe displays metrics from a managed model dash-managed-service-metrics	✅	✅	✅	✅	✅	✅
dash-05 - A user can discover dashboard help and next-step guidance dash-help-guidance	✅	✅	✅	✅	✅	✅
dash-06 - A user navigates to Serving through the command palette dash-command-palette-navigation	✅	✅	✅	✅	✅	✅
dash-07 - A managed model is visible in the dashboard dash-managed-service-visible	✅	✅	✅	✅	✅	✅
dash-08 - Gen throughput stays visible for the validity window after a scrape failure dash-gen-tps-held-after-scrape-failure	✅	✅	✅	✅	✅	✅
dash-09 - Gen throughput expires after the validity window following sustained failure dash-gen-tps-expiry-boundary	✅	✅	✅	✅	✅	✅
dash-10 - The launcher front door shows a live serving model rather than idle dash-launcher-shows-live-serving-instance	✅	✅	✅	✅	✅	✅
dash-11 - Escape closes a manager overlay on any tab dash-manager-escape-closes-on-any-tab	✅	✅	✅	✅	✅	✅
dash-12 - A surfaced tool call defaults to Deny and confirming without moving denies it dash-chat-approval-defaults-to-deny	✅	✅	✅	✅	✅	✅
dash-13 - Opening instance detail dims the screen behind the popup dash-instance-detail-dims-backdrop	✅	✅	✅	✅	✅	✅
dash-14 - Escape opens the menu when idle on the Chat tab dash-chat-idle-escape-opens-menu	✅	✅	✅	✅	✅	✅
dash-15 - Opening the theme picker dims the screen behind it dash-theme-picker-dims-backdrop	✅	✅	✅	✅	✅	✅
dash-16 - Replaying a missing recording fails before entering the dashboard dash-replay-missing-file-fails-fast	✅	✅	✅	✅	✅	✅
dash-17 - A SIGTERM restores the terminal and exits 143 dash-sigterm-restores-terminal	✅	✅	✅	✅	✅	✅
dash-18 - A SIGINT restores the terminal and exits 130 dash-sigint-restores-terminal	✅	✅	✅	✅	✅	✅
dash-19 - A SIGTERM to the launcher hub restores the terminal after a session dash-launcher-sigterm-restores-terminal-across-a-session	✅	✅	✅	✅	✅	✅
dash-20 - Typing Ctrl-C in the dashboard restores the terminal and exits 130 dash-ctrl-c-restores-terminal	✅	✅	✅	✅	✅	✅
dash-21 - Typing Ctrl-C at the launcher front door restores the terminal and exits 130 dash-launcher-ctrl-c-restores-terminal	✅	✅	✅	✅	✅	✅
dash-22 - Instance detail shows a scroll hint when content overflows dash-instance-detail-scroll-hint	✅	✅	✅	✅	✅	✅
dash-23 - The onboarding Configure step opens the install-folder browser dash-onboarding-configure-folder-browse	✅	✅	✅	✅	✅	✅
dash-24 - Dashboard displays GPU telemetry through WSL dash-reports-wsl-gpu-telemetry	n/a	n/a	n/a	n/a	n/a	n/a

Local server record cleanup

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
service-cleanup-01 - Removing a stopped record deletes every file it owns service-cleanup-removes-every-file-a-record-owns	✅	✅	✅	✅	✅	✅
service-cleanup-02 - Removing a running local server is refused service-cleanup-refuses-a-running-server	✅	✅	✅	✅	✅	✅
service-cleanup-03 - Pruning previews first, then sweeps leftover engine state service-cleanup-prunes-previews-then-sweeps-leftovers	✅	✅	✅	✅	✅	✅
service-cleanup-04 - The default keeps a fresh record and --any-age takes it service-cleanup-any-age-takes-what-the-default-kept	✅	✅	✅	✅	✅	✅
service-cleanup-05 - A record whose server died long ago is pruned by default service-cleanup-prunes-a-server-that-died-long-ago	✅	✅	✅	✅	✅	✅
service-cleanup-06 - A file prune cannot remove is named and fails the command service-cleanup-names-a-file-it-could-not-remove	✅	✅	✅	✅	✅	✅
service-cleanup-07 - Prune waits for an in-flight launch instead of sweeping its key service-cleanup-prune-waits-for-a-launch-to-publish	✅	✅	✅	✅	✅	✅

Local server records

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
server-records-01 - The disk report names the folder local server records are kept in server-records-storage-report-names-the-folder	✅	✅	✅	✅	✅	✅
server-records-02 - The dashboard's services overlay counts records that are no longer running server-records-dashboard-overlay-counts-them	✅	✅	✅	✅	✅	✅

Log inspection

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
logs-01 - Searching logs reports how many recent lines match logs-search-reports-match-count	✅	✅	✅	✅	✅	✅
logs-02 - Searching logs for an absent term reports no matches logs-search-absent-term-no-matches	✅	✅	✅	✅	✅	✅
logs-03 - Asking for a service and a search term at once is refused logs-service-and-search-conflict	✅	✅	✅	✅	✅	✅

Model serving

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
serve-01 - Short model names are expanded to their full name serve-short-name-expansion	✗	✗	✗	✗	✗	✗
serve-02 - Short name expansion is consistent across engines serve-short-name-consistent-across-engines	✗	✗	✗	✗	✗	✗
serve-03 - A running model server is discoverable by name serve-discoverable-by-name	✅	✅	✅	✅	✅	✅
serve-04 - Running services show the correct connection details serve-connection-details	✅	✅	✅	✅	✅	✅
serve-05 - A served model responds to inference requests on vLLM serve-vllm-inference	✅	✅	n/a	n/a	n/a	n/a
serve-06 - A large platform-specific model serves and responds to inference serve-large-model-inference	✅	✅	✅	✅	n/a	n/a
serve-07 - A model served on lemonade responds to inference requests serve-lemonade-inference	✗	✗	✗	✗	n/a	n/a
serve-08 - A canonical Hugging Face checkpoint serves and responds to inference serve-hf-checkpoint-inference	✅	✅	✅	✅	n/a	n/a
serve-09 - Serving a model without specifying an engine produces a working endpoint serve-default-engine-working-endpoint	n/a	n/a	n/a	n/a	n/a	n/a
serve-10 - A default-engine served model responds to inference requests serve-default-engine-inference	n/a	n/a	n/a	n/a	n/a	n/a
serve-11 - vLLM is the default serving engine on Instinct serve-vllm-default-on-instinct	✅	✅	n/a	n/a	n/a	n/a
serve-12 - A service reported ready can immediately serve inference serve-readiness-contract	n/a	n/a	n/a	n/a	n/a	n/a
serve-13 - Serving is refused on a host with no AMD GPU serve-no-gpu-fails-fast	n/a	n/a	n/a	n/a	✅	✅
serve-14 - Serving with a temperature below zero is refused with a clear reason serve-negative-temperature-rejected	✅	✅	✅	✅	✅	✅
serve-15 - Serving is refused when every GPU is masked from view serve-masked-devices-fail	✅	✅	✅	✅	n/a	n/a
serve-16 - Serving pinned to a GPU that does not exist is refused serve-absent-gpu-index-rejected	✅	✅	✅	✅	n/a	n/a
serve-17 - Selecting both a runtime and an environment at once is refused serve-runtime-and-env-selectors-conflict	✅	✅	✅	✅	✅	✅
serve-18 - Repeated Lemonade preparation failure gives the user a recovery path serve-lemonade-preparation-recovery	n/a	n/a	n/a	n/a	✅	✅
serve-19 - Serving pinned to a GPU hidden by the visibility mask is refused serve-masked-gpu-index-rejected	✅	✅	✅	✅	n/a	n/a
serve-20 - Serving pinned past the ROCR-reindexed visible set is refused serve-rocr-reindexed-gpu-index-rejected	✅	✅	✅	n/a	n/a	n/a
serve-21 - Serving is refused when ROCR hides every GPU a HIP mask names serve-rocr-empty-mask-beats-hip-mask	✅	✅	✅	✅	n/a	n/a
serve-22 - A failed local server is counted in the default list serve-past-attempts-surfaced	✅	✅	✅	✅	✅	✅
serve-23 - A vLLM serve plan on a nearly-full GPU points at the memory knob serve-vllm-low-vram-oom-guidance	✅	✅	n/a	n/a	n/a	n/a

Native HTTP networking

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
networking-01 - The CLI reaches a served endpoint over the native HTTP stack networking-native-http-endpoint-reachable	✅	✅	✅	✅	✅	✅
networking-02 - A chat round-trip over a local endpoint uses the native HTTP stack networking-native-http-chat-round-trip	✅	✅	✅	✅	✅	✅
networking-03 - Binding to a public interface without opt-in is refused up front networking-public-bind-requires-opt-in	✅	✅	✅	✅	✅	✅

Non-interactive bootstrap setup

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
bootstrap-01 - Running bootstrap setup without a terminal advertises the install-folder choice bootstrap-setup-no-tty-advertises-install-folder	✅	✅	✅	✅	✅	✅

Release install lifecycle

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
lifecycle-01 - Linux - a bundle signed with a key file installs, verifies, and sets up the shell profile lifecycle-linux-install-signed-keypath	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-02 - Linux - a bundle signed with an inline PEM installs and verifies lifecycle-linux-install-signed-pem	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-03 - Linux - an install with no public key falls back to the pinned trust root and rejects an untrusted signer lifecycle-linux-reject-untrusted-key	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-04 - Linux - a tampered checksum is rejected before activation lifecycle-linux-reject-bad-checksum	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-05 - Linux - a tampered signature is rejected before activation lifecycle-linux-reject-bad-signature	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-06 - Linux - a missing signature is rejected when a signature is required lifecycle-linux-reject-missing-signature	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-07 - Linux - reinstalling purges a stale prior entry and preserves config lifecycle-linux-reinstall-purges-stale	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-08 - Linux - the installed binary opens and exits interactive chat through a pseudo-terminal lifecycle-linux-installed-binary-pty	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-09 - Linux - uninstall removes binaries, manifest, and XDG state lifecycle-linux-uninstall-full-purge	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-10 - Windows - a signed zip installs and verifies with native crypto lifecycle-windows-install-signed	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-11 - Windows - a malformed current trust root falls through to the valid next key lifecycle-windows-key-rotation-fallback	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-12 - Windows - all malformed pinned trust roots fail deterministically lifecycle-windows-all-pinned-keys-malformed	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-13 - Windows - a default install updates the user PATH and restores it afterwards lifecycle-windows-updates-user-path	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-14 - Windows - the installer verifies with native crypto when openssl is absent from PATH lifecycle-windows-verifies-without-openssl	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-15 - Windows - a bad signature is rejected with native crypto when openssl is absent from PATH lifecycle-windows-rejects-bad-signature-without-openssl	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-16 - Windows - reinstalling purges a stale prior entry lifecycle-windows-reinstall-purges-stale	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-17 - Windows - an install with no public key rejects an untrusted signer lifecycle-windows-reject-untrusted-key	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-18 - Windows - a tampered checksum is rejected before activation lifecycle-windows-reject-bad-checksum	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-19 - Windows - a tampered signature is rejected before activation lifecycle-windows-reject-bad-signature	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-20 - Windows - a missing signature is rejected when a signature is required lifecycle-windows-reject-missing-signature	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-21 - Windows - a signed bundle installs over a loopback HTTP download lifecycle-windows-http-install	n/a	n/a	n/a	n/a	n/a	n/a
lifecycle-22 - Windows - the installed binary honors isolated directories and keeps the running executable on uninstall lifecycle-windows-installed-binary-smoke	n/a	n/a	n/a	n/a	n/a	n/a

Runtime configuration

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
runtime-01 - Installing the SDK makes it the active runtime runtime-install-sdk-active	✅	✅	✅	✅	n/a	n/a
runtime-02 - The managed runtime path is not nested inside another runtime runtime-path-not-nested	✗	✗	✗	✗	n/a	n/a
runtime-03 - Reinstalling the SDK leaves the installed engine able to use the GPU runtime-sdk-reinstall-keeps-engine-consistent	✅	✅	n/a	n/a	n/a	n/a
runtime-04 - Opting out of the torch alignment keeps the torch the user installed runtime-torch-alignment-opt-out	❌FAIL	❌FAIL	n/a	n/a	n/a	n/a
runtime-05 - The update check reports the active runtime's freshness runtime-update-reports-freshness	✅	✅	✅	✅	n/a	n/a
runtime-06 - Previewing an install through a linked runtimes folder names the real folder runtime-install-records-the-real-folder	✅	✅	✅	✅	✅	✅
runtime-07 - Adopting a pre-existing ROCm install is rejected with guidance runtime-adopt-preexisting-rejected	✅	✅	✅	✅	✅	✅
runtime-08 - Previewing a nightly SDK install reports canonical provenance runtime-resolve-canonical-nightly	✅	✅	✅	✅	✅	✅
runtime-09 - Previewing a release SDK install resolves the canonical aggregate for this GPU runtime-resolve-canonical-release	✅	✅	✅	✅	✅	✅
runtime-10 - Stating rollback's single-level limit in --help runtime-rollback-help-states-single-level-limit	✅	✅	✅	✅	✅	✅
runtime-11 - Reinstalling the SDK over an existing runtime without consent is refused runtime-install-sdk-overwrite-requires-yes	✅	✅	✅	✅	n/a	n/a
runtime-12 - Reinstalling the SDK over an existing runtime with --yes proceeds runtime-install-sdk-overwrite-with-yes	✅	✅	✅	✅	n/a	n/a
runtime-13 - Installing a different GPU family while a runtime is active is refused without consent runtime-install-sdk-other-family-requires-yes	✅	✅	✅	✅	n/a	n/a
runtime-14 - Stating that the non-interactive consent flag does not approve sudo in --help runtime-install-sdk-help-separates-consents	✅	✅	✅	✅	✅	✅
runtime-15 - Disclosing the consent added to a natural-language install approved with --yes runtime-freeform-yes-discloses-injected-consent	✅	✅	✅	✅	✅	✅
runtime-16 - Reinstalling Lemonade reports whether its ROCm backend was aligned runtime-lemonade-backend-alignment-reported	❌FAIL	❌FAIL	❌FAIL	✅	n/a	n/a
runtime-17 - Opting out of the Lemonade backend alignment keeps the packaged pin runtime-lemonade-backend-alignment-opt-out	✅	✅	✅	✅	n/a	n/a
runtime-18 - A runtime-only SDK install serves vLLM inference runtime-install-sdk-serves-without-toolchain	✅	✅	n/a	n/a	n/a	n/a

Runtime lifecycle state machine

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
runtime-lifecycle-01 - Activating a runtime records where it changed from runtime-lifecycle-activate-records-previous	✅	✅	✅	✅	✅	✅
runtime-lifecycle-02 - Rolling back returns to the previously active runtime runtime-lifecycle-rollback-returns-to-previous	✅	✅	✅	✅	✅	✅
runtime-lifecycle-03 - Uninstalling an externally-sourced runtime keeps its folder runtime-lifecycle-uninstall-keeps-external-folder	✅	✅	✅	✅	✅	✅
runtime-lifecycle-04 - Uninstalling without --yes is refused outside a terminal runtime-lifecycle-uninstall-requires-yes-noninteractive	✅	✅	✅	✅	✅	✅
runtime-lifecycle-05 - Dry-running an uninstall makes no changes runtime-lifecycle-uninstall-dry-run	✅	✅	✅	✅	✅	✅
runtime-lifecycle-06 - Importing a runtime, then rejecting a duplicate unless replacing runtime-lifecycle-import-rejects-duplicate-unless-replacing	✅	✅	✅	✅	✅	✅
runtime-lifecycle-07 - Listing runtimes explains the active and rollback markers runtime-lifecycle-list-shows-marker-legend	✅	✅	✅	✅	✅	✅
runtime-lifecycle-08 - Re-selecting the runtime already in use keeps the rollback target runtime-lifecycle-reactivating-keeps-rollback-target	✅	✅	✅	✅	✅	✅
runtime-lifecycle-09 - A selector matching two runtimes only by letter case is refused with both named runtime-lifecycle-case-twin-selector-refused	✅	✅	✅	✅	✅	✅

System dependency installs preserve ROCm

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
deps-guard-01 - Installing a dependency never silently removes ROCm deps-guard-refuses-rocm-removal	✅	✅	✅	✅	✅	✅

The ROCm Doctor skill's instructions match the CLI they drive

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
skill-01 - Every remediation the skill documents is one the CLI still offers skill-catalog-ids-match-cli	✅	✅	✅	✅	✅	✅
skill-02 - The skill agrees with the CLI about which remediations the CLI will run itself skill-auto-fix-set-matches-cli	✅	✅	✅	✅	✅	✅
skill-03 - The skill agrees with the CLI about which machines each remediation applies to skill-os-scope-matches-cli	✅	✅	✅	✅	✅	✅
skill-04 - A diagnosis carries everything the skill tells an agent to read skill-diagnosis-matches-what-the-skill-documents	✅	✅	✅	✅	✅	✅
skill-05 - Inspecting the machine returns a verdict the skill documents skill-examine-verdicts-are-documented	✅	✅	✅	✅	✅	✅
skill-06 - The upstream tracker the CLI hands back is one the skill documents skill-escalation-target-matches-cli	✅	✅	✅	✅	✅	✅

TheRock "next" ROCm 10 install layout

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
therock-next-01 - An unpinned release install stays on the canonical multi-arch source therock-next-01-unpinned-release-stays-canonical	✅	✅	✅	✅	✅	✅
therock-next-02 - A pinned ROCm 10 wheel install resolves the next index with raw device extras therock-next-02-wheel-pins-raw-device-extras	✅	✅	✅	✅	✅	✅
therock-next-03 - A pinned ROCm 10 wheel install refuses a group family label therock-next-03-wheel-group-family-refused	✅	✅	✅	✅	✅	✅
therock-next-04 - A pinned ROCm 10 tarball install skips the tests sibling therock-next-04-tarball-skips-tests-sibling	✅	✅	✅	✅	✅	✅
therock-next-05 - A pinned ROCm 10 tarball install refuses a group family label therock-next-05-tarball-group-family-refused	✅	✅	✅	✅	✅	✅
therock-next-06 - A ROCm 10 source override is ignored without explicit trust therock-next-06-base-override-requires-opt-in	✅	✅	✅	✅	✅	✅
therock-next-07 - Installing the SDK from the live ROCm 10 preview source auto-detects the exact arch therock-next-07-live-install-auto-detects-arch	✅	✅	✅	✅	n/a	n/a
therock-next-08 - Updating a ROCm 10 wheel runtime resolves past its grouped family therock-next-08-update-apply-recovers-exact-arch-from-grouped-family	✅	✅	✅	✅	✅	✅
therock-next-09 - Installing vLLM against a live ROCm 10 preview runtime reports the discovery pins therock-next-09-live-install-reports-vllm-rocm10x-discovery-pins	✅	✅	n/a	n/a	n/a	n/a
therock-next-10 - A pinned ROCm 10 wheel install adds the toolchain when asked therock-next-09-wheel-devel-adds-the-toolchain	✅	✅	✅	✅	✅	✅

Update report

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
update-01 - The update report distinguishes configured from not-configured feeds update-report-distinguishes-feed-status	✅	✅	✅	✅	✅	✅
update-02 - The machine-readable update check reports an empty runtimes array update-json-reports-empty-runtimes	✅	✅	✅	✅	✅	✅
update-03 - The machine-readable update check accepts a --timeout-secs flag update-json-accepts-timeout-flag	✅	✅	✅	✅	✅	✅
update-04 - Previewing an update with --dry-run does not require --apply update-dry-run-reaches-preview-path-without-apply	✅	✅	✅	✅	✅	✅
update-05 - --runtime or --activate without --apply or --dry-run is refused update-runtime-or-activate-without-apply-or-dry-run-is-refused	✅	✅	✅	✅	✅	✅
update-06 - --dry-run and --json cannot be combined update-dry-run-conflicts-with-json	✅	✅	✅	✅	✅	✅

Working with GPU machines over a private network

Scenario	mi350p (release) vllm	mi300x (release) vllm	gfx1201 (release) lemonade	strix-halo-linux (release) lemonade	strix-halo-wsl (nightly) lemonade	strix-halo-wsl (release) lemonade
remote-01 - The user sees which machines could host a model remote-targets-lists-machines	✅	✅	✅	✅	✅	✅
remote-02 - The list can be narrowed to machines marked as GPU nodes remote-targets-tag-filter	✅	✅	✅	✅	✅	✅
remote-03 - A machine that is offline is still listed, marked offline remote-targets-offline-shown	✅	✅	✅	✅	✅	✅
remote-04 - Discovery explains itself when the private network is not connected remote-targets-not-connected	✅	✅	✅	✅	✅	✅
remote-05 - Serving refuses a machine that is not on the private network remote-serve-unknown-machine	✅	✅	✅	✅	✅	✅
remote-06 - Serving refuses an offline machine instead of waiting for it remote-serve-offline-machine	✅	✅	✅	✅	✅	✅
remote-07 - The user is told when they have no remote sessions remote-status-no-sessions	✅	✅	✅	✅	✅	✅
remote-08 - Stopping a session that does not exist is refused remote-stop-unknown-session	✅	✅	✅	✅	✅	✅
remote-09 - Checking a machine's health never installs anything on it remote-doctor-refuses-to-install	n/a	n/a	n/a	n/a	n/a	n/a
remote-10 - Serving a model on another machine gives back a usable endpoint remote-serve-publishes-endpoint	n/a	n/a	n/a	n/a	n/a	n/a
remote-11 - Status reports the model and the endpoint separately remote-status-reports-both-halves	n/a	n/a	n/a	n/a	n/a	n/a
remote-12 - An endpoint withdrawn behind the user's back is repairable remote-attach-restores-endpoint	n/a	n/a	n/a	n/a	n/a	n/a
remote-13 - Stopping a session leaves nothing running and nothing exposed remote-stop-clears-both	n/a	n/a	n/a	n/a	n/a	n/a
remote-14 - Checking a remote machine reports that machine's health remote-doctor-reports-remote-health	n/a	n/a	n/a	n/a	n/a	n/a

Needs attention

• unexpected failure on mi350p (release): runtime-lemonade-backend-alignment-reported [engine: lemonade]
• unexpected failure on mi350p (release): runtime-torch-alignment-opt-out [engine: vllm]
• unexpected failure on mi300x (release): runtime-lemonade-backend-alignment-reported [engine: lemonade]
• unexpected failure on mi300x (release): runtime-torch-alignment-opt-out [engine: vllm]
• unexpected failure on gfx1201 (release): runtime-lemonade-backend-alignment-reported [engine: lemonade]

Command coverage

CLI surface coverage: 33/49 commands (67%) exercised by at least one platform.

Which rocm commands are exercised, with which engine, per platform. ✅ ran and worked here · ❌ ran but did not work here · n/a not run on this platform — this row is a specific model/engine invocation and this platform serves a different one, or the command is not applicable to its GPU/OS/engine.

Command	Engine	MI300X Linux (release)	MI350P Linux (release)	R9700 Linux (release)	Strix Halo Ubuntu (release)	Strix Halo WSL2 (nightly)	Strix Halo WSL2 (release)
rocm	n/a	✅	✅	✅	✅	✅	✅
rocm --version	n/a	✅	✅	✅	✅	✅	✅
rocm --yes install the latest TheRock nightly for this GPU into /home/ubuntu/actions-runner/tmp/rocm-e2e-POXZeg/freeform-therock	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm --yes install the latest TheRock nightly for this GPU into /home/ubuntu/actions-runner/tmp/rocm-e2e-gz9xL3/freeform-therock	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm --yes install the latest TheRock nightly for this GPU into /tmp/rocm-e2e-1aQU46/freeform-therock	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm --yes install the latest TheRock nightly for this GPU into /tmp/rocm-e2e-1b5Fj4/freeform-therock	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm --yes install the latest TheRock nightly for this GPU into /tmp/rocm-e2e-4X86mi/freeform-therock	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm --yes install the latest TheRock nightly for this GPU into /tmp/rocm-e2e-K11Hty/freeform-therock	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm --yes install the latest TheRock nightly for this GPU into /tmp/rocm-e2e-l8SwJy/freeform-therock	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm --yes install the latest TheRock nightly for this GPU into /tmp/rocm-e2e-yKB2s9/freeform-therock	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm --yes install the latest TheRock nightly for this GPU into /tmp/rocm-e2e-zMq4L0/freeform-therock	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm -V	n/a	✅	✅	✅	✅	✅	✅
rocm automations disable therock-update	n/a	✅	✅	✅	✅	✅	✅
rocm automations enable e2e-no-such-watcher --mode observe	n/a	✅	✅	✅	✅	✅	✅
rocm automations enable therock-update --mode observe	n/a	✅	✅	✅	✅	✅	✅
rocm automations enable therock-update --mode propose	n/a	✅	✅	✅	✅	✅	✅
rocm bench load --endpoint http://127.0.0.1:11435/v1 --model Qwen/Qwen3.5-0.8B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	✅	✅	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:32769 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:32859/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:32889/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-tS5SpU/bench-results.csv	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:33633/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:33817/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /home/ubuntu/actions-runner/tmp/rocm-e2e-7gfQQB/bench-results.csv	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:33909/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /home/ubuntu/actions-runner/tmp/rocm-e2e-PQ5i5i/bench-results.csv	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:34215/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-0n31bM/bench-results.csv	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:34361/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm bench load --endpoint http://127.0.0.1:34883/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:35261/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:35363/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:35627 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:35671 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:36069 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm bench load --endpoint http://127.0.0.1:36537/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:37479/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm bench load --endpoint http://127.0.0.1:37563 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:37607/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-KIUEnB/bench-results.csv	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:37607/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-my6ttI/bench-results.csv	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm bench load --endpoint http://127.0.0.1:37617/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-hRFokp/bench-results.csv	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:38007/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:38069/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /home/ubuntu/actions-runner/tmp/rocm-e2e-KOydGb/bench-results.csv	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:38117 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:38457/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:38551/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-cK8HKg/bench-results.csv	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:38909/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:39181/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-vUmbPn/bench-results.csv	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm bench load --endpoint http://127.0.0.1:39339 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:39401/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-w7RNP1/bench-results.csv	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:39593 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm bench load --endpoint http://127.0.0.1:39647/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:40065/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:40975/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-A1a3SU/bench-results.csv	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm bench load --endpoint http://127.0.0.1:41319/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:42423/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-k4Qjjp/bench-results.csv	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:42569/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm bench load --endpoint http://127.0.0.1:42711 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:42921/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm bench load --endpoint http://127.0.0.1:43773/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:44369/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-djQfsh/bench-results.csv	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:44415/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-YY7UaZ/bench-results.csv	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:44777/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /home/ubuntu/actions-runner/tmp/rocm-e2e-bAkBkO/bench-results.csv	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:44915/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-EyLjwo/bench-results.csv	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm bench load --endpoint http://127.0.0.1:46475/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bench load --endpoint http://127.0.0.1:46479/v1 --model TestModel/E2E-1B --concurrency 1 --isl 8 --osl 4 --requests 2 --out /tmp/rocm-e2e-tcnNAK/bench-results.csv	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm bootstrap setup	n/a	✅	✅	✅	✅	✅	✅
rocm chat	n/a	✅	✅	✅	✅	✅	✅
rocm chat --chat-mock	n/a	✅	✅	✅	✅	✅	✅
rocm chat --provider local --model TestModel/E2E-1B	n/a	✅	✅	✅	✅	✅	✅
rocm chat --provider local --model TestModel/E2E-1B --prompt Hello	n/a	✅	✅	✅	✅	✅	✅
rocm comfyui install	n/a	✅	✅	✅	✅	✅	✅
rocm comfyui install --runtime-id e2e-comfyui-runtime	n/a	✅	✅	✅	✅	✅	✅
rocm config clear-default-engine	n/a	✅	✅	✅	✅	✅	✅
rocm config clear-default-runtime	n/a	✅	✅	✅	✅	✅	✅
rocm config disable-provider openai	n/a	✅	✅	✅	✅	✅	✅
rocm config enable-provider local	n/a	✅	✅	✅	✅	✅	✅
rocm config enable-provider openai	n/a	✅	✅	✅	✅	✅	✅
rocm config set-default-engine vllm	n/a	✅	✅	✅	✅	✅	✅
rocm config set-default-runtime therock-release:gfx942	n/a	✅	✅	✅	✅	✅	✅
rocm config set-engine vllm	n/a	✅	✅	✅	✅	✅	✅
rocm config set-engine vllm --runtime-id therock-release:gfx942	n/a	✅	✅	✅	✅	✅	✅
rocm config set-permissions ask	n/a	✅	✅	✅	✅	✅	✅
rocm config set-provider-key openai	n/a	✅	✅	✅	✅	✅	✅
rocm config set-telemetry off	n/a	✅	✅	✅	✅	✅	✅
rocm dash	n/a	✅	✅	✅	✅	✅	✅
rocm dash --demo	n/a	✅	✅	✅	✅	✅	✅
rocm dash --replay /home/ubuntu/actions-runner/tmp/rocm-cli-e2e-no-such-recording-eai-8366-264655.ndjson	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm dash --replay /home/ubuntu/actions-runner/tmp/rocm-cli-e2e-no-such-recording-eai-8366-276489.ndjson	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm dash --replay /tmp/rocm-cli-e2e-no-such-recording-eai-8366-1646.ndjson	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm dash --replay /tmp/rocm-cli-e2e-no-such-recording-eai-8366-1870.ndjson	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm dash --replay /tmp/rocm-cli-e2e-no-such-recording-eai-8366-21734.ndjson	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm dash --replay /tmp/rocm-cli-e2e-no-such-recording-eai-8366-21885.ndjson	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm dash --replay /tmp/rocm-cli-e2e-no-such-recording-eai-8366-2292.ndjson	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm dash --replay /tmp/rocm-cli-e2e-no-such-recording-eai-8366-3068638.ndjson	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm dash --replay /tmp/rocm-cli-e2e-no-such-recording-eai-8366-3099978.ndjson	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm diagnose --distro rocm-cli-e2e-no-such-distro	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --model e2e-fixtures/not-a-curated-model --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --model e2e-fixtures/ram-degraded --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --model glm5	n/a	✅	✅	✅	n/a	n/a	n/a
rocm diagnose --model glm5 --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --model qwen-smoke --distro	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --model qwen-smoke --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --report	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --report --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --report --send	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --send	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --symptom Downloading shards: 10%Evllm serve starting upEDownloading shards: 90%Ellama.cpp: torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 7.21 GiB.E --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --symptom HSA_STATUS_ERROR_INVALID_ISA	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --symptom HSA_STATUS_ERROR_INVALID_ISA --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --symptom the office printer keeps jamming on page three --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --symptom vllm engine fails to start: OSError: libtorch_cuda.so: cannot open shared object file --json	n/a	✅	✅	✅	✅	n/a	n/a
rocm diagnose --symptom vllm: torch.OutOfMemoryError: HIP out of memory. Tried to allocate 7.21 GiB. --json	n/a	✅	✅	✅	✅	✅	✅
rocm diagnose --symptom xyzzy totally unrelated gibberish --json	n/a	✅	✅	✅	✅	✅	✅
rocm engines install lemonade --reinstall	n/a	❌	❌	❌	✅	n/a	n/a
rocm engines install vllm --reinstall --yes	n/a	✅	✅	n/a	n/a	n/a	n/a
rocm engines install vllm --runtime-id therock-release-gfx94X-dcgpu-e2e-guard --yes	n/a	✅	✅	✅	✅	✅	✅
rocm engines list	n/a	❌	❌	✅	✅	✅	✅
rocm engines shell vllm --env-id e2e-shell --shell /bin/bash	n/a	✅	✅	✅	✅	✅	✅
rocm examine	n/a	❌	❌	❌	❌	❌	❌
rocm examine --framework skip --json	n/a	✅	✅	✅	✅	n/a	n/a
rocm examine --json	n/a	✅	✅	✅	✅	❌	❌
rocm fix	n/a	✅	✅	✅	✅	✅	✅
rocm fix #1	n/a	✅	✅	✅	✅	✅	✅
rocm fix --json	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-1-arch --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-1-arch --json	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-13-hip-sdk-missing	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-16-vllm-oom	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-17-torch-dlpack --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-18-comgr-conflict	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-4-render-group --dry-run	n/a	✅	✅	✅	✅	n/a	n/a
rocm fix fix-4-render-group --yes	n/a	✅	✅	✅	✅	n/a	n/a
rocm fix fix-9-igpu-dgpu	n/a	✅	✅	✅	✅	n/a	n/a
rocm fix fix-9-igpu-dgpu --device-index 1	n/a	✅	✅	✅	✅	n/a	n/a
rocm fix fix-does-not-exist	n/a	✅	✅	✅	✅	✅	✅
rocm fix fix-wsl-6-host-driver-too-old	n/a	n/a	n/a	n/a	n/a	✅	✅
rocm help	n/a	✅	✅	✅	✅	✅	✅
rocm install driver	n/a	n/a	n/a	n/a	n/a	✅	✅
rocm install driver --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk	n/a	✅	✅	✅	✅	n/a	n/a
rocm install sdk --channel nightly --family gfx120X-all --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format tarball --family gfx1200 --version 10.0.0 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format tarball --family gfx120X-all --version 10.0.0 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format tarball --family gfx120X-all --yes	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format wheel --family gfx1200 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format wheel --family gfx1200 --version 10.0.0 --devel --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format wheel --family gfx1200 --version 10.0.0 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format wheel --family gfx1200 --version 10.1.0 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format wheel --family gfx120X-all --version 10.0.0 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --channel release --format wheel --version 10.1.0	n/a	✅	✅	✅	✅	n/a	n/a
rocm install sdk --family gfx110X-all --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --format tarball --family gfx110X-all	n/a	✅	✅	✅	✅	n/a	n/a
rocm install sdk --help	n/a	✅	✅	✅	✅	✅	✅
rocm install sdk --yes	n/a	❌	❌	✅	✅	n/a	n/a
rocm logs --search E2ENEEDLE	n/a	✅	✅	✅	✅	✅	✅
rocm logs --search e2e-no-such-term	n/a	✅	✅	✅	✅	✅	✅
rocm logs --service some-service --search E2ENEEDLE	n/a	✅	✅	✅	✅	✅	✅
rocm remote serve gpu-box some-model	n/a	✅	✅	✅	✅	✅	✅
rocm remote serve not-a-machine some-model	n/a	✅	✅	✅	✅	✅	✅
rocm remote status	n/a	✅	✅	✅	✅	✅	✅
rocm remote stop no-such-session	n/a	✅	✅	✅	✅	✅	✅
rocm remote targets	n/a	✅	✅	✅	✅	✅	✅
rocm remote targets --tag gpu	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes activate RELEASE-TARBALL-GFX942	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes activate Release-Tarball-Gfx942	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes activate release-tarball-gfx1100	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes activate release-tarball-gfx942	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes activate release-wheel-multi-arch-7-14-1-7219e4967df5fe32	n/a	❌	n/a	n/a	n/a	n/a	n/a
rocm runtimes activate release-wheel-multi-arch-7-14-1-b6d97739ec8402ce	n/a	n/a	n/a	❌	n/a	n/a	n/a
rocm runtimes activate release-wheel-multi-arch-7-14-1-c5b320fc0dfcf233	n/a	n/a	❌	n/a	n/a	n/a	n/a
rocm runtimes activate release-wheel-multi-arch-7-14-1-f1ec7c6b4e815e9f	n/a	n/a	n/a	n/a	❌	n/a	n/a
rocm runtimes adopt --python /usr/bin/python3 --root /opt/rocm	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes import /home/ubuntu/actions-runner/tmp/rocm-e2e-QLubdH/import-manifest.json	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm runtimes import /home/ubuntu/actions-runner/tmp/rocm-e2e-QLubdH/import-manifest.json --replace	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm runtimes import /home/ubuntu/actions-runner/tmp/rocm-e2e-sMireJ/import-manifest.json	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm runtimes import /home/ubuntu/actions-runner/tmp/rocm-e2e-sMireJ/import-manifest.json --replace	n/a	n/a	n/a	n/a	✅	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-CWZVvm/import-manifest.json	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-CWZVvm/import-manifest.json --replace	n/a	n/a	✅	n/a	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-KMi2NM/import-manifest.json	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm runtimes import /tmp/rocm-e2e-KMi2NM/import-manifest.json --replace	n/a	n/a	n/a	n/a	n/a	n/a	✅
rocm runtimes import /tmp/rocm-e2e-UAauJ2/import-manifest.json	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-UAauJ2/import-manifest.json --replace	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-iUUHWU/import-manifest.json	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-iUUHWU/import-manifest.json --replace	n/a	✅	n/a	n/a	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-j8O0W8/import-manifest.json	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-j8O0W8/import-manifest.json --replace	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-r4Uy2t/import-manifest.json	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-r4Uy2t/import-manifest.json --replace	n/a	n/a	n/a	✅	n/a	n/a	n/a
rocm runtimes import /tmp/rocm-e2e-spSQr5/import-manifest.json	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm runtimes import /tmp/rocm-e2e-spSQr5/import-manifest.json --replace	n/a	n/a	n/a	n/a	n/a	✅	n/a
rocm runtimes list	n/a	❌	❌	❌	❌	✅	✅
rocm runtimes rollback	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes rollback --help	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes uninstall release-tarball-gfx942	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes uninstall release-tarball-gfx942 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm runtimes uninstall release-tarball-gfx942 --yes	n/a	✅	✅	✅	✅	✅	✅
rocm serve Qwen/Qwen2.5-0.5B-Instruct --engine vllm --gpu 0 --managed	vllm	✅	✅	n/a	n/a	n/a	n/a
rocm serve Qwen/Qwen2.5-0.5B-Instruct --managed	vllm (default)	✅	✅	n/a	n/a	n/a	n/a
rocm serve Qwen/Qwen3.5-0.8B --engine vllm	vllm	✅	✅	n/a	n/a	n/a	n/a
rocm serve Qwen/Qwen3.5-0.8B --engine vllm --gpu 1	vllm	✅	✅	n/a	n/a	n/a	n/a
rocm serve Qwen/Qwen3.5-0.8B --engine vllm --gpu 99	vllm	✅	✅	n/a	n/a	n/a	n/a
rocm serve Qwen/Qwen3.5-0.8B --engine vllm --managed	vllm	❌	❌	n/a	n/a	n/a	n/a
rocm serve Qwen/Qwen3.6-27B --engine vllm --managed	vllm	✅	✅	n/a	n/a	n/a	n/a
rocm serve Qwen3-0.6B-GGUF --engine lemonade	lemonade	n/a	n/a	✅	✅	✅	✅
rocm serve Qwen3-0.6B-GGUF --engine lemonade --gpu 1	lemonade	n/a	n/a	✅	✅	n/a	n/a
rocm serve Qwen3-0.6B-GGUF --engine lemonade --gpu 99	lemonade	n/a	n/a	✅	✅	n/a	n/a
rocm serve Qwen3-0.6B-GGUF --engine lemonade --managed	lemonade	❌	❌	❌	❌	✅	✅
rocm serve qwen2.5 --engine lemonade	lemonade	❌	❌	❌	❌	❌	❌
rocm serve qwen2.5 --engine vllm	vllm	❌	❌	❌	❌	❌	❌
rocm serve sampling-check-model --temperature -1	n/a	✅	✅	✅	✅	✅	✅
rocm serve some-model --host 0.0.0.0	n/a	✅	✅	✅	✅	✅	✅
rocm serve some-model --runtime-id therock-release:gfx942 --env-id some-env	n/a	✅	✅	✅	✅	✅	✅
rocm serve unsloth/Qwen3-0.6B-GGUF:Q4_0 --engine lemonade --managed	lemonade	✅	✅	✅	✅	n/a	n/a
rocm serve unsloth/Qwen3.6-35B-A3B-GGUF:UD-Q4_K_XL --engine lemonade --managed	lemonade	n/a	n/a	✅	✅	n/a	n/a
rocm services list	n/a	✅	✅	✅	✅	✅	✅
rocm services list --all	n/a	✅	✅	✅	✅	✅	✅
rocm services prune --any-age --yes	n/a	✅	✅	✅	✅	✅	✅
rocm services prune --older-than-hours 0 --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm services prune --older-than-hours 0 --yes	n/a	✅	✅	✅	✅	✅	✅
rocm services prune --yes	n/a	✅	✅	✅	✅	✅	✅
rocm services remove vllm-e2e-cleanup --yes	n/a	✅	✅	✅	✅	✅	✅
rocm storage report	n/a	✅	✅	✅	✅	✅	✅
rocm update	n/a	✅	✅	✅	✅	✅	✅
rocm update --apply --dry-run --runtime release-wheel-next-v1-gfx120x-all-9-0-0	n/a	✅	✅	✅	✅	✅	✅
rocm update --dry-run	n/a	✅	✅	✅	✅	✅	✅
rocm update --dry-run --json	n/a	✅	✅	✅	✅	✅	✅
rocm update --json	n/a	✅	✅	✅	✅	✅	✅
rocm update --json --timeout-secs 5	n/a	✅	✅	✅	✅	✅	✅
rocm update --runtime some-runtime	n/a	✅	✅	✅	✅	✅	✅
rocm version	n/a	✅	✅	✅	✅	✅	✅

Uncovered commands (16)

• rocm remote doctor
• rocm remote attach
• rocm setup status
• rocm setup reset
• rocm model
• rocm comfyui status
• rocm comfyui start
• rocm comfyui stop
• rocm comfyui logs
• rocm comfyui models-path
• rocm services logs
• rocm services stop
• rocm services restart
• rocm automations list
• rocm config show
• rocm uninstall

Scenario reference

Artifact prefetch cleanup

artifact-prefetch-failed-marker-leaves-no-temp

artifact-prefetch-01 - A failed artifact cache write leaves no temporary marker

• Given a signed direct-download artifact fixture
• And its cache marker destination is occupied by a directory
• When the user approves the artifact prefetch
• Then the artifact download completes before marker publication fails
• And no temporary cache marker is left behind
• And the occupied cache marker destination remains unchanged

Automation watchers

automations-enable-confirms-mode

automations-01 - Enabling a watcher confirms its mode

• Given a fresh CLI configuration
• When the user enables an automation watcher in observe mode
• Then the CLI confirms the watcher is enabled in observe mode
• When the user re-enables the same watcher in propose mode
• Then the CLI confirms the watcher is enabled in propose mode

automations-disable-confirmed

automations-02 - Disabling a watcher is confirmed

• Given an enabled automation watcher
• When the user disables the watcher
• Then the CLI confirms the watcher is disabled

automations-enable-unknown-refused

automations-03 - Enabling an unknown watcher is refused

• Given a fresh CLI configuration
• When the user tries to enable a watcher that does not exist
• Then the CLI refuses and names it as unknown

automations-autostart-defers-during-spawn-window

automations-04 - Enabling during an in-flight daemon spawn starts no second daemon

• Given a daemon spawn is already in flight
• When the user enables an automation watcher in observe mode
• Then the CLI does not start a second background daemon

Benchmarking a served endpoint

bench-load-reports-throughput

bench-01 - Benchmarking a running server reports measured throughput

• Given a model is being served
• When the user benchmarks the served endpoint
• Then the benchmark reports measured throughput
• And the benchmark requests reached the versioned chat route

bench-load-accepts-plain-address

bench-02 - A plain host address is accepted and still reaches the server

• Given a model is being served
• When the user benchmarks the server using its plain host address
• Then the benchmark reports measured throughput
• And the benchmark requests reached the versioned chat route

bench-load-surfaces-failures

bench-03 - A benchmark whose every request is rejected fails loudly

• Given an endpoint that rejects every request
• When the user benchmarks the served endpoint
• Then the benchmark reports that the requests failed
• And the benchmark does not report a successful run

bench-load-records-engine-and-tpot

bench-04 - The recorded CSV row carries the engine and per-output-token latency

• Given a model is being served with a metrics endpoint
• When the user benchmarks the served endpoint recording results to a file
• Then the recorded benchmark row is labelled the vLLM engine with a per-output-token latency

bench-load-warns-on-engine-split

bench-05 - Appending over results that predate the engine column warns about the split

• Given a model is being served with a metrics endpoint
• And earlier results for the same cell were recorded without an engine
• When the user benchmarks the served endpoint recording results to a file
• Then the benchmark warns that the earlier rows group separately

bench-load-real-serve

bench-06 - Benchmarking a really served model reports throughput

• Given a managed runtime is active
• And a model is being served on GPU
• When the user benchmarks the served endpoint
• Then the benchmark reports measured throughput

Chat and endpoint detection

chat-served-model-discoverable

chat-01 - A served model is discoverable through the services list

• Given a model is being served
• And the model is registered with the CLI
• When the user checks for running services
• Then the served model is listed

chat-privacy-notice-accurate

chat-02 - The privacy notice is shown before using a local endpoint

• Given a model is being served locally
• And the model is registered with the CLI
• When the user opens interactive chat
• Then the local endpoint is shown for confirmation
• And the privacy notice is shown before any message is sent
• When the user quits interactive chat
• Then interactive chat exits successfully

chat-managed-model-interactive

chat-03 - Interactive chat uses a running managed model

• Given a running managed model is available locally
• When the user opens interactive chat
• Then the local endpoint is shown for confirmation
• When the user accepts the local endpoint
• And the user sends a message to the managed model
• Then the managed model's response is displayed
• And the mock received the typed prompt
• When the user quits interactive chat
• Then interactive chat exits successfully

chat-assistant-is-told-which-machine-it-is-on

chat-04 - The assistant is told what machine it is running on

• Given a running managed model is available locally
• When the user opens interactive chat
• Then the local endpoint is shown for confirmation
• When the user accepts the local endpoint
• And the user sends a message to the managed model
• Then the assistant is told which operating system this machine runs
• And the assistant is told which GPU this machine has
• When the user quits interactive chat
• Then interactive chat exits successfully

chat-endpoint-shown-in-services

chat-05 - A served model's endpoint is shown in the services list

• Given a model is being served
• And the model is registered with the CLI
• When the user lists running services
• Then the served model endpoint is listed

chat-tool-definitions-accepted

chat-06 - Chat requests that include tool definitions are accepted

• Given a managed runtime is active
• And a model is served in the background
• When a chat request with tool definitions is sent
• Then the chat response is successful

chat-end-to-end-local-model

chat-07 - End-to-end chat through a locally served model

• Given a managed runtime is active
• And a model is served in the background
• And the served model has been detected
• When the user sends a chat message
• Then the chat response is successful
• And the response contains a model-generated reply

chat-cli-oneshot-prompt

chat-08 - The chat CLI answers a one-shot prompt against a local server

• Given a model is being served
• And the model is registered with the CLI
• When the user sends a one-shot chat prompt through the CLI
• Then the CLI prints the assistant's reply

chat-cli-stdin-prompt

chat-09 - The chat CLI reads a one-shot prompt from stdin

• Given a model is being served
• And the model is registered with the CLI
• When the user pipes a one-shot chat prompt through the CLI
• Then the CLI prints the assistant's reply
• And the model receives the piped prompt with its whitespace intact

ComfyUI install reports progress and makes failures actionable

comfyui-uv-install-failure-names-log

comfyui-01 - A failed dependency install names the log it wrote

• Given a ready ROCm runtime with a ComfyUI checkout pending dependencies
• And the ComfyUI dependency install with uv fails
• When the user installs ComfyUI
• Then the CLI fails and names the install log it wrote

comfyui-uv-install-progress-streamed

comfyui-02 - A dependency install streams progress output

• Given a ready ROCm runtime with a ComfyUI checkout pending dependencies
• And the ComfyUI dependency install with uv prints progress and succeeds
• When the user installs ComfyUI
• Then the CLI succeeds and shows the install progress

comfyui-ambiguous-runtime-actionable

comfyui-03 - ComfyUI install refuses an ambiguous runtime choice and names every remediation

• Given two ready ROCm runtimes and no active default
• When the user installs ComfyUI without choosing a runtime
• Then ComfyUI install is refused as ambiguous
• And the refusal offers the /runtimes picker
• And the refusal names the --runtime-id flag
• And the refusal names rocm runtimes activate
• And the refusal lists both runtime keys

comfyui-source-download-shows-live-progress

comfyui-04 - The source-archive download spinner renders progress and clears on completion

• Given a paced ComfyUI source archive fixture
• When the user installs ComfyUI under a real terminal
• Then the terminal shows an intermediate ComfyUI download progress frame
• And the ComfyUI install exits cleanly
• And the final terminal screen shows no ComfyUI download spinner line

Configuration mutations

config-default-engine-set-and-cleared

config-01 - Setting and clearing the default engine is confirmed

• Given a fresh CLI configuration
• When the user sets the default engine
• Then the CLI confirms the default engine was set
• When the user clears the default engine
• Then the CLI confirms the default engine was cleared

config-default-runtime-set-and-cleared

config-02 - Setting and clearing the default runtime is confirmed

• Given a fresh CLI configuration
• When the user sets the default runtime
• Then the CLI confirms the default runtime was set
• When the user clears the default runtime
• Then the CLI confirms the default runtime was cleared

config-telemetry-mode-confirmed

config-03 - Choosing a telemetry mode is confirmed with its policy

• Given a fresh CLI configuration
• When the user turns telemetry off
• Then the CLI confirms the telemetry mode and states the policy

config-permissions-mode-confirmed

config-04 - Choosing a permissions mode is confirmed

• Given a fresh CLI configuration
• When the user selects a permissions mode
• Then the CLI confirms the permissions mode

config-set-engine-requires-target

config-05 - Configuring an engine requires a target

• Given a fresh CLI configuration
• When the user configures an engine without saying what to change
• Then the CLI refuses and explains a target is required
• When the user configures an engine with a runtime to use
• Then the CLI confirms the engine configuration was updated

config-provider-enable-disable

config-06 - Enabling and disabling a cloud provider is confirmed

• Given a fresh CLI configuration
• When the user enables a cloud provider
• Then the CLI confirms the provider is enabled for prompt sending
• When the user disables that provider
• Then the CLI confirms the provider is disabled

config-local-provider-not-toggleable

config-07 - The always-on local provider cannot be toggled as a cloud provider

• Given a fresh CLI configuration
• When the user tries to enable the local provider
• Then the CLI refuses and explains the local provider is always enabled

config-provider-key-no-secret-storage

config-08 - Saving a provider key without secure storage fails without leaking the key

• Given a machine with no secure secret storage
• When the user saves a provider API key
• Then the CLI reports it could not save the key securely
• And the key value never appears in the output

Diagnosing failures and listing fixes

diagnose-matches-known-symptom

diagnose-01 - Diagnosing a recognised failure reports a likely cause and a fix

• Given a user who hit a known ROCm failure
• When the user asks the CLI to diagnose that symptom
• Then the CLI reports a likely cause with a suggested fix
• And every reported cause comes with a command that applies it
• And every reported cause states its remediation flags

diagnose-always-offers-a-way-forward

diagnose-02 - Diagnosing any failure always gives the user a way to escalate

• Given a user who hit a failure the CLI does not recognise
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then the CLI always points to somewhere the problem can be reported

diagnose-json-has-match-flag

diagnose-03 - A diagnosis is available in machine-readable form for tooling

• Given a user who hit a known ROCm failure
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then the result is machine-readable and identifies the matched cause

diagnose-fix-lists-known-recipes

diagnose-04 - The user can see every fix the CLI knows how to apply

• When the user asks the CLI which fixes it offers
• Then the CLI lists the fixes it can apply
• And each fix indicates whether the CLI can apply it automatically
• And the listing explains what those indicators mean

diagnose-fix-dry-run-changes-nothing

diagnose-05 - Previewing a fix explains the change without making it

• Given a user who has chosen a known fix
• When the user previews that fix without applying it
• Then the CLI describes what the fix would change
• And nothing on the machine is changed
• And the preview states plainly that this fix is manual only

diagnose-fix-unknown-id-rejected

diagnose-06 - Asking for a fix the CLI does not know is refused clearly

• Given a user who names a fix the CLI does not offer
• When the user asks the CLI to apply that fix
• Then the CLI refuses and explains that the fix is not recognised

diagnose-fix-position-argument-rejected

diagnose-07 - Asking for a fix by its position in the diagnosis is corrected

• Given a user who refers to a cause by its position in the diagnosis
• When the user asks the CLI to apply that fix
• Then the CLI refuses and explains that a position is not a fix-id

diagnose-fix-requires-agreement-before-changing-anything

diagnose-08 - A fix that changes the machine is not applied without agreement

• Given a user who has chosen a fix that would change the machine
• When the user asks the CLI to apply it without agreeing to the change
• Then the CLI refuses and explains that it needs agreement
• And the file the fix would have changed is untouched

diagnose-json-states-when-nothing-matched

diagnose-09 - A tool is told plainly when no cause was established

• Given a user who hit a failure the CLI does not recognise
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then the result states that no cause was established
• And the CLI always points to somewhere the problem can be reported

diagnose-states-whether-the-platform-is-covered

diagnose-10 - A platform the catalog does not cover says so and routes onward

• Given a user who hit a known ROCm failure
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then the result says whether this platform is covered
• And a platform that is not covered is given no diagnosis
• And a platform that is covered gets a verdict that follows the evidence
• And the CLI always points to somewhere the problem can be reported

diagnose-fix-inapplicable-here-is-declined-not-attempted

diagnose-11 - A fix meant for another operating system is declined, not attempted

• Given a user who has chosen a fix meant for a different operating system
• When the user asks the CLI to apply that fix
• Then the CLI declines because the fix does not apply to this machine
• And nothing on the machine is changed

diagnose-fix-catalog-is-complete

diagnose-12 - The CLI offers every fix its catalog documents

• When the user asks the CLI which fixes it offers
• Then every fix the catalog documents is listed
• And only the fixes the CLI can carry out itself are marked as such

diagnose-recognises-the-engine-import-failure

diagnose-13 - A vLLM engine-startup import failure is recognised from its error text

• Given a user who hit the vLLM engine-startup import failure
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then the CLI reports the engine-startup import failure as an established cause

diagnose-fix-says-which-shell-each-step-runs-in

diagnose-14 - A fix whose steps span two shells says which shell each step runs in

• Given a user who has chosen the fix for the engine-startup import failure
• When the user previews that fix without applying it
• Then the printed plan says which shell each step runs in

diagnose-fix-command-failure-reported-on-stderr

diagnose-15 - A fix whose helper command fails explains why, on stderr, with exit code 4

• Given a user who has approved a fix whose helper command will fail
• When the user asks the CLI to apply the approved fix
• Then the CLI reports the command failure on stderr with exit code 4

diagnose-fix-interactive-decline-reported

diagnose-16 - Declining the confirmation prompt on a real terminal is reported the same way

• Given a user who has chosen a fix that would change the machine
• When the user is asked interactively to apply it and types no
• Then the CLI declines on the terminal and explains that it needs agreement
• And the file the fix would have changed is untouched

diagnose-wsl-never-reports-bare-metal-causes

diagnose-17 - A WSL machine is never given a bare-metal cause

• Given a user who hit a known ROCm failure
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then no reported cause is one that only exists on bare-metal Linux
• And the result says this platform is covered

diagnose-wsl-fix-is-explained-not-attempted

diagnose-18 - A WSL remedy is explained rather than carried out

• Given a user who has chosen a WSL remedy that belongs on the Windows host
• When the user asks the CLI to apply that fix
• Then the CLI explains the remedy instead of carrying it out
• And nothing on the machine is changed

diagnose-unreachable-machine-is-refused-not-substituted

diagnose-19 - Asking about a machine that cannot be reached is refused, not substituted

• Given a user who asks to diagnose a machine that does not exist
• When the user asks the CLI to diagnose that machine
• Then the CLI refuses and explains that it could not reach that machine
• And no diagnosis of this machine is reported

diagnose-fix-preview-states-required-flags

diagnose-20 - Previewing a fix that needs sudo and a re-login says so, and that it's auto-applicable here

• Given a user who has chosen a fix that needs sudo and a re-login
• When the user previews that fix without applying it
• Then the preview states that the fix requires sudo and a re-login
• And the preview states that the CLI can run it automatically

diagnose-model-too-large-is-refused-with-something-that-fits

diagnose-21 - A model this machine cannot serve is refused before anything is downloaded

• Given a user asking about a model no single machine could serve
• When the user asks the CLI whether that model would run, in machine-readable form
• Then the model is never reported as ready
• And a machine that measured its GPU is told the model will not run, and what would
• And a machine that could not measure its GPU is told why, rather than that the model is incompatible
• And the human-readable answer names what would run instead
• And no model weights were fetched

diagnose-model-that-fits-is-ready-and-names-the-engine

diagnose-22 - A model this machine can serve is reported ready, with the engine that would serve it

• Given a user asking about the smallest curated model
• When the user asks the CLI whether that model would run, in machine-readable form
• Then a machine with enough measured GPU memory is told the model is ready
• And the answer names the engine that would serve it
• And a machine that could not measure its GPU is told why, rather than that the model is incompatible

diagnose-model-unreachable-catalog-is-not-an-incompatible-model

diagnose-23 - A recipe catalog that cannot be read is not reported as an incompatible model

• Given a machine that cannot reach the model recipe catalog
• When the user asks the CLI whether that model would run, in machine-readable form
• Then the CLI reports that it could not determine the answer
• And the reason given is the unreachable catalog, not the model
• And nothing is claimed about whether the model fits this machine

diagnose-model-not-curated-is-undetermined-not-blocked

diagnose-24 - A model outside the curated catalog is undetermined, not blocked

• Given a user asking about a model the curated catalog does not carry
• When the user asks the CLI whether that model would run, in machine-readable form
• Then the CLI reports that it could not determine the answer
• And the reason given is that the model is not curated, not that it does not fit
• And nothing is claimed about whether the model fits this machine

diagnose-model-below-recommended-ram-is-degraded-not-blocked

diagnose-25 - A model that runs below its recommended system RAM is degraded, not blocked

• Given a user asking about a model that recommends far more system RAM than this host has
• When the user asks the CLI whether that model would run, in machine-readable form
• Then a machine with enough measured GPU memory to run it is told the model is degraded
• And a machine that could not measure its GPU is told why, rather than that the model is incompatible

diagnose-model-with-distro-is-refused-not-answered-for-the-local-host

diagnose-26 - Asking --model with --distro is refused before answering for the wrong machine

• Given a user who asks --model together with --distro
• When the user asks the CLI to diagnose with both flags
• Then the CLI refuses and says --model answers for this machine, not the one --distro names
• And no model verdict is reported

diagnose-fix-applicability-is-per-machine

diagnose-27 - A fix that only explains itself here is not advertised as one the CLI will run

• Given a fix the CLI carries out on one kind of machine and only explains on another
• When the user asks the CLI which fixes it offers
• Then that fix is shown as what it does on this machine

diagnose-fix-needing-an-argument-says-so

diagnose-28 - A fix that needs more information says what it needs and changes nothing

• Given a user who has chosen a fix that cannot run until it is told what to act on
• When the user asks the CLI to apply it without saying what to act on
• Then the CLI names what it still needs and reports no change

diagnose-report-is-shown-and-not-sent

diagnose-29 - Asking what a report would say shows it and sends nothing

• When the user asks the CLI what a report would carry
• Then the CLI either shows the whole report or says why it will not prepare one
• And the CLI states that nothing has been sent

diagnose-report-carries-no-identifying-detail

diagnose-30 - What a report would carry never identifies the machine

• When the user asks the CLI what a report would carry in machine-readable form
• Then the answer names no user, no host, and no file path

diagnose-send-without-report-is-refused

diagnose-31 - Asking the CLI for a way to send a report, without asking to see it first, is refused

• When the user asks the CLI for a way to send a report, without asking to see the report first
• Then the CLI refuses and explains that the report must be requested too

diagnose-send-on-a-headless-machine-prints-instead-of-opening

diagnose-32 - Asking to send on a machine with no desktop prints the address and a link instead of starting a mail client

• When the user asks the CLI for a way to send a report, with no desktop available to open it on
• Then the CLI either shows the whole report or says why it will not prepare one
• And the CLI states that nothing has been sent
• And the CLI prints the address to mail and a link, and starts nothing

diagnose-fix-comgr-conflict-is-advisory-only

diagnose-33 - The fix for a shadowed compilation library changes nothing and recommends nothing

• Given a user who has chosen the fix for a shadowed compilation library
• When the user asks the CLI to apply that fix
• Then the CLI explains that it will not make the change itself
• And the CLI offers both options without ranking them

diagnose-fix-catalog-is-machine-readable

diagnose-34 - A tool can read the catalog without parsing prose

• When a tool asks the CLI for its catalog in machine-readable form
• Then the catalog names every entry and what the CLI does with each
• And it gives the meaning of every exit code the CLI can return

diagnose-fix-catalog-json-rejects-a-fix-id

diagnose-35 - Asking to apply one fix in machine-readable form is refused

• Given a user who has chosen a known fix
• When the user asks the CLI to apply that fix in machine-readable form
• Then the CLI refuses and explains that the two cannot be combined

diagnose-vllm-oom-is-conditional

diagnose-36 - A vLLM startup OOM receives conditional remediation

• Given a user whose vLLM server ran out of GPU memory
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then the diagnosis identifies the vLLM startup OOM
• And the OOM remedy distinguishes a busy GPU from a model that does not fit
• And the CLI can act on the fix the diagnosis named

diagnose-vllm-oom-not-attributed-across-rendered-lines

diagnose-37 - Another engine's OOM is not blamed on a vLLM mention elsewhere in the paste

• Given a user who pasted a capture naming vLLM and another engine's OOM on separate rendered lines
• When the user asks the CLI to diagnose that symptom in machine-readable form
• Then no vLLM startup OOM is reported

Download-progress spinner under a real terminal

download-progress-linux-tarball-install-shows-live-progress

download-progress-01 - The tarball download spinner renders progress and clears on completion

• Given a paced canonical release tarball fixture
• When the user installs the tarball SDK for family gfx120X-all under a real terminal
• Then the terminal shows an intermediate download progress frame
• And the terminal shows the archive being extracted
• And the tarball install exits cleanly
• And the final terminal screen shows neither spinner line

Driver installation planning

driver-install-wsl-dry-run-plan

driver-install-01 - Previewing the WSL driver install produces an actionable packaged plan

• When the user previews driver installation on this WSL host
• Then the driver plan is supported and mutating
• And the dry-run driver plan requires no approval and previews no execution
• And the driver plan verifies the download before installing it
• And the driver plan does not direct the user to the removed WSL setup script

driver-install-wsl-review-requires-approval

driver-install-02 - Reviewing the WSL driver install requires approval before execution

• When the user reviews driver installation on this WSL host without approval
• Then the unapproved WSL driver plan is actionable but not executed
• And the driver plan does not direct the user to the removed WSL setup script

driver-install-wsl-unverified-release-refused

driver-install-03 - Installing a ROCDXG release with no known digest is refused

• When the user previews driver installation for a ROCDXG release with no known digest
• Then the driver plan refuses rather than installing an unverified package

Engine shell

engine-shell-marks-the-prompt

engine-shell-01 - Entering an engine shell is visibly different from the shell you left

• Given a machine with an installed engine environment
• When the user opens a shell for that engine
• Then the shell is visibly marked as that engine's shell
• And the engine environment's interpreter is the one that runs
• When the user leaves the engine shell
• Then the engine shell exits successfully

GPU detection and system inspection

examine-version

examine-01 - The CLI reports its version

• When the user asks for the version through every CLI surface
• Then matching traceable version strings are returned

examine-engines-list

examine-02 - The CLI lists all supported engines

• When the user lists available engines
• Then all supported engines are listed

examine-help-lists-subcommands-alphabetically

examine-03 - The help output lists subcommands in alphabetical order

• When the user asks for help
• Then the subcommands are listed in alphabetical order

examine-detects-gpu-and-driver

examine-04 - System inspection detects the GPU and driver

• Given a machine with an AMD GPU
• When the user inspects the system
• Then the inspection reports which GPU is installed
• And the inspection names the GPU target that the kernel reports
• And the inspection reports that the driver is available

examine-reports-host-default-engine

examine-05 - System inspection names the engine this machine serves on

• When the user inspects the system
• Then the inspection names the engine this host serves on by default

examine-distinguishes-unmanaged-rocm

examine-06 - System inspection distinguishes CLI-managed from pre-existing ROCm

• Given a machine with a ROCm install that was not set up by the CLI
• When the user inspects the system
• Then the inspection reports the install as pre-existing
• And the inspection names that install's version
• And the inspection does not claim nothing is installed
• And the inspection suggests setting up a CLI-managed install

examine-machine-readable-report

examine-07 - What the inspection tells a tool matches what it tells a person

• When the user inspects the system both for reading and for scripting
• Then the machine-readable form states everything the readable one does

examine-both-forms-agree-on-gpu

examine-08 - Both forms of the inspection agree about the GPU

• When the user inspects the system both for reading and for scripting
• Then both reports agree on whether this machine has an AMD GPU
• And both reports agree on whether this platform is in scope

examine-reports-without-failing

examine-09 - Inspecting a machine reports what it finds without failing

• When the user inspects the system
• Then the inspection completes successfully
• And it states a verdict for this machine

examine-can-skip-framework-probing

examine-10 - The user can leave the frameworks out of the inspection

• When the user inspects the system without probing frameworks
• Then the inspection reports that it skipped the frameworks
• And it still states a verdict for this machine

examine-detects-wsl

examine-11 - System inspection recognizes a WSL host

• Given the CLI is running in WSL
• When the user inspects the system
• Then the inspection reports Linux as the operating system
• And the inspection reports that the host is WSL

examine-install-driver-dry-run-resolves-repo-version

examine-12 - The driver install dry-run shows the effective repo version

• When the user previews the driver install plan
• Then the plan's repo version is a concrete version, not a shell placeholder

examine-engines-list-shows-default-engine-legend

examine-13 - Listing engines explains the default-engine marker

• When the user lists available engines
• Then the engine listing explains the default-engine marker
• And the host's default engine is marked in the listing

examine-shows-default-engine-legend

examine-14 - Inspecting the system explains the default-engine marker

• When the user inspects the system
• Then the inspection explains the default-engine marker
• And the host's default engine is marked in the inspection's engine inventory

examine-framework-names-the-interpreter-that-answered

examine-15 - The framework report describes the runtime the engines will use

• Given a managed runtime is active
• When the user inspects the system both for reading and for scripting
• Then the framework report names the runtime's interpreter

examine-json-names-the-setup-runtime-folder

examine-16 - The scripting form names the setup runtime folder unaided

• Given setup names a runtime folder the registry has forgotten
• When the user inspects the system for scripting before reading
• Then the machine-readable form names the setup runtime folder
• And it does not pass that folder off as the active runtime's

examine-lists-every-gpu-with-its-address-and-target

examine-17 - The machine-readable report lists every GPU the kernel sees

• Given a machine with an AMD GPU
• When the user inspects the system both for reading and for scripting
• Then it lists one AMD GPU per kernel GPU node, each with its PCI address and gfx target

examine-reports-code-object-manager-copies

examine-18 - The inspection says which code object manager libraries the machine holds

• When the user inspects the system in machine-readable form
• Then the inspection lists the code object manager libraries it found
• And it names which of them would load, or says it found none
• And it lists the HIP runtime libraries the machine holds the same way
• And it names which HIP runtime copy would load, or says it found none

examine-finds-the-managed-runtimes-own-compilation-library

examine-19 - The inspection finds the compilation library the CLI installed itself

• Given a managed runtime is active
• When the user inspects the system in machine-readable form
• Then the inspection attributes a code object manager library to that runtime

Interactive dashboard

dash-opens-and-navigates

dash-01 - A user opens the dashboard and navigates to ROCm setup

• When the user opens the dashboard with demo data
• Then the dashboard home view is displayed
• When the user opens the ROCm view
• Then ROCm setup actions are displayed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-chat-offline-reply

dash-02 - A user receives a response in interactive chat

• Given interactive chat uses an offline assistant
• When the user opens interactive chat
• And the user sends a message about GPU health
• Then the assistant's GPU status response is displayed
• When the user quits interactive chat
• Then interactive chat exits successfully

dash-loading-service-status

dash-03 - The dashboard reports a model that is still loading as loading

• Given a managed model is still loading
• When the user opens the dashboard
• And the user opens the Observe view
• Then the managed model is shown as loading rather than ready
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-managed-service-metrics

dash-04 - Observe displays metrics from a managed model

• Given a managed model exposes serving metrics
• When the user opens the dashboard
• And the user opens the Observe view
• Then live serving metrics are displayed for the managed model
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-help-guidance

dash-05 - A user can discover dashboard help and next-step guidance

• When the user opens the dashboard with demo data
• And the user opens dashboard help
• Then navigation and next-step guidance are displayed
• And the backdrop behind the popup is dimmed
• When the user closes dashboard help
• And the user quits the dashboard
• Then the dashboard exits successfully

dash-command-palette-navigation

dash-06 - A user navigates to Serving through the command palette

• When the user opens the dashboard with demo data
• And the user opens the command palette
• Then dashboard destinations are displayed
• When the user chooses Serving
• Then Serving actions are displayed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-managed-service-visible

dash-07 - A managed model is visible in the dashboard

• Given a running managed model is available locally
• When the user opens the dashboard
• And the user opens the Observe view
• Then the managed model is displayed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-gen-tps-held-after-scrape-failure

dash-08 - Gen throughput stays visible for the validity window after a scrape failure

• Given a managed model exposes scripted serving metrics
• And dashboard observation time is deterministic
• When the user opens the dashboard
• And the user opens the Observe view
• Then positive generation throughput is displayed for the managed model
• When dashboard observation time is held
• And the metrics endpoint fails transiently
• Then generation throughput remains visible within the validity window
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-gen-tps-expiry-boundary

dash-09 - Gen throughput expires after the validity window following sustained failure

• Given a managed model exposes scripted serving metrics
• And dashboard observation time is deterministic
• When the user opens the dashboard
• And the user opens the Observe view
• Then positive generation throughput is displayed for the managed model
• When dashboard observation time is held
• And the metrics endpoint fails transiently
• Then generation throughput remains visible within the validity window
• When the validity window has elapsed
• Then generation throughput is no longer displayed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-launcher-shows-live-serving-instance

dash-10 - The launcher front door shows a live serving model rather than idle

• Given a running managed model is available locally
• When the user opens the launcher
• Then the launcher shows the model serving
• When the user quits the launcher
• Then the launcher exits successfully

dash-manager-escape-closes-on-any-tab

dash-11 - Escape closes a manager overlay on any tab

• When the user opens the dashboard with demo data
• And the user opens the Observe view
• And the user opens the services manager
• Then the services manager is displayed
• When the user presses Escape
• Then the services manager is closed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-chat-approval-defaults-to-deny

dash-12 - A surfaced tool call defaults to Deny and confirming without moving denies it

• Given interactive chat uses an offline assistant
• When the user opens interactive chat
• And the user sends a message that triggers a tool approval
• Then a tool approval prompt is displayed
• When the user confirms the approval prompt without moving the cursor
• Then the tool call is shown as declined
• When the user quits interactive chat
• Then interactive chat exits successfully

dash-instance-detail-dims-backdrop

dash-13 - Opening instance detail dims the screen behind the popup

• When the user opens the dashboard with demo data
• And the user opens the Observe view
• And the user opens instance detail
• Then instance details are displayed
• And the backdrop behind the popup is dimmed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-chat-idle-escape-opens-menu

dash-14 - Escape opens the menu when idle on the Chat tab

• When the user opens the dashboard with demo data
• And the user opens the Chat view
• When the user presses Escape
• Then the dashboard menu is displayed
• When the user presses Escape
• Then the dashboard menu is closed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-theme-picker-dims-backdrop

dash-15 - Opening the theme picker dims the screen behind it

• When the user opens the dashboard with demo data
• And the user opens the theme picker
• Then the backdrop behind the popup is dimmed
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-replay-missing-file-fails-fast

dash-16 - Replaying a missing recording fails before entering the dashboard

• When the user replays a recording that does not exist
• Then the dashboard is refused before taking over the terminal
• And the user is told the replay file was not found

dash-sigterm-restores-terminal

dash-17 - A SIGTERM restores the terminal and exits 143

• When the user opens the dashboard with demo data
• Then the dashboard home view is displayed
• When the dashboard receives a SIGTERM
• Then the dashboard exits from the signal with code 143
• And the terminal is restored to the normal screen

dash-sigint-restores-terminal

dash-18 - A SIGINT restores the terminal and exits 130

• When the user opens the dashboard with demo data
• Then the dashboard home view is displayed
• When the dashboard receives a SIGINT
• Then the dashboard exits from the signal with code 130
• And the terminal is restored to the normal screen

dash-launcher-sigterm-restores-terminal-across-a-session

dash-19 - A SIGTERM to the launcher hub restores the terminal after a session

• When the user opens the launcher
• Then the launcher front door is displayed
• When the user opens the dashboard from the launcher
• Then the dashboard home view is displayed
• When the user quits back to the launcher
• Then the launcher front door is displayed
• When the launcher receives a SIGTERM
• Then the launcher exits from the signal with code 143
• And the terminal is restored to the normal screen

dash-ctrl-c-restores-terminal

dash-20 - Typing Ctrl-C in the dashboard restores the terminal and exits 130

• When the user opens the dashboard with demo data
• Then the dashboard home view is displayed
• When the user presses Ctrl-C in the dashboard
• Then the dashboard exits from the keystroke with code 130
• And the terminal is restored to the normal screen

dash-launcher-ctrl-c-restores-terminal

dash-21 - Typing Ctrl-C at the launcher front door restores the terminal and exits 130

• When the user opens the launcher
• Then the launcher front door is displayed
• When the user presses Ctrl-C in the launcher
• Then the launcher exits from the keystroke with code 130
• And the terminal is restored to the normal screen

dash-instance-detail-scroll-hint

dash-22 - Instance detail shows a scroll hint when content overflows

• When the user opens the dashboard with demo data
• And the user opens the Observe view
• And the user opens instance detail
• Then the instance detail footer does not show the scroll hint
• When the user shrinks the terminal until the detail body overflows
• Then the instance detail footer shows the scroll hint
• And the instance detail body shows a scrollbar
• When the user quits the dashboard
• Then the dashboard exits successfully

dash-onboarding-configure-folder-browse

dash-23 - The onboarding Configure step opens the install-folder browser

• When the user opens the dashboard with demo data
• And the user opens the Observe view
• And the user opens onboarding setup
• Then the onboarding welcome screen is displayed
• When the user continues past the onboarding welcome screen
• Then the onboarding setup choices are displayed
• When the user chooses to install the ROCm SDK
• Then the SDK Configure step is displayed
• When the user browses for an install folder
• Then the install-folder browser is displayed
• When the user chooses the current folder
• Then the Configure step shows the chosen folder instead of the placeholder
• When the user closes onboarding setup
• And the user quits the dashboard
• Then the dashboard exits successfully

dash-reports-wsl-gpu-telemetry

dash-24 - Dashboard displays GPU telemetry through WSL

Not run on any platform in this run.

Local server record cleanup

service-cleanup-removes-every-file-a-record-owns

service-cleanup-01 - Removing a stopped record deletes every file it owns

• Given a local server record that is no longer running
• When the user removes that local server record
• Then the CLI names the log file before deleting it
• And every file belonging to that record is gone
• And the shared launch lock is still there
• And the record no longer appears in the full list

service-cleanup-refuses-a-running-server

service-cleanup-02 - Removing a running local server is refused

• Given a local server record that is still running
• When the user tries to remove that local server record
• Then the CLI refuses and tells the user to stop the server first
• And every file belonging to that record is still there

service-cleanup-prunes-previews-then-sweeps-leftovers

service-cleanup-03 - Pruning previews first, then sweeps leftover engine state

• Given a local server record that is no longer running
• And an engine state file whose local server record was deleted by hand
• When the user previews a prune of every record that is not running
• Then the preview lists the record and the leftover file
• And every file belonging to that record is still there
• When the user prunes every record that is not running
• Then every file belonging to that record is gone
• And the leftover engine state file is gone

service-cleanup-any-age-takes-what-the-default-kept

service-cleanup-04 - The default keeps a fresh record and --any-age takes it

• Given a local server record that is no longer running
• When the user prunes with the default age rule
• Then the CLI says it kept the record for being recent and names --any-age
• And every file belonging to that record is still there
• When the user prunes every record whatever its age
• Then every file belonging to that record is gone

service-cleanup-prunes-a-server-that-died-long-ago

service-cleanup-05 - A record whose server died long ago is pruned by default

• Given a local server record whose server died long ago and was never listed since
• When the user prunes with the default age rule
• Then every file belonging to that record is gone
• And the CLI does not claim it kept anything for being recent

service-cleanup-names-a-file-it-could-not-remove

service-cleanup-06 - A file prune cannot remove is named and fails the command

• Given a local server record that is no longer running
• And that record's engine state file cannot be deleted
• When the user prunes every record that is not running
• Then the CLI names the file it could not remove and exits non-zero
• And the record's other files are gone
• And the prune is still recorded in the audit log

service-cleanup-prune-waits-for-a-launch-to-publish

service-cleanup-07 - Prune waits for an in-flight launch instead of sweeping its key

• Given a local server record that is no longer running
• And a managed launch holding the launch lock between its key write and its record write
• When the user prunes every record whatever its age
• Then the prune did not return before the staged hold elapsed
• And every file belonging to that record is gone
• And the endpoint key file of the starting server is still there

Local server records

server-records-storage-report-names-the-folder

server-records-01 - The disk report names the folder local server records are kept in

• Given a local server attempt has failed
• When the user asks what ROCm CLI is keeping on disk
• Then the report names the folder holding local server records
• And the report says which of its folders can be downloaded again

server-records-dashboard-overlay-counts-them

server-records-02 - The dashboard's services overlay counts records that are no longer running

• Given a local server attempt has failed
• When the user opens the dashboard
• And the user opens the Observe view
• And the user opens the managed services overlay
• Then the overlay reports the record that is no longer running
• When the user closes the managed services overlay
• And the user quits the dashboard
• Then the dashboard exits successfully

Log inspection

logs-search-reports-match-count

logs-01 - Searching logs reports how many recent lines match

• Given recorded command logs containing several lines about a topic
• When the user searches the logs for that topic
• Then the CLI reports the matching recent lines

logs-search-absent-term-no-matches

logs-02 - Searching logs for an absent term reports no matches

• Given recorded command logs containing several lines about a topic
• When the user searches the logs for a term that appears nowhere
• Then the CLI reports no matching lines

logs-service-and-search-conflict

logs-03 - Asking for a service and a search term at once is refused

• Given recorded command logs containing several lines about a topic
• When the user asks for one service's logs and a search term together
• Then the CLI refuses and explains only one may be used

Model serving

serve-short-name-expansion

serve-01 - Short model names are expanded to their full name

• When the user serves a model using its short name
• Then the output shows the full model name

serve-short-name-consistent-across-engines

serve-02 - Short name expansion is consistent across engines

• When the user serves the same short name with different engines
• Then all engines expand to the same full model name

serve-discoverable-by-name

serve-03 - A running model server is discoverable by name

• Given a model is being served on the default port
• And the model is registered with the CLI
• When the user lists running services
• Then the service appears with the correct model name and connection details

serve-connection-details

serve-04 - Running services show the correct connection details

• Given a model is being served on a non-default port
• And the model is registered with the CLI
• When the user lists running services
• Then the connection details match the actual server port

serve-vllm-inference

serve-05 - A served model responds to inference requests on vLLM

• Given a managed runtime is active
• And a model is being served on GPU
• When the user sends a chat completion request
• Then the response contains a model reply
• And the response identifies the correct model

serve-large-model-inference

serve-06 - A large platform-specific model serves and responds to inference

• Given a managed runtime is active
• And a large model is being served on GPU
• When the user sends a chat completion request
• Then the response contains a model reply
• And the response identifies the correct model

serve-lemonade-inference

serve-07 - A model served on lemonade responds to inference requests

• Given a managed runtime is active
• And a GGUF model is being served on lemonade

serve-hf-checkpoint-inference

serve-08 - A canonical Hugging Face checkpoint serves and responds to inference

• Given a managed runtime is active
• And a canonical Hugging Face GGUF checkpoint is being served on lemonade
• When the user sends a chat completion request
• Then the response contains a model reply
• And the response identifies the correct model

serve-default-engine-working-endpoint

serve-09 - Serving a model without specifying an engine produces a working endpoint

Not run on any platform in this run.

serve-default-engine-inference

serve-10 - A default-engine served model responds to inference requests

Not run on any platform in this run.

serve-vllm-default-on-instinct

serve-11 - vLLM is the default serving engine on Instinct

• Given a managed runtime is active
• When the user serves a vLLM-capable model without specifying an engine
• Then vLLM is selected as the default engine

serve-readiness-contract

serve-12 - A service reported ready can immediately serve inference

Not run on any platform in this run.

serve-no-gpu-fails-fast

serve-13 - Serving is refused on a host with no AMD GPU

• When the user serves a model under the GPU-required default
• Then serving is refused before any engine starts
• And the user is told no AMD GPU was detected

serve-negative-temperature-rejected

serve-14 - Serving with a temperature below zero is refused with a clear reason

• When the user serves a model with a negative sampling temperature
• Then serving is refused before any engine starts
• And the CLI explains that temperature cannot be negative

serve-masked-devices-fail

serve-15 - Serving is refused when every GPU is masked from view

• When the user serves a model with every GPU masked from view
• Then serving is refused before any engine starts
• And the user is told no AMD GPU was detected

serve-absent-gpu-index-rejected

serve-16 - Serving pinned to a GPU that does not exist is refused

• When the user serves a model pinned to a GPU index that does not exist
• Then serving is refused before any engine starts
• And the user is told that GPU index is unavailable

serve-runtime-and-env-selectors-conflict

serve-17 - Selecting both a runtime and an environment at once is refused

• When the user serves a model selecting both a runtime and an environment
• Then serving is refused before any engine starts
• And the user is told the two selectors cannot be combined

serve-lemonade-preparation-recovery

serve-18 - Repeated Lemonade preparation failure gives the user a recovery path

• Given Lemonade preparation cannot complete
• When the user serves a model with Lemonade
• Then serving stops after one automatic retry
• And the user is told how to reinstall Lemonade and retry serving

serve-masked-gpu-index-rejected

serve-19 - Serving pinned to a GPU hidden by the visibility mask is refused

• When the user serves a model pinned to a GPU hidden by the visibility mask
• Then serving is refused before any engine starts
• And the user is told the pinned GPU is unavailable

serve-rocr-reindexed-gpu-index-rejected

serve-20 - Serving pinned past the ROCR-reindexed visible set is refused

• When the user serves a model pinned past the ROCR-reindexed visible set
• Then serving is refused before any engine starts
• And the user is told the pinned GPU is unavailable

serve-rocr-empty-mask-beats-hip-mask

serve-21 - Serving is refused when ROCR hides every GPU a HIP mask names

• When the user serves a model with ROCR hiding every GPU a HIP mask names
• Then serving is refused before any engine starts
• And the user is told no AMD GPU was detected

serve-past-attempts-surfaced

serve-22 - A failed local server is counted in the default list

• Given a local server attempt has failed
• When the user lists running services
• Then the list reports the attempt and how to look at it

serve-vllm-low-vram-oom-guidance

serve-23 - A vLLM serve plan on a nearly-full GPU points at the memory knob

• Given a managed runtime is active
• And the selected GPU is reported nearly out of VRAM
• When the user previews a vLLM serve plan pinned to that GPU
• Then the serve plan warns the GPU is low on VRAM
• And the serve plan explains how to lower vLLM's memory reservation

Native HTTP networking

networking-native-http-endpoint-reachable

networking-01 - The CLI reaches a served endpoint over the native HTTP stack

• Given a model is being served
• And the model is registered with the CLI
• When the user lists running services
• Then the served model is listed
• And the served model endpoint is listed

networking-native-http-chat-round-trip

networking-02 - A chat round-trip over a local endpoint uses the native HTTP stack

• Given a model is being served
• And the model is registered with the CLI
• When the user sends a one-shot chat prompt through the CLI
• Then the CLI prints the assistant's reply

networking-public-bind-requires-opt-in

networking-03 - Binding to a public interface without opt-in is refused up front

• When the user serves a model bound to a public interface without allowing public binding
• Then serving is refused before any engine starts
• And the user is told to allow public binding first

Non-interactive bootstrap setup

bootstrap-setup-no-tty-advertises-install-folder

bootstrap-01 - Running bootstrap setup without a terminal advertises the install-folder choice

• When the user runs bootstrap setup without a terminal
• Then the CLI tells the user how to choose an install folder

Release install lifecycle

lifecycle-linux-install-signed-keypath

lifecycle-01 - Linux - a bundle signed with a key file installs, verifies, and sets up the shell profile

Not run on any platform in this run.

lifecycle-linux-install-signed-pem

lifecycle-02 - Linux - a bundle signed with an inline PEM installs and verifies

Not run on any platform in this run.

lifecycle-linux-reject-untrusted-key

lifecycle-03 - Linux - an install with no public key falls back to the pinned trust root and rejects an untrusted signer

Not run on any platform in this run.

lifecycle-linux-reject-bad-checksum

lifecycle-04 - Linux - a tampered checksum is rejected before activation

Not run on any platform in this run.

lifecycle-linux-reject-bad-signature

lifecycle-05 - Linux - a tampered signature is rejected before activation

Not run on any platform in this run.

lifecycle-linux-reject-missing-signature

lifecycle-06 - Linux - a missing signature is rejected when a signature is required

Not run on any platform in this run.

lifecycle-linux-reinstall-purges-stale

lifecycle-07 - Linux - reinstalling purges a stale prior entry and preserves config

Not run on any platform in this run.

lifecycle-linux-installed-binary-pty

lifecycle-08 - Linux - the installed binary opens and exits interactive chat through a pseudo-terminal

Not run on any platform in this run.

lifecycle-linux-uninstall-full-purge

lifecycle-09 - Linux - uninstall removes binaries, manifest, and XDG state

Not run on any platform in this run.

lifecycle-windows-install-signed

lifecycle-10 - Windows - a signed zip installs and verifies with native crypto

Not run on any platform in this run.

lifecycle-windows-key-rotation-fallback

lifecycle-11 - Windows - a malformed current trust root falls through to the valid next key

Not run on any platform in this run.

lifecycle-windows-all-pinned-keys-malformed

lifecycle-12 - Windows - all malformed pinned trust roots fail deterministically

Not run on any platform in this run.

lifecycle-windows-updates-user-path

lifecycle-13 - Windows - a default install updates the user PATH and restores it afterwards

Not run on any platform in this run.

lifecycle-windows-verifies-without-openssl

lifecycle-14 - Windows - the installer verifies with native crypto when openssl is absent from PATH

Not run on any platform in this run.

lifecycle-windows-rejects-bad-signature-without-openssl

lifecycle-15 - Windows - a bad signature is rejected with native crypto when openssl is absent from PATH

Not run on any platform in this run.

lifecycle-windows-reinstall-purges-stale

lifecycle-16 - Windows - reinstalling purges a stale prior entry

Not run on any platform in this run.

lifecycle-windows-reject-untrusted-key

lifecycle-17 - Windows - an install with no public key rejects an untrusted signer

Not run on any platform in this run.

lifecycle-windows-reject-bad-checksum

lifecycle-18 - Windows - a tampered checksum is rejected before activation

Not run on any platform in this run.

lifecycle-windows-reject-bad-signature

lifecycle-19 - Windows - a tampered signature is rejected before activation

Not run on any platform in this run.

lifecycle-windows-reject-missing-signature

lifecycle-20 - Windows - a missing signature is rejected when a signature is required

Not run on any platform in this run.

lifecycle-windows-http-install

lifecycle-21 - Windows - a signed bundle installs over a loopback HTTP download

Not run on any platform in this run.

lifecycle-windows-installed-binary-smoke

lifecycle-22 - Windows - the installed binary honors isolated directories and keeps the running executable on uninstall

Not run on any platform in this run.

Runtime configuration

runtime-install-sdk-active

runtime-01 - Installing the SDK makes it the active runtime

• Given a machine with no CLI-managed runtimes
• When the user installs the SDK
• Then a runtime is registered
• And the runtime is set as active
• And the runtime includes an inference engine
• And the runtime excludes the compiler toolchain
• And the inspection reports the active runtime has no compiler toolchain

runtime-path-not-nested

runtime-02 - The managed runtime path is not nested inside another runtime

• Given a managed runtime is active
• When the user inspects the system
• Then the managed runtime folder path is not recursively nested

runtime-sdk-reinstall-keeps-engine-consistent

runtime-03 - Reinstalling the SDK leaves the installed engine able to use the GPU

• Given a managed runtime with an inference engine already installed
• When the user installs the SDK again
• Then the runtime can still use the GPU
• And the torch alignment settled rather than being skipped

runtime-torch-alignment-opt-out

runtime-04 - Opting out of the torch alignment keeps the torch the user installed

• Given a managed runtime with an inference engine already installed
• And the user has opted out of realigning torch
• When the user installs the SDK again
• Then the torch alignment reports the opt-out instead of rewriting torch
• And the install does not offer to reinstall the engine over the kept torch

runtime-update-reports-freshness

runtime-05 - The update check reports the active runtime's freshness

• Given a managed runtime is active
• When the user checks for runtime updates
• Then the report states the runtime's freshness against the channel index

runtime-install-records-the-real-folder

runtime-06 - Previewing an install through a linked runtimes folder names the real folder

• Given a machine whose runtimes folder is a link to somewhere else
• When the user previews an SDK install
• Then the planned runtime folder is inside the folder the link points at
• And the planned runtime folder is not expressed through the link

runtime-adopt-preexisting-rejected

runtime-07 - Adopting a pre-existing ROCm install is rejected with guidance

• Given a machine with a standard ROCm install
• When the user tries to adopt the existing install
• Then the adoption is refused
• And the error explains which install types can be adopted

runtime-resolve-canonical-nightly

runtime-08 - Previewing a nightly SDK install reports canonical provenance

• When the user dry-runs a nightly SDK install for a known family
• Then the SDK preview reports canonical nightly provenance

runtime-resolve-canonical-release

runtime-09 - Previewing a release SDK install resolves the canonical aggregate for this GPU

• Given a machine with an AMD GPU
• When the user dry-runs a release SDK install for this host
• Then the SDK preview reports canonical release provenance
• And the SDK preview requests the device payload for this host's GPU

runtime-rollback-help-states-single-level-limit

runtime-10 - Stating rollback's single-level limit in --help

• When the user asks for rollback help
• Then the help states that rollback has no history

runtime-install-sdk-overwrite-requires-yes

runtime-11 - Reinstalling the SDK over an existing runtime without consent is refused

• Given a managed runtime is active
• When the user reinstalls the SDK without confirming
• Then the reinstall is refused
• And the error explains how to approve the replacement non-interactively

runtime-install-sdk-overwrite-with-yes

runtime-12 - Reinstalling the SDK over an existing runtime with --yes proceeds

• Given a managed runtime is active
• When the user reinstalls the SDK with --yes
• Then the install reports that --yes approved replacing the existing runtime
• And a runtime is registered
• And the runtime is set as active

runtime-install-sdk-other-family-requires-yes

runtime-13 - Installing a different GPU family while a runtime is active is refused without consent

• Given a managed runtime is active
• When the user installs a different GPU family without confirming
• Then the reinstall is refused
• And the error explains how to approve the replacement non-interactively
• And the error names the active default runtime it would replace

runtime-install-sdk-help-separates-consents

runtime-14 - Stating that the non-interactive consent flag does not approve sudo in --help

• When the user asks for SDK install help
• Then the help offers a consent flag that does not approve system-package installs

runtime-freeform-yes-discloses-injected-consent

runtime-15 - Disclosing the consent added to a natural-language install approved with --yes

• Given the CLI cannot reach a usable Python
• When the user approves a natural-language SDK install with --yes
• Then the request plan shows an install command carrying no replacement consent
• And the executed command carries the replacement consent
• And the execution section says the consent came from the user's --yes

runtime-lemonade-backend-alignment-reported

runtime-16 - Reinstalling Lemonade reports whether its ROCm backend was aligned

• Given a managed runtime is active
• When the user reinstalls the lemonade engine
• Then the CLI reports that Lemonade's ROCm backend was aligned to the active SDK

runtime-lemonade-backend-alignment-opt-out

runtime-17 - Opting out of the Lemonade backend alignment keeps the packaged pin

• Given a managed runtime is active
• And the user has opted out of realigning Lemonade's backend
• When the user reinstalls the lemonade engine
• Then the CLI reports that Lemonade's backend alignment was skipped by the opt-out
• And the packaged pin survives the install

runtime-install-sdk-serves-without-toolchain

runtime-18 - A runtime-only SDK install serves vLLM inference

• Given a machine with no CLI-managed runtimes
• When the user installs the SDK
• Then the runtime excludes the compiler toolchain
• When the user serves a model on GPU from the installed runtime
• And the user sends a chat completion request
• Then the response contains a model reply
• And the response identifies the correct model

Runtime lifecycle state machine

runtime-lifecycle-activate-records-previous

runtime-lifecycle-01 - Activating a runtime records where it changed from

• Given two registered runtimes and none active
• When the user activates the first runtime
• Then that runtime becomes active having changed from nothing
• When the user activates the second runtime
• Then that runtime becomes active having changed from the first

runtime-lifecycle-rollback-returns-to-previous

runtime-lifecycle-02 - Rolling back returns to the previously active runtime

• Given two registered runtimes with the second active after the first
• When the user rolls back
• Then the first runtime is active again

runtime-lifecycle-uninstall-keeps-external-folder

runtime-lifecycle-03 - Uninstalling an externally-sourced runtime keeps its folder

• Given a registered read-only runtime
• When the user uninstalls that runtime
• Then its registry entry is removed
• And its external folder is left in place

runtime-lifecycle-uninstall-requires-yes-noninteractive

runtime-lifecycle-04 - Uninstalling without --yes is refused outside a terminal

• Given a registered read-only runtime
• When the user tries to uninstall that runtime without confirming
• Then the CLI refuses and requires --yes

runtime-lifecycle-uninstall-dry-run

runtime-lifecycle-05 - Dry-running an uninstall makes no changes

• Given a registered read-only runtime
• When the user dry-runs an uninstall of that runtime
• Then the dry run reports the plan without confirming or changing anything

runtime-lifecycle-import-rejects-duplicate-unless-replacing

runtime-lifecycle-06 - Importing a runtime, then rejecting a duplicate unless replacing

• Given a runtime manifest to import
• When the user imports the runtime
• Then the runtime is registered as read-only
• When the user imports the same runtime again
• Then the CLI refuses because it already exists
• When the user imports it again allowing replacement
• Then the import succeeds

runtime-lifecycle-list-shows-marker-legend

runtime-lifecycle-07 - Listing runtimes explains the active and rollback markers

• Given two registered runtimes with the second active after the first
• When the user rolls back
• And the user lists the registered runtimes
• Then the listing explains the active and rollback markers
• And the first runtime is marked active
• And the second runtime is marked as the rollback target

runtime-lifecycle-reactivating-keeps-rollback-target

runtime-lifecycle-08 - Re-selecting the runtime already in use keeps the rollback target

• Given two registered runtimes with the second active after the first
• When the user activates the second runtime again
• Then the second runtime is still the one in use
• And the first runtime is still the rollback target

runtime-lifecycle-case-twin-selector-refused

runtime-lifecycle-09 - A selector matching two runtimes only by letter case is refused with both named

• Given two registered runtimes whose keys differ only in letter case
• When the user activates a runtime with a selector that matches both only by letter case
• Then the CLI refuses and names both runtimes
• And no runtime is active
• When the user activates one of them by its exact key
• Then that exact runtime becomes active

System dependency installs preserve ROCm

deps-guard-refuses-rocm-removal

deps-guard-01 - Installing a dependency never silently removes ROCm

• Given a machine with a registered ROCm runtime
• And installing OpenMPI would remove the ROCm packages
• When the user installs the vLLM engine and approves system changes
• Then the CLI refuses instead of removing them
• And it does so before changing anything on the system
• And it lists every ROCm package that would have been removed

The ROCm Doctor skill's instructions match the CLI they drive

skill-catalog-ids-match-cli

skill-01 - Every remediation the skill documents is one the CLI still offers

• Given the ROCm Doctor skill as it is published
• When an agent asks the CLI which remediations it knows
• Then the skill and the CLI describe the same set of remediations

skill-auto-fix-set-matches-cli

skill-02 - The skill agrees with the CLI about which remediations the CLI will run itself

• Given the ROCm Doctor skill as it is published
• When an agent asks the CLI which remediations it knows
• Then the skill and the CLI agree on which ones the CLI applies without help

skill-os-scope-matches-cli

skill-03 - The skill agrees with the CLI about which machines each remediation applies to

• Given the ROCm Doctor skill as it is published
• When an agent asks the CLI which remediations it knows
• Then the skill and the CLI agree on which machines each remediation is for

skill-diagnosis-matches-what-the-skill-documents

skill-04 - A diagnosis carries everything the skill tells an agent to read

• Given the ROCm Doctor skill as it is published
• And a user who reports a recognised ROCm failure
• When an agent asks the CLI to diagnose that report for tooling
• Then the diagnosis carries every field the skill names
• And its confidence thresholds are the ones the skill reasons about

skill-examine-verdicts-are-documented

skill-05 - Inspecting the machine returns a verdict the skill documents

• Given the ROCm Doctor skill as it is published
• When an agent inspects the machine for tooling
• Then the inspection succeeds whatever it finds
• And its verdict is one the skill documents

skill-escalation-target-matches-cli

skill-06 - The upstream tracker the CLI hands back is one the skill documents

• Given the ROCm Doctor skill as it is published
• And a user who reports a failure with no catalog keyword in it
• When an agent asks the CLI to diagnose that report for tooling
• Then the CLI routes the report to a tracker the skill documents

TheRock "next" ROCm 10 install layout

therock-next-01-unpinned-release-stays-canonical

therock-next-01 - An unpinned release install stays on the canonical multi-arch source

• Given a canonical release pip index fixture and a ROCm 10 pip index fixture
• When the user previews a wheel SDK install for arch gfx1200 with no version pin
• Then the preview resolves the canonical release pip index
• And the preview reports the canonical multi-arch source layout generation
• And the preview never mentions the ROCm 10 pip index

therock-next-02-wheel-pins-raw-device-extras

therock-next-02 - A pinned ROCm 10 wheel install resolves the next index with raw device extras

• Given a canonical release pip index fixture and a ROCm 10 pip index fixture
• When the user previews a wheel SDK install for arch gfx1200 pinned to ROCm 10.0.0
• Then the preview resolves the ROCm 10 pip index
• And the preview reports the next source layout generation
• And the preview requests the gfx1200 device extras

therock-next-03-wheel-group-family-refused

therock-next-03 - A pinned ROCm 10 wheel install refuses a group family label

• Given a canonical release pip index fixture and a ROCm 10 pip index fixture
• When the user previews a wheel SDK install for family gfx120X-all pinned to ROCm 10.0.0
• Then the install fails
• And the failure asks for an exact GPU arch and names --family gfx1200

therock-next-04-tarball-skips-tests-sibling

therock-next-04 - A pinned ROCm 10 tarball install skips the tests sibling

• Given a canonical release tarball fixture and a ROCm 10 tarball fixture with a tests sibling
• When the user previews a tarball SDK install for arch gfx1200 pinned to ROCm 10.0.0
• Then the preview resolves the ROCm 10 tarball catalog
• And the preview reports the next source layout generation
• And the preview selects the real tarball artifact
• And the preview does not select the tests artifact

therock-next-05-tarball-group-family-refused

therock-next-05 - A pinned ROCm 10 tarball install refuses a group family label

• Given a canonical release tarball fixture and a ROCm 10 tarball fixture with a tests sibling
• When the user previews a tarball SDK install for family gfx120X-all pinned to ROCm 10.0.0
• Then the install fails
• And the failure asks for an exact GPU arch and names --family gfx1200

therock-next-06-base-override-requires-opt-in

therock-next-06 - A ROCm 10 source override is ignored without explicit trust

• Given an untrusted ROCm 10 pip base override
• When the user previews a wheel SDK install for arch gfx1200 pinned to the latest published ROCm 10 version
• Then the preview resolves the default ROCm 10 pip index
• And the preview never mentions the untrusted ROCm 10 pip index

therock-next-07-live-install-auto-detects-arch

therock-next-07 - Installing the SDK from the live ROCm 10 preview source auto-detects the exact arch

• Given a machine with no CLI-managed runtimes
• When the user installs the SDK from the ROCm 10 preview source with no family override
• Then the install used the ROCm 10 preview source
• And the install requested the device extras for this host's detected GPU
• And a runtime is registered
• And the runtime is set as active
• And the runtime includes an inference engine
• And the ROCm 10 runtime passes SDK and Torch GPU probes

therock-next-08-update-apply-recovers-exact-arch-from-grouped-family

therock-next-08 - Updating a ROCm 10 wheel runtime resolves past its grouped family

• Given a canonical release pip index fixture and a ROCm 10 pip index fixture
• And a registered ROCm 10 wheel runtime with a grouped family
• When the user previews applying the pending update to that runtime
• Then the preview requests the gfx1200 device extras with the toolchain

therock-next-09-live-install-reports-vllm-rocm10x-discovery-pins

therock-next-09 - Installing vLLM against a live ROCm 10 preview runtime reports the discovery pins

• Given a machine with no CLI-managed runtimes
• When the user installs the SDK from the ROCm 10 preview source with no family override
• Then a runtime is registered
• And the runtime is set as active
• And the runtime includes an inference engine
• And the ROCm 10 runtime provisioned a cp314 Python interpreter
• When the user reinstalls vllm
• Then the install reports the vLLM ROCm 10.x discovery pins
• Given a model is being served on GPU
• When the user sends a chat completion request
• Then the response contains a model reply
• And the response identifies the correct model

therock-next-09-wheel-devel-adds-the-toolchain

therock-next-10 - A pinned ROCm 10 wheel install adds the toolchain when asked

• Given a canonical release pip index fixture and a ROCm 10 pip index fixture
• When the user previews a wheel SDK install for arch gfx1200 pinned to ROCm 10.0.0 with the toolchain
• Then the preview resolves the ROCm 10 pip index
• And the preview requests the gfx1200 device extras with the toolchain

Update report

update-report-distinguishes-feed-status

update-01 - The update report distinguishes configured from not-configured feeds

• Given a machine with no managed runtimes
• When the user checks for updates
• Then the report shows there are no managed runtimes to update
• And it reports each update feed's status, marking unpublished feeds as not configured

update-json-reports-empty-runtimes

update-02 - The machine-readable update check reports an empty runtimes array

• Given a machine with no managed runtimes
• When the user checks for updates as machine-readable JSON
• Then the machine-readable check reports no runtimes to update

update-json-accepts-timeout-flag

update-03 - The machine-readable update check accepts a --timeout-secs flag

• Given a machine with no managed runtimes
• When the user checks for updates as machine-readable JSON with a 5 second timeout
• Then the machine-readable check reports no runtimes to update

update-dry-run-reaches-preview-path-without-apply

update-04 - Previewing an update with --dry-run does not require --apply

• Given a machine with no managed runtimes
• When the user previews an update
• Then the CLI refuses because no managed runtimes are registered

update-runtime-or-activate-without-apply-or-dry-run-is-refused

update-05 - --runtime or --activate without --apply or --dry-run is refused

• Given a machine with no managed runtimes
• When the user requests updating a specific runtime without --apply or --dry-run
• Then the CLI refuses because --apply or --dry-run is required with --runtime or --activate

update-dry-run-conflicts-with-json

update-06 - --dry-run and --json cannot be combined

• Given a machine with no managed runtimes
• When the user checks for updates as JSON with --dry-run
• Then the CLI refuses because --dry-run and --json cannot be combined

Working with GPU machines over a private network

remote-targets-lists-machines

remote-01 - The user sees which machines could host a model

• Given a private network with a GPU machine and a phone
• When the user asks which remote targets exist
• Then both machines are listed
• And the listing says it is not a readiness check

remote-targets-tag-filter

remote-02 - The list can be narrowed to machines marked as GPU nodes

• Given a private network with a GPU machine and a phone
• When the user asks for remote targets tagged as GPU machines
• Then only the GPU machine is listed

remote-targets-offline-shown

remote-03 - A machine that is offline is still listed, marked offline

• Given a private network whose GPU machine is offline
• When the user asks which remote targets exist
• Then the GPU machine is listed as offline

remote-targets-not-connected

remote-04 - Discovery explains itself when the private network is not connected

• Given the private network client is installed but not connected
• When the user asks which remote targets exist
• Then the user is told it is not connected and how to connect
• And the command still succeeds

remote-serve-unknown-machine

remote-05 - Serving refuses a machine that is not on the private network

• Given a private network with a GPU machine and a phone
• When the user asks to serve a model on a machine that is not there
• Then the user is told it is not on the network
• And they are pointed at the list of machines that are

remote-serve-offline-machine

remote-06 - Serving refuses an offline machine instead of waiting for it

• Given a private network whose GPU machine is offline
• When the user asks to serve a model on the GPU machine
• Then the user is told the machine is offline

remote-status-no-sessions

remote-07 - The user is told when they have no remote sessions

• When the user asks about their remote sessions
• Then the user is told there are none and how to start one

remote-stop-unknown-session

remote-08 - Stopping a session that does not exist is refused

• When the user asks to stop a remote session that does not exist
• Then the user is told no such session is recorded

remote-doctor-refuses-to-install

remote-09 - Checking a machine's health never installs anything on it

Not run on any platform in this run.

remote-serve-publishes-endpoint

remote-10 - Serving a model on another machine gives back a usable endpoint

Not run on any platform in this run.

remote-status-reports-both-halves

remote-11 - Status reports the model and the endpoint separately

Not run on any platform in this run.

remote-attach-restores-endpoint

remote-12 - An endpoint withdrawn behind the user's back is repairable

Not run on any platform in this run.

remote-stop-clears-both

remote-13 - Stopping a session leaves nothing running and nothing exposed

Not run on any platform in this run.

remote-doctor-reports-remote-health

remote-14 - Checking a remote machine reports that machine's health

Not run on any platform in this run.