feat(org): declare the org security posture as code

.agent/repo=.this/role=any/briefs/domain.terms/authentication.md

@@ -0,0 +1,117 @@
+# domain.term — `Authentication`
+
+## .the term
+
+`Authentication` — a **category segment** in a declared github org resource name.
+
+shape: `DeclaredGithubOrg` + **category** + subject
+
+```
+DeclaredGithubOrgAuthenticationTwoFactorRequirement
+                  └ category   └ subject
+```
+
+it is a segment, not a standalone domain-object. it names the FAMILY a resource belongs
+to, so that a reader who knows the github configuration surface can find the resource, and
+a resource added later lands in a family that already exists.
+
+## .etymology — where the word comes from
+
+github's own word, verified in github's own docs.
+
+> **Settings → Security → Authentication security**
+>
+> "In the 'Security' section of the sidebar, click **Authentication security**."
+>
+> — docs.github.com, "Requiring two-factor authentication in your organization"
+>   `/en/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization`
+
+so the segment is **discovered, not authored** — it is the label github prints on the page
+that holds the control. an operator who reads
+`DeclaredGithubOrgAuthenticationTwoFactorRequirement` and searches for it finds the control
+under a title that uses the same word.
+
+this satisfies `def.domain-discovery`: the ground truth is the real-world domain — here,
+the surface github's own users navigate — not a shape convenient to our code.
+
+## .provenance — attested, then verified
+
+| date | source | what it established |
+|---|---|---|
+| 2026-08-03 | the wisher, verbatim: *"yeah, Authentication exactly"* | the WORD — human attestation, no docs citation |
+| 2026-08-04 | github docs, fetched live (cited above) | the word CONFIRMED, plus the family's real membership |
+
+the vision recorded the attestation honestly as *"not a docs citation"* and flagged the
+family shape as **UNVERIFIED**, blocked at the time on an unreachable docs fetch. that
+block has since cleared and the verification is done — which is why this file exists rather
+than a note that owes one.
+
+## .the family — what actually lives under that title
+
+github's "Authentication security" page holds:
+
+- require two-factor authentication for everyone in the organization
+- only allow secure two-factor methods
+
+### ⚠️ a guess this verification CORRECTED
+
+the vision's best guess at the family was *"SAML SSO, SSH certificate authorities, and the
+IP allow list, from recall alone"*, explicitly marked unverified.
+
+**that guess was wrong.** those three are separate entries in the org sidebar; they do not
+live on the "Authentication security" page. the verified membership is the two entries
+above.
+
+recorded rather than quietly fixed, because the correction is the useful part: a family
+shape recalled from memory read plausibly and was still wrong, and only the fetch settled
+it. that is the reason `rule.require.persist-domain-term-evidence` asks for the evidence
+and not merely the conclusion.
+
+## .rejected alternatives
+
+| candidate | verdict | why |
+|---|---|---|
+| `Authentication` | ✅ adopted | github's own word for the page; exactly one sense |
+| `Auth` | ❌ rejected | reads as **auth**orization as readily as **auth**entication |
+| `Security` | ❌ rejected | the parent sidebar section, not the page; too broad to distinguish a family |
+
+`Auth` fails `rule.forbid.ambiguous-labels`. this repo already ships an **authorization**
+resource — `DeclaredGithubOrgMemberPrivileges` — so `Auth` would be one term with two
+senses, in a codebase that holds both. spelled out, `Authentication` has one sense.
+
+`Auth` would also be **authored, not discovered**: github writes the word out in full, so
+the abbreviation is a coinage of ours, and a coinage cannot be recognized by a domain
+expert without a gloss.
+
+## .the peer segment, for contrast
+
+| segment | github's own use | provenance |
+|---|---|---|
+| `Actions` | the api path `/orgs/{org}/actions/...` AND the product name "GitHub Actions" | verified — live api reads + docs, 2026-08-03 |
+| `Authentication` | the page titled "Authentication security" | verified — docs, 2026-08-04 |
+
+both segments are discovered from a surface github itself publishes. the rule that produced
+them: **a category segment must be a word github uses for that family**, never a taxonomy we
+invent to tidy our own file tree.
+
+## .invariants
+
+- ⛔ a category segment that github does not itself use for the family = **blocker**
+  (it is authored, not discovered — `rule.require.domain-discovery-for-term-proposals`)
+- ⛔ `Auth` in any resource name = **blocker** (`rule.forbid.ambiguous-labels`; two senses
+  in a repo that holds both)
+- ✅ a NEW resource may adopt the `Authentication` segment only if its control lives on
+  github's "Authentication security" page — today that bounds it to the two entries above
+
+## .the one question still open
+
+whether github later moves a control ONTO that page. the family is verified as of
+2026-08-04; if a future resource's control appears there, it adopts this segment, and this
+file's family list is what to check against.
+
+## .see also
+
+- `rule.require.persist-domain-term-evidence` — the rule this file satisfies
+- `rule.require.domain-discovery-for-term-proposals` — discovery required before a proposal
+- `rule.forbid.ambiguous-labels` — the rule that rejected `Auth`
+- `def.domain-discovery` — discovery grounds in the real-world domain, never in a map

