pulse/docs/release-control/v6/internal/PRE_RELEASE_CHECKLIST.md

Pulse v6 Pre-Release Checklist

Use this as the final gate before cutting a Pulse v6 pre-release.

Execution Notes

• Run the commands from the repository root unless a step says otherwise.
• Treat every failed command or failed scenario as a release blocker until it is explained or fixed.
• If the mobile app is part of the release, run the mobile checks from /Volumes/Development/pulse/repos/pulse-mobile.
• Record pass/fail notes inline in this file or in the release ticket as each section is completed.
• Use HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md for the trust-critical hosted, relay, mobile, entitlement, org-scope, and API-token checks that must be manually confirmed before release.
• Follow RELEASE_PROMOTION_POLICY.md for channel routing, prerelease soak, stable promotion, and rollback expectations.

Current Status

• Automated command-driven checks completed on 2026-03-06 are marked [x] below.
• status.json is no longer overclaiming threshold-unmet gates as passed.
• There are no remaining rc-ready high-risk release-gate blockers, and the explicit rc-publication-judgment was approved on 2026-04-09 for the first governed Pulse v6 RC.
• The latest RC publication judgment packet is docs/release-control/v6/internal/records/rc-publication-judgment-packet-2026-04-09.md. It now records approval, not a proof blocker.
• The active target is now v6-product-lane-expansion; the stable promotion packet is no longer the only release-ready concern, and release-ready gates must still fail closed if the product truth changes.
• rc-to-ga-promotion-readiness was cleared on 2026-04-20 by Release Dry Run run 24673393628, recorded at docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-rehearsal-2026-04-20.md.
• The stable 6.0.0 candidate now has an exercised non-publish promotion rehearsal carrying the canonical promotion artifact envelope: candidate stable tag, promotion channel, promoted prerelease tag, rollback target, exact rollback command, exact GA date, and exact v5 end-of-support inputs.
• known-rc-issue-closure-for-ga was introduced on 2026-04-21 to reflect the locked rule that v6 GA must be feature-complete relative to the prerelease issue set. It is currently blocked on the dated RC issue-closure packet.
• Mobile is in scope for the release and now has targeted readiness coverage in pulse-mobile.
• High-risk release confidence now lives in docs/release-control/v6/internal/HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md and should be cleared alongside this checklist.

Promotion Policy

• Record the previous stable tag and exact rollback pin command before publishing a new prerelease or stable release.
• For any prerelease or stable publication, confirm the repo variable PULSE_UPDATE_SIGNING_PUBLIC_KEY is set to the intended active update signer public key and that the release workflows are consuming it alongside PULSE_UPDATE_SIGNING_KEY, so accidental trust-root rotation fails closed before publication.
• For the GA/stable candidate, confirm the release pipeline has already been exercised on a real prerelease tag, not only linted or YAML-parsed.
• For stable promotion, confirm the candidate commit has already shipped on rc.
• For stable promotion, confirm the chosen promoted_from_tag is a prerelease that was actually published through the governed prerelease path, not an accidental git tag.
• For stable promotion, confirm the prerelease soak window is at least 72 hours or document the hotfix exception explicitly.
• For stable promotion, confirm paid production tenants are not being moved onto an unvalidated build.
• For GA/stable promotion, confirm V5_MAINTENANCE_SUPPORT_POLICY.md is still the intended policy and replace any placeholder GA notice dates with the exact v6 GA date and exact v5 end-of-support date that will ship with the announcement.
• For GA/stable promotion, confirm the pushed governed release-branch copy of .github/workflows/release-dry-run.yml already accepts the governed stable rehearsal metadata envelope (promoted_from_tag, rollback_version, ga_date, v5_eos_date) through workflow_dispatch, because GitHub executes the selected remote ref and does not see local-only governance state.
• For GA/stable promotion, confirm the local rehearsal branch exactly matches origin before dispatching Release Dry Run, so the run exercises the intended governed branch state instead of stale remote control-plane metadata.
• For GA/stable promotion, confirm the release rehearsal and publish workflows both derive the governed release branch from release-control metadata instead of hardcoding a branch name inline.
• For GA/stable promotion, materialize the final rehearsal record with python3 scripts/release_control/record_rc_to_ga_rehearsal.py --run-id <run-id> and, unless an explicit --output is chosen, confirm it lands at docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-rehearsal-<record-date>.md.
• For GA/stable promotion, attach the dated rehearsal record, Release Dry Run run URL, and rc-to-ga-rehearsal-summary artifact to the release ticket, and confirm that artifact records the canonical promotion metadata envelope for that candidate: candidate stable tag, promotion channel, promoted prerelease tag, rollback target, exact rollback command, planned GA date, and planned v5 end-of-support date.
• For v6 GA specifically, attach the exact self-hosted public forward and rollback packet from pulse-pro/V6_LAUNCH_CHECKLIST.md to the launch ticket: preview deploy/audit, production deploy/audit, and rollback deploy/audit commands must all be explicit before the gate can clear.

