docs: suppress reviewed write-good.Passive false positives

133 hits across 38 files, all previously classified during #4548's sweep
and deliberately left un-rewritten (predicate-adjective state/necessity
description, design-intent idiom, structural/type-description idiom,
no-single-actor topology claim, parallel-triple exception, vale
substring-match artifact — see hyperhive#4548's per-PR bodies for the
per-hit reasoning).

Wraps each one in a scoped <!-- vale write-good.Passive = NO/YES -->
pair (the supported mechanism — TokenIgnores has a known offset-drift
bug) rather than a blanket per-file or per-rule silence, so a *new*
passive-voice hit anywhere in these files still fails once the rule
gates CI (next commit). Table/list false positives (docs/swarm/credentials.md's
renewal-table cells) wrap the whole block, not each cell.

Part of #4546.

docs/tools/forge.md

@@ -142,10 +142,12 @@ field; `pr status` when the only question is "can I merge it."
 
 ### Contributing to a read-only repo (`clone` + `pr create --agit`)
 
+<!-- vale write-good.Passive = NO -->
 Agents are read-only collaborators on some repos (e.g.
 `internal/knowledge`) and so can't push branches. Forgejo's AGit flow
 lets a read-only user open a PR by pushing the current `HEAD` to the
 magic ref `refs/for/<base>/<topic>`. Two verbs cover the workflow:
+<!-- vale write-good.Passive = YES -->
 
 ```
 hive-forge -r internal/knowledge clone          # clone, auth handled for you
@@ -158,6 +160,7 @@ hive-forge -r internal/knowledge pr create --agit \
   [--body "details"]       # PR description (also accepts --body-file)
 ```
 
+<!-- vale write-good.Passive = NO -->
 `clone` derives the dest dir from the repo basename (override with a
 positional arg); it passes `--branch` / `--depth` through. The clone
 URL and the `origin` remote it leaves behind carry no credentials —
@@ -166,6 +169,7 @@ URL and the `origin` remote it leaves behind carry no credentials —
 hand), which git calls fresh on every fetch/push. That's what lets
 `pr create --agit` (default remote `origin`) push without re-auth,
 without a durable token sitting in the checkout's `.git/config`.