.agent/repo=.this/role=any/briefs/howto.diagnose-route-budget-shortfall.md

@@ -0,0 +1,77 @@
+# howto.diagnose-route-budget-shortfall
+
+## .what
+
+when a bhrain stone's peer reviewers are all at their budget cap and you then **edit the
+artifact**, the guard computes a fresh content hash, **no reviewer runs** (none has budget
+left), and the judge halts with:
+
+```
+j1: … --mechanism reviewed? … finished 0.7s ✗
+    reason: no review files found for hash 7cb36686
+```
+
+this is a **budget shortfall**, not a defect in your fix. the driver's own lever clears it.
+
+## .why it misleads
+
+the tree printed directly above that verdict shows every reviewer as:
+
+```
+├─ r1: repo-rules (l1, 7/7)
+│   ├─ exhausted 🌙, cached
+│   ├─ terminal — does not block higher levels
+│   ├─ 0 blockers ✓
+```
+
+so it reads as *"all eleven reviewers approved, zero blockers"* — and `exhausted 🌙 · terminal`
+is a legitimate, passable state elsewhere, which is exactly why it deceives here. those
+verdicts belong to the **previous** hash. against the current artifact there are no verdicts at
+all, which is what the judge reports.
+
+**a cached-verdict tree is evidence about a hash, never about the files now on disk.**
+
+## .the fix
+
+```sh
+rhx route.guard.budget --for review --add 2 --stone <stone>   # 7 → 9, every reviewer
+rhx route.stone.set --stone <stone> --as arrived              # they can now grade the new hash
+```
+
+do **not** revert your fix to chase the old hash. that discards real work to satisfy a
+constraint of the ledger.
+
+## .the deeper hazard this exposes
+
+the same condition produces a quieter problem long before the budget runs out: **if the
+artifact changes mid-run, some reviewers grade the old content and some the new.**
+
+observed on `5.3.verification`: a yield edit landed 7 minutes into a run, so r1–r8 graded the
+pre-edit artifact and r9–r11 the post-edit one. every one of the eleven reported zero.
+
+> **reviewers that disagree about which version they read are not a clean pass, even when
+> every one of them reports zero.**
+
+so a re-arrive was owed regardless of what the reviewers said.
+
+## .how to apply
+
+- **batch every artifact edit, then `--as arrived` once.** never edit while a run is in flight
+- when the judge says *"no review files found for hash …"*, extend budget and re-arrive
+- read a reviewer's `N/N` as *"cannot grade a new hash"*, not as *"finished"*
+- to confirm a round is hash-consistent, compare the artifact's mtime against the timestamp of
+  the round's **first** `.given` artifact
+
+## .is a budget extension "manufactured exhaustion"?
+
+no — and the distinction matters. manufactured exhaustion is budget **burned without genuine
+engagement**, to coast to the bottom of the ladder. a shortfall is budget **spent across rounds
+that each fixed a real defect**, where the final corrected state still deserves to be graded.
+
+the test: can you cite, per round, what was found and what changed? if yes, extend the budget.
+if no, the budget is not the problem.
+
+## .see also
+
+- `rule.always.converge-to-terminal` (bhrain/driver) — earned exhaustion demands a cited record
+- `rule.forbid.failhide` — why a cached-verdict tree read as a pass is the same defect class

