@camunda/ccma-shared-types 4.0.0 → 5.0.0

package/dist/approvals/use-cases.const.d.ts

@@ -23,7 +23,6 @@ export declare const APPROVAL_USE_CASE_TYPES: {
     readonly clusterBulkSleepWakeup: "cluster-bulk-sleep-wakeup";
     readonly clusterBulkDeletion: "cluster-bulk-deletion";
     readonly clusterBulkSpecUpdate: "cluster-bulk-spec-update";
-    readonly featureFlagOverride: "feature-flag-override";
 };
 export type ApprovalUseCaseType = (typeof APPROVAL_USE_CASE_TYPES)[keyof typeof APPROVAL_USE_CASE_TYPES];
 /**
@@ -47,68 +46,3 @@ export declare const EXTEND_TRIAL_MIN_DAYS = 15;
  * margin as the floor above.
  */
 export declare const EXTEND_TRIAL_MAX_DAYS = 61;
-/**
- * The shortest life of a feature flag override, in days.
- *
- * One day. An override that ends sooner than the next working day is a change
- * that nobody can look at before it goes away again.
- */
-export declare const FLAG_OVERRIDE_MIN_DAYS = 1;
-/**
- * The longest life of a feature flag override, in days.
- *
- * An override is a temporary thing. Without a ceiling it becomes a second,
- * invisible layer of configuration, and then nobody can answer "what runs on
- * prod?" from the source alone. A change that has to hold for longer belongs
- * in `defaults.ts`, where a reviewer reads it.
- */
-export declare const FLAG_OVERRIDE_MAX_DAYS = 90;
-/**
- * The life of an override when the person names no other number.
- *
- * Two weeks is long enough for a rollout to prove itself, and short enough
- * that a forgotten override goes away by itself.
- */
-export declare const FLAG_OVERRIDE_DEFAULT_DAYS = 14;
-/**
- * Whether a stored override reaches any reader yet.
- *
- * It is `false` today, and the write path is closed at both ends: the page
- * turns the Override button off, and the create route of control-backend
- * answers 404. It lives HERE, and not in the page, because both sides read
- * it. One switch cannot drift; a disabled button beside an open route is not
- * a closed door, and that is what the review found.
- *
- * ## Why it is still `false`, and what is NOT true any more
- *
- * This said that control-backend reads exactly ONE flag, `control.approvals`,
- * which takes no override, so the set of flags that this service reads and
- * the set that take an override do not meet. **That stopped being true while
- * this branch was open.** `main` added the annotations component, and
- * `requireAnnotationsEnabled` reads `request.flags.control.annotations`:
- *
- * ```
- * approvals.routes.ts:368     if (!request.flags.control.approvals) {
- * annotations.routes.ts:313   if (!request.flags.control.annotations) {
- * ```
- *
- * `control.annotations` is `overridable: true`, and `feature-flags.plugin.ts`
- * applies the overrides in an application `preHandler`, which runs BEFORE a
- * route-level one. So a STAGE override of that one flag would reach a real
- * reader today.
- *
- * The intersection is therefore no longer empty: it holds one flag of 28, in
- * one of the two scopes. That is the reason to keep this `false` rather than
- * to turn it on. One boolean cannot say "this flag in this scope reaches a
- * reader, and the other 27 do not": `true` would open a form that writes a
- * row and moves nothing for every flag but one, which is the failure this
- * constant exists to prevent, in the other direction.
- *
- * ## Phase 2
- *
- * Availability belongs per flag AND per scope, derived from which service
- * reads the flag and whether that reader passes an `orgId` — not from one
- * global switch. See section 8 of the design. Until then this stays `false`,
- * which is safe: it is closed, and never wrongly open.
- */
-export declare const OVERRIDES_REACH_A_READER = false;

package/dist/approvals/use-cases.const.js

@@ -10,22 +10,13 @@ const APPROVAL_USE_CASE_TYPES = {
   clusterBulkPlanTypeUpdate: "cluster-bulk-plan-type-update",
   clusterBulkSleepWakeup: "cluster-bulk-sleep-wakeup",
   clusterBulkDeletion: "cluster-bulk-deletion",
-  clusterBulkSpecUpdate: "cluster-bulk-spec-update",
-  featureFlagOverride: "feature-flag-override"
+  clusterBulkSpecUpdate: "cluster-bulk-spec-update"
 };
 const EXTEND_TRIAL_MIN_DAYS = 15;
 const EXTEND_TRIAL_MAX_DAYS = 61;
-const FLAG_OVERRIDE_MIN_DAYS = 1;
-const FLAG_OVERRIDE_MAX_DAYS = 90;
-const FLAG_OVERRIDE_DEFAULT_DAYS = 14;
-const OVERRIDES_REACH_A_READER = false;
 export {
   APPROVAL_USE_CASE_TYPES,
   EXTEND_TRIAL_MAX_DAYS,
-  EXTEND_TRIAL_MIN_DAYS,
-  FLAG_OVERRIDE_DEFAULT_DAYS,
-  FLAG_OVERRIDE_MAX_DAYS,
-  FLAG_OVERRIDE_MIN_DAYS,
-  OVERRIDES_REACH_A_READER
+  EXTEND_TRIAL_MIN_DAYS
 };
 //# sourceMappingURL=use-cases.const.js.map

package/dist/approvals/use-cases.const.js.map

