diff --git a/src/frontend/src/content/docs/get-started/glossary.mdx b/src/frontend/src/content/docs/get-started/glossary.mdx
index d7b48663..7d28c4bc 100644
--- a/src/frontend/src/content/docs/get-started/glossary.mdx
+++ b/src/frontend/src/content/docs/get-started/glossary.mdx
@@ -50,7 +50,7 @@ Resources are the building blocks you compose in your AppHost.
 
 ### Distributed application
 
-A **distributed application**is an application split into multiple independent services that communicate over a network. Instead of one monolithic application, you have:
+A **distributed application** is an application split into multiple independent services that communicate over a network. Instead of one monolithic application, you have:
 
 - A frontend service
 - One or more API services  
@@ -63,7 +63,7 @@ Aspire helps you orchestrate all these pieces together.
 
 ### Service defaults
 
-**Service defaults**are pre-configured settings that Aspire applies to your .NET projects automatically. They include:
+**Service defaults** are pre-configured settings that Aspire applies to your .NET projects automatically. They include:
 
 - **OpenTelemetry** - Automatic logging, tracing, and metrics
 - **Health checks** - Endpoints for monitoring (`/health`, `/alive`)
@@ -153,7 +153,7 @@ Example: `Host=localhost;Port=5432;Database=mydb;Username=postgres;Password=secr
 
 ### Service discovery
 
-**Service discovery**is the mechanism that allows your services to find and communicate with each other by name, without hardcoding addresses. In Aspire:
+**Service discovery** is the mechanism that allows your services to find and communicate with each other by name, without hardcoding addresses. In Aspire:
 
 - Resources are addressable by their resource name (e.g., `http://apiservice`)
 - The AppHost configures DNS/environment variables so services can resolve each other
@@ -163,7 +163,7 @@ For details, see [Service Discovery](/fundamentals/service-discovery/).
 
 ### Health check
 
-A **health check**is a mechanism to determine if a resource is ready and functioning. Aspire uses health checks in two ways:
+A **health check** is a mechanism to determine if a resource is ready and functioning. Aspire uses health checks in two ways:
 
 1. **AppHost level**: Determines when dependencies are ready (controls `WaitFor()` behavior)
 2. **Application level**: Exposes `/health` and `/alive` endpoints for load balancers
@@ -172,7 +172,7 @@ For details, see [Health Checks](/fundamentals/health-checks/).
 
 ### Environment variable
 
-Aspire uses **environment variables**to pass configuration from the AppHost to your services:
+Aspire uses **environment variables** to pass configuration from the AppHost to your services:
 
 - Connection strings: `ConnectionStrings__resourcename`
 - Service endpoints: `services__servicename__https__0`
@@ -198,7 +198,7 @@ Example: `Aspire.Hosting.PostgreSQL` adds the `AddPostgres()` method.
 
 ### Client integration
 
-A **client integration**is an Aspire package that helps your application code connect to resources. Client integrations:
+A **client integration** is an Aspire package that helps your application code connect to resources. Client integrations:
 
 - Register SDK clients with dependency injection
 - Configure connection strings from environment variables
@@ -242,7 +242,7 @@ Aspire operates in two distinct modes depending on what you're trying to accompl
 
 ### Publish mode
 
-**Publish mode**generates deployment artifacts. When you execute `aspire publish`:
+**Publish mode** generates deployment artifacts. When you execute `aspire publish`:
 
 - Aspire generates Kubernetes manifests, Docker Compose files, or cloud infrastructure
 - No containers are started locally