Merge branch 'main' into mm/local-regular-activities

Author: flippedcoder

.vale-ci.ini

@@ -14,8 +14,56 @@ Temporal.programming = NO
 Temporal.WordList = NO
 Temporal.terms = NO
 
+; Temporal.Headings and Temporal.RelativeLinks are intentionally left enabled
+; (not listed above) — they're the two high-confidence checks this CI gate runs.
+
 ; ignore MDX custom heading-ID comments, e.g. {/* #ha-worker-patterns */}
 TokenIgnores = (\{/\*[^\n]*?\*/\})
 
+; These are reference docs whose headings are literal command/metric names
+; (e.g. "## audit-log", "### --workflow_id"), not prose — sentence-case
+; capitalization doesn't apply, so skip Temporal.Headings for them.
+[docs/references/sdk-metrics.mdx]
+Temporal.Headings = NO
+
+[docs/tctl-v1/**]
+Temporal.Headings = NO
+
+[docs/cli/command-reference/**]
+Temporal.Headings = NO
+
+[docs/cloud/tcld/**]
+Temporal.Headings = NO
+
+[docs/cloud/references/regions/**]
+Temporal.Headings = NO
+
+[docs/cloud/metrics/reference.mdx]
+Temporal.Headings = NO
+
+[docs/cloud/metrics/openmetrics/metrics-reference.mdx]
+Temporal.Headings = NO
+
+[docs/references/cluster-metrics.mdx]
+Temporal.Headings = NO
+
+[docs/references/configuration.mdx]
+Temporal.Headings = NO
+
+[docs/references/web-ui-configuration.mdx]
+Temporal.Headings = NO
+
+[docs/references/server-options.mdx]
+Temporal.Headings = NO
+
+[docs/references/errors.mdx]
+Temporal.Headings = NO
+
+[docs/references/commands.mdx]
+Temporal.Headings = NO
+
+[docs/references/events.mdx]
+Temporal.Headings = NO
+
 [formats]
 mdx = md

.vale.ini

@@ -27,6 +27,51 @@ Google.Will = NO
 Microsoft.ComplexWords = NO
 Google.WordList = NO
 
+; These are reference docs whose headings are literal command/metric names
+; (e.g. "## audit-log", "### --workflow_id"), not prose — sentence-case
+; capitalization doesn't apply, so skip Temporal.Headings for them.
+[docs/references/sdk-metrics.mdx]
+Temporal.Headings = NO
+
+[docs/tctl-v1/**]
+Temporal.Headings = NO
+
+[docs/cli/command-reference/**]
+Temporal.Headings = NO
+
+[docs/cloud/tcld/**]
+Temporal.Headings = NO
+
+[docs/cloud/references/regions/**]
+Temporal.Headings = NO
+
+[docs/cloud/metrics/reference.mdx]
+Temporal.Headings = NO
+
+[docs/cloud/metrics/openmetrics/metrics-reference.mdx]
+Temporal.Headings = NO
+
+[docs/references/cluster-metrics.mdx]
+Temporal.Headings = NO
+
+[docs/references/configuration.mdx]
+Temporal.Headings = NO
+
+[docs/references/web-ui-configuration.mdx]
+Temporal.Headings = NO
+
+[docs/references/server-options.mdx]
+Temporal.Headings = NO
+
+[docs/references/errors.mdx]
+Temporal.Headings = NO
+
+[docs/references/commands.mdx]
+Temporal.Headings = NO
+
+[docs/references/events.mdx]
+Temporal.Headings = NO
+
 [formats]
 mdx = md
 

docs/best-practices/cloud-access-control.mdx

@@ -50,16 +50,16 @@ Select the option that aligns best with your infrastructure, security requiremen
 
 In the case that you are using multiple certificates signed by the same CA, and some of these certificates are for production environments, there are some workarounds you can employ. 
 
-One convention is to give certificates a common name that matches the namespace. If you do this when using the same CA for dev and prod, then you can leverage Certificate Filters to prevent access to production environments. This is described in detail under the [authorization section](https://docs.temporal.io/cloud/certificates#control-authorization) of the documentation. 
+One convention is to give certificates a common name that matches the namespace. If you do this when using the same CA for dev and prod, then you can leverage Certificate Filters to prevent access to production environments. This is described in detail under the [authorization section](/cloud/certificates#control-authorization) of the documentation. 
 
 ## Best practices
 
 ### Establish clear guidelines on authentication methods
 
-Teams should standardize on either [mTLS certificates](https://docs.temporal.io/cloud/certificates) or
-[API keys](https://docs.temporal.io/cloud/api-keys) for the following operations:
+Teams should standardize on either [mTLS certificates](/cloud/certificates) or
+[API keys](/cloud/api-keys) for the following operations:
 - Connect Temporal clients to Temporal Cloud (e.g. Worker processes)
-- Automation (e.g. Temporal Cloud [Operations API](https://docs.temporal.io/ops), [Terraform provider](https://docs.temporal.io/cloud/terraform-provider), [Temporal CLI](https://docs.temporal.io/cli/setup-cli))
+- Automation (e.g. Temporal Cloud [Operations API](/ops), [Terraform provider](/cloud/terraform-provider), [Temporal CLI](/cli/setup-cli))
 
 By default, teams should use API keys with [service accounts](/cloud/manage-access/service-accounts) for both operations. API keys
 are generally easier to set up and rotate than mTLS certificates, and service accounts let you assign account-level and

docs/best-practices/cost-optimization.mdx

@@ -114,7 +114,7 @@ Focus optimization efforts on what's driving costs with a specific workload:
 
 ## Measuring
 
-Establish [baseline metrics](https://docs.temporal.io/cloud/metrics/reference) before optimizing and be sure to validate impact after implementation.
+Establish [baseline metrics](/cloud/metrics/reference) before optimizing and be sure to validate impact after implementation.
 Specifically:
 
 - Actions consumption (per Workflow, per day/month, by Namespace)
@@ -124,7 +124,7 @@ Specifically:
 
 ## Actions optimization
 
-[Actions](https://docs.temporal.io/cloud/actions) encompass Workflow operations, Activity Executions, Signals, Queries, and other interactions with Temporal.
+[Actions](/cloud/actions) encompass Workflow operations, Activity Executions, Signals, Queries, and other interactions with Temporal.
 Each represents a unit of consumption.
 
 ### Activity granularity

docs/best-practices/knowledge-hub.mdx

@@ -26,7 +26,7 @@ To bootstrap your knowledge hub, use the
 
 ## What belongs in your knowledge hub
 
-Although Temporal itself has [thorough documentation](https://docs.temporal.io/), not all of it applies to your organization or your teams' use cases.
+Although Temporal itself has [thorough documentation](/), not all of it applies to your organization or your teams' use cases.
 The knowledge hub distills the documentation into just the specific information your teams need.
 One way to organize the content is according to where developers are in their journey.
 The following sample outline shows what sections to include.
@@ -97,7 +97,7 @@ These metrics create a feedback loop: measure, identify gaps, improve content, a
 
 ## What doesn't belong in your knowledge hub
 
-A knowledge hub is not a mirror of [Temporal's official documentation](https://docs.temporal.io/).
+A knowledge hub is not a mirror of [Temporal's official documentation](/).
 Avoid duplicating SDK API references, concept explanations, or release notes that Temporal already maintains.
 When that content changes, your copy becomes a source of confusion rather than clarity.
 Instead, link to the official docs and reserve your knowledge hub for organization-specific decisions, conventions,

docs/best-practices/security-controls.mdx

@@ -35,21 +35,21 @@ Strong identity management in Temporal Cloud is crucial for ensuring secure acce
 
 ### Best Practices:
 
-#### 1. Enable [SAML Single Sign-on](https://docs.temporal.io/cloud/manage-access/saml) (SSO) for User Access
+#### 1. Enable [SAML Single Sign-on](/cloud/manage-access/saml) (SSO) for User Access
 
 Integrate Temporal Cloud with your organization's identity provider via SAML 2.0 for centralized authentication. SSO allows you to enforce your corporate login policies (MFA, password complexity, etc.). When you configure SAML with Temporal Cloud, you can disable social logins (i.e. Microsoft, Google) by opening a support ticket. 
 
 #### 2. Use Least-Privilege Roles for Temporal Cloud Users
 
-Temporal Cloud provides [preconfigured account-level roles](https://docs.temporal.io/cloud/manage-access/users) (Account Owner, Finance Admin, Global Admin, Developer, Read-Only) and Namespace-level permissions. Assign users the lowest level of access they need. For example, give developers access only to the Namespaces they work on, and use read-only roles for auditors or reviewers. Regularly review user roles and remove or downgrade accounts that are no longer needed
+Temporal Cloud provides [preconfigured account-level roles](/cloud/manage-access/users) (Account Owner, Finance Admin, Global Admin, Developer, Read-Only) and Namespace-level permissions. Assign users the lowest level of access they need. For example, give developers access only to the Namespaces they work on, and use read-only roles for auditors or reviewers. Regularly review user roles and remove or downgrade accounts that are no longer needed
 
 #### 3. Leverage SCIM or Automated User Provisioning
 
-When applicable, use [SCIM](https://docs.temporal.io/cloud/manage-access/scim) or the Temporal Cloud user management API to automate adding and removing user accounts. This ensures timely removal of access when people change roles or leave the organization.
+When applicable, use [SCIM](/cloud/manage-access/scim) or the Temporal Cloud user management API to automate adding and removing user accounts. This ensures timely removal of access when people change roles or leave the organization.
 
 #### Use Service Accounts for Automation
 
-For non-human access (CI/CD pipelines, backend services), use [Temporal Cloud Service Accounts](https://docs.temporal.io/cloud/manage-access/service-accounts) instead of shared user logins. Service Accounts are machine identities that can be granted specific permissions without ties to an individual. Create separate Service Accounts with unique API keys for different applications or microservices, and apply least privilege to each (e.g. a service account that only has access to one Namespace).
+For non-human access (CI/CD pipelines, backend services), use [Temporal Cloud Service Accounts](/cloud/manage-access/service-accounts) instead of shared user logins. Service Accounts are machine identities that can be granted specific permissions without ties to an individual. Create separate Service Accounts with unique API keys for different applications or microservices, and apply least privilege to each (e.g. a service account that only has access to one Namespace).
 
 ## Secure Application Authentication and API Access
 
@@ -67,7 +67,7 @@ We recommend you enable mTLS for strong identity assurance of clients; it ensure
 
 #### 2. Proactively manage and rotate certificates
 
-Track the expiration dates of your client and [Certificate Authority certificates](https://docs.temporal.io/cloud/certificates). Temporal Cloud trusts the uploaded CA; if it expires, all client authorizations will fail. Establish and automate a certificate rotation schedule (e.g. rotate client certificates quarterly and CA certificates annually, well before expiry). Temporal supports uploading a new CA certificate alongside the old one to allow seamless rollover. Always test new certificates in a staging environment if possible.
+Track the expiration dates of your client and [Certificate Authority certificates](/cloud/certificates). Temporal Cloud trusts the uploaded CA; if it expires, all client authorizations will fail. Establish and automate a certificate rotation schedule (e.g. rotate client certificates quarterly and CA certificates annually, well before expiry). Temporal supports uploading a new CA certificate alongside the old one to allow seamless rollover. Always test new certificates in a staging environment if possible.
 
 #### 3. If you’re using API Keys, handle them with strict care
 
@@ -86,11 +86,11 @@ Although Temporal Cloud is a SaaS offering, you retain control over its networki
 
 #### 1. Use Private Connectivity
 
-Temporal Cloud supports private connectivity options such as [AWS PrivateLink](https://docs.temporal.io/cloud/connectivity/aws-connectivity) and [Google Cloud Private Service Connect](https://docs.temporal.io/cloud/connectivity/gcp-connectivity). If your infrastructure is in AWS or GCP, configure a PrivateLink/PSC endpoint for Temporal Cloud. This allows your workers and applications to reach Temporal Cloud over a private network path, avoiding traversal of the public internet. Private connectivity reduces the surface for man-in-the-middle attacks and can meet stringent network security policies.
+Temporal Cloud supports private connectivity options such as [AWS PrivateLink](/cloud/connectivity/aws-connectivity) and [Google Cloud Private Service Connect](/cloud/connectivity/gcp-connectivity). If your infrastructure is in AWS or GCP, configure a PrivateLink/PSC endpoint for Temporal Cloud. This allows your workers and applications to reach Temporal Cloud over a private network path, avoiding traversal of the public internet. Private connectivity reduces the surface for man-in-the-middle attacks and can meet stringent network security policies.
 
 #### 2. Separate environments by Namespace
 
-Use [Temporal Namespaces](https://docs.temporal.io/best-practices/managing-namespace#naming-conventions) to isolate workflows for different environments or teams (e.g. development, staging, production). Each Namespace is logically segregated and cannot interact with others by default, providing a security boundary. 
+Use [Temporal Namespaces](/best-practices/managing-namespace#naming-conventions) to isolate workflows for different environments or teams (e.g. development, staging, production). Each Namespace is logically segregated and cannot interact with others by default, providing a security boundary. 
 
 Ensure that your production Namespace uses stricter network controls (e.g. only accessible from the prod network) and that credentials for it are separate from non-prod Namespaces. This limits the impact of any compromise in a lower environment, and as workflow data is only visible to users with access to that Namespace, separating environments by Namespace also enforces data-visibility boundaries.
 
@@ -102,19 +102,19 @@ Temporal's data encryption capabilities ensure the security and confidentiality
 
 #### 1. Enable Client-Side Encryption for Workflow Data
 
-Temporal provides an optional [data conversion framework](https://docs.temporal.io/dataconversion) (Data Converter) and payload codec interface; customers must implement, deploy, and operate their own custom codec and manage encryption keys. 
+Temporal provides an optional [data conversion framework](/dataconversion) (Data Converter) and payload codec interface; customers must implement, deploy, and operate their own custom codec and manage encryption keys. 
 
 In practice, this means you can encrypt any sensitive data before it is sent to Temporal Cloud and only decrypt it on the Client/Worker side. Because encryption keys stay under your control, you are responsible for key generation, secure storage, rotation, and versioning. Implementing this involves developing a custom codec plugin in your Temporal SDK and optionally (if you need to inspect decrypted payloads in the Web UI or CLI) deploying a dedicated codec server.
 
-#### 2. Encode Workflow Failure Details with a [Failure Converter](https://docs.temporal.io/failure-converter)
+#### 2. Encode Workflow Failure Details with a [Failure Converter](/failure-converter)
 
 Temporal’s default behavior copies error messages and call stacks as plain text, and this text is directly accessible in the Message field of Workflow Executions.
 
-If your failure messages and stack traces contain sensitive information, it is recommended that you configure the [Failure Converter](https://docs.temporal.io/failure-converter) to encrypt the error information. This would encrypt the `message` and `stack_trace` fields in the payloads.
+If your failure messages and stack traces contain sensitive information, it is recommended that you configure the [Failure Converter](/failure-converter) to encrypt the error information. This would encrypt the `message` and `stack_trace` fields in the payloads.
 
 #### 3. Leverage Namespace Data Retention Policies
 
-Temporal Cloud Namespace has a [Retention Period](https://docs.temporal.io/temporal-service/temporal-server#retention-period) setting for workflow histories (1 to 90 days). Set an appropriate retention period to balance operational needs with security. Shorter retention means completed workflow data (history, payloads) is purged sooner, reducing the amount of sensitive data stored in the cloud at any time. Document your retention choices to align with your company’s data retention policies and regulatory requirements. For retention periods over 90 days, these can be exported to your own GCS or S3 buckets.
+Temporal Cloud Namespace has a [Retention Period](/temporal-service/temporal-server#retention-period) setting for workflow histories (1 to 90 days). Set an appropriate retention period to balance operational needs with security. Shorter retention means completed workflow data (history, payloads) is purged sooner, reducing the amount of sensitive data stored in the cloud at any time. Document your retention choices to align with your company’s data retention policies and regulatory requirements. For retention periods over 90 days, these can be exported to your own GCS or S3 buckets.
 
 ### Availability and Disaster Recovery
 
@@ -137,8 +137,8 @@ Run a business-impact analysis to flag workflows where a regional outage would c
 
 For many organizations, ensuring High Availability (HA) is required because of strict uptime requirements, compliance, and regulatory needs. 
 
-For these critical use cases, enable High Availability features for specific namespaces for a [99.99% contractual SLA](https://docs.temporal.io/cloud/high-availability#high-availability-features). When choosing between [same-region, multi-region, and multi-cloud replication](https://docs.temporal.io/cloud/high-availability), it is recommended to use multi-region/multi-cloud replication to distribute your dependencies across regions. Using physically separated regions improves the fault tolerance of your application.
+For these critical use cases, enable High Availability features for specific namespaces for a [99.99% contractual SLA](/cloud/high-availability#high-availability-features). When choosing between [same-region, multi-region, and multi-cloud replication](/cloud/high-availability), it is recommended to use multi-region/multi-cloud replication to distribute your dependencies across regions. Using physically separated regions improves the fault tolerance of your application.
 
-By default, Temporal Cloud provides a [99.9% contractual SLA guarantee](https://docs.temporal.io/cloud/high-availability) against service errors for all namespaces. 
+By default, Temporal Cloud provides a [99.9% contractual SLA guarantee](/cloud/high-availability) against service errors for all namespaces. 
 
-Note: [enabling HA features for namespaces will 2x the consumption cost.](https://docs.temporal.io/cloud/pricing#high-availability-features)
+Note: [enabling HA features for namespaces will 2x the consumption cost.](/cloud/pricing#high-availability-features)

docs/cloud/audit-logs-gcp.mdx

@@ -59,6 +59,6 @@ If everything is configured correctly, you will see a `Success` status indicatin
 
 :::info MORE INFORMATION
 
-For more details, refer to [Audit Logs with Temporal Cloud](https://docs.temporal.io/cloud/audit-logs).
+For more details, refer to [Audit Logs with Temporal Cloud](/cloud/audit-logs).
 
 :::

docs/cloud/capacity-modes.mdx

@@ -155,7 +155,7 @@ For Requests in excess of 4 TRUs in regions outside of the US, we recommend subm
 ### Provisioned Capacity Availability
 The amount of capacity available within a region may vary. 
 Temporal will check available capacity at the time of your request and aims to provision requested capacity within two minutes. 
-If you need capacity beyond what is self-serviceable or available in a region, please [file a support ticket](https://docs.temporal.io/cloud/support#ticketing) indicating the limit, region, and timeframe that the capacity is needed. 
+If you need capacity beyond what is self-serviceable or available in a region, please [file a support ticket](/cloud/support#ticketing) indicating the limit, region, and timeframe that the capacity is needed. 
 
 
 ### When should I use Provisioned Capacity?