Updated Fusion Getting Started Guide

website/content/docs/fusion/getting-started.md

@@ -1,6 +1,6 @@
 ---
-title: "Getting Started"
-description: "Build your first Hot Chocolate Fusion setup: two subgraphs and a gateway composed into one GraphQL API, with entities, lookups, and composition basics."
+title: "Getting Started with GraphQL Federation"
+description: "Follow a practical GraphQL Federation tutorial to build two subgraphs, compose a unified schema, and query the unified API with ChilliCream's Fusion gateway."
 ---
 
 In this tutorial, you will build and run a small Fusion setup locally.

website/content/docs/fusion/local-development.md

@@ -1,9 +1,9 @@
 ---
-title: "Local Development"
-description: "Develop Fusion locally with a .NET Aspire AppHost, written in C# or TypeScript, that composes subgraph schemas into a gateway archive at startup."
+title: "Local GraphQL Federation Development with Aspire"
+description: "Develop GraphQL subgraphs locally in isolation, then compose them into your full graph and test changes with Aspire and ChilliCream's Fusion gateway."
 ---
 
-Fusion's local development experience is built on .NET Aspire: an AppHost, written in C# or TypeScript, starts your subgraphs and composes them into a running gateway. Without it, every change to a type, a field, or a resolver means re-exporting the schema, re-composing with the Nitro CLI, and restarting the gateway.
+Fusion's local development experience is built on [Aspire](https://aspire.dev): an AppHost, written in C# or TypeScript, starts your subgraphs and composes them into a running gateway. Without it, every change to a type, a field, or a resolver means re-exporting the schema, re-composing with the Nitro CLI, and restarting the gateway.
 
 The `HotChocolate.Fusion.Aspire` package integrates composition into the Aspire AppHost. When you run the AppHost, the orchestrator starts your subgraphs, fetches their source schemas from live endpoints, composes them into a Fusion archive, and writes it to the gateway project directory. This startup flow replaces the manual export-compose-restart cycle. Mark each local subgraph with `WithGraphQLHttpEndpoint()` so composition uses the schema exposed by the running service. The examples on this page show both AppHost languages.
 

website/content/docs/fusion/migration/migrating-from-schema-stitching.md

@@ -21,7 +21,7 @@ If you have worked with Schema Stitching, you already understand the core idea:
 | Delegating resolvers (`@delegate` directive)                   | Lookups (`[Lookup]` attribute)                     | The gateway handles cross-subgraph resolution automatically. You declare a lookup field in each subgraph; composition wires them together. |
 | `@delegate(path: "...")` field references                      | `[Require]` attribute                              | When a field needs data from another subgraph, you declare the dependency as a method parameter with `[Require]`.                          |
 | Auto-stitching / runtime schema merging                        | Build-time composition (`nitro fusion compose`)    | Schemas are merged offline by the Nitro CLI, producing a static configuration file. Conflicts are caught before deployment.                |
-| `PublishSchemaDefinition()` + Redis                            | `schema export` + `nitro fusion upload`            | Schema distribution uses the Nitro CLI or .NET Aspire instead of Redis pub/sub.                                                            |
+| `PublishSchemaDefinition()` + Redis                            | `schema export` + `nitro fusion upload`            | Schema distribution uses the Nitro CLI or Aspire instead of Redis pub/sub.                                                                 |
 | `RenameType()` / `RenameField()` / `IgnoreType()`              | Composition rules + `[Internal]` / `@inaccessible` | Type conflicts are resolved by composition rules. Fields you want to hide use `[Internal]` on lookups or `@inaccessible` on types.         |
 | `SchemaDefinition` / `SchemaExtension`                         | `schema.graphqls` + `schema-settings.json`         | Exported automatically by the subgraph on startup. You do not write these by hand.                                                         |
 
@@ -445,7 +445,7 @@ After migrating, several things that required manual work in stitching become au
 
 - **No gateway code changes when adding subgraphs.** In stitching, adding a remote schema meant updating the gateway's `Program.cs` (adding `AddRemoteSchema()`, HTTP clients, and extension files). In Fusion, you add the new subgraph's schema to the composition step and redeploy the gateway with the updated `.far` file. No gateway code changes.
 
-- **No Redis dependency for schema distribution.** If you used `PublishToRedis()` for schema federation, Fusion replaces that with the Nitro CLI or .NET Aspire orchestration.
+- **No Redis dependency for schema distribution.** If you used `PublishToRedis()` for schema federation, Fusion replaces that with the Nitro CLI or Aspire orchestration.
 
 ## Common Pitfalls