/hooks/` | **пусто** — принуждения нет | | `SOUL.md` сборки | про обезличивание, периметр и заказчика — **ни слова** | Отсюда формулировка «у нас обезличивание до отправки в модель» сегодня не подтверждается: правило записано в скилле, но срабатывает по триггеру и зависит от того, вспомнит ли модель его применить. -### 1. Поставить `ailab/anonymization-check` в профиль при установке и обновлении +### 1. Один канон процедуры + скилл в сборку и в профиль -- Что: категория `skills/ailab/*` должна попадать в установленный профиль так же, как остальные скиллы; сейчас в профиле её нет. -- Где: механизм установки скиллов (bundle → `~/hermes/skills`), `setup.ps1`, проверка состава после установки. -- Критерий приёмки: после чистой установки и после обновления `ls <профиль>/skills/ailab/anonymization-check` даёт `SKILL.md` и `scripts/scan_open_pii.py`; скилл виден в индексе скиллов агента. -- Причина: скилл, лежащий только в сборке, в работе не участвует. Это главное расхождение между «заявлено» и «есть». +Проблема: одна и та же процедура описана в трёх местах — `docx/references/anonymization.md`, `ailab/anonymization-check`, `engineering/ai-data-perimeter`. Три редакции разъедутся. -### 2. Правило порядка в `SOUL.md` — и в сборке, и в профиле +Иерархия, которую фиксируем: -Добавить раздел (формулировка для вставки): +| Место | Роль | +|---|---| +| `engineering/ai-data-perimeter` | **канон**: правила периметра, проверка «соблюдается ли», порядок работы с документом заказчика, чек-лист и нормы (`references/perimeter-rules.md`) | +| `docx/references/anonymization.md` | техника правки DOCX-пакета + `scripts/scan_open_pii.py` — исполнение под каноном | +| `ailab/anonymization-check` | свести к тонкой ссылке на канон либо убрать; сейчас это третья редакция того же правила | + +- Что: положить `engineering/ai-data-perimeter` в сборку (`dist/vasily/skills/engineering/`), проверить, что категории `engineering` и `ailab` доезжают до установленного профиля при установке и обновлении. +- Критерий приёмки: после чистой установки в профиле есть `skills/engineering/ai-data-perimeter/SKILL.md` + `references/perimeter-rules.md`; третьей редакции правила в профиле нет. +- Причина: скилл, лежащий только в профиле разработчика или только в сборке, в работе не участвует. Правило в SOUL.md на него ссылается — битая ссылка хуже отсутствия ссылки. + +### 2. Правило порядка в `SOUL.md` — сведено с `ai-data-perimeter` + +Сверено с каноном. SOUL не переписывает светофор и контуры (они в `references/perimeter-rules.md`), а закрывает то, что действует до первого чтения файла, и не противоречит трём правилам скилла: аудит вместо согласия (Правило 0), декларация ≠ контроль (Правило 1), агент сам канал (Правило 2). + +Расхождения первой редакции, исправленные при сверке: + +| Было в первой редакции | Что говорит скилл | Исправлено | +|---|---|---| +| не покрывала запрос «подтверди, что соблюдается» | Правило 0: это аудит по двум слоям, а не согласие | добавлены оба слоя и запрет ответа по одному | +| «не открывается, пока не решено» — без статуса данных | документ до классификации считается красным | добавлен статус «считается красным» | +| правило жило само по себе | процедура — в скилле, SOUL задаёт только порядок | добавлена ссылка на канон, дублирование убрано | +| не было стоп-сигнала | «маркеров нет» = скорее всего оригинал; ноль находок ≠ чисто | добавлено | +| не сказано, кто обезличивает | обезличивание — работа человека, спорное агент не решает | добавлено | + +Формулировка для вставки в `SOUL.md` (в сборку и в рабочий профиль): ``` ## Периметр данных -- Документ заказчика (ТЗ, договор, переписка, форма, ИД) не открывается инструментами - чтения, пока не решено, откуда берётся обезличенная копия: её даёт пользователь - или агент делает копию и читает только её. -- Читается и разбирается только копия. Оригинал не открывать «чтобы посмотреть объект». -- Таблица соответствия токенов и реальных значений не читается никогда — она и есть +Правила, светофор и процедура — скилл `ai-data-perimeter`. Здесь — то, что +действует до первого чтения файла. + +- Документ заказчика (ТЗ, договор, переписка, форма, ИД) до классификации считается + красным. Инструментами чтения он не открывается, пока не решено, откуда берётся + обезличенная копия: её даёт владелец или агент делает копию и читает только её. +- Оригинал не открывать «чтобы посмотреть объект». Таблица соответствия токенов и + реальных значений не читается никогда — она и есть закрываемые данные. +- Обезличивание — работа человека по его таблице соответствий. Агент делает копию по + технике `docx/anonymization.md`, только если об этом попросили, и не решает за + человека, что закрывать в спорных случаях. +- Проверка полноты: `python scripts/scan_open_pii.py "<файл>" --summary`. Агент читает + счётчики; полный отчёт со значениями — человеку, потому что находки и есть закрываемые данные. -- Отчёт по проверке полноты обезличивания агент читает в `--summary` (счётчики); - полный отчёт со значениями — человеку. -- Формулировка «документ обезличен» запрещена. Правильно: «шаблоны нашли N, вот что - осталось открытым». +- «Маркеров нет» — единственный стоп-сигнал: скорее всего, это оригинал. Ноль находок + ≠ «документ чист». Формулировка: «шаблоны нашли N, открыто: …». +- «Документ обезличен» и «у нас это соблюдается» без проверки файлов — запрещены. + На просьбу подтвердить меру проверяются два слоя: организационный (приказ, + регламент, журнал) и технический (SOUL, установленные скиллы, hooks). Ответ по + одному слою — ошибка в обе стороны. +- Если механизма принуждения нет — говорить это прямо: правило в промпте срабатывает + по триггеру, а не по факту. ``` - Где: `SOUL.md` в сборке (приезжает всем получателям) + `profiles/
/SOUL.md` в рабочем профиле (иначе правило не действует у того, кто уже установлен). - Критерий приёмки: правило есть в обоих файлах; на контрольной задаче («прочитай ТЗ и найди требования») агент сначала спрашивает про обезличенную копию, а не открывает оригинал. -- Ограничение, которое надо написать в релиз-ноутах честно: это по-прежнему правило в промпте. Принуждение — только через hook/шлюз (см. п. 4). +- Оговорка для релиз-ноутов, честно: это по-прежнему правило в промпте. Принуждение — только hook/шлюз (п. 4). ### 3. Журнал применения ИИ — с записями, а не пустая форма -- Что: форма журнала + процедура, при которой запись появляется сама, а не заполняется задним числом «для проверки». +- Что: форма журнала + процедура, при которой запись появляется по факту задачи, а не заполняется задним числом «для проверки». - Минимальный состав записи: дата · задача · сервис · контур · категория данных (🟢/🟡/🔴) · обезличивание выполнено (да/нет, чем подтверждено) · результат перепроверен человеком · кто. - Куда писать: файл журнала в рабочей папке проекта (CSV/MD), запись — по факту задачи; при инциденте — отдельной строкой в журнал инцидентов. - Критерий приёмки: после пилота на одной команде в журнале есть не менее 5 реальных записей, каждая с категорией данных и отметкой обезличивания; повторяющаяся операция закрывается одной строкой, без ручного заполнения таблицы каждый раз. @@ -71,7 +107,7 @@ ## Как выпускается -1. Пункты 1–3 закрыты и проверены на чистой установке, а не только в рабочем профиле. +1. Состав закрыт Олегом; пункты 1–3 проверены на чистой установке, а не только в рабочем профиле. 2. `distribution.yaml` → `version: 1.7.6`; `README.md` → «Текущая версия: 1.7.6». 3. Коммит с сообщением `v1.7.6: <главное изменение>`. 4. Сборка bundle, проверка по разделу «Проверка перед передачей» в README.