From 9217c065dfd73b5c59594550a7c1422cd0c6b94f Mon Sep 17 00:00:00 2001 From: rcourtman Date: Tue, 28 Apr 2026 20:48:10 +0100 Subject: [PATCH] Clarify self-hosted no-cap Pro continuity --- docs/PULSE_PRO.md | 10 ++++---- docs/UPGRADE_v6.md | 10 ++++---- .../v6/internal/subsystems/cloud-paid.md | 23 ++++++++++--------- .../subsystems/deployment-installability.md | 6 ++++- .../release_promotion_policy_test.py | 7 ++++++ 5 files changed, 34 insertions(+), 22 deletions(-) diff --git a/docs/PULSE_PRO.md b/docs/PULSE_PRO.md index 4549f7423..6e87bec74 100644 --- a/docs/PULSE_PRO.md +++ b/docs/PULSE_PRO.md @@ -62,7 +62,7 @@ Runtime rules: - Deduplication follows canonical unified-resource identity rather than transport-specific state. Migration policy: -- Legacy recurring Pulse Pro subscriptions already active before the public v6 pricing cutover keep their grandfathered recurring price and uncapped monitored-system and guest capacity until cancellation. +- Legacy recurring Pulse Pro subscriptions already active before the public v6 pricing cutover keep their grandfathered recurring price until cancellation. Self-hosted monitoring and child-resource volume remain uncapped under the current v6 policy. - Existing lifetime license holders remain valid and uncapped. - Supported legacy paid v5 migrations outside that recurring grandfathered path can still exchange into the v6 activation model without losing self-hosted monitoring access. Migration metadata can preserve the original cohort for support and audit, but monitored-system volume is no longer the paid gate. @@ -70,14 +70,14 @@ Migration policy: | Customer cohort | What happens in v6 | Pricing and capacity outcome | |---|---|---| -| Legacy recurring subscriber from a v5 or earlier Pulse Pro monthly/annual plan, already active before the public v6 pricing cutover | The install can migrate into the v6 activation model without forcing a repurchase. | The existing recurring price stays in place and monitored-system plus guest capacity remain uncapped while the subscription remains continuously active. | -| Existing lifetime license holder | The license remains valid through the v6 licensing transition. | Lifetime remains permanently valid and monitored-system plus guest capacity stay uncapped. | +| Legacy recurring subscriber from a v5 or earlier Pulse Pro monthly/annual plan, already active before the public v6 pricing cutover | The install can migrate into the v6 activation model without forcing a repurchase. | The existing recurring price stays in place while the subscription remains continuously active; self-hosted monitoring and child-resource volume remain uncapped under the current v6 policy. | +| Existing lifetime license holder | The license remains valid through the v6 licensing transition. | Lifetime remains permanently valid; self-hosted monitoring and child-resource volume stay uncapped. | | Legacy paid v5 license migrated into v6 outside the recurring grandfathered path | The install can still exchange into the v6 activation model without forcing a repurchase. Migration records can still preserve the original cohort for support and audit. | Self-hosted monitoring stays available; monitored-system volume is no longer sold as a paid gate on current v6 self-hosted plans. | -| Former recurring subscriber who already canceled or later lapses/cancels | A later return is treated as a new paid purchase, not as a grandfathered renewal. | The old grandfathered price and uncapped capacity do not resume automatically; current public v6 pricing applies. | +| Former recurring subscriber who already canceled or later lapses/cancels | A later return is treated as a new paid purchase, not as a grandfathered renewal. | The old grandfathered price does not resume automatically; current public v6 pricing applies for paid features while self-hosted monitoring remains unlimited. | | New self-hosted v6 purchase | The purchase uses the current Community / Relay / Pro self-hosted plans. | Core monitoring stays unlimited; paid value comes from convenience, AI, history, and advanced admin features. | Support rule: -- If any self-hosted v6 install shows a bounded monitored-system cap after activation or migration, treat it as a bug rather than as intended policy. Guest limits still follow the active tier or continuity contract. +- If any self-hosted v6 install shows a bounded monitored-system, guest, or child-resource volume cap after activation or migration, treat it as a bug rather than as intended policy. ## V6 Product Classification diff --git a/docs/UPGRADE_v6.md b/docs/UPGRADE_v6.md index aa64b65b9..f904cf4a9 100644 --- a/docs/UPGRADE_v6.md +++ b/docs/UPGRADE_v6.md @@ -147,19 +147,19 @@ Pulse v6 uses the activation/grant model for active licensing, but it can migrat - The exchanged v6 entitlement depends on the original cohort. Lifetime, active pre-cutover recurring Pro, and other migrated legacy paid installs do not all land on the same commercial continuity posture. -- Legacy recurring Pulse Pro subscriptions already active before the public v6 pricing cutover keep their grandfathered recurring price and uncapped monitored-system and guest capacity until cancellation. If they cancel and later return, current v6 pricing applies. +- Legacy recurring Pulse Pro subscriptions already active before the public v6 pricing cutover keep their grandfathered recurring price until cancellation. Self-hosted monitoring and child-resource volume remain uncapped under the current v6 policy. If they cancel and later return, current v6 pricing applies for paid features. #### Paid Upgrade Truth Table When an existing paid user asks what changes for them specifically, use this rule set: -- Legacy recurring Pulse Pro subscriptions from v5 or earlier that were already active before the public v6 pricing cutover keep their current recurring price and uncapped monitored-system plus guest capacity while the subscription remains continuously active. -- Existing lifetime customers remain permanently valid and uncapped. +- Legacy recurring Pulse Pro subscriptions from v5 or earlier that were already active before the public v6 pricing cutover keep their current recurring price while the subscription remains continuously active. Self-hosted monitoring and child-resource volume remain uncapped under the current v6 policy. +- Existing lifetime customers remain permanently valid, with uncapped self-hosted monitoring and child-resource volume. - Legacy paid v5 licenses migrated into v6 outside the recurring grandfathered path can still exchange into the v6 activation model without repurchasing. Migration records can preserve the original cohort for support and audit, but self-hosted monitoring volume is no longer the paid gate. -- Former recurring customers who already canceled, or who cancel and later return, do not resume the old grandfathered pricing or uncapped capacity automatically; they re-enter on current public v6 pricing. +- Former recurring customers who already canceled, or who cancel and later return, do not resume the old grandfathered pricing automatically; they re-enter on current public v6 pricing for paid features while self-hosted monitoring remains unlimited. - New self-hosted v6 purchases use the current Community / Relay / Pro plan model with unlimited core monitoring. -If a self-hosted v6 install sees a new monitored-system cap after moving to v6, treat that as a regression, not as expected upgrade behavior. +If a self-hosted v6 install sees a new monitored-system, guest, or child-resource volume cap after moving to v6, treat that as a regression, not as expected upgrade behavior. Practical recommendation: diff --git a/docs/release-control/v6/internal/subsystems/cloud-paid.md b/docs/release-control/v6/internal/subsystems/cloud-paid.md index 51328c62e..a4e01d69c 100644 --- a/docs/release-control/v6/internal/subsystems/cloud-paid.md +++ b/docs/release-control/v6/internal/subsystems/cloud-paid.md @@ -413,13 +413,12 @@ Community limit enforcement. they keep the Pro feature set, but they must not inherit monitored-system or guest caps from recurring Pro contracts anywhere in runtime, issuance, or migrated-license storage. -6. Treat active recurring v5 Pulse Pro customers as uncapped grandfathered - commercial entitlements until cancellation: migrated and renewing v5/v1 - recurring plans keep their existing recurring price plus uncapped - monitored-system and guest capacity while the subscription remains - continuous, and only new v6 retail purchases or post-cancellation re-entry - may take the current Community / Relay / Pro no-cap self-hosted packaging, - with Pro+ remaining legacy continuity only. +6. Treat active recurring v5 Pulse Pro customers as grandfathered commercial + entitlements until cancellation: migrated and renewing v5/v1 recurring + plans keep their existing recurring price while the subscription remains + continuous. The current Community / Relay / Pro self-hosted packaging also + stays no-cap for monitored systems, guests, and child-resource volume, with + Pro+ remaining legacy continuity only. 7. Keep Pro+ app presentation continuity-only: customer-facing tier, plan, and plan-version labels for `pro_plus` must include legacy framing while still mapping the entitlement to the Pro runtime feature set. @@ -1393,8 +1392,9 @@ resolves to `v5_pro_monthly_grandfathered` or That Pro-license presentation rule is explicit UX, not only hidden metadata: when a migrated recurring v5 plan is active or in grace, the settings surface must render plan terms and a continuity notice that makes it clear the -existing recurring price plus uncapped monitored-system and guest capacity -remain in force until cancellation. +existing recurring price remains in force until cancellation, while +self-hosted monitoring and child-resource volume stay uncapped under the +current v6 policy. The self-hosted commercial presentation on that same surface is now locked to the no-cap monitored-system model as well. `ProLicensePanel.tsx`, `CommercialBillingSections.tsx`, and @@ -1408,8 +1408,9 @@ continuity only. Cloud/MSP pricing semantics stay separate, and grandfathered v5 continuity copy remains an explicit boundary policy. That same settings-owned presentation must distinguish between active grandfathered recurring v5 continuity and bounded legacy fallbacks. Active -grandfathered recurring v5 plans must render uncapped monitored-system and -guest capacity directly and must not show a pending or captured floor banner. +grandfathered recurring v5 plans must render the existing recurring price +continuity directly and must not show a pending or captured floor banner or +any finite self-hosted volume cap. Only bounded legacy fallback migrations may render the base plan limit, the effective monitored-system limit, any grandfathered floor, and whether continuity capture is still pending. When monitored-system usage is diff --git a/docs/release-control/v6/internal/subsystems/deployment-installability.md b/docs/release-control/v6/internal/subsystems/deployment-installability.md index 86db48fe1..b22a055f9 100644 --- a/docs/release-control/v6/internal/subsystems/deployment-installability.md +++ b/docs/release-control/v6/internal/subsystems/deployment-installability.md @@ -142,10 +142,14 @@ server-side update execution surfaces. recovery, and signed support handoffs, but it must not teach ordinary self-hosted users to start a general in-app trial or depend on hosted AI quickstart acquisition as part of the upgrade path. + The same guide must treat bounded monitored-system, guest, or + child-resource volume caps after self-hosted v6 activation or migration as + regressions, not as upgrade outcomes or paid-plan differentiators. Release notes and changelog packets under `docs/releases/` must follow the same rule when they mention licensing: historical RC context may be preserved, but current self-hosted v6 guidance must not present - monitored-system volume or trial eligibility as the active paid model. + monitored-system volume, child-resource volume, or trial eligibility as the + active paid model. The active prerelease cut must keep the repo-root `VERSION` file aligned with the current RC packet itself: when the governed line moves from `rc.1` to `rc.2` or later, the staged release-notes packet, changelog packet, and diff --git a/scripts/release_control/release_promotion_policy_test.py b/scripts/release_control/release_promotion_policy_test.py index 24e0b56b3..e5f8a0649 100644 --- a/scripts/release_control/release_promotion_policy_test.py +++ b/scripts/release_control/release_promotion_policy_test.py @@ -176,6 +176,13 @@ class ReleasePromotionPolicyTest(unittest.TestCase): self.assertIn("### License and Entitlements", upgrade_guide) self.assertNotIn("### License, Trial, and Entitlements", upgrade_guide) self.assertIn("does not expose a general in-app trial, trial-return callback, or hosted AI quickstart", normalize_ws(upgrade_guide)) + self.assertIn( + "Self-hosted monitoring and child-resource volume remain uncapped under the current v6 policy", + upgrade_guide, + ) + self.assertIn("monitored-system, guest, or child-resource volume cap", upgrade_guide) + self.assertNotIn("uncapped monitored-system and guest capacity", upgrade_guide) + self.assertNotIn("uncapped capacity automatically", upgrade_guide) self.assertNotIn("`POST /api/license/trial/start`", upgrade_guide) self.assertNotIn("signed activation token to `/auth/trial-activate`", upgrade_guide) self.assertNotIn("25 hosted Patrol", upgrade_guide)