diff --git a/docs/release-control/v6/internal/PRE_RELEASE_CHECKLIST.md b/docs/release-control/v6/internal/PRE_RELEASE_CHECKLIST.md index c034f8510..8436c6e1f 100644 --- a/docs/release-control/v6/internal/PRE_RELEASE_CHECKLIST.md +++ b/docs/release-control/v6/internal/PRE_RELEASE_CHECKLIST.md @@ -20,8 +20,9 @@ Use this as the final gate before cutting a Pulse v6 pre-release. - The latest RC publication judgment packet is `docs/release-control/v6/internal/records/rc-publication-judgment-packet-2026-04-09.md`. It does not clear the open decision: the active-target proof currently blocks - on the parallel `pulse-enterprise` approval-handler slice requiring - `go mod tidy`. + in `pulse/internal/api` because `vmware_handlers.go` still references the old + monitored-system helper names instead of the canonical `...FromUsage` + helpers. - The active target is back on `v6-rc-cut`, so GA rehearsal remains intentionally out of scope until a real RC has actually shipped and promotion is resumed explicitly. diff --git a/docs/release-control/v6/internal/records/rc-publication-judgment-packet-2026-04-09.md b/docs/release-control/v6/internal/records/rc-publication-judgment-packet-2026-04-09.md index 15fb2dda2..97b72624a 100644 --- a/docs/release-control/v6/internal/records/rc-publication-judgment-packet-2026-04-09.md +++ b/docs/release-control/v6/internal/records/rc-publication-judgment-packet-2026-04-09.md @@ -72,7 +72,7 @@ Result: 3. `frontend-grandfathered-license-presentation`: pass. 4. `pulse-pro-public-checkout-reentry-guard`: pass. -## Current Blocker +## Enterprise Follow-Up After the `RA16` proof repair, the full active-target guard was rerun. It progressed through the earlier RC proof slices and then blocked at `RA17`: @@ -100,7 +100,15 @@ go: updates to go.mod needed; to update it: The `pulse-enterprise` repo already had unrelated dirty files in `cmd/pulse-enterprise/main.go` and `cmd/pulse-enterprise/main_test.go` before this packet was written. Those changes appear to belong to another parallel -slice, so this packet does not run `go mod tidy` or edit `pulse-enterprise`. +slice, so the dependency fix stayed limited to the module graph only. + +`pulse-enterprise` was repaired with: + +```text +abdcd2d chore(deps): tidy enterprise module graph +``` + +That commit touched only `go.mod` and `go.sum`. The mobile portions of the `RA17` proof passed: @@ -117,19 +125,58 @@ python3 scripts/release_control/readiness_assertion_guard.py --assertion RA18 Result: pass. +The isolated `RA17` proof was then rerun: + +```bash +python3 scripts/release_control/internal/mobile_relay_auth_approvals_proof.py --json +``` + +Result: all subchecks passed, including `enterprise-approval-handlers`. + +## Current Blocker + +With the enterprise module graph repaired, the full active-target guard was +rerun outside the sandbox so the loopback test server could bind normally. That +run progressed past `RA17` and then blocked earlier in the Pulse runtime at +`RA3`/`RA4`: + +```text +BLOCKED: readiness assertion proof failed for RA3,RA4:entitlement-gating-api-tests (exit 1) +``` + +The concrete failure is now a Pulse API build break: + +```text +internal/api/vmware_handlers.go:672:14: undefined: monitoredSystemLimitDecisionForRecords +internal/api/vmware_handlers.go:712:14: undefined: monitoredSystemLimitDecisionForRecordsReplacement +``` + +The canonical helpers currently present in the repo are: + +```text +internal/api/monitored_system_limit_enforcement.go:289: monitoredSystemLimitDecisionForRecordsFromUsage +internal/api/monitored_system_limit_enforcement.go:313: monitoredSystemLimitDecisionForRecordsReplacementFromUsage +``` + +That means the RC blocker is no longer the enterprise repo. The current blocker +is an in-progress Pulse monitored-system enforcement/admission slice where +`vmware_handlers.go` still references the pre-rename helper names while the +shared contract has already moved to the `...FromUsage` helpers. + ## Judgment Outcome Do not clear `rc-publication-judgment` from this packet. The release-control metadata is close to the RC floor, but the current -workspace cannot complete the active-target proof while the enterprise approval -handler slice requires `go mod tidy`. Publishing an RC from this state would -turn a parallel worktree hygiene problem into an ambiguous release decision. +workspace still cannot complete the active-target proof. Publishing an RC from +this state would let an incomplete Pulse monitored-system slice masquerade as a +governed release judgment. ## Required Unblock Steps -1. Resolve the `pulse-enterprise` mod-tidy requirement in the owning - enterprise slice. +1. Finish the Pulse monitored-system enforcement/admission slice so + `internal/api/vmware_handlers.go` uses the canonical helper names that + currently exist in `monitored_system_limit_enforcement.go`. 2. Return all active repos needed for the RC proof to a clean, intentional state. 3. Rerun: diff --git a/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md b/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md index 40c259ff5..cac39cd5b 100644 --- a/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md +++ b/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md @@ -9,26 +9,23 @@ 1. No Pulse v6 prerelease has shipped yet. 2. The repository contains accidental prerelease git tag history (`v6.0.0-rc.1`), but those tags were never published and do not count as shipped prerelease lineage. -3. The selected remote ref `origin/pulse/v6-release` is still behind the current - local governed branch state, so `Release Dry Run` would exercise stale remote - control-plane metadata instead of the intended candidate. -4. The governed release profile in `docs/release-control/control_plane.json` +3. The governed release profile in `docs/release-control/control_plane.json` currently declares both `prerelease_branch` and `stable_branch` as `pulse/v6-release`. -5. The active control-plane target is still `v6-rc-cut`, not +4. The active control-plane target is still `v6-rc-cut`, not `v6-ga-promotion`. -6. The active local `pulse/v6-release` branch currently reports `VERSION=6.0.0-dev`, so the +5. The active local `pulse/v6-release` branch currently reports `VERSION=6.0.0-dev`, so the working line is still prerelease and there is not yet a governed local stable `6.0.0` candidate. -7. There is still no governed `Prerelease-to-GA Rehearsal Record` proving a successful +6. There is still no governed `Prerelease-to-GA Rehearsal Record` proving a successful non-publish `Release Dry Run` for the eventual stable `6.0.0` candidate. -8. `docs/releases/RELEASE_NOTES_v6.md` and +7. `docs/releases/RELEASE_NOTES_v6.md` and `docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md` still leave the GA announcement dates as placeholders because no real prerelease lineage or GA-ready rehearsal has locked them yet: - `v6` GA date placeholder: `[v6-ga-date]` - `v5` end-of-support placeholder: `[v5-eos-date]` -9. There is still no governed `Release Dry Run` artifact or rehearsal record +8. There is still no governed `Release Dry Run` artifact or rehearsal record exercising stable inputs for: - `version=6.0.0` - no governed `promoted_from_tag` exists yet because no prerelease has shipped diff --git a/docs/release-control/v6/internal/status.json b/docs/release-control/v6/internal/status.json index 733cd1c73..50f7fcc39 100644 --- a/docs/release-control/v6/internal/status.json +++ b/docs/release-control/v6/internal/status.json @@ -4225,7 +4225,7 @@ "open_decisions": [ { "id": "rc-publication-judgment", - "summary": "Pulse v6 prerelease publication remains an explicit product judgment: the 2026-04-09 packet records that the current active-target proof is blocked by the parallel pulse-enterprise approval-handler mod-tidy state, so `rc_ready` stays blocked until that proof passes and the owner explicitly approves a real governed RC.", + "summary": "Pulse v6 prerelease publication remains an explicit product judgment: the 2026-04-09 packet records that the enterprise module drift was repaired, but the current active-target proof still blocks in Pulse because `internal/api/vmware_handlers.go` references pre-rename monitored-system helper names instead of the canonical `...FromUsage` helpers, so `rc_ready` stays blocked until that proof passes and the owner explicitly approves a real governed RC.", "owner": "project-owner", "blocking_level": "rc-ready", "status": "blocked",