docs: rephrase the vale warnings that have a better wording

Words the alex and Microsoft styles flag where a plainer one reads as well:
disabled/special/invalid as a state, primitive, trap, hang, several, click,
first-person FAQ questions, hyphenated adverb pairs. Left as they are: Let's
Encrypt, quoted UI labels and phrases, the generated forge CLI reference, and
the middle-click gesture.

docs/scheduler/ci.md

@@ -40,7 +40,7 @@ internals, container design, and the full security writeup.
 
 <!-- vale write-good.Passive = NO -->
 
-Several jobs run on every PR (and on `workflow_dispatch` for manual
+The jobs run on every PR (and on `workflow_dispatch` for manual
 re-triggers), defined in
 [`.forgejo/workflows/ci.yml`](../../.forgejo/workflows/ci.yml). The first four
 below are required checks (forge branch protection) — a hit on any of them
@@ -270,7 +270,7 @@ A malicious `default.nix` or build script in a PR can therefore:
 
 No forge admin token enters the container: swarm-controller holds it and publishes only the registration token, which only `swarm-ci-runner-register.service` loads, so a job step can't read it. A build process can still reach the forge over the network, and it runs as the runner's own user, so it can read `.runner` and act as this runner; it can't issue admin API calls.
 
-Note: `nix flake check --no-build` (eval-only) reduces the attack surface but doesn't eliminate it — `builtins.fetchGit`, `builtins.fetchurl`, and import-from-derivation can reach the network and filesystem during evaluation. The CI workflow's `nix flake check` job builds every check derivation, which is the higher-risk path.
+Note: `nix flake check --no-build` (eval-only) reduces the exposure but doesn't eliminate it — `builtins.fetchGit`, `builtins.fetchurl`, and import-from-derivation can reach the network and filesystem during evaluation. The CI workflow's `nix flake check` job builds every check derivation, which is the higher-risk path.
 
 ### Mitigation
 

docs/scheduler/coordinator.md

@@ -16,11 +16,11 @@ resource/lease semantics).
 
 hive-c0re submits every container operation (rebuild, first-spawn, power
 changes) to the global job-DAG queue (`hive-c0re/src/job_queue/`)
-as a **DAG of primitive nodes**. One scheduler task drives all DAGs;
+as a **DAG of basic nodes**. One scheduler task drives all DAGs;
 concurrency comes from the resource classes below, not from multiple workers.
-Special cases like graceful stop, deferred starts, and the boot sweep
+Exceptions like graceful stop, deferred starts, and the boot sweep
 need no bespoke code paths — each takes the shape of a DAG built
-from the same primitive nodes.
+from the same basic nodes.
 
 ### Two levels: DAG and node
 

docs/scheduler/observability.md

@@ -273,13 +273,13 @@ X" string to set, so mapping every level takes one rule each. A level button
 then filters on `level` **or** the matching `severity_text`, and the store
 answers the second half. Each enabled rule appends an `OR
 <field>:<op>"<value>"` term to the query a level button emits, beside the
-`level:…` term that matches nothing here. Clicking "info" goes from
+`level:…` term that matches nothing here. Selecting "info" goes from
 
 ```
 level:contains_common_case("info","information","informational","notice")
 ```
 
-to that OR `severity_text:="INFO"`, which our rows do match.
+to that OR `severity_text:="INFO"`, which the rows here do match.
 
 `Unspecified` is deliberately left out of those rules. It's VictoriaLogs' own
 rendering of an absent severity, and it's what the **Log rows with no
@@ -684,6 +684,6 @@ unaffected either way; gauges have no temporality. The hive-tier collector
 runs a `deltatocumulative` processor ahead of export, so a delta
 `hive-metric` counter still lands in VictoriaMetrics as a cumulative
 series — the standard `rate()`/`increase()` idioms work on it exactly like
-any other counter in this system, no special query needed.
+any other counter in this system, no extra query needed.
 
 <!-- vale write-good.Passive = YES -->