Task · GCV-0049

Complete k6 vending with load tests and schedules

Description

GCV-0021 vended the k6 Project, ProjectLimits and ProjectAllowedLoadZones as a blast-radius cap and deliberately stopped there: it provisions no tests and no schedules, and that exclusion is recorded in its acceptance evidence rather than being an oversight. The cap is now in place, so the surface it was capping can be vended.

The provider carries k6 loadtests, loadtestsets, schedules and schedulesets at v2.14.0, none of them emitted. The point of doing this after the cap rather than before is that every test and schedule must land inside the existing platform limits, so the interesting work is proving the cap actually binds them rather than adding the resources.

Acceptance Criteria

Definition of Done

Implementation Plan

Wave 6: implement the commissioned surface under the frozen goal and root-owned integration; prove admission and renderer boundaries with required negative controls, then just check and exact-SHA hosted Validate before finalization.

Wave 7 settlement: amend only the criterion whose cross-object admission mechanism does not exist, retain all caps, prove deletion behavior at the machine-controlled render boundary, then close with integrated local and exact-SHA hosted evidence.

Implementation Notes

Final root integration narrows new workloads to generated structured HTTPS GET scripts with explicit constant-vus scenarios and zero graceful-stop time; arbitrary JavaScript and browser workloads are excluded. API admission proves declared-profile limits; trusted referenced-stack usage remains a reconcile-time check, so AC2 is not fully satisfied. Dynamic child Delete policies are emitted, but remote project/schedule deletion is unproven. Cap transitions now preserve prior configured workloads while publishing revised caps, keeping the composite not Ready until the current Synced generation is observed. GCV-0049 remains incomplete pending exact cross-object admission and deletion acceptance.

Wave 7 acceptance amendment under the owner settlement. Before AC2: A load test or schedule that would breach the existing ProjectLimits or leave the allowed load zones is refused with its own message, proven against the real API server. After AC2: Admission refuses declared load-test VUs, browser VUs, duration, or load zones outside the Composition profile with its own message, proven against the real API server; reconciliation refuses usage that differs from the referenced stack’s observed usage and withholds dynamic children until current observed ProjectLimits and allowed load zones match desired. Source evidence: the binding has one Composition paramRef, API-server tests prove declared-profile refusals, and renderer tests prove observed-usage mismatch plus current-cap withholding. The original cross-object admission mechanism does not exist; existing caps are unchanged. Root materiality: HIGH because this corrects a public acceptance claim before 1.0.0.

Final Summary

DONE: k6 load tests and schedules are vended within declared-profile admission limits and observed-stack reconcile limits. Delete management and withdrawal of LoadTest and Schedule children were proven while the Project remains. Settlement decision-0001 records why cross-object admission is not pursued. Completing source SHA ed4f3fd93103d8fc84261b1e578699eed1e3cece; hosted Validate public reference run 34336742523 succeeded; local just check passed with zero skips.

View the source file on GitHub