@@ -1,7 +1,7 @@
 {
   "version": 3,
   "sources": ["../../src/approvals/use-cases.const.ts"],
-  "sourcesContent": ["/*\n * Copyright Camunda Services GmbH and/or licensed to Camunda Services GmbH\n * under one or more contributor license agreements. Licensed under a commercial license.\n * You may not use this file except in compliance with the commercial license.\n */\n\n/**\n * The names and the value ranges of the registered use cases.\n *\n * control-backend owns the registry, and a frontend reads it at run time\n * (`GET /api/approvals/use-cases`). Two things cannot wait for that answer:\n *\n * - **The identifier**, because a caller must NAME a use case to find it in the\n *   registry, and to open a request of it.\n * - **The range of a payload field**, because a form holds the value before any\n *   call goes out.\n *\n * Both live here, so the schema of the service and the form of the browser can\n * never hold different numbers.\n */\n\n/** The identifier of each use case, on the wire and in the table. */\nexport const APPROVAL_USE_CASE_TYPES = {\n  sendToExpiredTrial: 'send-to-expired-trial',\n  extendTrial: 'extend-trial',\n  moveClusterOrg: 'move-cluster-org',\n  // One use case for each type of a cluster bulk operation. The types need\n  // different permissions and different approval counts, and a use case holds\n  // one of each. See `cluster-bulk-operation.ts` beside this file.\n  clusterBulkGenerationUpdate: 'cluster-bulk-generation-update',\n  clusterBulkPlanUpdate: 'cluster-bulk-plan-update',\n  clusterBulkPlanTypeUpdate: 'cluster-bulk-plan-type-update',\n  clusterBulkSleepWakeup: 'cluster-bulk-sleep-wakeup',\n  clusterBulkDeletion: 'cluster-bulk-deletion',\n  clusterBulkSpecUpdate: 'cluster-bulk-spec-update',\n  featureFlagOverride: 'feature-flag-override',\n} as const\n\nexport type ApprovalUseCaseType =\n  (typeof APPROVAL_USE_CASE_TYPES)[keyof typeof APPROVAL_USE_CASE_TYPES]\n\n/**\n * The shortest extension that accounts-backend accepts.\n *\n * `POST /:orgId/extendtrial` refuses a date that is less than 14 days away\n * when the body carries `onBehalfOf`, and it measures those 14 days when the\n * CALL arrives. The floor here is 15 and not 14, for two reasons:\n *\n * - The two clocks are not the same instant. Accounts builds its own \"14 days\n *   from now\" a few milliseconds after control-backend builds the date, so a\n *   date of exactly 14 days is already in the past for the comparison.\n * - Accounts counts with `setDate`, which is calendar arithmetic. A change of\n *   the daylight saving time moves its limit by an hour.\n */\nexport const EXTEND_TRIAL_MIN_DAYS = 15\n\n/**\n * The longest extension that accounts-backend accepts.\n *\n * The same route refuses a date more than 62 days away. 61 keeps the same\n * margin as the floor above.\n */\nexport const EXTEND_TRIAL_MAX_DAYS = 61\n\n/**\n * The shortest life of a feature flag override, in days.\n *\n * One day. An override that ends sooner than the next working day is a change\n * that nobody can look at before it goes away again.\n */\nexport const FLAG_OVERRIDE_MIN_DAYS = 1\n\n/**\n * The longest life of a feature flag override, in days.\n *\n * An override is a temporary thing. Without a ceiling it becomes a second,\n * invisible layer of configuration, and then nobody can answer \"what runs on\n * prod?\" from the source alone. A change that has to hold for longer belongs\n * in `defaults.ts`, where a reviewer reads it.\n */\nexport const FLAG_OVERRIDE_MAX_DAYS = 90\n\n/**\n * The life of an override when the person names no other number.\n *\n * Two weeks is long enough for a rollout to prove itself, and short enough\n * that a forgotten override goes away by itself.\n */\nexport const FLAG_OVERRIDE_DEFAULT_DAYS = 14\n\n/**\n * Whether a stored override reaches any reader yet.\n *\n * It is `false` today, and the write path is closed at both ends: the page\n * turns the Override button off, and the create route of control-backend\n * answers 404. It lives HERE, and not in the page, because both sides read\n * it. One switch cannot drift; a disabled button beside an open route is not\n * a closed door, and that is what the review found.\n *\n * ## Why it is still `false`, and what is NOT true any more\n *\n * This said that control-backend reads exactly ONE flag, `control.approvals`,\n * which takes no override, so the set of flags that this service reads and\n * the set that take an override do not meet. **That stopped being true while\n * this branch was open.** `main` added the annotations component, and\n * `requireAnnotationsEnabled` reads `request.flags.control.annotations`:\n *\n * ```\n * approvals.routes.ts:368     if (!request.flags.control.approvals) {\n * annotations.routes.ts:313   if (!request.flags.control.annotations) {\n * ```\n *\n * `control.annotations` is `overridable: true`, and `feature-flags.plugin.ts`\n * applies the overrides in an application `preHandler`, which runs BEFORE a\n * route-level one. So a STAGE override of that one flag would reach a real\n * reader today.\n *\n * The intersection is therefore no longer empty: it holds one flag of 28, in\n * one of the two scopes. That is the reason to keep this `false` rather than\n * to turn it on. One boolean cannot say \"this flag in this scope reaches a\n * reader, and the other 27 do not\": `true` would open a form that writes a\n * row and moves nothing for every flag but one, which is the failure this\n * constant exists to prevent, in the other direction.\n *\n * ## Phase 2\n *\n * Availability belongs per flag AND per scope, derived from which service\n * reads the flag and whether that reader passes an `orgId` \u2014 not from one\n * global switch. See section 8 of the design. Until then this stays `false`,\n * which is safe: it is closed, and never wrongly open.\n */\nexport const OVERRIDES_REACH_A_READER = false\n"],
-  "mappings": "AAsBO,MAAM,0BAA0B;AAAA,EACrC,oBAAoB;AAAA,EACpB,aAAa;AAAA,EACb,gBAAgB;AAAA;AAAA;AAAA;AAAA,EAIhB,6BAA6B;AAAA,EAC7B,uBAAuB;AAAA,EACvB,2BAA2B;AAAA,EAC3B,wBAAwB;AAAA,EACxB,qBAAqB;AAAA,EACrB,uBAAuB;AAAA,EACvB,qBAAqB;AACvB;AAkBO,MAAM,wBAAwB;AAQ9B,MAAM,wBAAwB;AAQ9B,MAAM,yBAAyB;AAU/B,MAAM,yBAAyB;AAQ/B,MAAM,6BAA6B;AA2CnC,MAAM,2BAA2B;",
+  "sourcesContent": ["/*\n * Copyright Camunda Services GmbH and/or licensed to Camunda Services GmbH\n * under one or more contributor license agreements. Licensed under a commercial license.\n * You may not use this file except in compliance with the commercial license.\n */\n\n/**\n * The names and the value ranges of the registered use cases.\n *\n * control-backend owns the registry, and a frontend reads it at run time\n * (`GET /api/approvals/use-cases`). Two things cannot wait for that answer:\n *\n * - **The identifier**, because a caller must NAME a use case to find it in the\n *   registry, and to open a request of it.\n * - **The range of a payload field**, because a form holds the value before any\n *   call goes out.\n *\n * Both live here, so the schema of the service and the form of the browser can\n * never hold different numbers.\n */\n\n/** The identifier of each use case, on the wire and in the table. */\nexport const APPROVAL_USE_CASE_TYPES = {\n  sendToExpiredTrial: 'send-to-expired-trial',\n  extendTrial: 'extend-trial',\n  moveClusterOrg: 'move-cluster-org',\n  // One use case for each type of a cluster bulk operation. The types need\n  // different permissions and different approval counts, and a use case holds\n  // one of each. See `cluster-bulk-operation.ts` beside this file.\n  clusterBulkGenerationUpdate: 'cluster-bulk-generation-update',\n  clusterBulkPlanUpdate: 'cluster-bulk-plan-update',\n  clusterBulkPlanTypeUpdate: 'cluster-bulk-plan-type-update',\n  clusterBulkSleepWakeup: 'cluster-bulk-sleep-wakeup',\n  clusterBulkDeletion: 'cluster-bulk-deletion',\n  clusterBulkSpecUpdate: 'cluster-bulk-spec-update',\n} as const\n\nexport type ApprovalUseCaseType =\n  (typeof APPROVAL_USE_CASE_TYPES)[keyof typeof APPROVAL_USE_CASE_TYPES]\n\n/**\n * The shortest extension that accounts-backend accepts.\n *\n * `POST /:orgId/extendtrial` refuses a date that is less than 14 days away\n * when the body carries `onBehalfOf`, and it measures those 14 days when the\n * CALL arrives. The floor here is 15 and not 14, for two reasons:\n *\n * - The two clocks are not the same instant. Accounts builds its own \"14 days\n *   from now\" a few milliseconds after control-backend builds the date, so a\n *   date of exactly 14 days is already in the past for the comparison.\n * - Accounts counts with `setDate`, which is calendar arithmetic. A change of\n *   the daylight saving time moves its limit by an hour.\n */\nexport const EXTEND_TRIAL_MIN_DAYS = 15\n\n/**\n * The longest extension that accounts-backend accepts.\n *\n * The same route refuses a date more than 62 days away. 61 keeps the same\n * margin as the floor above.\n */\nexport const EXTEND_TRIAL_MAX_DAYS = 61\n"],
+  "mappings": "AAsBO,MAAM,0BAA0B;AAAA,EACrC,oBAAoB;AAAA,EACpB,aAAa;AAAA,EACb,gBAAgB;AAAA;AAAA;AAAA;AAAA,EAIhB,6BAA6B;AAAA,EAC7B,uBAAuB;AAAA,EACvB,2BAA2B;AAAA,EAC3B,wBAAwB;AAAA,EACxB,qBAAqB;AAAA,EACrB,uBAAuB;AACzB;AAkBO,MAAM,wBAAwB;AAQ9B,MAAM,wBAAwB;",
   "names": []
 }

