nits

Author: anupras-mohapatra-arm

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/2-environment-setup.md

@@ -9,7 +9,7 @@ layout: learningpathall
 
 ## Set up a Microsoft Azure virtual machine powered by Cobalt 100
 
-Set up an Arm Cobalt environment first, then keep your toolchain and runtime configuration stable across all test runs. This creates a reliable Arm baseline for migration and tuning work.
+Set up an Arm Azure environment first, then keep your toolchain and runtime configuration stable across all test runs. This creates a reliable Arm baseline for migration and tuning work.
 
 Start with the [Azure Cobalt Learning Path](https://learn.arm.com/learning-paths/servers-and-cloud-computing/cobalt/) and complete VM provisioning.
 
@@ -33,13 +33,14 @@ sudo apt-get install -y dotnet-sdk-9.0
 
 The Docker group change applies to new login sessions. Sign out and sign back in before running Docker without `sudo`, or run `newgrp docker` in the current terminal before continuing.
 
-Confirm architecture and tool versions before proceeding. On Azure Cobalt, the Linux machine architecture should be `aarch64`, and the .NET SDK should be a 9.0.x release.
+Confirm architecture and tool versions before proceeding: 
 
 ```bash
 uname -m
 dotnet --version
 docker --version
 ```
+On Azure Cobalt, the Linux machine architecture should be `aarch64`, and the .NET SDK should be a `9.0.x` release.
 
 The output is similar to:
 
@@ -55,7 +56,7 @@ If you're upgrading from an older .NET version before migrating to Cobalt, use [
 
 nopCommerce defaults to SQL Server, but you'll use PostgreSQL for Arm validation. For PostgreSQL installs, you need `citext` before migration and installation. Without it, installer migrations fail with `type "citext" does not exist` (captured in local test artifacts).
 
-Create PostgreSQL and enable `citext` before running the installer. The database runs in Docker on the Cobalt VM so the nopCommerce app can connect to `127.0.0.1:5432` during the local validation phase. 
+Create PostgreSQL and enable `citext` before running the installer. The database runs in Docker on the VM so the nopCommerce app can connect to `127.0.0.1:5432` during the local validation phase. 
 
 Replace the password value before running the following commands:
 

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/3-checkout-build-baseline.md

@@ -26,7 +26,7 @@ git fetch --tags --prune
 git checkout release-4.90.3
 git rev-parse --short=10 HEAD   # expect 9beda11c42
 ```
-The later commands assume you're in the `nopCommerce` repository root unless stated otherwise.
+Later commands in the section assume you're in the `nopCommerce` repository root unless stated otherwise.
 
 If you open a new terminal later, return to the same repository root before running commands:
 
@@ -49,7 +49,9 @@ Restoring first separates package resolution problems from compilation problems,
 
 ### Start and install nopCommerce
 
-Start the app locally and complete installer setup with PostgreSQL. Run the following command in one terminal and leave it running: 
+Start the app locally and complete installer setup with PostgreSQL. 
+
+Run the following command in one terminal and leave it running: 
 
 ```bash
 cd src/Presentation/Nop.Web
@@ -221,7 +223,7 @@ python3 test_nopcommerce_endpoints.py \
 
 The command prints the per-route summary and writes the raw measurements to `arm_before.json`. Keep that JSON file unchanged because it's the baseline artifact used in the tuning step.
 
-#### Baseline quality rules
+### Baseline quality rules
 
 Use these rules before you compare any optimization result:
 

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/4-dependency-mapping-manifests.md

@@ -13,26 +13,31 @@ Run dependency discovery before migration changes so you understand direct refer
 
 ### Map direct references
 
-Start from the `nopCommerce` repository root. Project-level references show what the app explicitly depends on before NuGet expands the graph. The command searches project files under `src` and prints file names and line numbers so you can jump directly to the owning project.
+Start from the `nopCommerce` repository root. Project-level references show what the app explicitly depends on before NuGet expands the graph. 
+
+Run the following command to search project files under `src` and print file names and line numbers, so you can jump directly to the owning project:
 
 ```bash
 rg -n "<PackageReference|<ProjectReference" src
 ```
 
 ### List transitive dependencies
 
-Enumerate the full dependency graph for the web entry point. Transitive packages often carry architecture-sensitive constraints, so review the output for runtime-specific package names, native library packages, image processing libraries, database providers, and platform-specific assets.
+Enumerate the full dependency graph for the web entry point:
 
 ```bash
 dotnet list src/Presentation/Nop.Web/Nop.Web.csproj package --include-transitive
 ```
+Transitive packages often carry architecture-sensitive constraints. Review the output for runtime-specific package names, native library packages, image processing libraries, database providers, and platform-specific assets.
 
 ### Generate an SBOM
 
 Generate an SBOM so you can track all components, versions, and exposure surface as a first-class migration artifact. While not strictly necessary for migration purposes, this is a best practice that'll save time. You can also give this SBOM to an LLM to extract insights about your codebase.
 
 The CycloneDX tool is installed as a .NET global tool. Add `~/.dotnet/tools` to `PATH` in the current shell so the `dotnet-CycloneDX` command is available immediately after installation.
 
+To generate an SBOM, run the following command:
+
 ```bash
 dotnet tool install --global CycloneDX
 export PATH="$PATH:$HOME/.dotnet/tools"
@@ -43,7 +48,7 @@ The `-rs` option includes project references, and `-F Json` writes JSON output t
 
 ### Inspect package internals for native payloads
 
-Inspect package contents directly when a dependency looks architecture-sensitive. NuGet package folders are usually lower case on Linux, so set `PACKAGE_ID` to the folder name under `~/.nuget/packages` and `PACKAGE_VERSION` to the version you want to inspect.
+Inspect package contents directly when a dependency looks architecture-sensitive. NuGet package folders are usually lower case on Linux, so set `PACKAGE_ID` to the folder name under `~/.nuget/packages` and `PACKAGE_VERSION` to the version you want to inspect:
 
 ```bash
 PACKAGE_ID="replace-with-package-id"
@@ -72,4 +77,4 @@ You must resolve B first, then validate A, then validate the app.
 
 You've reviewed application dependencies to understand what can change when you migrate to Arm.
 
-Next, you'll explore options to containerize the application.
+Next, you'll explore options to containerize and migrate the application.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/5-containerization.md

@@ -9,7 +9,7 @@ layout: learningpathall
 
 ## Containerize and migrate the application
 
-Containerization should preserve reproducibility across architectures. The following are practical paths for Dockerfile-based builds and .NET SDK container publish, with guardrails for multi-architecture delivery.
+Containerization should preserve reproducibility across architectures. The following are practical paths for Dockerfile-based builds, and .NET SDK container publish with multi-architecture delivery guardrails.
 
 Use the Dockerfile workflow as the default migration path for nopCommerce until your SDK-published image has the same Linux runtime dependencies and smoke-test results. Use SDK publish when you want MSBuild-owned image metadata and have a repeatable plan for the native packages that the Dockerfile previously installed.
 

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/6-deploy-verify-cobalt.md

@@ -17,7 +17,7 @@ Start with a conservative runtime profile that's commonly effective for server w
 
 Runtime environment variables are read when the .NET process starts. Stop the baseline `dotnet run` process, set the variables in the same terminal, and then restart nopCommerce. 
 
-The following thread-pool minimum matches the 2-vCPU validation VM. Treat it as a starting point, not a universal value for every Cobalt size:
+The following thread-pool minimum matches the 2-vCPU validation VM. Treat it as a starting point, not a universal value for every VM size:
 
 ```bash
 export DOTNET_TieredCompilation=1
@@ -36,7 +36,7 @@ cd ~/nopCommerce/src/Presentation/Nop.Web  # replace with your clone path if dif
 dotnet run -c Release --no-build --urls http://0.0.0.0:5000
 ```
 
-Increase `DOTNET_ThreadPool_ForceMinWorkerThreads` only when traces or load-test data show thread-pool starvation. Keep `DOTNET_EnableDiagnostics=0` for final measurement runs only; remove it when you need `dotnet-trace`, `dotnet-counters`, or profiler-based evidence.
+Increase `DOTNET_ThreadPool_ForceMinWorkerThreads` only when traces or load-test data show thread-pool starvation. Keep `DOTNET_EnableDiagnostics=0` for final measurement runs only. Remove it when you need `dotnet-trace`, `dotnet-counters`, or profiler-based evidence.
 
 #### (Optional) Run spin-wait experiment for .NET 8, 9, and 10
 
@@ -56,7 +56,7 @@ Treat this as an experiment, not a default. Turning off spin waiting can reduce
 - `TieredPGO` favors steady-state throughput by letting the JIT recompile hot methods with runtime profile data.
 - Test them together and separately if startup latency and warmed throughput both matter.
 
-Run the same endpoint suite used in the baseline from a second terminal. Keep the app running with the tuning profile in the first terminal, and run the tester from the repository root so the before and after JSON files sit next to each other.
+Run the same endpoint suite used in the baseline from a second terminal. Keep the app running with the tuning profile in the first terminal, and run the tester from the repository root so the before and after JSON files sit next to each other:
 
 ```bash
 cd ~/nopCommerce  # replace with your clone path if different
@@ -80,7 +80,7 @@ jq '.summary' arm_after.json
 
 Use these rules before adopting a tuning profile:
 
-- Run at least 5 baseline and 5 tuned trials.
+- Run at least five baseline and five tuned trials.
 - Keep endpoint sequence fixed across all runs.
 - Reset warm-up policy consistently (always warm or always cold).
 - Require improvement in both throughput and p95 latency, not just one.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/7-arm-mcp-server.md

@@ -9,7 +9,7 @@ layout: learningpathall
 
 ## Optimize with the Arm MCP Server
 
-Use the Arm MCP Server after the manual baseline is complete. The agent should accelerate analysis and execution, but your benchmark artifacts remain the source of truth for what actually improved.
+Use the Arm MCP Server after the manual baseline is complete. The agent accelerates analysis and execution, but your benchmark artifacts remain the source of truth for what actually improved.
 
 If you're new to this toolchain, see the [Arm MCP Server Learning Path](https://learn.arm.com/learning-paths/servers-and-cloud-computing/arm-mcp-server/) for setup and core usage patterns.
 
@@ -25,7 +25,7 @@ Identify endpoints most likely to benefit from Arm tuning.
 Rank them by expected impact and explain why.
 ```
 
-The output includes the following:
+The output should include the following:
 
 - Ranked endpoint list
 - Bottleneck hypotheses per endpoint

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/_index.md

@@ -39,8 +39,8 @@ generated_summary_faq:
     Arm-based virtual machine powered by Azure Cobalt 100, create a reproducible baseline, and apply
     measured runtime tuning. First, you'll pin a specific nopCommerce release, verify a clean build,
     and capture an endpoint baseline on Arm to control for drift. By running dependency discovery and generating SBOM, you'll surface direct, transitive, and native payloads early to reduce surprises during
-    deployment. You'll compare and choose a containerization path between a Dockerfile workflow and a .NET
-    SDK publish with guardrails for multi-architecture delivery. Finally, you'll apply
+    deployment. You'll compare and choose a containerization path between a Dockerfile workflow, and a .NET
+    SDK publish with multi-architecture delivery guardrails. Finally, you'll apply
     architecture-conditional runtime settings and validate them against fixed workloads so you
     can keep or discard changes based on repeatable results.
   faqs: