Repository navigation
REQ 018
REQ-018: LabVIEW activation is exclusively human-driven/interactive, never an automated phase, wherever such a step genuinely exists (merged former REQ-019 into this row, 2026-11-07; corrected 2026-11-07 with real workflow_dispatch proof that no such step exists at all for Ubuntu/Linux)
LabVIEW product activation shall remain an exclusively human-driven, interactive step -- never an automated phase of VM provisioning -- wherever such an activation step genuinely exists in this engine's supported platforms.
Activation is the one step in the pipeline deliberately kept outside automation, per operator decision, rather than an oversight or a not-yet-implemented phase. A human must retain direct, interactive control over this specific action rather than it being delegated to any script or service account. This is scoped to LabVIEW specifically -- see REQ-032 for VIPM activation, which is a deliberately-automated exception with its own narrower requirement. Real workflow_dispatch proof (#62, run 42394542555) found this engine's own Ubuntu-LabVIEW appliance genuinely has no separate LabVIEW license-activation step at all (NI's Linux LabVIEW distribution's authenticated package-repository access is itself the licensing gate) -- complete-activation.sh's former usage-text claim that the operator "has already activated LabVIEW Professional in the guest" was an unverified assumption carried over from the Windows family, not a real precondition, and has been corrected in the script itself. This requirement's own prohibition is satisfied vacuously for Linux (there is no human-only LabVIEW activation step to protect from automation there) and remains fully, genuinely in force for Windows, where a real interactive activation step does exist. (Merged from the former REQ-019, retired 2026-11-07: its own Fit Criterion read "Same evidence as REQ-018," failing ISO/IEC/IEEE 29148 §5.2.5's "Necessary" characteristic -- its removal leaves no capability deficiency not already covered by this row. See the Notation section's ID-retirement convention.)
provision-windows-labview-vm.yml's own header comment states this explicitly ("LabVIEW/VIPM activation remains an operator-driven interactive step and is intentionally NOT a phase here -- it is the one step that must stay human"); no phase option in that workflow's workflow_dispatch input performs activation -- genuinely true for Windows, confirmed real since no script anywhere in this repo performs LabVIEW activation for either platform. For Ubuntu/Linux, real workflow_dispatch proof (run 42394542555) confirms complete-activation succeeds end-to-end with zero human-interactive LabVIEW steps of any kind -- only REQ-032's automated VIPM activation runs.
Real workflow_dispatch dispatch of provision-ubuntu-vm.yml's complete-activation phase against a disposable appliance (#62), producing a genuine activation-receipt.json with outcome: PASS and a functional LabVIEW known-answer probe (20+22=42) -- not merely code review of usage text, which this requirement's prior verification wrongly relied on alone. Windows's own human-activation step remains verified by code review only (no real interactive activation has been live-dispatch-proven this session).
Software-Requirements-Specification
High
Real workflow_dispatch of complete-activation (#62, run 42394542555) for Ubuntu/Linux; code review of the Windows workflow's header comment + phase enum for Windows (not live-dispatch-proven this round)
.github/workflows/provision-windows-labview-vm.yml, vm/ubuntu-labview/complete-activation.sh, .github/workflows/provision-ubuntu-vm.yml
Verified (live, Linux); Verified (manual, Windows)