RC Issue Closure

• Materialize a dated RC issue-closure record for the actual GA candidate under docs/release-control/v6/internal/records/.
• Confirm that record enumerates the labeled affects-6.0.0-rc.* issues plus any additional open v6 RC-soak issues the project owner still expects v6 GA to address.
• Review the live RC feedback intake surface before GA signoff: newly opened issues, new issue comments, the pinned prerelease feedback hub, and equivalent actionable RC feedback must either be absorbed into the dated closure record or explicitly judged out of v6 GA scope.
• For each item, record exactly one disposition: fixed in the candidate with proof, invalid with evidence, or conservatively superseded with the original user-visible failure resolved or explicitly narrowed.
• Do not carry any open RC-era user-visible issue into GA as accepted “post-GA cleanup”.

Stable / GA Packet

Use this exact operator sequence when the stable 6.0.0 candidate is actually ready to rehearse. Replace the placeholder dates and run id with the real GA decision values; do not fill them in speculatively.

cd /Volumes/Development/pulse/repos/pulse
git fetch origin --tags
git status --porcelain
git rev-parse HEAD
git rev-parse origin/pulse/v6-release

# Confirm VERSION=6.0.0 first, then run the governed stable rehearsal helper.
./scripts/trigger-release-dry-run.sh 6.0.0

# After dispatch:
gh run list --workflow=release-dry-run.yml --limit 1
gh run watch <run-id>
python3 scripts/release_control/record_rc_to_ga_rehearsal.py --run-id <run-id>

For the same launch ticket, keep the exact public self-hosted commercial packet from /Volumes/Development/pulse/repos/pulse-pro/V6_LAUNCH_CHECKLIST.md alongside the release dry-run artifact:

# Preview deploy and audit (non-production URL/branch only)
cd /Volumes/Development/pulse/repos/pulse-pro
PULSE_PUBLIC_SITE_BRANCH=<preview-branch> \
PULSE_PUBLIC_SITE_URL=https://<preview-host> \
PULSE_LICENSE_PUBLIC_URL=https://<preview-license-host> \
PULSE_PUBLIC_RELEASE_TRACK=v6 \
PULSE_V6_RELEASE_APPROVED=1 \
./scripts/deploy-landing.sh

PULSE_PUBLIC_SITE_URL=https://<preview-host> \
PULSE_LICENSE_PUBLIC_URL=https://<preview-license-host> \
PULSE_PUBLIC_RELEASE_TRACK=v6 \
PULSE_V6_RELEASE_APPROVED=1 \
./scripts/audit_public_release.sh

# Production GA flip and rollback packet
PULSE_PUBLIC_RELEASE_TRACK=v6 PULSE_V6_RELEASE_APPROVED=1 ./scripts/deploy-landing.sh
PULSE_PUBLIC_RELEASE_TRACK=v6 PULSE_V6_RELEASE_APPROVED=1 ./scripts/audit_public_release.sh
PULSE_PUBLIC_RELEASE_TRACK=v5 PULSE_V6_RELEASE_APPROVED=0 ./scripts/deploy-landing.sh
PULSE_PUBLIC_RELEASE_TRACK=v5 PULSE_V6_RELEASE_APPROVED=0 ./scripts/audit_public_release.sh

