docs: remove hyphens from auto-X compounds per Microsoft.Auto style
Fixed 72 hyphenated 'auto-X' compounds across the docs by deleting the hyphen to match Microsoft style guide (autogenerated, autoregistration, autodiscovery, etc). Preserved original capitalization throughout. Covered 26 documentation files in docs/, including README.md, agent-lifecycle, integrations, scheduler, networking, process, tools, trust-boundary, turn-loop, and web-ui sections.
This commit is contained in:
parent
4f2d1d281a
commit
05cf8e8276
26 changed files with 70 additions and 70 deletions
|
|
@ -26,7 +26,7 @@ looks like a natural extension point and does nothing. Use
|
|||
|
||||
Not `boot.isContainer = true`. Renamed in nixos-25.11+.
|
||||
|
||||
### `nixos-container create` auto-assigns `HOST_ADDRESS` / `LOCAL_ADDRESS`
|
||||
### `nixos-container create` autoassigns `HOST_ADDRESS` / `LOCAL_ADDRESS`
|
||||
|
||||
…in the `.conf`. The start script's `if HOST_ADDRESS set →
|
||||
--network-veth` branch then forces a private netns — silently fatal
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# The PR review gate
|
||||
|
||||
What a review verdict means, why a reviewer shouldn't wait on CI to
|
||||
submit one, and what "armed to auto-merge" actually signals about the
|
||||
submit one, and what "armed to automerge" actually signals about the
|
||||
human review that already happened.
|
||||
|
||||
## The gate has (up to) three parts, and they're per-repo settings
|
||||
|
|
@ -17,7 +17,7 @@ hive or every repo. The pieces a repo _can_ require:
|
|||
(Forgejo's "dismiss stale approvals" branch-protection option), not
|
||||
universal behavior.
|
||||
- **Someone with write access has armed the PR to merge** — a manual
|
||||
merge once the required conditions hold, or Forgejo's auto-merge
|
||||
merge once the required conditions hold, or Forgejo's automerge
|
||||
(merges automatically the moment the other required conditions are
|
||||
met).
|
||||
|
||||
|
|
@ -36,9 +36,9 @@ still running"), but don't gate the formal verdict on it: CI isn't a
|
|||
signal a reviewer waits on, it's a separate condition that resolves
|
||||
independently.
|
||||
|
||||
## What arming auto-merge actually means
|
||||
## What arming automerge actually means
|
||||
|
||||
Auto-merge isn't "no human ever looked at this." Whoever arms it has
|
||||
Automerge isn't "no human ever looked at this." Whoever arms it has
|
||||
already judged the PR sound at a coarse level — the signal it sends is
|
||||
roughly _"apart from maybe minor tweaks a reviewer can still catch,
|
||||
I think this is fine."_ That's the human-in-the-loop step, and it
|
||||
|
|
@ -46,7 +46,7 @@ already happened. No large changes are expected to surface after
|
|||
that point — a reviewer's job past that point is to flag it if one
|
||||
does, not to assume none ever will.
|
||||
|
||||
The practical consequence for a reviewer: on a repo where auto-merge
|
||||
The practical consequence for a reviewer: on a repo where automerge
|
||||
may already be armed before your review lands, a plain `APPROVED` can
|
||||
be the last step before the merge actually happens, with no further
|
||||
review pass after yours. That's a reason to actually finish checking
|
||||
|
|
|
|||
Loading…
Reference in a new issue