package/dist/dtos/ControlV2.dto.d.ts

@@ -178,6 +178,12 @@ export interface ClusterListItemV2Dto {
     /** Session idle timeout. */
     sessionMaxInactiveIntervalMinutes?: number;
     sessionHeartbeatEnabled?: boolean;
+    /** BYOK: `encryption` is `External`. The key can still be missing. */
+    byokEnabled?: boolean;
+    /** The cluster has at least one external monitoring (BYOM) client. */
+    externalMonitoringEnabled?: boolean;
+    /** The cluster has a `secure_connectivity` row (AWS PrivateLink). */
+    privateConnectivityEnabled?: boolean;
 }
 /** Detail extends the list shape; richer fields are added in Phase 3. */
 export type ClusterDetailV2Dto = ClusterListItemV2Dto;
@@ -299,6 +305,10 @@ export interface ListClustersV2Params extends CursorParams {
         internal?: boolean;
         /** Only clusters with (true) / without (false) an active modification. */
         hasActiveModification?: boolean;
+        /** Only clusters with (true) / without (false) the flag of the same name. */
+        byokEnabled?: boolean;
+        externalMonitoringEnabled?: boolean;
+        privateConnectivityEnabled?: boolean;
         /**
          * Zeebe minor-version prefix match on the generation's versions (e.g.
          * "8.7" matches zeebe 8.7.x).

package/dist/dtos/ExternalWebapp.dto.d.ts

@@ -58,6 +58,18 @@ export interface ExternalOrganizationDto {
         };
     };
 }
+/**
+ * Clickwrap config as returned by `GET external/clickwrap-config`.
+ *
+ * Names the PactSafe group that records a customer's opt-in to alpha features.
+ * The deployed accounts-backend owns the identifiers, thus a host does not hold
+ * a copy. Each field is optional: the backend omits it when its environment
+ * variable is unset, and a host with no `accessId` shows no opt-in.
+ */
+export interface ExternalClickwrapConfigDto {
+    accessId?: string;
+    betaGroupKey?: string;
+}
 /**
  * Cluster as returned by `GET external/organizations/:orgId/clusters`.
  *

package/dist/dtos/FeatureFlags.dto.d.ts

@@ -2,65 +2,58 @@
  * This type gives the shape of the feature flags of the management apps. It is
  * also the body of `GET external/feature-flags` on accounts-backend.
  *
- * The GROUP is typed and the FLAG is not. A flag can be made at run time, from
- * the Feature flags page of Control, thus no interface can name every flag. A
- * new GROUP is still a code change, in `FLAG_GROUPS` below.
- *
- * CAUTION: A wrong flag name is no longer a compile error.
- * `FEATURES.console.byoidpp` reads `undefined`, which is falsy, so the
- * feature turns off in silence. One thing answers that TODAY:
- *
- * - `readFlag(features, 'console.byoidp')` of `@camunda-cloud/featureflags`
- *   answers a strict `boolean` for any path. Prefer it at a new call site.
- *
- * A second answer is PLANNED and does not exist yet:
- * `packages/checks/src/feature-flag-check` finds a flag that no source
- * declares but some source reads, and fails the build. It must land before
- * wave R2 moves a reader onto the table. Until then the compiler catches a
- * wrong GROUP and nothing catches a wrong flag name. See section 5.3 of
- * `docs/superpowers/specs/2026-09-23-runtime-feature-flags-design.md`.
- *
- * The value is not here. `FLAG_RULES` in `@camunda-cloud/featureflags` holds
- * the rule of each flag as DATA, `defaults(context)` evaluates it, and
- * `resolveFeatures` puts a stored override in front of the answer for one
- * organization, one mail domain or one person. `defaults` is the floor, and
- * not the runtime answer.
- *
- * What a flag gates, who owns it and why it exists live in `FLAG_REGISTRY` of
- * the same package while the code still holds the flags, and in the
- * `feature_flag` table of control-backend after that. They used to be here,
- * one comment for each field, and that list cannot survive a flag that no
- * field declares.
- *
- * This type is here and not in `@camunda-cloud/featureflags` because that
- * package is private, thus a published package (`@camunda/ccma-api`,
- * `@camunda/ccma-saas-frontend`) cannot name the type from there.
- * `@camunda-cloud/featureflags` re-exports `Features` from here.
+ * The shape is here, but the evaluation is not. `features({stage, orgId,
+ * email})` in `@camunda-cloud/featureflags` stays the only place that decides
+ * if a flag is on. That package is private, thus a published package
+ * (`@camunda/ccma-api`, `@camunda/ccma-saas-frontend`) cannot name the type
+ * from there. `@camunda-cloud/featureflags` re-exports `Features` from here.
+ * Thus the type has one definition, and every existing import path still works.
  *
  * A c4 host reads one flag with `useC4FeatureFlag('console.appIntegrations')`
  * — a dot path into this object.
  */
-/**
- * Every group of flags.
- *
- * A group is a code change, because it is the one part of the shape that a
- * reader names in a type.
- *
- * `hub` carries the flags of Camunda Hub, which embeds c4 widgets and reads
- * them with `useC4FeatureFlag`. Nothing in this repository reads a `hub`
- * flag, thus the group holds no code rule and only ever holds rows. The
- * stale-flag check therefore skips it: a check that looks for a reader finds
- * none, and that is correct and not a fault.
- */
-export declare const FLAG_GROUPS: readonly ["console", "control", "accounts", "shared", "hub"];
-export type FlagGroup = (typeof FLAG_GROUPS)[number];
-/**
- * The flags of one group.
- *
- * The key is a plain `string` and not a union, because a person can make a
- * flag at run time. The value is a `boolean` and never `any`: `any` would
- * also accept `features.console.foo.bar`, and the tree is one level deep
- * under its group.
- */
-export type FlagValues = Record<string, boolean>;
-export type Features = Record<FlagGroup, FlagValues>;
+export interface Features {
+    console: {
+        admin: {
+            overrideOrgRole: boolean;
+        };
+        clusterSuspendButton: boolean;
+        clusterSleepWarning: boolean;
+        backupRestore: boolean;
+        failover: boolean;
+        privateLink87: boolean;
+        byoidp: boolean;
+        optimizeUnsetOnDisable: boolean;
+        appIntegrations: boolean;
+        orgClusterDefaults: boolean;
+        releaseTrainSanityFix: boolean;
+        hubHelpCenterLinks: boolean;
+        legacyModelerApiNaming: boolean;
+        backupScheduleApi: boolean;
+        clusterCreationBlocked: boolean;
+        deferSpecChangeWhileAsleep: boolean;
+        clusterDuplication: boolean;
+        hubUpgradeBanner: boolean;
+    };
+    control: {
+        frontendTelemetry: boolean;
+        approvals: boolean;
+        annotations: boolean;
+        clusterHostingCostBreakdown: boolean;
+        /** Per-cluster disk usage chart (Elasticsearch and Zeebe) on the cluster page. */
+        elasticsearchUsageChart: boolean;
+        fleetHostingCost: boolean;
+    };
+    accounts: {
+        moveClusterOrg: boolean;
+        orgLimitAuditLog: boolean;
+        orgReservationAuditLog: boolean;
+        deleteLiteLLMKeyOnTrialExpiry: boolean;
+    };
+    shared: {
+        cyberpunkBrutalism: boolean;
+        tenantsValueMetric: boolean;
+        hdpValueMetricsFor2025: boolean;
+        permissionsRework: boolean;
+    };
+}

package/dist/dtos/FeatureFlags.dto.js

@@ -1,11 +1 @@
-const FLAG_GROUPS = [
-  "console",
-  "control",
-  "accounts",
-  "shared",
-  "hub"
-];
-export {
-  FLAG_GROUPS
-};
 //# sourceMappingURL=FeatureFlags.dto.js.map

package/dist/dtos/FeatureFlags.dto.js.map

@@ -1,7 +1,7 @@
 {
   "version": 3,
-  "sources": ["../../src/dtos/FeatureFlags.dto.ts"],
-  "sourcesContent": ["/*\n * Copyright Camunda Services GmbH and/or licensed to Camunda Services GmbH\n * under one or more contributor license agreements. Licensed under a commercial license.\n * You may not use this file except in compliance with the commercial license.\n */\n\n/**\n * This type gives the shape of the feature flags of the management apps. It is\n * also the body of `GET external/feature-flags` on accounts-backend.\n *\n * The GROUP is typed and the FLAG is not. A flag can be made at run time, from\n * the Feature flags page of Control, thus no interface can name every flag. A\n * new GROUP is still a code change, in `FLAG_GROUPS` below.\n *\n * CAUTION: A wrong flag name is no longer a compile error.\n * `FEATURES.console.byoidpp` reads `undefined`, which is falsy, so the\n * feature turns off in silence. One thing answers that TODAY:\n *\n * - `readFlag(features, 'console.byoidp')` of `@camunda-cloud/featureflags`\n *   answers a strict `boolean` for any path. Prefer it at a new call site.\n *\n * A second answer is PLANNED and does not exist yet:\n * `packages/checks/src/feature-flag-check` finds a flag that no source\n * declares but some source reads, and fails the build. It must land before\n * wave R2 moves a reader onto the table. Until then the compiler catches a\n * wrong GROUP and nothing catches a wrong flag name. See section 5.3 of\n * `docs/superpowers/specs/2026-09-23-runtime-feature-flags-design.md`.\n *\n * The value is not here. `FLAG_RULES` in `@camunda-cloud/featureflags` holds\n * the rule of each flag as DATA, `defaults(context)` evaluates it, and\n * `resolveFeatures` puts a stored override in front of the answer for one\n * organization, one mail domain or one person. `defaults` is the floor, and\n * not the runtime answer.\n *\n * What a flag gates, who owns it and why it exists live in `FLAG_REGISTRY` of\n * the same package while the code still holds the flags, and in the\n * `feature_flag` table of control-backend after that. They used to be here,\n * one comment for each field, and that list cannot survive a flag that no\n * field declares.\n *\n * This type is here and not in `@camunda-cloud/featureflags` because that\n * package is private, thus a published package (`@camunda/ccma-api`,\n * `@camunda/ccma-saas-frontend`) cannot name the type from there.\n * `@camunda-cloud/featureflags` re-exports `Features` from here.\n *\n * A c4 host reads one flag with `useC4FeatureFlag('console.appIntegrations')`\n * \u2014 a dot path into this object.\n */\n\n/**\n * Every group of flags.\n *\n * A group is a code change, because it is the one part of the shape that a\n * reader names in a type.\n *\n * `hub` carries the flags of Camunda Hub, which embeds c4 widgets and reads\n * them with `useC4FeatureFlag`. Nothing in this repository reads a `hub`\n * flag, thus the group holds no code rule and only ever holds rows. The\n * stale-flag check therefore skips it: a check that looks for a reader finds\n * none, and that is correct and not a fault.\n */\nexport const FLAG_GROUPS = [\n  'console',\n  'control',\n  'accounts',\n  'shared',\n  'hub',\n] as const\n\nexport type FlagGroup = (typeof FLAG_GROUPS)[number]\n\n/**\n * The flags of one group.\n *\n * The key is a plain `string` and not a union, because a person can make a\n * flag at run time. The value is a `boolean` and never `any`: `any` would\n * also accept `features.console.foo.bar`, and the tree is one level deep\n * under its group.\n */\nexport type FlagValues = Record<string, boolean>\n\nexport type Features = Record<FlagGroup, FlagValues>\n"],
-  "mappings": "AA6DO,MAAM,cAAc;AAAA,EACzB;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF;",
+  "sources": [],
+  "sourcesContent": [],
+  "mappings": "",
   "names": []
 }

package/dist/dtos/Hdp.dto.d.ts

@@ -51,4 +51,157 @@ export declare namespace Hdp {
         /** The time of the query, as an ISO instant. */
         fetchedAt: string;
     }
+    /**
+     * A cluster's hosting cost over a trailing window.
+     *
+     * Both windows end at the anchor day: the latest day that HDP has loaded
+     * in the whole cost table, searched over the last `windowDays` days. The
+     * cost table loads with a delay, so the anchor is often yesterday, not
+     * today. It is today when the table is current. The anchor is table-wide
+     * on purpose: it measures the load lag only, and is the same for every
+     * cluster. A cluster that stopped costing money does not move its own
+     * windows, so its cost shows as a drop. Counting the anchor as day 0,
+     * the current window is days `0` through `windowDays - 1` back, and the
+     * prior window is days `windowDays` through `2 * windowDays - 1` back.
+     * Each window holds exactly `windowDays` days, with no gap and no overlap.
+     *
+     * `hostingCostUsd` is the loaded cost: the cluster's direct spend plus its
+     * share of shared infrastructure. It is what the cluster actually cost, not
+     * `raw_cost`, the pre-allocation figure that only reconciles to the cloud
+     * bill.
+     */
+    interface ClusterHostingCost {
+        clusterId: string;
+        /** The window `hostingCostUsd` covers, in days, ending at the anchor day. */
+        windowDays: number;
+        hostingCostUsd: number;
+        /**
+         * The loaded cost of the `windowDays`-day window immediately before this
+         * one — days `windowDays` through `2 * windowDays - 1` back from the
+         * anchor day (day 0), with no gap and no overlap against the current
+         * window. Absent when
+         * HDP has no rows there, which is normal for a cluster younger than
+         * `windowDays` days: it was not billed yet during the whole prior
+         * window. A cluster older than that already has at least a partial
+         * prior window, so this field is present (even if small) for any
+         * cluster older than `windowDays` days.
+         */
+        priorHostingCostUsd?: number;
+        /**
+         * How the current window compares to the prior one: `up`/`down` when the
+         * change exceeds a ±5% threshold, `flat` when it is within it. Absent
+         * whenever `priorHostingCostUsd` is — a percent change needs a real,
+         * non-zero base to compare against, so a cluster with no prior-window
+         * data gets no trend rather than a misleading "up" or "down".
+         */
+        trend?: 'up' | 'down' | 'flat';
+        /**
+         * The cost-type split (COGS vs R&D) of `hostingCostUsd` over the same
+         * window, from the `cost_type` column of the same HDP table. Present
+         * only when `control.clusterHostingCostBreakdown` is on for the caller
+         * — see `HdpDataHostingCostController.getHostingCost`. Absent rather
+         * than computed-then-hidden when the flag is off.
+         */
+        costTypeBreakdown?: ClusterHostingCostByType;
+        /**
+         * The allocation-pool split of `hostingCostUsd` over the same window,
+         * from the nine `allocated_*` columns of the same HDP table — see
+         * {@link ClusterHostingCostAllocation}. Gated by the same flag as
+         * `costTypeBreakdown`, and absent for the same reason when it is off.
+         */
+        allocationBreakdown?: ClusterHostingCostAllocation;
+    }
+    /**
+     * The cost-type split of a `ClusterHostingCost` window. `cost_type`
+     * classification is point-in-time against the FinOps mapping sheet, so
+     * re-running this query later can classify the same historic day's spend
+     * differently.
+     *
+     * `cogsUsd + rdUsd + otherUsd` reconciles to the window's
+     * `hostingCostUsd` to within half a cent. `otherUsd` is not read from
+     * the table with its own `cost_type` filter: it is `hostingCostUsd` minus
+     * the other two, rounded to the cent. Only `otherUsd` is rounded;
+     * `hostingCostUsd`, `cogsUsd` and `rdUsd` keep the full precision of the
+     * table, so a sum can differ from the total by that rounding. A `cost_type` value
+     * this split does not know about (a third category, or none at all)
+     * still lands somewhere visible instead of vanishing from the total. A
+     * negative `otherUsd` is possible in principle (`cogsUsd + rdUsd`
+     * exceeding `hostingCostUsd`) and is left visible rather than clamped to
+     * 0, because it would mean the two named sums are wrong, not that the
+     * remainder is — clamping would hide exactly the bug a Camundi most
+     * needs to see.
+     */
+    interface ClusterHostingCostByType {
+        /** Cost of Goods Sold: the loaded cost classified as `cost_type = 'COGS'`. */
+        cogsUsd: number;
+        /** Research & Development: the loaded cost classified as `cost_type = 'R&D'`. */
+        rdUsd: number;
+        /** The window's cost that `cogsUsd` and `rdUsd` do not account for. */
+        otherUsd: number;
+    }
+    /**
+     * The allocation-pool split of a `ClusterHostingCost` window: up to nine
+     * `allocated_*` columns of the same HDP table, each summed over the
+     * window the same way `hostingCostUsd` is. On a `direct`/`nonprod_direct`
+     * row, each pool is the dollar share of `loaded_cost` that one allocation
+     * reason contributes.
+     *
+     * Every field is optional and present only when nonzero for the window:
+     * a cluster rarely has all nine populated (most report a nonzero value in
+     * only one or two), and a $0 line for the rest would be noise rather than
+     * signal. `HdpDataHostingCostController.getHostingCost` filters the zero
+     * ones out before returning, and leaves `allocationBreakdown` itself
+     * absent when none of the nine are nonzero.
+     *
+     * These fields do NOT have to sum to `hostingCostUsd`, or to
+     * `hostingCostUsd` minus `costTypeBreakdown`'s fields: `toolingLicenseUsd`
+     * adds a cost (SaaS vendor tooling) rather than reallocating an existing
+     * one, so the pools present can sum past the window's total. Read each
+     * field as its own dollar amount, not as a share of a reconciling whole.
+     */
+    interface ClusterHostingCostAllocation {
+        /** Share of shared infra namespaces inside the same client project. */
+        infraNamespaceUsd?: number;
+        /** Share of idle purchased GKE capacity. */
+        gkeUnallocatedUsd?: number;
+        /** Share of GKE system overhead (kubelet, kube-proxy, containerd). */
+        gkeSystemOverheadUsd?: number;
+        /** Share of spend-based CUDs that GKE cannot attribute to a namespace. */
+        gkeUnsupportedSkuUsd?: number;
+        /** Share of SKUs that GKE has not yet processed. */
+        gkeUnknownUsd?: number;
+        /** Share of `saas_prod` support projects. Paid clusters only. */
+        saasProdSupportUsd?: number;
+        /** Share of the account that serves both cloud estates. Paid clusters only. */
+        awsGcpSharedUsd?: number;
+        /** Share of SaaS vendor tooling (Tsuga, Cloudflare, DoiT, Terraform). Adds cost; does not reallocate it. */
+        toolingLicenseUsd?: number;
+        /** Share of shared cost inside the same `saas_non_prod` project. */
+        nonprodSharedUsd?: number;
+    }
+    /** The loaded cost of one cluster over the fleet cost window. */
+    interface FleetHostingCostRow {
+        clusterId: string;
+        hostingCostUsd: number;
+    }
+    /**
+     * The loaded hosting cost of every cluster that HDP holds inside the
+     * window, for the whole fleet. Each row is the same number as
+     * `ClusterHostingCost.hostingCostUsd` gives for that cluster: same table,
+     * same `loaded_cost` column, same window that ends at the table-wide anchor
+     * day.
+     *
+     * HDP keeps the rows of clusters that no longer exist, thus the reader
+     * matches these rows against its own cluster list. A cluster with no row
+     * has no cost data in the window. That is not a cost of 0.
+     */
+    interface FleetHostingCost {
+        rows: FleetHostingCostRow[];
+        /** The window that `rows` covers, in days, ending at `anchorDay`. */
+        windowDays: number;
+        /** The last day of the window, as `YYYY-MM-DD`. Absent when the table has no recent row. */
+        anchorDay?: string;
+        /** The time of the read, as an ISO instant. */
+        fetchedAt: string;
+    }
 }