Scope

• Confirm whether there is a separate mobile app codebase.
• If yes, do not call the whole product pre-release ready until that app is audited.
• If no, treat this checklist as the full product gate.

Worktree

• Run git status --porcelain.
• Confirm there are no tracked modified or staged files.
• Ignore only the known local untracked artifacts if they are expected:
  • .gocache/
  • .gotmp/
  • pulse-host-agent
  • unused_param_test.o

Run:

cd /Volumes/Development/pulse/repos/pulse
git status --porcelain

Canonical v6 Contract

• Verify the key canonical v6 hardening commits are present in the release target:
  • 26a88bf66512ec5cafaf6e597a5ba736d5ff279b internal/api/resources
  • c5eb7057a0b2a7e8dfbcd44470185a72d083feff internal/ai/tools
  • 3ab9d6c13 internal/servicediscovery
  • f89e4a56bcad9901edd6afc3212172845605d6e7 internal/api/state_provider / router_helpers
  • 7115143825647f5bfade7469fe20a324d3a76dbe internal/monitoring/monitor.go
• Verify the Patrol and frontend canonicalization commits required for the release target are included.
• Run the key backend/API/AI/frontend test slices that protect canonical v6 behavior.

Run:

cd /Volumes/Development/pulse/repos/pulse
git merge-base --is-ancestor 26a88bf66512ec5cafaf6e597a5ba736d5ff279b HEAD
git merge-base --is-ancestor c5eb7057a0b2a7e8dfbcd44470185a72d083feff HEAD
git merge-base --is-ancestor 3ab9d6c13 HEAD
git merge-base --is-ancestor f89e4a56bcad9901edd6afc3212172845605d6e7 HEAD
git merge-base --is-ancestor 7115143825647f5bfade7469fe20a324d3a76dbe HEAD
go test ./internal/api -run 'Test(FrontendResourceType|ApplyFrontendTypes|ComputeFrontendByType|ParseResourceTypesNodeAlias|UnsupportedResourceTypeFilterTokensRejectsLegacyAliases|ResourceListIncludesKubernetesPods|ResourceListFiltersCanonicalKubernetesNamespace|BuildDiscoveryTargetKubernetesPrefersAgentID|ResourceListRejectsLegacyKubernetesTypeAlias|ResourceListReturnsCanonicalKubernetesMetricsTargets|ResourceListProxmoxNodeReturnsFrontendNodeType|ResourceGetProxmoxNodeReturnsFrontendNodeType|ResourceListRejectsLegacyHostTypeFilter|ResourceListMergesLinkedHost|ResourceListUsesUnifiedSeedProvider|ResourceListDoesNotMergeOneSidedLinkedHost|ResourceGetResource|ResourceLinkMergesResources|ResourceReportMergeCreatesExclusions)$'
go test ./internal/ai/tools
go test ./internal/servicediscovery
go test ./internal/monitoring -run 'TestMonitor(GetUnifiedReadStateOrSnapshot|UnifiedResourceSnapshot)'
cd /Volumes/Development/pulse/repos/pulse/frontend-modern
npx vitest run src/utils/__tests__/frontendResourceTypeBoundaries.test.ts

Hosted / Cloud

• Run hosted signup and billing lifecycle tests.
• Verify hosted paid checkout fails closed when org linkage is missing.
• Verify replay succeeds once the linked org exists.
• Verify the normal hosted provisioning path still succeeds.
• Confirm commit 8b3a5d30246a86005d363b405126b0e9bfdda8d3 is present.
• Clear gate hosted-signup-billing-replay in HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md.

Run:

