docs: fix Microsoft.Foreign hits (e.g./i.e. -> for example/that is)
Substitutes 'for example' for 'e.g.' and 'that is' for 'i.e.' per Microsoft style, with no comma after the replacement -- this repo never puts a comma after e.g./i.e. either, so the substituted phrase matches that house style instead of vale's literal 'for example,' suggestion. Covers all 77 real hits (72 from the initial vale pass + 5 more of the same pattern found on a follow-up vale run). None of the flagged instances were sentence-initial, so there's no capitalization concern here. Verified via a fresh vale run: 0 remaining Microsoft.Foreign hits. Full accounting in /agents/iris/state/haiku-batches/foreign-report.md.
This commit is contained in:
parent
ff377b0dee
commit
4f2d1d281a
30 changed files with 80 additions and 80 deletions
|
|
@ -382,7 +382,7 @@ The gateway always terminates TLS, so the `behindGateway = true` case is
|
|||
always advertised over `https://`; only the direct (`behindGateway =
|
||||
false`) shape stays `http://`. Set `rootUrl` explicitly when
|
||||
`forge.domain` resolves differently from the public URL, or for a
|
||||
genuinely bespoke shape (e.g. an external reverse proxy on a different
|
||||
genuinely bespoke shape (for example an external reverse proxy on a different
|
||||
host/path). Must end with `/` (Forgejo requirement; an assertion
|
||||
enforces this).
|
||||
|
||||
|
|
@ -450,7 +450,7 @@ store path baked in at hive-c0re build time, and c0re (writing
|
|||
so they see the same store.
|
||||
|
||||
**Graceful degradation**: if `HIVE_AGENT_FRONTEND_DIR` is empty or
|
||||
unset (e.g. a build that predates `cfg.frontend`), each agent gets the
|
||||
unset (for example a build that predates `cfg.frontend`), each agent gets the
|
||||
legacy single-proxy block and all traffic is forwarded to the agent
|
||||
daemon as before.
|
||||
|
||||
|
|
@ -575,7 +575,7 @@ vhost (`_`, `forge.<swarm-domain>`, `chat.<swarm-domain>`):
|
|||
|
||||
nginx's `add_header` inheritance rule: a `location` block that sets its
|
||||
own `add_header` does **not** inherit server-scope headers. API locations
|
||||
that carry their own CORS headers (e.g. `/.well-known/matrix/client`,
|
||||
that carry their own CORS headers (for example `/.well-known/matrix/client`,
|
||||
`/_matrix/`) are therefore unaffected. HTML-serving and proxy locations
|
||||
with no `add_header` of their own pick the security headers up
|
||||
automatically.
|
||||
|
|
|
|||
Loading…
Reference in a new issue