Task · SKT-0033

Make control UI, inventory, diagnostics, and scaling self-verifying

Description

SKT-0011 scenarios C5, D5, D6, and D8 could reach the control surfaces, but the UI path yielded only a redirect in the clean-container check, inventory exposed no per-blueprint entries, diagnostics did not establish shell-free sufficiency, and the full catalogue exposed zero scalable targets. The round could not verify every UI view, identity separation, or a real scaling mutation from the supplied control data.

Acceptance Criteria

Definition of Done

Implementation Plan

Lane B makes UI, inventory, diagnostics, reset, and scaling self-verifying; root performs emitted-data mutation checks live.

2026-08-31 Root-owned: add a failing runner regression for the inert scale multiplier, inspect the prior high_dpm floor seam, fix composition-root propagation, and prove both scale and reset transitions in emitted live rate without changing the assertion.

Implementation Notes

2026-08-30 closeout: UI enumeration, per-blueprint/substrate inventory, lane diagnostics, and a scalable acceptance target landed. Live scale 2 to 4 and reset were accepted and read back, but emitted rate ratios were 0.977853 while scaled and 0.995540 after reset.

2026-08-31 live proof: scaling the declared application service from 2 to 4 changed the two-minute server-span increase from 926.04 to 2120.12, a 2.29x ratio. Reset produced 966.01, 1.04x baseline, and cleared the control scaling map. HTTP status alone was not used as evidence.

Final Summary

Parked at AC#5. Resume in the runner scaling path and require the selected target live rate to move with the configured multiplier before accepting reset/scaling as self-verifying.

2026-08-31: Propagated the scale multiplier through the runner to the declared application service and proved scale plus reset through emitted live span-rate movement. The final gates passed.

References

View the source file on GitHub