cd /Volumes/Development/pulse/repos/pulse
git merge-base --is-ancestor 8b3a5d30246a86005d363b405126b0e9bfdda8d3 HEAD
go test ./internal/api -run 'TestStripeWebhook_'
go test ./internal/cloudcp/... -count=1
go test ./internal/hosted/... -count=1

Canonical hosted staging smoke:

cd /Volumes/Development/pulse/repos/pulse
PULSE_CLOUD_BASE_URL='https://cloud-staging.pulserelay.pro' \
PULSE_CLOUD_SSH_TARGET='root@pulse-cloud-staging' \
PULSE_CP_ADMIN_KEY='<admin-key>' \
PULSE_E2E_STRIPE_API_KEY='<stripe-test-secret>' \
PULSE_E2E_STRIPE_WEBHOOK_SECRET='<stripe-webhook-secret>' \
./scripts/run_hosted_staging_smoke.sh

Notes:

• Set PULSE_E2E_HOSTED_TENANT_ID only when the mobile onboarding proof must target a specific tenant; otherwise the smoke script auto-selects the newest active tenant from /admin/tenants?state=active.
• This command covers the hosted signup, billing lifecycle, and hosted mobile onboarding proof pack. Environment-specific DNS/TLS/container preflight remains a separate operator step.

Manual scenario:

• Complete a hosted signup or replay a recorded checkout flow.
• Verify webhook handling does not return success when org linkage is unresolved.
• Verify a replay succeeds once the org exists.

Relay

• Run Relay tests end to end.
• Verify fresh register works.
• Verify reconnect works.
• Verify stale cached session resume recovers by fresh registration.
• Verify abrupt disconnect and inflight drain behavior still work.
• Confirm commit ee78cb33dd35b891d84e61bfce2098b4548bbb56 is present.
• Clear gate relay-registration-reconnect-drain in HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md.

Run:

cd /Volumes/Development/pulse/repos/pulse
git merge-base --is-ancestor ee78cb33dd35b891d84e61bfce2098b4548bbb56 HEAD
go test ./internal/relay -count=1 -timeout=120s

Manual scenario:

• Connect a Relay client normally.
• Force a stale cached session or server-side session eviction.
• Verify the client retries with fresh registration instead of hanging in resume/backoff loops.

Multi-Tenant / MSP

• Run multi-tenant tests.
• Verify unknown non-default orgs fail closed.
• Verify explicitly provisioned orgs initialize correctly.
• Verify there is no default-org fallback for non-default tenant requests.
• Confirm commit f090a77ae is present.
• Clear gate organization-user-scope-and-rbac in HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md.

Run:

cd /Volumes/Development/pulse/repos/pulse
git merge-base --is-ancestor f090a77ae HEAD
go test ./internal/monitoring -run 'TestMultiTenantMonitor'
go test ./internal/api -run 'TestMultiTenantStateProvider_|TestSetMultiTenantMonitor_WiresHandlers|TestResourceHandlers_NonDefaultOrg|TestMultiTenant_ConcurrentAPIStress'

Manual scenario:

• Use a non-default org header/cookie/token that does not correspond to a provisioned tenant.
• Verify monitor/API access fails closed.
• Provision the tenant explicitly and verify access succeeds afterwards.

Frontend Smoke

• Verify dashboard/workloads.
• Verify infrastructure/discovery.
• Verify alerts/investigate.
• Verify reporting/settings.
• Verify metrics history / charts.
• Confirm canonical routes and page state still behave correctly.

Run:

cd /Volumes/Development/pulse/repos/pulse/frontend-modern
npx vitest run src/routing/__tests__/resourceLinks.test.ts src/routing/__tests__/navigation.test.ts src/utils/__tests__/frontendResourceTypeBoundaries.test.ts src/api/__tests__/chartsApi.test.ts src/hooks/__tests__/useDashboardTrends.test.ts

Manual scenario:

• Open workloads, infrastructure/discovery, alerts, reporting, and metrics screens.
• Verify workload URLs use canonical types.
• Verify Kubernetes/pod pages and investigation paths still behave correctly.

