address review comments

Author: lennessyy

docs/encyclopedia/workers/serverless-workers.mdx

@@ -81,7 +81,7 @@ The invocation flow works as follows:
 5. The Serverless Worker starts, creates a Temporal Client, and begins polling the Task Queue.
 6. The Worker processes available Tasks until it exits (see [Worker lifecycle](#worker-lifecycle)).
 
-The WCI also monitors the Task Queue backlog independently. If tasks arrive faster than Workers can process them, the
+The WCI also monitors the Task Queue backlog independently. If Tasks arrive faster than Workers can process them, the
 WCI invokes additional Workers in parallel until the backlog drains or provider concurrency limits are reached.
 
 Each invocation is independent. The Worker creates a fresh client connection on every invocation. There is no connection
@@ -90,7 +90,7 @@ reuse or shared state across invocations.
 ## Autoscaling {#autoscaling}
 
 Temporal automatically scales Serverless Workers based on Task Queue signals. When Tasks arrive and no Worker is
-available, Temporal invokes new Workers. When the work is done, Workers exit and scale to zero.
+available, Temporal invokes new Workers. When the Tasks are done, Workers exit and scale to zero.
 
 The WCI uses two signals to decide when to invoke new Workers:
 
@@ -105,7 +105,7 @@ responsive.
 ### Task Queue backlog {#task-queue-backlog}
 
 The WCI monitors Task Queue metadata to determine whether pending Tasks exist without enough Workers to process them. If
-there is work on the queue and not enough Workers, the WCI invokes additional Workers.
+there are Tasks on the queue and not enough Workers, the WCI invokes additional Workers.
 
 ## Scaling with long-lived Workers {#scaling-with-long-lived-workers}
 
@@ -125,7 +125,7 @@ A single Serverless Worker invocation has three phases: init, work, and shutdown
   src="/diagrams/serverless-worker-lifecycle.svg"
   srcDark="/diagrams/serverless-worker-lifecycle-dark.svg"
   alt="Serverless Worker lifecycle"
-  title="The shutdown deadline buffer controls when the Worker stops polling, and the Worker stop timeout controls how long the Worker waits for in-flight Tasks to finish before shutdown hooks run. Diagram is not to scale. Shutdown hooks typically take less than a few seconds."
+  title="Diagram is not to scale. The shutdown deadline buffer controls when the Worker stops polling, and the Worker stop timeout controls how long the Worker waits for in-flight Tasks to finish before shutdown hooks run. Shutdown hooks typically take less than a few seconds."
 />
 
 During the **init** phase, the Worker initializes and establishes a client connection to Temporal.
@@ -150,7 +150,7 @@ If your Worker handles long-running Activities, set these three values together:
   :::tip
 
   If your longest-running Activity runs longer than half the maximum invocation deadline, this constraint may be difficult or impossible to meet.
-  In this case, use [Activity Heartbeats](/activity-heartbeat) to record the state of the Activity execution so that the next retry can pick up where it left off.
+  In this case, use [Activity Heartbeats](/detecting-activity-failures#activity-heartbeat) to record the state of the Activity execution so that the next retry can pick up where it left off.
 
   :::
 
@@ -210,7 +210,7 @@ With single-slot configuration, each Activity gets a dedicated execution environ
 | Activity duration | Must complete within the compute provider's invocation limit (minus shutdown deadline buffer). For AWS Lambda, the maximum is 15 minutes. |
 | Workflow duration | No limit. Workflows of any duration work, regardless of the invocation timeout. A Workflow runs across as many invocations as needed.     |
 | Worker code       | Same Temporal SDK Worker code, using the serverless Worker package for your SDK.                                                          |
-| Versioning        | [Worker Versioning](/worker-versioning) is required. Each Workflow must have an `AutoUpgrade` or `Pinned` behavior, set per-Workflow or as a worker-level default. |
+| Versioning        | [Worker Versioning](/worker-versioning) is required. Each Workflow must have an `AutoUpgrade` or `Pinned` behavior, set per-Workflow or as a Worker-level default. |
 
 ## Compute providers {#compute-providers}
 

docs/production-deployment/worker-deployments/index.mdx

@@ -37,7 +37,7 @@ This section also covers specific Worker Deployment examples:
 
 - [**Serverless Workers**](/production-deployment/worker-deployments/serverless-workers)
   Deploy Serverless Workers on serverless compute like AWS Lambda.
-  Temporal invokes your Worker when tasks arrive, with no long-lived processes to manage.
+  Temporal invokes your Worker when Tasks arrive, with no long-lived processes to manage.
 
 - [**Deploy Workers to Amazon EKS**](/production-deployment/worker-deployments/deploy-workers-to-aws-eks)
   Containerize your Worker, publish it to Amazon Elastic Container Registry (ECR), and deploy it to Amazon Elastic Kubernetes Service (EKS) using the Temporal Python SDK.

docs/production-deployment/worker-deployments/serverless-workers/aws-lambda.mdx

@@ -45,48 +45,18 @@ APIs are experimental and may be subject to backwards-incompatible changes.
 - The AWS-specific steps in this guide require the [`aws` CLI](https://aws.amazon.com/cli/) installed and configured
   with your AWS credentials. You may use other tools to perform the steps, such as the AWS Console or the AWS SDKs.
 
-<SdkTabs hideUnsupportedLanguages>
-<SdkTabs.Go>
-
-- The [Go SDK](/develop/go) (`go.temporal.io/sdk`)
-
-  :::tip
-
-  If you are just exploring the Serverless Worker feature and don't have a Workflow ready, you can use the sample
-  Workflows and Activities from the
-  [Go Lambda Worker sample](https://github.com/temporalio/samples-go/tree/main/lambda-worker).
-
-  :::
-
-</SdkTabs.Go>
-<SdkTabs.Python>
-
-- The [Python SDK](/develop/python) (`temporalio`)
+- The [Go SDK](/develop/go), [Python SDK](/develop/python), or [TypeScript SDK](/develop/typescript), depending on which
+  language you are using. Use the tabs to select your language and the rest of the page will update accordingly.
 
   :::tip
 
-  If you are just exploring the Serverless Worker feature and don't have a Workflow ready, you can use the sample
-  Workflows and Activities from the
-  [Python Lambda Worker sample](https://github.com/temporalio/samples-python/tree/main/lambda_worker).
-
-  :::
-
-</SdkTabs.Python>
-<SdkTabs.TypeScript>
-
-- The [TypeScript SDK](/develop/typescript) (`@temporalio/lambda-worker`)
-
-  :::tip
-
-  If you are just exploring the Serverless Worker feature and don't have a Workflow ready, you can use the sample
-  Workflows and Activities from the
+  If you are exploring the Serverless Worker feature and don't have a Workflow ready, you can use a sample from
+  the [Go Lambda Worker sample](https://github.com/temporalio/samples-go/tree/main/lambda-worker),
+  [Python Lambda Worker sample](https://github.com/temporalio/samples-python/tree/main/lambda_worker), or
   [TypeScript Lambda Worker sample](https://github.com/temporalio/samples-typescript/tree/main/lambda-worker).
 
   :::
 
-</SdkTabs.TypeScript>
-</SdkTabs>
-
 ## 1. Write Worker code {#write-worker-code}
 
 Write a Worker that runs inside a Lambda function. The Worker handles the per-invocation lifecycle: connecting to
@@ -124,7 +94,7 @@ func main() {
 ```
 
 Each Workflow must have a [versioning behavior](/worker-versioning#versioning-behaviors), either `AutoUpgrade` or
-`Pinned`. Set it per-Workflow at registration time, or set a worker-level default with `DefaultVersioningBehavior` in
+`Pinned`. Set it per-Workflow at registration time, or set a Worker-level default with `DefaultVersioningBehavior` in
 `DeploymentOptions`.
 
 For details on configuration options, Lambda-tuned defaults, and the invocation lifecycle, see
@@ -159,7 +129,7 @@ lambda_handler = run_worker(
 ```
 
 Each Workflow must have a [versioning behavior](/worker-versioning#versioning-behaviors), either `PINNED` or
-`AUTO_UPGRADE`. Set it per-Workflow in the `@workflow.defn` decorator, or set a worker-level default with
+`AUTO_UPGRADE`. Set it per-Workflow in the `@workflow.defn` decorator, or set a Worker-level default with
 `default_versioning_behavior` in the worker config.
 
 ```python

docs/production-deployment/worker-deployments/serverless-workers/index.mdx

@@ -21,8 +21,8 @@ Deploy your Worker code to a serverless provider, configure a compute provider f
 There are no long-lived processes to provision or scale.
 
 Temporal monitors Task Queues that have a compute provider configured.
-When a task arrives and no Worker is polling, Temporal invokes the configured compute target.
-The Worker starts, processes available tasks, and shuts down when the invocation window ends.
+When a Task arrives and no Worker is polling, Temporal invokes the configured compute target.
+The Worker starts, processes available Tasks, and shuts down when the invocation window ends.
 
 ## Supported providers
 

docs/production-deployment/worker-deployments/serverless-workers/self-hosted-setup.mdx

@@ -41,7 +41,7 @@ Worker.
 
 ## Ensure Lambda can reach the Temporal Service {#ensure-network-reachability}
 
-The [Temporal Service frontend](/temporal-service#frontend-service) must be reachable from the Lambda execution
+The [Temporal Service frontend](/temporal-service/temporal-server#frontend-service) must be reachable from the Lambda execution
 environment. How to achieve this depends on your network setup. If the Temporal Service runs on a private network, you
 may need [VPC access for Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html), VPC peering, or a
 similar mechanism to allow the Lambda function to connect to the Temporal frontend.