From a90dcb480b7e383e1d38bb1bdd1500ef9024364f Mon Sep 17 00:00:00 2001 From: rcourtman Date: Tue, 31 Mar 2026 09:51:49 +0100 Subject: [PATCH] Clarify VMware first-lab-ready harness --- .../v6/internal/PLATFORM_SUPPORT_MODEL.md | 38 ++++++++++++++-- .../v6/internal/SOURCE_OF_TRUTH.md | 22 +++++++--- .../VMWARE_VCENTER_PHASE1_PROOF_MATRIX.md | 30 ++++++++++++- .../VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md | 43 +++++++++++++++---- ...vcenter-phase1-proof-blocked-2026-03-30.md | 8 ++++ docs/release-control/v6/internal/status.json | 21 +++++++++ .../release_control/subsystem_lookup_test.py | 1 + 7 files changed, 143 insertions(+), 20 deletions(-) diff --git a/docs/release-control/v6/internal/PLATFORM_SUPPORT_MODEL.md b/docs/release-control/v6/internal/PLATFORM_SUPPORT_MODEL.md index 0bea26a6b7..fb4ff81dc4 100644 --- a/docs/release-control/v6/internal/PLATFORM_SUPPORT_MODEL.md +++ b/docs/release-control/v6/internal/PLATFORM_SUPPORT_MODEL.md @@ -1,6 +1,6 @@ # Pulse v6 Platform Support Model -Last updated: 2026-03-30 +Last updated: 2026-03-31 Status: ACTIVE This file is the canonical governed model for platform support in Pulse v6. @@ -170,6 +170,32 @@ is not acceptable. 3. `read-only` 4. `n/a` +## Pre-Support Readiness Stages + +An admitted first-class platform may be real engineering work long before it +is honest to call it supported. Pulse therefore uses one governed pre-support +checkpoint so delivery progress is visible without inflating the support claim. + +1. `architecture-locked` + The admission model is resolved and implementation may start, but the + platform is still only a planned or admitted direction. +2. `first-lab-ready` + The architecture is locked, the bounded shared phase floor is implemented, + automated non-live proof covers that floor well enough to catch regression, + and the next highest-value step is a real lab or customer environment run. + `first-lab-ready` is an implementation checkpoint, not a support claim. +3. `supported` + Live proof validates the declared floor and the platform is admitted into + the current support matrix. + +Rules: + +1. Only `supported` changes the current support matrix. +2. `first-lab-ready` may be used in execution plans, proof matrices, + blocked-proof records, and progress reporting for admitted platforms. +3. `first-lab-ready` must not leak into product wording, settings wording, or + Assistant behavior as if support already exists. + ## Current Classification ### First-class platforms @@ -297,9 +323,9 @@ starts. artifacts out of the phase-1 projection contract unless a later governed slice proves they belong on the shared path -| Platform | Family | Entry point | Primary mode | Optional augmentation | Canonical projections | Admission state | -| --- | --- | --- | --- | --- | --- | --- | -| `vmware-vsphere` | VMware | `vCenter` only in phase 1 | `api-backed` | host or guest agent later, not phase 1 | `agent`, `vm`, `storage` | architecture locked, not yet admitted | +| Platform | Family | Entry point | Primary mode | Optional augmentation | Canonical projections | Admission state | Readiness stage | +| --- | --- | --- | --- | --- | --- | --- | --- | +| `vmware-vsphere` | VMware | `vCenter` only in phase 1 | `api-backed` | host or guest agent later, not phase 1 | `agent`, `vm`, `storage` | architecture locked, not yet in support matrix | `first-lab-ready` | ## VMware vSphere Proposed Phase-1 Floor @@ -346,3 +372,7 @@ history truth, and assistant read behavior. If that proof does not hold, implementation must stop at governance rather than widening the support claim. The concrete first-implementation slice order and stop/go checks live in `docs/release-control/v6/internal/VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md`. +As of 2026-03-31, VMware has reached the governed `first-lab-ready` +checkpoint: the non-live phase-1 floor is implemented and regression-proofed +well enough that the next proper step is a real `vCenter` proof run rather +than more architecture work. diff --git a/docs/release-control/v6/internal/SOURCE_OF_TRUTH.md b/docs/release-control/v6/internal/SOURCE_OF_TRUTH.md index 8c072b0de5..28f9ce54a9 100644 --- a/docs/release-control/v6/internal/SOURCE_OF_TRUTH.md +++ b/docs/release-control/v6/internal/SOURCE_OF_TRUTH.md @@ -499,6 +499,12 @@ VMware is the current admitted next-platform direction for Pulse, but it is not yet a supported platform claim. This section defines the only acceptable phase-1 floor while support remains proof-gated. +Pulse also now distinguishes an admitted platform that is merely +`architecture-locked` from one that is `first-lab-ready`: `first-lab-ready` +means the bounded non-live phase floor is implemented and regression-proofed +well enough that the next proper move is a real lab run, while the support +claim stays blocked until live proof passes. + 1. Architecture boundary: VMware vSphere should enter Pulse only as the first-class `vmware-vsphere` platform. Phase 1 is `vCenter` only; direct `ESXi` is @@ -536,29 +542,35 @@ phase-1 floor while support remains proof-gated. though VMware exposes power, snapshot, and guest-operation APIs, because Pulse is not yet claiming a broad VMware action plane ahead of the existing action-governance coverage gap. -8. Support gate: +8. Current implementation checkpoint: + VMware may be described internally as `first-lab-ready` once the shared + phase-1 onboarding, projection, alert/history, and Assistant-read floor is + implemented with automated non-live proof. `first-lab-ready` is an + implementation milestone only; it does not change the support matrix or any + user-facing support wording. +9. Support gate: Do not call VMware supported until one real `vCenter` capability is recorded in `LOCAL_CAPABILITIES.md` and proves connection onboarding, the minimum privilege bundle, the supported version floor, canonical `agent`/`vm`/`storage` projection, alert and metrics-history truth, and assistant read behavior. If those proofs do not hold, implementation should stop at governance rather than shipping an inflated support claim. -9. Execution sequence: +10. Execution sequence: VMware phase-1 execution should follow `docs/release-control/v6/internal/VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md` as the concrete slice order and stop/go contract for the first admitted VMware support floor. -10. Projection contract: +11. Projection contract: VMware phase-1 projection should also follow `docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_RESOURCE_PROJECTION_SPEC.md` as the canonical source, identity, topology, alert-mapping, and non-projection boundary for phase-1 VMware resources. -11. Alerts and Assistant contract: +12. Alerts and Assistant contract: VMware phase-1 alerts and Assistant work should also follow `docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_ALERTS_AND_ASSISTANT_SPEC.md` as the canonical shared-alert, shared-timeline, Assistant-read, and Assistant-control-exclusion boundary for the VMware phase-1 floor. -12. Backend API/runtime contract: +13. Backend API/runtime contract: VMware phase-1 backend API/runtime work should also follow `docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_API_RUNTIME_SPEC.md` as the canonical public API-boundary, session-ownership, provider-health, diff --git a/docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_PROOF_MATRIX.md b/docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_PROOF_MATRIX.md index 048f51d514..bdc7695ecd 100644 --- a/docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_PROOF_MATRIX.md +++ b/docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_PROOF_MATRIX.md @@ -1,7 +1,7 @@ # VMware vCenter Phase-1 Proof Matrix Last updated: 2026-03-31 -Status: PLANNED +Status: ACTIVE Governance surfaces: - `status.json.candidate_lanes.platform-admission-execution` - `docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_API_RUNTIME_SPEC.md` @@ -14,12 +14,14 @@ Use this matrix as the live-proof runbook for the trust-critical boundary between: 1. a planned VMware architecture -2. an implemented VMware onboarding and projection path +2. an implemented VMware phase-1 floor that may be `first-lab-ready` 3. an honest claim that VMware is actually supported in Pulse This matrix does not replace repo-local tests. It exists because VMware can look correct in isolated API, poller, or UI work while still failing the real support floor on a live `vCenter`. +It also defines when the non-live harness may honestly say `first-lab-ready` +instead of collapsing all progress into the same `not supported` bucket. ## Governing Policy @@ -128,6 +130,30 @@ boundary: prove the shipped route and browser surface stay out of direct `ESXi`, recovery, and VMware admin-plane territory. +## First-Lab-Ready Checkpoint + +Pulse may classify VMware `first-lab-ready` before live proof only when all of +these are true: + +1. the governed architecture is locked +2. the bounded phase-1 floor is implemented on shared paths +3. automated non-live proof covers shared onboarding, canonical projection, + alerts/history, Assistant read, and exclusion integrity +4. the remaining blockers to a support claim are live-only facts rather than + missing shared product work + +`first-lab-ready` means the next proper move is a real `vCenter` run. +It does not mean VMware is supported, marketed, or admitted into the support +matrix. + +Current state as of 2026-03-31: + +1. VMware meets the governed `first-lab-ready` checkpoint. +2. The next highest-value step is a real `vCenter` proof pass through + `VC-0` through `VC-7`. +3. Repeating `not supported` without also reporting `first-lab-ready` is no + longer an accurate description of implementation progress. + ## Scenario Matrix | ID | Scenario | Pass focus | diff --git a/docs/release-control/v6/internal/VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md b/docs/release-control/v6/internal/VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md index 5e0b2146cc..cc24e03b10 100644 --- a/docs/release-control/v6/internal/VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md +++ b/docs/release-control/v6/internal/VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md @@ -1,7 +1,7 @@ # VMware vSphere Phase-1 Execution Plan -Last updated: 2026-03-30 -Status: PLANNED +Last updated: 2026-03-31 +Status: ACTIVE Governance surfaces: - `status.json.candidate_lanes.platform-admission-execution` - `status.json.resolved_decisions.vmware-vsphere-vcenter-first-admission-model` @@ -10,7 +10,25 @@ Governance surfaces: Pulse now has a locked architecture recommendation for VMware vSphere. This document turns that recommendation into an executable phase-1 plan so -implementation can start without drifting into a provider-specific island. +implementation can proceed without drifting into a provider-specific island, +and so the harness can distinguish real pre-support progress from the final +support claim. + +## Current Checkpoint + +Current governed checkpoint: `first-lab-ready`, not `supported`. + +That means: + +1. the architecture and support floor are locked +2. the bounded shared phase-1 implementation floor is landed +3. automated non-live proof covers the shared onboarding, projection, + alerts/history, Assistant-read, and exclusion boundaries well enough that + the next highest-value step is a real `vCenter` run +4. the remaining blockers to a support claim are live-only facts: privilege + floor, supported version floor, and real-signal fidelity + +This checkpoint is an implementation handoff, not a product support claim. ## Support Decision @@ -24,7 +42,7 @@ Pulse should add VMware support, but only in one narrow form: 6. assistant control: `read-only` 7. recovery support: `n/a` -Implementation may start next on that basis. +Implementation may continue on that basis. If live validation disproves the minimum privilege bundle, supported version floor, or declared support-floor coverage, Pulse should stop at governance and must not widen the support claim. @@ -258,9 +276,16 @@ VMware/Broadcom APIs: 5. performance/history: [PerformanceManager QueryPerfComposite](https://developer.broadcom.com/xapis/virtual-infrastructure-json-api/latest/sdk/vim25/release/PerformanceManager/moId/QueryPerfComposite/post/) -## Start Decision +## Next Decision -Implementation should start next only as slice 1 of this plan. -If slice 1 cannot prove the minimum privilege bundle and supported version -floor on a real `vCenter`, Pulse should stop and record that gap instead of -moving forward as if VMware were already supportable. +The next proper move is the first real `vCenter` proof run. + +Additional non-live VMware work is still valid only when it: + +1. closes a newly found shared-contract or shared-runtime gap +2. materially reduces first-lab risk +3. strengthens the same governed phase-1 floor instead of adding synthetic + VMware-local polish + +Do not keep extending VMware through repetitive non-live polish once this plan +is already `first-lab-ready`. diff --git a/docs/release-control/v6/internal/records/vmware-vcenter-phase1-proof-blocked-2026-03-30.md b/docs/release-control/v6/internal/records/vmware-vcenter-phase1-proof-blocked-2026-03-30.md index e19245d7ef..dc3f81f78e 100644 --- a/docs/release-control/v6/internal/records/vmware-vcenter-phase1-proof-blocked-2026-03-30.md +++ b/docs/release-control/v6/internal/records/vmware-vcenter-phase1-proof-blocked-2026-03-30.md @@ -27,6 +27,14 @@ Pulse has enough evidence to say what the VMware support model should be, but not enough evidence to say VMware is supported in practice. +Current non-live checkpoint: + +1. VMware is now `first-lab-ready`. +2. The shared phase-1 implementation floor and automated non-live proof are + far enough along that the next proper move is a real `vCenter` run. +3. Additional non-live work should be justified only when it closes a newly + discovered shared-contract gap or materially reduces first-lab risk. + The support-claim ratchet now requires both: 1. one real `vCenter` capability recorded in `LOCAL_CAPABILITIES.md` diff --git a/docs/release-control/v6/internal/status.json b/docs/release-control/v6/internal/status.json index 1d16d0ab8d..de07921e55 100644 --- a/docs/release-control/v6/internal/status.json +++ b/docs/release-control/v6/internal/status.json @@ -4113,6 +4113,27 @@ "L15", "L16" ] + }, + { + "id": "platform-admission-first-lab-ready-stage", + "summary": "Admitted but not yet supported platforms now have one governed pre-support checkpoint, `first-lab-ready`: the architecture is locked, the shared phase floor is implemented, automated non-live proof is strong enough that the next highest-value step is live validation, and the support claim remains blocked until that live proof passes.", + "kind": "governance", + "decided_at": "2026-03-31", + "subsystem_ids": [ + "agent-lifecycle", + "ai-runtime", + "alerts", + "api-contracts", + "monitoring", + "storage-recovery", + "unified-resources" + ], + "lane_ids": [ + "L6", + "L13", + "L15", + "L16" + ] } ] } diff --git a/scripts/release_control/subsystem_lookup_test.py b/scripts/release_control/subsystem_lookup_test.py index e751901b40..adb5106e5f 100644 --- a/scripts/release_control/subsystem_lookup_test.py +++ b/scripts/release_control/subsystem_lookup_test.py @@ -4381,6 +4381,7 @@ class SubsystemLookupTest(unittest.TestCase): "canonical-timeline-source-precedence", "host-type-migration-boundary-audit", "mixed-private-infrastructure-operations-direction", + "platform-admission-first-lab-ready-stage", "platform-support-model-v1", "vmware-vsphere-vcenter-first-admission-model", "vmware-vsphere-vcenter-support-claim-ratchet",