AI / Tools Smoke

• Verify pulse_query works.
• Verify Kubernetes tools work through unified read-state.
• Verify PMG tools still work.
• Verify Patrol scoped runs still behave correctly.
• Clear gate paid-feature-entitlement-gating in HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md.

Run:

cd /Volumes/Development/pulse/repos/pulse
go test ./internal/ai/tools -count=1
go test ./internal/ai -count=1

Manual scenario:

• Run representative pulse_query, Kubernetes, PMG, and Patrol flows.
• Verify scoped Patrol runs only see and mutate in-scope resources.

Release-Facing Scenarios

• Agent registration / install journey.
• /api/resources filtering and resource detail retrieval.
• Relay pairing flow.
• Hosted signup / org creation / billing webhook replay.
• Commercial cancellation / reactivation journey.
• Multi-tenant org switching / tenant-bound API calls.
• AI investigate / execute / query on canonical resource types.

Run:

cd /Volumes/Development/pulse/repos/pulse/tests/integration
npx tsc --noEmit

Manual scenario:

• Walk the user-visible flows end to end in a staging-like environment.
• Confirm the canonical resource model holds up in real UI/API usage, not only in unit tests.

Final Verification

• Run the final targeted Go test slices required for release confidence.
• Run the relevant frontend tests/build checks for canonicalized surfaces.
• Document any known unrelated failures explicitly before release.
• Confirm there are no new high-severity regressions in hosted, relay, tenant isolation, or canonical v6 boundaries.

Run:

cd /Volumes/Development/pulse/repos/pulse
go test ./internal/api/... -count=1
go test ./internal/relay/... -count=1
go test ./internal/cloudcp/... -count=1
go test ./internal/hosted/... -count=1
go test ./internal/monitoring/... -count=1
go test ./internal/ai/... -count=1
cd /Volumes/Development/pulse/repos/pulse/frontend-modern
npx vitest run

If mobile is in scope, also run:

cd /Volumes/Development/pulse/repos/pulse-mobile
git status --porcelain
npm test -- --runTestsByPath src/utils/__tests__/secureStorage.test.ts src/stores/__tests__/instanceStore.test.ts src/stores/__tests__/authStore.test.ts
npx jest --runInBand --runTestsByPath src/relay/__tests__/client.test.ts src/relay/__tests__/client-hardening.test.ts
npm test -- --runTestsByPath src/stores/__tests__/approvalStore.test.ts

Mobile automated checks completed:

• Secure storage / auth / instance persistence
• Relay reconnect and hardening tests
• Approval store state consistency
• Clear gate mobile-relay-auth-approvals in HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md.

High-Risk Trust Gates

• Clear gate commercial-cancellation-reactivation.
• Clear gate hosted-signup-billing-replay.
• Clear gate paid-feature-entitlement-gating.
• Clear gate rc-to-ga-promotion-readiness.
• Clear gate relay-registration-reconnect-drain.
• Clear gate mobile-relay-auth-approvals.
• Clear gate organization-user-scope-and-rbac.
• Clear gate api-token-scope-and-assignment.
• Clear gate cloud-hosted-tier-runtime-readiness.
• Clear gate msp-provider-tenant-management.

Release Decision

Mark Pulse v6 pre-release ready only if all of the following are true:

• The smoke checks above pass.
• There is no separate unaudited mobile app.
• There is no tracked dirty state.
• No new high-severity regressions appear.

Stable Promotion Decision

Mark a Pulse v6 build stable-promotion ready only if all of the following are true:

• The candidate commit has already been exercised on rc.
• The Promotion Policy section above is complete.
• Applicable items in HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md are cleared.
• The rollback target and exact reinstall command are recorded.
• The release pipeline has already been exercised on the candidate prerelease path in a real run, not only statically validated.
• The v5 maintenance-only support policy, exact GA/EOS dates, and release-note notice are written and ready to publish.
• The prerelease-to-GA rehearsal record and dry-run artifact are linked from the release ticket.