Previously the stage indices reflected logical milestones but not the
order they fire in. Run-ShopfloorSetup posted idx=1 (start) and idx=4
(PPKG) - but 09-Setup-Keyence (inside per-type loop) ran BETWEEN them
and posted idx=5/6. The dashboard then "regressed" from 6 back to 4
when PPKG fired, making it look stuck at the per-type-complete card.
New numbering matches actual execution order:
1 - WinPE: PESetup / WIM apply (startnet.cmd)
2 - Run-ShopfloorSetup: starting (Run-ShopfloorSetup.ps1)
3 - 09-Setup-<Type>: starting (per-type)
4 - 09-Setup-<Type>: complete (per-type)
5 - Run-ShopfloorSetup: PPKG enrollment (Run-ShopfloorSetup.ps1)
6 - Run-ShopfloorSetup: handoff to Monitor (Run-ShopfloorSetup.ps1)
7 - Monitor-IntuneProgress: Intune Device ID captured
services/imaging_status.py rewind threshold reverts to stage_index <= 1
now that WinPE startnet posts idx=1.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wires the imaging-progress helper into the three PC-type setup scripts
that were either clean (CMM) or untracked (Common, Heattreat). Each
gains two calls per the pattern committed for Keyence in 9122b28:
* idx 5/8 - "09-Setup-<Type>: starting" right after the session start banner
* idx 6/8 - "09-Setup-<Type>: complete" just before the completion banner
Display, Genspect, and WaxAndTrace also got the same two-line additions
locally and on the live server, but those files have pre-existing WIP
edits intermixed so they aren't staged here. They'll travel along
when the operator commits their unrelated shopfloor work.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
