docs: name the specific daemon instead of the vague 'backend'
Per mara's ruling on hyperhive#4041 (Microsoft.Avoid): 'backend' never says
which system it means. Fixed all 21 fixable hits to name the actual daemon
(mostly hive-c0re; one hive-agent instance and one hive-matrix-daemon one,
both confirmed against surrounding context, not guessed). Also tightened
Weston's own 'VNC backend'/'RDP backend' plugin references to their literal
upstream names (vnc-backend/rdp-backend) rather than dropping the accurate
term entirely, and reworded one unrelated Microsoft.Avoid hit ('and so on').
Left alone (flagged on the issue, not guessed): docs/turn-loop/config.md's
3 remaining hits match the actual nix option name (backendEnvironmentFile)
and describe a genuinely pluggable concept (which LLM API provider), not
one specific internal system.
This commit is contained in:
parent
08074807cc
commit
29927b7dfe
7 changed files with 24 additions and 24 deletions
|
|
@ -280,8 +280,8 @@ straight to `new Date(s)` for display.
|
|||
Every HTTP API in this repo answers failures with **RFC 9457
|
||||
`application/problem+json`** (`{ type, title, status, detail }`), with the
|
||||
human-readable cause in `detail`. An endpoint of ours returning a bare string
|
||||
or a bespoke error shape is a **bug to file against the backend**, not
|
||||
something for the caller to work around.
|
||||
or a bespoke error shape is a **bug to file against the daemon that
|
||||
returned it**, not something for the caller to work around.
|
||||
|
||||
Use the `problem_details` crate (`features = ["axum"]`), which the daemons
|
||||
already depend on: type a handler `Result<_, ProblemDetails>` and hand
|
||||
|
|
|
|||
|
|
@ -369,7 +369,7 @@ Never use raw `curl` for forge access.
|
|||
### Weston VNC compositor (per-agent `hyperhive.gui.enable`)
|
||||
|
||||
`nix/agent-modules/weston-vnc.nix` adds an optional Weston Wayland
|
||||
compositor with the VNC backend, surfaced as
|
||||
compositor with the `vnc-backend` plugin, surfaced as
|
||||
`hyperhive.gui.enable = true` per-agent. The harness's
|
||||
`/screen/ws` WebSocket relay (`docs/web-ui/agent.md::Per-agent endpoints`)
|
||||
connects to the compositor at `127.0.0.1:<vnc_port>`.
|
||||
|
|
@ -413,8 +413,8 @@ connects to the compositor at `127.0.0.1:<vnc_port>`.
|
|||
back to a headless display or errors out, the app "works" on a
|
||||
second invisible display, and the VNC session shows a blank weston
|
||||
desktop (#540 double-screen).
|
||||
- **VNC bind address**: weston's VNC backend has no CLI
|
||||
bind-address flag (unlike the RDP backend's `--address`), so the
|
||||
- **VNC bind address**: Weston's `vnc-backend` has no CLI
|
||||
bind-address flag (unlike the `rdp-backend`'s `--address`), so the
|
||||
listener binds `0.0.0.0`. The harness relay only connects via
|
||||
`127.0.0.1`; the host firewall blocks the per-agent VNC port range
|
||||
from external access. A future weston.ini `[vnc] address=` will
|
||||
|
|
|
|||
Loading…
Reference in a new issue