docs: fix alex whitelist + condescending-word findings
Fixes the 'genuine' bucket from #4040's triage: whitelist/allowlist (6 hits across 5 files, including a heading rename in turn-loop/mcp.md -- checked no anchor links reference it first) and the simply/obvious/easy condescending-word cluster (10 of 13 hits, real sentence-level rewrites rather than mechanical deletion so nothing reads awkwardly). Left 3 alex.Condescending hits untouched on purpose: integrations/matrix.md:271 and process/conventions.md:442 both say "non-obvious", swarm/ca.md:162 says "not obvious" -- alex matched the substring "obvious" inside a negated phrase, the literal opposite of condescending. Flagging these on the issue rather than silently leaving them out.
This commit is contained in:
parent
115de60b09
commit
cd252ca6b2
10 changed files with 19 additions and 19 deletions
|
|
@ -68,7 +68,7 @@ request.
|
|||
config, not the tree to edit: authoring in place there produces no PR
|
||||
and no approval. (It is currently mounted read-write, which is a
|
||||
defect tracked separately, not an authoring path.)
|
||||
Branch protection (push/merge whitelist = `core`, approvals whitelist
|
||||
Branch protection (push/merge allowlist = `core`, approvals allowlist
|
||||
= operator team; see "Forge mirror" and #1787) makes the agent a
|
||||
write collaborator that **cannot merge its own config PR**.
|
||||
2. hive-c0re's `/webhook/config-pr` endpoint receives the Forgejo
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ the basename of the first real command, looking past `cd repo &&`
|
|||
prefixes, env-assignments, and prefix-runners like `sudo`/`env`. It
|
||||
backs the "favorite tools" view on the /stats page (aggregated
|
||||
host-side). Best-effort and created on first write
|
||||
(`CREATE TABLE IF NOT EXISTS`), so it's simply absent until a bash
|
||||
(`CREATE TABLE IF NOT EXISTS`), so it's absent until a bash
|
||||
task runs.
|
||||
|
||||
turn-stats.sqlite has **no vacuum** — it's one tiny row per turn
|
||||
|
|
@ -357,7 +357,7 @@ boundary a convention rather than a permission.
|
|||
approval resolves: that writes the child's initial config repo as
|
||||
**hive-c0re, against the host path**, and `read_only` on a bind
|
||||
constrains writers *inside* a container only. The two are unrelated —
|
||||
conflating them is an easy way to reason your way into thinking this
|
||||
conflating them can lead you to reason your way into thinking this
|
||||
mount should be writable when it shouldn't.
|
||||
|
||||
Per-child isolation still holds: a container only ever has its *own*
|
||||
|
|
|
|||
Loading…
Reference in a new issue