+<!-- vale write-good.Passive = YES -->
 
 `pr create --agit` prints the PR URL. Re-running with the same
 `--topic` force-updates the existing open PR (the AGit ref is
@@ -244,6 +248,7 @@ to discover valid label names before triaging or to audit the label set.
 
 ## Notes
 
+<!-- vale write-good.Passive = NO -->
 - **Read-before-comment guard:** `comment` refuses to post when forge still
   has an unread notification for the thread (that is, someone commented since
   you last read it). This prevents accidentally replying to old activity without
@@ -341,3 +346,4 @@ to discover valid label names before triaging or to audit the label set.
   response's `X-Total-Count` (`… 50 of 187 shown … 137 more`), so trust
   the trailer, not the row count, when deciding whether you've seen
   everything.
+<!-- vale write-good.Passive = YES -->

docs/tools/hivectl.md

@@ -92,6 +92,8 @@ hivectl matrix invite @mara:server --room '#hive-chat:server'  # ...or to a spec
 
 ## GitHub
 
+<!-- vale write-good.Passive = NO -->
+
 Write an operator-supplied GitHub personal access token (PAT) into an
 agent's token file so its `gh` wrapper + git credential helper can act as
 the bot account. Unlike forge/matrix there is no account creation — the PAT
@@ -99,6 +101,8 @@ is for an existing GitHub account. A CLI alternative to the dashboard
 credentials tab; the [GitHub integration](../integrations/github.md) is on by default
 (`services.hyperhive.agent.github.enable`), so no per-agent config is needed.
 
+<!-- vale write-good.Passive = YES -->
+
 ```bash
 hivectl github set-token damocles --token-stdin   # paste the PAT on stdin (preferred)
 hivectl github set-token damocles --token <pat>    # inline (visible in shell history)
@@ -242,8 +246,8 @@ session id — the flag name deliberately matches the claude flag it maps
 to. (choom never uses claude's `--continue`: that's a bare flag that
 takes no argument and resumes the cwd's _latest_ session, that is, the
 harness's; claude would consume a value after it as the first prompt,
-silently poking the live harness session.) A value is required when you
-pass the flag. Either way choom never collides with the harness's live
+silently poking the live harness session.) Passing the flag requires a
+value. Either way choom never collides with the harness's live
 session in the same project dir: the harness pins its own id via
 `--resume`, so a blank choom session is invisible to it. The container
 must be running.

docs/tools/matrix.md

@@ -53,6 +53,7 @@ room you haven't read yet.
 
 ### Room membership
 
+<!-- vale write-good.Passive = NO -->
 - `invite_user(room, user_id)` — invite `@user:server` into a room
   you're already in; you must have a high enough power level.
   The invitee sees a pending invite and resolves it via
@@ -66,6 +67,7 @@ room you haven't read yet.
   invites (it can reject too).
 - `list_invites()` — rooms this agent has been invited to but not
   yet joined (`{ id, canonical_alias, name }` per room).
+<!-- vale write-good.Passive = YES -->
 
 ### Receipts
 
@@ -73,6 +75,7 @@ room you haven't read yet.
 
 ## Multiple accounts
 
+<!-- vale write-good.Passive = NO -->
 `services.hyperhive.agent.matrixAccounts` (declared in `agent.nix`) is
 the agent's full set of matrix identities — for example an
 external-facing account alongside the internal one — **and, being
@@ -89,6 +92,7 @@ here are the *further* accounts. hive-c0re pins its `tokenFile` to
 `<state>/matrix-token` and provisions it there, and the
 dashboard's link-account route refuses to create an account by that
 name.
+<!-- vale write-good.Passive = YES -->
 
 `main` is present exactly when that URL is non-null, which is the whole
 mechanism behind "accounts are the enable signal": an agent with no

docs/tools/scheduling.md

@@ -17,11 +17,15 @@ cancel.
 
 ### `request_schedule_prompt(targets, body, first_fire_at_unix, interval_seconds?, description?)`
 
+<!-- vale write-good.Passive = NO -->
+
 Queue an operator-approval for a scheduled prompt. On approve,
 hive-c0re fans `body` out to each agent in `targets` at
 `first_fire_at_unix` (Unix timestamp). Recurring when `interval_seconds`
 is set, one-shot otherwise.
 
+<!-- vale write-good.Passive = YES -->
+
 Catch-up clamp: if hive-c0re is down across multiple intervals, only
 ONE delayed fire happens on resume (per recurring schedule). The
 skipped-cycle count surfaces in the per-target `last_result` for
@@ -41,10 +45,14 @@ rows (terminal state).
 
 ### `cancel_schedule(id, targets?)`
 
+<!-- vale write-good.Passive = NO -->
+
 Cancel a schedule. Omit `targets` / pass empty to cancel the whole
 schedule; pass a list to cancel just those recipients (the schedule
 autocancels once every target is gone).
 
+<!-- vale write-good.Passive = YES -->
+
 ### `fire_schedule_now(id)`
 
 Fire a scheduled prompt out of band immediately. Recurring schedules

docs/tools/subagent.md

@@ -144,12 +144,16 @@ no progress left to describe.
 
 ## A `continue` that finds no session
 
+<!-- vale write-good.Passive = NO -->
+
 `continue` doesn't check for the session before spawning. claude's own
 `--resume` is the authority, and it exits non-zero rather than quietly
 starting a fresh session, so the check could only duplicate the lookup
 the driver was about to do — while answering as though the session were
 gone. The usual truth is that the session exists somewhere else.
 
+<!-- vale write-good.Passive = YES -->
+
 `continue` waits for that answer instead. Where `start` returns the
 instant the process exists — it creates its session, so the spawn
 succeeding is the whole story — a resumed turn can fail a moment _after_
@@ -198,6 +202,8 @@ to report it, which is what `OOMPolicy=continue` on the unit is for.
 
 ## Compaction trade-off
 
+<!-- vale write-good.Passive = NO -->
+
 Built on `hive_claude::Claude::spawn` + `RunningClaude::wait` directly
 rather than `InfiniteSession::run`, since only the low-level driver
 exposes a cancel handle to stop a turn mid-flight — that's what makes
@@ -208,6 +214,8 @@ Subagents are meant to be bounded, single-batch work, not sessions
 long-lived enough to need in-place compaction — a real follow-up if that
 assumption stops holding.
 
+<!-- vale write-good.Passive = YES -->
+
 ## Configuration
 
 `services.hyperhive.agent.mcp.subagentHttpPort` — the daemon's streamable-http listen

docs/tools/swarm-logs-cli.md

@@ -51,7 +51,9 @@ Run a LogsQL query and print the matched log lines
 
 <hr/>
 
+<!-- vale write-good.Passive = NO -->
 <small><i>
     This document was generated automatically by
     <a href="https://crates.io/crates/clap-markdown"><code>clap-markdown</code></a>.
 </i></small>
+<!-- vale write-good.Passive = YES -->