formatting

Author: idalithb

website/src/pages/en/subgraphs/guides/subgraph-linter.mdx

@@ -9,15 +9,14 @@ It complements existing tools by helping you catch problems locally while writin
 
 ## When to use it
 
-Run Subgraph Linter when you want to detect handler and mapping issues that don't often appear until indexing starts, such as: 
+Run Subgraph Linter when you want to detect handler and mapping issues that don't often appear until indexing starts, such as:
 
 - Entities saved with missing required fields
 - Entity overwrite issues from concurrent/stale instances
 - Optional values force-unwrapped without checks
 - Divisions without guaranteeing a non-zero denominator
 - `@derivedFrom` fields mutated directly or left stale
-- Contract calls are used without being declared in the manifest
-These bugs usually compile fine, but crash at runtime or silently produce incorrect data. Subgraph Linter performs static analysis on your mapping code to detect these issues before deploying the subgraph.
+- Contract calls are used without being declared in the manifest These bugs usually compile fine, but crash at runtime or silently produce incorrect data. Subgraph Linter performs static analysis on your mapping code to detect these issues before deploying the subgraph.
 
 ## How it works
 
@@ -38,7 +37,7 @@ Subgraph Linter currently detects the following categories of issues:
 - `entity-overwrite`: Detects cases where a handler works with an entity instance that becomes stale after calling a helper (or other code path) that loads and saves the same entity, and then the handler saves its stale instance and overwrites those updates.
 - `unexpected-null`: Detects when entities may be saved in an invalid state—either because required fields weren’t initialized before `save()`, or because code attempts to assign to `@derivedFrom` fields.
 - `unchecked-load`: Detects risky patterns where `Entity.load(...)` is treated as always present (for example via `!`) instead of explicitly handling the case where the entity doesn’t exist yet.
-- `unchecked-nonnull`: Detects risky non-null assertions on values that can be missing at runtime, and encourages explicit guards instead of assuming the value is always set.
+- `uncheckednonnull-`: Detects risky non-null assertions on values that can be missing at runtime, and encourages explicit guards instead of assuming the value is always set.
 - `division-guard`: Detects divisions where the denominator may be zero on some execution paths, and suggests guarding the value before dividing.
 - `derived-field-guard`: Detects cases where code updates “base” fields that require derived recomputation, but then saves without the helper(s) that keep derived values consistent.
 - `helper-return-contract`: Detects helper functions that can return entities without fully initializing required fields, and flags call sites where the returned entity is used/saved without completing initialization.
@@ -79,7 +78,7 @@ You can also provide an explicit config file:
 npm run check -- --manifest ../your-subgraph/subgraph.yaml --config ./subgraph-linter.config.json
 ```
 
-*Configuration note:* Subgraph Linter supports configurable severities per check. By default, checks have sensible severities, but you can override them to match your project’s tolerance. Only checks with effective severity `error` cause a non-zero exit code; warnings-only runs exit successfully.
+_Configuration note:_ Subgraph Linter supports configurable severities per check. By default, checks have sensible severities, but you can override them to match your project’s tolerance. Only checks with effective severity `error` cause a non-zero exit code; warnings-only runs exit successfully.
 
 #### Configuration (severity overrides and suppression)