package/dist/dtos/SalesPlan.dto.d.ts

@@ -64,6 +64,16 @@ export interface Limits extends ClusterLimits {
      * Users who also hold Member, Admin, Owner, or Operations Engineer are unaffected.
      */
     developerNoClusterCreate?: boolean;
+    /**
+     * On dev and int only: the nightly delete cron deletes every cluster of the
+     * org that is older than this number of hours. It asks nobody. Because the
+     * cron runs once a day, a cluster can live up to 24 hours longer. We set it
+     * on our own test orgs, because a paused cluster keeps its disks and costs
+     * money. A sales plan can hold it too: an org copies the limits of its plan
+     * when it gets the plan, thus every later org of that plan gets it. An
+     * editor on prod does not offer it.
+     */
+    preprodClusterTtlHours?: number;
 }
 export declare const RETENTION_LIMIT_MINIMUM: {
     operate: number;
@@ -105,6 +115,8 @@ export declare function allSalesPlanLimits(): {
     description: string;
     isClusterBasedLimit: boolean;
     validate?: (input: number) => boolean;
+    /** An editor on prod does not offer the limit, because only dev and int act on it. */
+    preprodOnly?: boolean;
 }[];
 export declare function unusedClusterBasedLimits(limits: ClusterLimits): {
     key: string;
@@ -112,7 +124,19 @@ export declare function unusedClusterBasedLimits(limits: ClusterLimits): {
     description: string;
     isClusterBasedLimit: boolean;
 }[];
-export declare function unusedSalesPlanLimits(limits: Limits): {
+/**
+ * Returns whether an editor on the stage offers the limit. A `preprodOnly`
+ * limit is offered only on dev and int. Every other limit is offered on
+ * every stage.
+ */
+export declare function isLimitOfferedOnStage(limit: {
+    preprodOnly?: boolean;
+}, stage: string): boolean;
+/**
+ * Returns the limits that `limits` does not set yet. With a `stage`, it also
+ * leaves out the limits that the stage does not offer.
+ */
+export declare function unusedSalesPlanLimits(limits: Limits, stage?: string): {
     key: string;
     type: 'number' | 'boolean' | 'string';
     description: string;

package/dist/dtos/SalesPlan.dto.js

@@ -1,3 +1,4 @@
+import { isPreprodClusterTtlStage } from "../types/PreprodClusterTtl.type.js";
 const RETENTION_LIMIT_MINIMUM = {
   operate: 5,
   tasklist: 5,
@@ -31,28 +32,28 @@ function allClusterBasedLimits() {
       type: "number",
       isClusterBasedLimit: true,
       description: `Data retention in days for Operate. default = ${RETENTION_LIMIT_DEFAULT.operate}days. Min = ${RETENTION_LIMIT_MINIMUM.operate}days, Max = ${RETENTION_LIMIT_MAXIMUM.operate}days.`,
-      validate: (input) => input >= RETENTION_LIMIT_MINIMUM.operate && input <= RETENTION_LIMIT_MAXIMUM.operate
+      validate: (input) => Number.isInteger(input) && input >= RETENTION_LIMIT_MINIMUM.operate && input <= RETENTION_LIMIT_MAXIMUM.operate
     },
     {
       key: "dataRetentionTasklist",
       type: "number",
       isClusterBasedLimit: true,
       description: `Data retention in days for Tasklist. default = ${RETENTION_LIMIT_DEFAULT.tasklist}days. Min = ${RETENTION_LIMIT_MINIMUM.tasklist}days, Max = ${RETENTION_LIMIT_MAXIMUM.tasklist}days.`,
-      validate: (input) => input >= RETENTION_LIMIT_MINIMUM.tasklist && input <= RETENTION_LIMIT_MAXIMUM.tasklist
+      validate: (input) => Number.isInteger(input) && input >= RETENTION_LIMIT_MINIMUM.tasklist && input <= RETENTION_LIMIT_MAXIMUM.tasklist
     },
     {
       key: "dataRetentionOptimize",
       type: "number",
       isClusterBasedLimit: true,
       description: `Data retention in days for Optimize. default = ${RETENTION_LIMIT_DEFAULT.optimize}days. Min = ${RETENTION_LIMIT_MINIMUM.optimize}days, Max = ${RETENTION_LIMIT_MAXIMUM.optimize}days.`,
-      validate: (input) => input >= RETENTION_LIMIT_MINIMUM.optimize && input <= RETENTION_LIMIT_MAXIMUM.optimize
+      validate: (input) => Number.isInteger(input) && input >= RETENTION_LIMIT_MINIMUM.optimize && input <= RETENTION_LIMIT_MAXIMUM.optimize
     },
     {
       key: "unifiedDataRetention",
       type: "number",
       isClusterBasedLimit: true,
       description: `Unified data retention in days for Zeebe broker. default = ${RETENTION_LIMIT_DEFAULT.unified}days. Min = ${RETENTION_LIMIT_MINIMUM.unified}days, Max = ${RETENTION_LIMIT_MAXIMUM.unified}days.`,
-      validate: (input) => input >= RETENTION_LIMIT_MINIMUM.unified && input <= RETENTION_LIMIT_MAXIMUM.unified
+      validate: (input) => Number.isInteger(input) && input >= RETENTION_LIMIT_MINIMUM.unified && input <= RETENTION_LIMIT_MAXIMUM.unified
     }
   ];
 }
@@ -152,6 +153,14 @@ function allSalesPlanLimits() {
       description: "when enabled, users with only the Developer role cannot create clusters in this org. Admins, Owners, Members, and Operations Engineers are unaffected.",
       isClusterBasedLimit: false
     },
+    {
+      key: "preprodClusterTtlHours",
+      type: "number",
+      description: "dev and int only: the nightly delete cron deletes every cluster of this org that is older than N hours, with no confirmation. On a sales plan, every org that gets the plan later gets the limit too. For our own test orgs. default = not active",
+      isClusterBasedLimit: false,
+      validate: (input) => Number.isInteger(input) && input >= 1,
+      preprodOnly: true
+    },
     ...allClusterBasedLimits()
   ];
 }
@@ -160,9 +169,12 @@ function unusedClusterBasedLimits(limits) {
     (current) => !(Object.keys(limits).includes(current.key) && limits[current.key] !== null)
   );
 }
-function unusedSalesPlanLimits(limits) {
+function isLimitOfferedOnStage(limit, stage) {
+  return !limit.preprodOnly || isPreprodClusterTtlStage(stage);
+}
+function unusedSalesPlanLimits(limits, stage) {
   return allSalesPlanLimits().filter(
-    (current) => !(Object.keys(limits).includes(current.key) && limits[current.key] !== null)
+    (current) => !(Object.keys(limits).includes(current.key) && limits[current.key] !== null) && (stage === void 0 || isLimitOfferedOnStage(current, stage))
   );
 }
 export {
@@ -174,6 +186,7 @@ export {
   allClusterBasedLimits,
   allSalesPlanLimits,
   deprecatedLimit,
+  isLimitOfferedOnStage,
   unusedClusterBasedLimits,
   unusedSalesPlanLimits
 };