contraction nits

Author: anupras-mohapatra-arm

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

@@ -39,7 +39,7 @@ export PATH="$PATH:$HOME/.dotnet/tools"
 dotnet-CycloneDX src/Presentation/Nop.Web/Nop.Web.csproj -o sbom/ -rs -F Json
 ```
 
-The `-rs` option includes project references, and `-F Json` writes JSON output that is easier to diff in CI. If tool installation is blocked, treat `dotnet list --include-transitive` plus `*.deps.json` evidence as a temporary fallback, not the final state.
+The `-rs` option includes project references, and `-F Json` writes JSON output that's easier to diff in CI. If tool installation is blocked, treat `dotnet list --include-transitive` plus `*.deps.json` evidence as a temporary fallback, not the final state.
 
 ### Inspect package internals for native payloads
 
@@ -56,7 +56,7 @@ cd /tmp/nupkg-audit
 unzip -l "$(basename "$NUPKG")" | rg "runtimes/|native/"
 ```
 
-If the command prints `runtimes/linux-arm64`, the package already carries an Arm Linux asset. If it prints only `linux-x64`, `win-x64`, or another non-Arm runtime, trace whether that asset is used by nopCommerce before you treat the dependency as portable. If there is no output, the package does not advertise runtime or native payload directories in the `.nupkg`.
+If the command prints `runtimes/linux-arm64`, the package already carries an Arm Linux asset. If it prints only `linux-x64`, `win-x64`, or another non-Arm runtime, trace whether that asset is used by nopCommerce before you treat the dependency as portable. If there's no output, the package doesn't advertise runtime or native payload directories in the `.nupkg`.
 
 ### Dependency cascade rule
 

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

@@ -37,7 +37,7 @@ docker buildx imagetools inspect "$IMAGE"
 
 ### Single architecture .NET SDK publish path
 
-Use SDK publish when you want tighter integration with .NET build settings and fewer custom Docker steps. For nopCommerce, treat this as a validation path until you have confirmed that the generated image includes the Linux native packages your store needs. SDK publish creates the container image, but it doesn't run `apk add` or `apt-get install` steps the way a Dockerfile does.
+Use SDK publish when you want tighter integration with .NET build settings and fewer custom Docker steps. For nopCommerce, treat this as a validation path until you've confirmed that the generated image includes the Linux native packages your store needs. SDK publish creates the container image, but it doesn't run `apk add` or `apt-get install` steps the way a Dockerfile does.
 
 This command publishes an arm64 image into the local Docker daemon with an explicit repository, tag, and container runtime identifier:
 
@@ -60,7 +60,7 @@ The expected output is `arm64`.
 
 ### Multi-arch .NET SDK publish path
 
-Define runtime identifiers and multi-arch container runtime identifiers in the project file, then publish once. Add this metadata only after you have decided where nopCommerce's Linux runtime dependencies will live. If you use SDK publish for production, move those dependencies into a custom base image or another repeatable image-build step before replacing the Dockerfile workflow.
+Define runtime identifiers and multi-arch container runtime identifiers in the project file, then publish once. Add this metadata only after you've decided where nopCommerce's Linux runtime dependencies will live. If you use SDK publish for production, move those dependencies into a custom base image or another repeatable image-build step before replacing the Dockerfile workflow.
 
 ```xml
 <PropertyGroup>

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

@@ -13,7 +13,7 @@ Treat tuning as an experiment pipeline, not a one-shot tweak. On Arm, apply chan
 
 ### Configure a tuned run
 
-Start with a conservative runtime profile that is commonly effective for server workloads. Keep these settings outside the application code at first so you can switch profiles without rebuilding.
+Start with a conservative runtime profile that's commonly effective for server workloads. Keep these settings outside the application code at first so you can switch profiles without rebuilding.
 
 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. 
 
@@ -50,9 +50,9 @@ Treat this as an experiment, not a default. Turning off spin waiting can reduce
 
 ### Optimize tiered PGO and ReadyToRun 
 
-`DOTNET_TieredPGO=1` and `DOTNET_ReadyToRun=1` are not the same optimization:
+`DOTNET_TieredPGO=1` and `DOTNET_ReadyToRun=1` aren't the same optimization:
 
-- `ReadyToRun` favors startup and early request latency by using precompiled code when it is available.
+- `ReadyToRun` favors startup and early request latency by using precompiled code when it's available.
 - `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.
 

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

@@ -11,7 +11,7 @@ layout: learningpathall
 
 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.
 
-If you are 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.
+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.
 
 ### Identify endpoints likely to benefit most