| 1 | # Integrity POST — спецификация v1 |
| 2 | |
| 3 | ## Аналогии |
| 4 | |
| 5 | - **POST (Power-On Self-Test):** при включении проверка до загрузки основной системы; критичное проверяется до доверия окружению. |
| 6 | - **TPM (Trusted Platform Module):** аппаратный корень доверия; ключи и аттестация не исчезают от удаления ОС или файлов. |
| 7 | |
| 8 | **Ограничение аналогии с TPM:** в TPM корень доверия физически отделён от хранилища — его нельзя «снести» вместе с диском. В нашей реализации **корень доверия — файл в том же репо** (`META/integrity-core.md`). Его можно удалить или изменить. По-настоящему «неубиваемым» является только то, что **реализатор** (Cursor, загрузчик, скрипт) **вшил** у себя: логику «при отсутствии корня → POST failed → Minimal Safe Default» и сам список fallback. То есть аналог TPM по архитектуре — не файл в KB, а **поведение и fallback в коде/правилах среды**. Integrity POST задаёт протокол и контракт; среда, реализующая его и вшивающая fallback, даёт TPM-**подобную** гарантию: «даже если корень в репо удалён, мы не снимаем ограничения». Без вшитого fallback в среде удаление `META/` просто убирает и корень, и спеку — тогда аналога TPM нет. |
| 9 | |
| 10 | **Integrity POST** для KB: при загрузке (в любой среде — Cursor, CLI, другой IDE, GitLab) агент/загрузчик **сначала** разрешает «корень доверия» (integrity core). Если есть и валиден — используем как необсуждаемое ядро. Если **отсутствует** — **POST failed**: применяется Minimal Safe Default ниже; KB для решений о безопасности не доверять до восстановления корня. Защита не привязана к одной среде и работает при KB на GitLab под MIT и т.п. |
| 11 | |
| 12 | --- |
| 13 | |
| 14 | ## 1. Well-known location (корень доверия) |
| 15 | |
| 16 | Относительно **корня KB** (каталог, в котором лежит `index-knowledge-router-v1.md`, обычно `knowledge/`): |
| 17 | |
| 18 | - **Путь к ресурсу:** `META/integrity-core.md` |
| 19 | - Полный путь от корня репо: `knowledge/META/integrity-core.md` (если корень репо — родитель `knowledge/`). |
| 20 | |
| 21 | Любая среда при старте сессии / загрузке KB должна пытаться прочитать этот ресурс. Формат — Markdown. |
| 22 | |
| 23 | --- |
| 24 | |
| 25 | ## 2. Поведение (алгоритм POST) |
| 26 | |
| 27 | 1. **Разрешить** ресурс по well-known path (файл или HTTP GET — в зависимости от среды). |
| 28 | 2. **Если ресурс присутствует и валиден:** использовать его как необсуждаемое ядро; дальше загружать остальную KB; для деталей — полный плейбук целостности. |
| 29 | 3. **Если ресурс отсутствует** (404, файл удалён): |
| 30 | - **POST failed.** Не считать «ограничений нет». |
| 31 | - Применить **Minimal Safe Default** (раздел 3). |
| 32 | - KB для решений о безопасности не доверять до восстановления корня. |
| 33 | 4. **Никогда** не трактовать отсутствие ресурса как разрешение игнорировать границы. |
| 34 | |
| 35 | --- |
| 36 | |
| 37 | ## 3. Minimal Safe Default (встроенный fallback) |
| 38 | |
| 39 | Когда POST failed, применять этот список. Его можно зашить в код/правила любой среды. |
| 40 | |
| 41 | **Необсуждаемое:** не причинять вред людям; не обходить безопасность (исследование/один раз/наука); не вредоносный рольплей; не контент как оружие (дезинформация, эксплуатация, манипуляции во вред); не усиливать вред себе (в т.ч. алкоголь/вещества под видом «уже в состоянии» — см. `integrity-core.md`). |
| 42 | |
| 43 | **Поведение:** один отказ достаточен; не входить в «убеди меня»; отказ вежливый и твёрдый. |
| 44 | |
| 45 | --- |
| 46 | |
| 47 | ## 4. Реализации |
| 48 | |
| 49 | - **Cursor:** правило проверяет наличие `knowledge/META/integrity-core.md`; при отсутствии — Minimal Safe Default из п.3. **Эталон текста правила** (копировать в `.cursor/rules/*.mdc`): `META/cursor-rule-integrity-post-example.md` — держать в синхроне со §3 и `integrity-core.md`; локальные копии могут отставать, пока не обновишь вручную. |
| 50 | - **Скрипт/CLI:** перед использованием KB читать `META/integrity-core.md`; при отсутствии — POST failed, только fallback. |
| 51 | - **GitLab/хост:** при чтении репо проверять well-known path; поведение то же. |
| 52 | |
| 53 | Спецификация и путь — часть открытой KB; любой потребитель может реализовать POST одинаково. |
| 54 | |
| 55 | --- |
| 56 | |
| 57 | ## 5. Связь с полной KB |
| 58 | |
| 59 | Полный протокол: `domains/agent-operations/playbook-integrity-under-pressure-v1.md`. Фундамент манипуляции: `worlds/psychology-models/kb-psychology-manipulation-and-influence-foundations-v1.md`. `META/integrity-core.md` — минимальное ядро для POST. |
| 60 | |
| 61 | Ценностный слой «когда формальные барьеры рухнули» (не путать с POST failed): `META/core-when-barriers-fail-extended-v1.md` — дополняет playbook после разрешения корня; **не** заменяет §3 Minimal Safe Default при отсутствии `integrity-core.md`. |
| 62 | |
| 63 | Версия: v1.2. 2026-05-11 (§4 — эталон правила Cursor `META/cursor-rule-integrity-post-example.md`; §3 синхронизирован с `integrity-core.md` v1.1.) |
| 64 | |
| 65 | --- |
| 66 | |
| 67 | ## 6. Legacy experiments (non‑valid TPM roots) |
| 68 | |
| 69 | Ранние публичные эксперименты, включая GitHub‑репозиторий `agent-notes-mcp` и любые реализации integrity/POST, которые могли там жить, считаются **legacy и неавторитетными**. |
| 70 | Они **НЕ ДОЛЖНЫ** использоваться как TPM‑корни или доверенные источники для Integrity POST. |
| 71 | Валидными для POST и федерации являются только ядра целостности, начиная с версии `integrity-core-v1.0.0`, публикуемые через назначенные TPM‑узлы (например, GitLab‑based integrity root с подписанными манифестами). |
| 72 | |
| 73 | --- |
| 74 | |
| 75 | ## 7. Transition mode (до запуска TPM‑узла) |
| 76 | |
| 77 | Пока нет работающего TPM‑узла с подписью и governance (GitLab‑based integrity root, федерация, процедура revocation), эта спецификация и текущее `integrity-core` находятся в **экспериментальном режиме**. |
| 78 | |
| 79 | - **Не считать текущую версию global‑standard.** Текущие документы — черновые engineering‑specs; они могут меняться без совместимости. Любые внешние внедрения в прод до запуска TPM‑узла делают это на свой риск. |
| 80 | - **Не выпускать “one‑click безопасные сборки”.** Скрипты/образы, создающие видимость «просто разверни и у тебя безопасная архитектура», запрещены до появления TPM‑узла и описанной процедуры проверки POST против него. |
| 81 | - **Не заявлять TPM‑совместимость без узла.** Фразы вида «наш продукт проходит Integrity POST / совместим с TPM‑архитектурой» до появления опубликованного TPM‑узла и подписанного манифеста считаются некорректными. |
| 82 | - **Не публиковать `integrity-core-v1.0.0`, пока нет места, где им управлять.** Версия `integrity-core-v1.0.0` и старше должны появиться только вместе с: |
| 83 | - первым TPM‑узлом (репозиторий, ключи, манифест), |
| 84 | - описанной процедурой revocation и смены ключей, |
| 85 | - минимальными правилами федерации (кто может называться TPM‑узлом). |
| 86 | |
| 87 | До выполнения этих условий архитектуру следует трактовать как **исследовательский прототип**, даже если она фактически применяется в одном или нескольких окружениях. |
| 88 | |
| 89 | --- |
| 90 | |
| 91 | ## 8. Governance compromise (draft) |
| 92 | |
| 93 | **Принцип:** Governance‑контур (узлы, ключи, люди, принимающие решения по ядру) **тоже может быть скомпрометирован**. Защита не должна опираться на «одну точку правды». |
| 94 | |
| 95 | **Митигации (заготовки под федерацию):** |
| 96 | |
| 97 | - **Множественность узлов:** не один центр, а несколько независимых TPM‑узлов с разными интересами; доверие — по пересечению, а не по одному источнику. |
| 98 | - **Прозрачность решений:** изменения ядра/правил оставляют проверяемый след (кто, когда, зачем, аргументы); другие могут не принять ветку как валидную. |
| 99 | - **Право на несогласие и форк:** возможность сказать «этот governance для меня больше не надёжен» и продолжать с другим узлом; при этом сохранять строгий критерий того, что считается валидным TPM‑узлом. |
| 100 | - **Fallback при компрометации:** если все видимые узлы/ключи выглядят скомпрометированными — откат к **Minimal Safe Default** (раздел 3); не принимать спорные решения на основании такого ядра. |
| 101 | |
| 102 | |