🎯 Objective

Take the platform from the developer's terminal to the bench: Init-->Develop-->Comply(quantum-standard)-->Field Test for devices and experiments. The hub modules should be verified on the hardware it drives, by the person who runs that rig, with a report that lands in the repo and on the hub — and the tooling that makes a field test a fifteen-minute job instead of an afternoon. What the previous milestone built (the field-test contract, plesty init field-test, the client tier, the reports as a first-class artifact) is now used across the whole HUB, and every bug it surfaces is fixed in the release that follows.

🚀 Expected Outcomes

1. Device rotation. Every quantum-standard HUB device is field-tested on its instrument, host and client tier, and the reports are committed under reports/<INSTRUMENT>/ and shown on the hub.
2. Experiment field test (plesty-lib#28). The tier below the composite: one run per config file, verifying build_plan(), each Step.op, the retry path, journal and resume — with a report — replacing the hand-rolled scripts/field_test.py in plesty-pol-pl and plesty-pl-image-scan.
3. Bench tooling (governance#22, plesty-server). Install, launch and supervise a rig's device servers from a fleet.yaml, with the field-test runner and the report copy built in; Windows first.
4. Friction goes to zero. Everything the rotation finds is a field-test issue and is fixed before the next rotation (plesty-sdk#32, plesty-lib#38 set the pattern); the interview and /plesty:field-test decide their answers from the device, not from the tester's memory.
5. Releases. plesty-lib / plesty-sdk 0.4 carry the full field-test contract — host, client and experiment tiers — and the HUB modules move to it.

🛑 Main Updates

The field-test experiences from real test on devices. Track the main updates and considerations here.

• (lib#39) Initial definition of field test kinds(read, motion, acquire, lifecycle, control, configure) on device operations.