vrr/Pulse
2
0
Fork 0
mirror of https://github.com/rcourtman/Pulse.git synced 2026-10-19 10:33:29 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 13

Clarify VMware first-lab-ready harness

Browse source
This commit is contained in:
rcourtman 2026-03-31 09:51:49 +01:00
parent 98a0b37d8c
commit a90dcb480b
7 changed files with 143 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

38
docs/release-control/v6/internal/PLATFORM_SUPPORT_MODEL.md
View file

@ -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.

22
docs/release-control/v6/internal/SOURCE_OF_TRUTH.md
View file

@ -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,

30
docs/release-control/v6/internal/VMWARE_VCENTER_PHASE1_PROOF_MATRIX.md
View file

@ -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 |

43
docs/release-control/v6/internal/VMWARE_VSPHERE_PHASE1_EXECUTION_PLAN.md
View file

@ -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`.

8
docs/release-control/v6/internal/records/vmware-vcenter-phase1-proof-blocked-2026-03-30.md
View file

@ -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`

21
docs/release-control/v6/internal/status.json
View file

@ -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"
]
}
]
}

1
scripts/release_control/subsystem_lookup_test.py
View file

@ -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",