User Workflow

Preconditions

The shipped extension-user workflow assumes:

• the extension is installed from the VS Code Marketplace, from code --install-extension, or from a VSIX
• the workspace is trusted
• the target file is a tracked LabVIEW VI in a Git repository
• at least two commits modify that VI
• the runtime has been selected with vihs
• vihs --validate has been run at least once on the current machine
• if Docker is selected, docker info succeeds in the same session that launched VS Code

Execution Policy

Comparison generation follows the current provider-explicit installed contract.

Current installed rules:

• Windows defaults to local LabVIEWCLI when the persisted provider is absent
• Docker remains a bounded expert provider selected through the published install/bootstrap surface or later vihs updates
• viHistorySuite.labviewVersion and viHistorySuite.labviewBitness stay explicit across both provider classes
• vihs --validate exposes whether the current bundle is ready, needs-image-acquisition, or blocked
• if Docker is selected, the extension derives the Windows or Linux image family from the current engine and fails closed on unsupported x86
• if the chosen provider bundle is blocked, compare stops with next-step guidance instead of silently switching provider classes
• compare progress, selected provider, current engine, selected image, acquisition state, and next action stay visible in the history panel while the action runs

Repository Support

VI History can be opened from any trusted Git repository by selecting the LabVIEW file you want to review.

Current scope:

• the checkbox-selected compare workflow is repo-agnostic
• benchmark and maintainer-only host-review evidence are optional local confidence paths
• you do not need to be on ni/labview-icon-editor or ni/actor-framework to use the core two-commit compare flow

Primary Review Flow

1. Right-click the VI you want to review and choose Review VI History.
2. The extension evaluates that selected file for VI signature, Git tracking, and at least two modifying commits.
3. Review the history panel facts:
   • repository name
   • relative path
   • VI signature
   • retained commit chronology
4. Use the checkbox column to choose the exact two retained revisions you want to compare.
5. Review the explicit compare preflight section for the exact selected/base pair.
6. Choose Compare.

The current action model is:

• Checkboxes: define the exact selected/base pair you want to compare
• Compare: generates or reopens retained comparison evidence for the exact admitted pair
• Open docs: open the bundled user documentation that ships with the installed extension version

Practical selection rule:

• a selected tracked VI with at least two modifying commits is enough to use VI History
• the commit body shown in a row is review context only; the two checked revisions define the exact compare pair
• the newer selected revision becomes selected and the older selected revision becomes base
• the oldest retained revision is still selectable as the older/base side of a checkbox-selected pair
• there is no separate dashboard or decision-record step in the extension-user compare flow

Comparison Report Flow

Comparison-report generation and opening are treated as review actions inside the extension, not ad hoc shell commands.

When a pair comparison is generated or refreshed, the extension retains:

• the comparison-report packet
• report metadata
• the generated NI comparison report when one exists
• a compact runtime summary with provider and next action

The embedded compare view now leads with a white Comparison context block that foregrounds selected/base commit hash, date, author, and subject facts before any deeper runtime evidence. Runtime diagnostics remain retained, but they stay on packet/runtime evidence surfaces instead of leading the embedded compare view.

Exact-pair compare behavior is explicit:

• select exactly two retained revisions with the checkbox column
• review the explicit compare preflight section for the exact selected/base pair plus runtime facts
• choose Compare to generate or reopen retained comparison evidence for that exact pair
• the newer selected revision becomes selected and the older selected revision becomes base
• the oldest retained revision is still selectable as the older/base side of a checkbox-selected pair

If you cancel before the comparison view opens, the action stays cancelled instead of opening a late result.

Trust, Progress, And Cancellation

The checkbox-selected compare workflow is trust-gated and progress-aware.

• compare actions fail closed in untrusted workspaces
• long-running actions show bounded progress in the extension
• cancellation preserves already retained evidence where possible instead of silently discarding it
• the extension does not wait for a separate third-step dashboard or decision-record action after the second checkbox selection

Bundled Documentation

The extension packages a version-matched installed-user guide so you can read workflow guidance without leaving VS Code.

The packaged guide is intentionally concise: it keeps the extension-user workflow, execution-policy, and compare rules that a developer needs while omitting historical release-control material.

Open it from:

• the Command Palette via VI History: Open Documentation
• the history panel via Open docs