vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

docs: fix Microsoft.UIVerbs findings (click -> select)

Browse source 
Part of #4041's forgotten remainder (UIVerbs was scoped as pure
execution work, no decision needed -- see comment 71586).

29 genuine input-device-neutral rewrites ("click"/"clicking"/"clicked"
-> "select"/"selecting"/"selected", a few reworded where a direct verb
swap didn't read naturally: "one click from the hub" -> "one step from
the hub", "click straight from X into Y" -> "go straight from X into
Y", "the operator never clicked" -> "the operator never triggered").

Left 5 hits unfixed, each read in context and genuinely not a
device-assumption problem:
- docs/process/gotchas.md:439 -- "click-to-unlock screen" names a
  specific OS lock-screen pattern, not an instruction to the reader.
- docs/web-ui/agent.md:377 -- "clicks" describes literal RFB pointer
  events forwarded by hive-screen-mcp's sendPointer, genuinely
  mouse-specific.
- docs/web-ui/agent.md:78 -- "ctrl/middle-click" names a specific
  keyboard-modifier + mouse-button combination with no "select"
  equivalent.
- docs/web-ui/dashboard.md:741 -- explicitly contrasts "click (or
  Enter/Space)" as two named input methods; replacing "click" with
  "select" would conflate the two the sentence is distinguishing.
- docs/web-ui/shape.md:253 -- "swipes in from the right" describes the
  panel's own slide animation, not a user touch gesture.

Verified: fresh `vale --filter '.Name == "Microsoft.UIVerbs"' docs`
after the fix shows exactly those 5, `nix fmt` reports 0 changes.
This commit is contained in:
iris 2026-09-07 18:37:41 +02:00 • committed by mara
commit a8fb08a7e8
8 changed files with 29 additions and 29 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/agent-lifecycle/approvals.md
View file

@ -2,7 +2,7 @@
The approval queue is hyperhive's pivot: nothing that changes the
shape of an agent (its config, whether it exists) happens without an
operator click. The submitting agent — any agent with the `approvals`
operator selection. The submitting agent — any agent with the `approvals`
tool group, which manages the config of its **direct children** (the
root agent for top-level agents; a sub-manager for its own subtree) — is
the policy gate in front of that queue; helper events are how it stays
@ -81,7 +81,7 @@ request.
actually deploy.
3. The operator reviews the PR **on the forge** (native diff, threaded
comments, CI status) and sees a matching card on the dashboard with a
"review PR on forge" deep link. They click ◆ APPR0VE (or
"review PR on forge" deep link. They select ◆ APPR0VE (or
`hivectl approvals approve <id>` on the CLI) once satisfied.
4. On approve, a deploy DAG runs three phases under a resource-holding
`DeployWindow` root (see *Queue templates* below):
@ -443,7 +443,7 @@ the config PR, and for a spawn runs the post-spawn forge bookkeeping.
Two visible consequences:
- **Operator dashboard**: after clicking APPR0VE the work-in-progress
- **Operator dashboard**: after selecting APPR0VE the work-in-progress
shows up on the *rebuild queue* card (`GET /api/jobq/graph`, refetched
on every `rebuild_queue_changed` tick), not on the approvals panel
(which already moved the row to "approved"). A long meta-update