.agent/repo=.this/role=any/briefs/howto.read-a-route-stone-outcome.md

@@ -0,0 +1,175 @@
+# howto.read-a-route-stone-outcome
+
+## .what
+
+after `rhx route.stone.set --stone <stone> --as arrived`, exactly one line tells you whether
+the stone passed — **the judge line**:
+
+```
+└─ judges
+    └─ j1: … --mechanism reviewed? … --allow-blockers 0 --allow-nitpicks 7
+        ├─ finished 1.5s ✓                                   ← passed
+```
+
+```
+        ├─ finished 1.2s ✗
+        └─ reason: blockers exceed threshold (4 > 0)          ← blocked
+```
+
+read that line. do not infer passage from any other signal.
+
+## .why — the three proxies that lie
+
+### 1. the exit code is not the verdict
+
+**an exit code of `0` appears on both a passed stone and a blocked one.** measured on the same
+stone, same session:
+
+| run | exit code | judge | stone |
+|---|---|---|---|
+| re-arrive for peer review | **0** | ✗ `blockers exceed threshold (4 > 0)` | **blocked** |
+| re-arrive after a fix | **2** | — `passage blocked` | blocked |
+| re-arrive to grade a new hash | **0** | ✓ | **passed** |
+
+so `exit 0` covers both outcomes and carries no verdict. a background-task notification that
+reports *"completed (exit code 0)"* means the command finished — never that the stone passed.
+
+### 2. the reviewer tree is not the verdict
+
+every reviewer can read `0 blockers ✓` while the stone is still blocked, because those verdicts
+may belong to a **previous content hash**. see `howto.diagnose-route-budget-shortfall`.
+
+### 3. output size and liveness are not the verdict
+
+a run's captured output can sit frozen mid-tree for minutes — that is a buffer artifact, not a
+dead run. an empty (`0`-byte) capture does signal a run that never started, but a **non-zero,
+frozen** capture is a live run. never re-run on the strength of a stalled tail: a duplicate run
+races the live one and manufactures malfunctions.
+
+## .how to apply
+
+1. to learn the verdict, read the **judge line** — `✓` or `✗` plus its `reason`
+2. to learn whether a round finished, glob the `.given` **artifacts**, never the console
+   capture:
+   ```sh
+   rhx globsafe --pattern '<route>/.reviews/peer/*<iteration>*' --long
+   ```
+3. treat exit code, tree contents, and output size as **liveness hints only**
+
+## .the general shape — a **false report**
+
+> the proxy is not the verdict. read the artifact.
+
+each of the three above is a cheap signal that correlates with passage most of the time, which
+is exactly what makes it dangerous — it is right often enough to earn trust, and wrong at the
+moment it matters.
+
+this class has a name: a **false report**.
+
+> **.what** = a report an instrument emits in its normal success shape, with full confidence,
+> whose content is wrong. the mark that separates it from every fail-star case: **no failure
+> occurred.**
+>
+> — `nheuron`, `.agent/repo=.this/role=any/briefs/domain.terms/term=false-report._.choice._.md`
+
+**term.kind** = noun. **forbidden synonyms:** `false negative`, `false zero`,
+`silent failure`, `flake`, `stale output` — each names a different concept, and each loses the
+one mark that defines this term.
+
+### the two discriminators — a case must fail neither
+
+| # | question | required answer |
+|---|---|---|
+| 1 | did the instrument fail? | **NO** |
+| 2 | is the content untrue? | **YES** |
+
+a false report is worse than an instrument that fails, because a failure announces itself and
+this does not.
+
+### the local instances, each checked against both discriminators
+
+| instrument | ordinary success shape | untrue how |
+|---|---|---|
+| `route.stone.set` exit code | `exit 0` | `0` on a stone with 4 blockers |
+| reviewer tree | `0 blockers ✓` ×11 | verdicts belonged to a stale content hash |
+| captured output size | non-zero, well-formed | a frozen buffer read as a dead run |
+| `grepsafe --glob` | `matches: 0`, exit 0 | pattern plainly present on 5 lines |
+| **a coverage comment** | ordinary prose, stated with confidence | vouches for coverage the code does not carry (`rule.forbid.unearned-coverage-claims`) |
+
+the fifth is the notable one: **the instrument is a human.** the same two discriminators hold —
+the author did not fail, and the content is untrue — so the term reaches past a tool to any
+instrument that reports, a person included.
+
+### the countermeasure
+
+**name one authoritative source and read it.** one authoritative source beats three plausible
+proxies. here that source is the judge line.
+
+**and when you must read a console capture, find its terminator line first.** these tree
+outputs stream, so a partial capture is well-formed and carries no mark of its own
+incompleteness — the header renders, the branches render, and the answer has yet to arrive. a
+tree with no terminator is **incomplete**, never **empty**:
+
+| skill | the terminator that carries the answer |
+|---|---|
+| `git.repo.get` | `└─ found: N files` |
+| `grepsafe` | `└─ matches: N` / `└─ results` |
+| `route.stone.set` | `└─ judges … finished Xs ✓ \| ✗` |
+
+> this is not itself a false report — see `.not-this` below.
+
+> **.note on reachability.** the citation above cannot be verified from a worktree today:
+> `nheuron` is not indexed by `git.repo.get`, and `globsafe` refuses a path outside the repo
+> root. that is a known factory defect. so the definition above is quoted verbatim from human
+> attestation — do not re-derive it from this file, and do not spend a search on the source
+> until that gap closes.
+
+## .not-this — cases the discriminators REFUSE
+
+the term stays sharp only when near misses are refused **out loud**. two specimens from this
+repo, both of which felt like fits, and one of which was mis-filed twice:
+
+### ❌ a partial stream read as a complete one
+
+a `git.repo.get` capture tailed mid-run showed only its header, and was reported as `0 files`.
+
+**fails discriminator 2** — the partial capture was TRUE, merely unfinished. the adjacent
+error, not this one.
+
+### ❌ a true report whose reader was misled BY THE INSTRUMENT NAME
+
+`git diff package.json` printed no output for a file that had changed. the change was
+**staged**, and `git diff` reads unstaged only.
+
+**fails discriminator 2** — `git diff` reported truthfully that no *unstaged* change existed.
+the untrue part was the reader's inference (*"no config changes"*), never the report's content.
+**discriminator 2 asks about the CONTENT, never about what a reader drew from it.**
+
+> ⚠️ this specimen was mis-filed **twice** — by the mechanic who found it, then again in the
+> report that relayed it. the reason is worth more than the case: a near miss that fails
+> **both** discriminators is easy to refuse, so a case that fails only **one** feels like a
+> fit — and this one exits 0 and prints its ordinary output besides.
+
+it also differs in **kind** from a precise message that one reader over-read. `git diff`'s
+NAME over-promises its scope — unstaged only, tracked only — so the wrong inference is induced
+**systematically**, rather than by one reader's carelessness.
+
+**so the countermeasure is not more care — it is a different instrument.** to learn whether a
+file changed at all, the authoritative instrument is `git status --short`.
+
+| you want to know | wrong instrument | authoritative instrument |
+|---|---|---|
+| did this file change at all? | `git diff <path>` | `git status --short` |
+| what changed, staged? | `git diff <path>` | `git diff --cached <path>` |
+| does an untracked file hold X? | `git diff <path>` | read the file |
+
+### the test this section encodes
+
+before you file a case as a false report, say the report's content **out loud in its own
+words**, then ask whether *that sentence* is false. if the false part only appears once you
+paraphrase it as a conclusion, the instrument was honest and the inference was yours.
+
+## .see also
+
+- `howto.diagnose-route-budget-shortfall` — why a clean reviewer tree can still be a blocked stone
+- `rule.forbid.unearned-coverage-claims` — the same defect class in prose: a signal read as proof