product: assert audience: test-developer authority: normative

Prompt Value Input

A prompt step can display an interactive input control so the operator can enter a measured value, confirm a string, toggle a boolean, or select from a list.

The entered value IS:

1. Stored in a named variable (available to downstream steps via {{variable}}).
2. Stored in the well-known InputValue variable.
3. Limit-checked (number mode) or compared against an expected value (text / boolean / list modes) to determine the step verdict.

Input modes

Verdict priority

1. Abort button pressed → ABORTED (highest — ignores limit check).
2. Fail button pressed → FAIL.
3. Pass / Continue button pressed → limit / expected check runs:
   • Check passes → PASS.
   • Check fails → FAIL.

Output variables

Number mode — voltage limit check

- name: "Measure Supply Voltage"
  type: prompt
  prompt:
    title: "Voltage Entry"
    message: "Connect DMM to TP1 / TP2 and enter the measured value."
    input:
      mode: number
      variable: supply_voltage
      low_limit: 4.75
      high_limit: 5.25
      unit: "V"
    buttons:
      - name: "Submit"
        action: continue
  post_execution_action: terminate-on-fail

Omit both low_limit and high_limit for informational logging — the step always passes.

Text mode — firmware version check

- name: "Verify Firmware Version"
  type: prompt
  prompt:
    message: "Read the firmware version from the device display and type it below."
    input:
      mode: text
      variable: fw_version
      expected: "v2.1.0"
    buttons:
      - name: "Confirm"
        action: continue
  post_execution_action: terminate-on-fail

Boolean mode — relay continuity check

- name: "Relay Self-Test"
  type: prompt
  prompt:
    message: "Does the multimeter show continuity across pins 3 and 7?"
    input:
      mode: boolean
      variable: relay_closed
      expected: "true"
    buttons:
      - name: "Submit"
        action: continue
  post_execution_action: terminate-on-fail

List mode — LED colour selection

# Informational — any selection passes
- name: "Record LED Colour"
  type: prompt
  prompt:
    message: "Select the LED colour you observe."
    input:
      mode: list
      variable: led_colour
      options: ["Green", "Amber", "Red", "Off"]
    buttons:
      - name: "Submit"
        action: continue

# Pass/fail — must be Green
- name: "LED Must Be Green"
  type: prompt
  prompt:
    message: "Select the LED colour (must be Green to pass)."
    input:
      mode: list
      variable: led_colour
      options: ["Green", "Amber", "Red", "Off"]
      expected: "Green"
    buttons:
      - name: "Submit"
        action: continue
  post_execution_action: terminate-on-fail

Using the entered value in downstream steps

steps:
  - name: "Enter Voltage"
    type: prompt
    prompt:
      message: "Enter measured voltage."
      input:
        mode: number
        variable: measured_v
        low_limit: 4.75
        high_limit: 5.25
        unit: "V"
    buttons:
      - name: "Submit"
        action: continue

  - name: "Log Voltage Measurement"
    type: mock
    measurement:
      name: "VOUT"
      value: "{{measured_v}}"
      low_limit: 4.75
      high_limit: 5.25
      unit: "V"

Required vs optional input

By default required: true — submit buttons are disabled until the operator enters a non-empty value. Set required: false for optional fields:

input:
  mode: text
  variable: operator_note
  required: false

Pre-filled value — default

default pre-fills the input field when the dialog opens, so the operator confirms a value instead of typing it. In list mode it must match one of the options.

input:
  mode: number
  variable: ambient_temp
  unit: "degC"
  default: 25

The same key is what makes a value-input prompt safe to run unattended: an unattended run submits default on the operator's behalf, and a value-input prompt without one FAILS the step. See mcp/unattended-mode.md.

The operator's answer is recorded automatically

Every prompt step records the button the operator chose as a string measurement named Response, with the log operator so it is informational and can never change a verdict. You do not declare it and cannot switch it off.

This exists because a prompt answer is a decision that changes what a test covers. Where the answer gates a precondition: on later steps, the only other trace of it is which children came back SKIPPED — and by that route a calibration the operator declined is indistinguishable from a calibration that vanished through a package or engine fault.

An unattended run records its own answer too, suffixed [unattended], and a prompt that auto-submitted on its timeout is suffixed [timed out]. A machine-chosen answer is a decision as much as a person's, and the record should not pass one off as the other.

Step result measurement

When a prompt step includes input:, the entered value and its limits/expected value ARE recorded as a measurement point on the step result — identical to gRPC runner measurements. Expand the step in the test results tree to see the actual value alongside the configured limits.

Sample package

sample-prompt-value-input in the package browser demonstrates all four modes with and without limit / expected-value checks.