docs: изменения ландятся через ветку и PR, включая мейнтейнерские (#24)

Правило записано там, где было нарушено: за одну сессию пять коммитов ушли прямо в main,
последний — на двадцать один файл, на основании единожды сказанного «коммитом в main» про
однострочный релизный chore. Зелёный локальный make ci — предиктор, CI на пул-реквесте —
гейт, и изменение без обозримой единицы не ревьюится в принципе.

Ветка main защищена: прямых пушей не принимает, требует зелёный build-test и линейную
историю. Защита распространяется на администраторов — иначе она охраняла бы от всех, кроме
того аккаунта, который сюда и пушит.

Попутно: в AGENTS.md было «131 tests», сейчас 330.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: RSafargalin

AGENTS.md

@@ -8,14 +8,36 @@ breaking something invisible.
 ## Build and verify
 
 ```bash
-swift build && swift test          # 131 tests
+swift build && swift test          # 330 tests
 make ci                            # build + test + self-lint — run this before committing
 swift test --filter "<suite name>" # one suite
 ```
 
 `make lint` runs sextant on its own sources with `sextant-rules.json`. The tool is dogfooded:
 if a change makes `lint` noisy on this repository, that is a finding about the change.
 
+## How a change lands
+
+Every change goes through a branch and a pull request — maintainer changes included. `main` is
+protected: it takes no direct pushes, and a pull request merges only once CI is green on it.
+
+```bash
+git switch -c fix/what-it-fixes
+# … work, `make ci` …
+git push -u origin HEAD && gh pr create
+```
+
+The rule is written here because it was broken here. Five commits were pushed straight to `main`
+in one session, the last of them a change across twenty-one files, on the strength of a "commit
+straight to main" that had been said once about a one-line release chore. Nothing broke, and that
+is not the point: a green local `make ci` is a predictor, while CI on a pull request is a gate, and
+a twenty-one-file change with no reviewable unit is not reviewable in principle.
+
+The protection is what makes this a rule rather than a resolution. It applies to administrators
+too — otherwise it would guard against everyone except the account that actually pushes here. An
+emergency turns it off in the repository settings, deliberately and visibly, which is the whole
+difference from bypassing it by habit.
+
 ## Layout
 
 - `Sources/SextantCore` — all logic, testable. Anything worth a test lives here.

CONTRIBUTING.md

@@ -21,6 +21,18 @@ The semantic layer additionally needs `libIndexStore.dylib`, which sextant locat
 what to do about it. The syntactic commands (`map`, `api`, `search`, `lint`, `changed`) work
 without any of it.
 
+## Every change goes through a pull request
+
+Including the maintainer's. `main` is protected: it accepts no direct pushes, and a pull request
+merges only once CI is green on it. Administrators are not exempt — a gate that the account doing
+the pushing can walk around is a note, not a gate.
+
+```bash
+git switch -c fix/what-it-fixes
+# … work …
+git push -u origin HEAD && gh pr create
+```
+
 ## Before you open a pull request
 
 ```bash

CONTRIBUTING.ru.md

@@ -21,6 +21,18 @@ swift build && swift test
 и что с этим делать. Синтаксические команды (`map`, `api`, `search`, `lint`, `changed`)
 работают и без всего этого.
 
+## Любое изменение приходит через пул-реквест
+
+В том числе мейнтейнерское. Ветка `main` защищена: прямых пушей не принимает, а пул-реквест
+вливается только с зелёным CI на нём. Администраторы не исключение — гейт, который аккаунт,
+делающий пуши, может обойти, это не гейт, а памятка.
+
+```bash
+git switch -c fix/what-it-fixes
+# … работа …
+git push -u origin HEAD && gh pr create
+```
+
 ## Перед пул-реквестом
 
 ```bash