docs: define v1 stabilization dev lane policy

2026-05-19 03:47:19 +00:00
parent 9d46ca2531
commit f36ea37548
3 changed files with 28 additions and 0 deletions
@@ -39,6 +39,8 @@ The CLI may be run from `master` if it remains backward compatible with the pinn

 CI/CD services should report their source commit, API/schema capability, supported environments and supported operations. CI diagnostics should include that information when rejecting an operation as unsupported.

+During a `release/v1` stabilization window, CI should continue using the implemented dev desired-state contract rather than adding split-lane infrastructure. The `origin/master:deploy.json#environments.dev` service pins may point at v1 stabilization commits for validation, but CI must print the manifest commit and service commits it used. Explicit `dev-v1` and `dev-master` support is a later infrastructure change after v1 is stable.
+
 Steps that call the Kubernetes API directly clear inherited proxy variables so service-account HTTPS calls to `kubernetes.default.svc` do not accidentally use the Code Queue image's Docker Compose proxy defaults.
 The rollout poll reads the Deployment main resource rather than the `/status` subresource, keeping CI RBAC limited to the same app/service resources it creates and deletes.
 The performance probe scans recent Code Queue tasks until it finds one with trace steps, so a newly selected task without persisted step detail does not make the whole gate fail before measuring the trace endpoints.